woniper

개발자로써 내가 중요하게 생각하는 것, 기초 예외 테스트 협업 본문

이야기

개발자로써 내가 중요하게 생각하는 것, 기초 예외 테스트 협업

woniper1 2015. 5. 2. 19:26

요즘 개발 공부하면서 중요하다고(개발자로써) 생각드는 몇 가지를 정리한다.


기초

  개발뿐 아니라 어떤 분야도 마찬가지겠지만 특히나 기술로 먹고 사는 사람에게는 기초는 정말 중요하다고 생각한다. 개발 분야도 여러 분야가 있지만 기초의 범위는 거의 비슷한거 같다. 내가 생각되는 개발의 기초는 언어, 알고리즘, 자료구조, 객체지향이다. 사람마다 기초의 범위는 모두 틀리겠지만 적어도 내가 생각하는 범위는 이렇다. 그래서 내가 기초가 정말 중요하다고 생각한 이후로는 최신 기술에 휘둘리지 않고, 기초를 충실히 공부하고 있다고 생각한다. 물론 최신 기술의 흐름은 파악하고 있다. 지금은 언어와 객체지향을 중심으로 공부를 하는데, 나는 올해로 3년차 개발자가 되었는데, 처음부터 스프링이라는 기술을 사용해 웹 개발을 했는데 스프링이라는 기술 자체는 객체지향과 디자인패턴에 덩어리라고 생각해도 될 정도로 객체지향이 중요하다. 결과적으로 디자인패턴도 객체지향을 패턴화 시킨게 디자인패턴인 만큼 객체지향이 스프링을 잘 이해하기 위한 기초가 되는것이고 디자인패턴을 잘 이해하기 위한 기초가 되는것이다. 뿐만 아니라 스프링과 디자인 패턴을 떠나서 객체지향은 개발에 있어서 정말 중요한 부분이다.

  나는 아직도 기초가 너무 부족하다고 생각하는데 이유는 알고리즘과 자료구조를 잘 모른다. 알고리즘과 자료구조는 모든 대학 컴공과는 필수로 수강해야 하는 과목일 정도로 중요하다.


예외

  예외라는 단어를 쓰면서 “사용자”라는 단어도 같이 생각 났다.

서비스를 만든다는 것은 결국 사용자를 잘 파악하고 사용자가 편하게 사용하기 위한 서비스를 만드는 것인데, 예외라는 것은 개발을 하다가 예외 상황을 만났을때 그 예외를 어떻게 잘 처리하냐라고 생각한다. 예를 들어서 사용자가 회원가입을 하다가 서버에서 회원가입을 처리하는 작업을 수행하다가 DB서버와 연결이 끊어지면서 에러가 난 경우 사용자에게 아무런 응답도 없이 페이지가 멈춰있다거나, 다른 페이지로 이동하는 것은 바람직한 예외처리가 아니다. 이 경우에는 사용자에게 서버에서 에러가 났다고 알려주는 편이 더 좋은 방법이다. 이 처럼 예외는 개발자가 어느정도 예상할 수 있는 상황 처리를 말하는데 이를 잘 처리 해야 좋은 코드 더 나아가 좋은 서비스가 만들어 진다고 생각된다. 개발적으로 예외 상황은 놓치기 쉽고 처리하기 귀찮은 부분일 수 있지만, 사용자 편의상 반드시 놓치지 말아야하는 영역이라고 생각한다. 놓치기 쉽고 귀찮은 부분 일 수 있기 때문에 TDD에서 중요한 것은 예외 상황을 먼저 처리하고 정상적인 처리를 하라는 규칙이 있을 정도다.


테스트

  완벽한 프로그램은 없다. 프로그램에 있어서 버그는 항상 생기고 완벽하게 수정하기 보다는 보완하는거라 생각하고 지속적으로 프로그램을 가꾸어 나가야된다. 그리고 변경되지 않는 프로그램은 없다. 어디선가 본적이 있는데 하나의 버그를 수정하면 평균적으로 3개의 또 다른 버그가 생긴다고 한다. 이 말은 수정된 소스에 의존되어 있는 코드에서 또 다른 버그가 생긴다는 말이다. 이런 문제가 있기 때문에 테스트가 중요하다고 생각된다. 버그를 잡기 위해 코드를 수정하고 또 다른 버그를 생기지 않게하고 기능이 변경되거나, 추가 될 때를 대비해서 테스트가 필요하다. 그 부분에서 버그가 있는지, 그 기능이 잘 동작하는지 확인하기 위해서 말이다.

정확히 말하면 테스트라기 보다 테스트 코드를 작성하는게 중요하다. 물론 테스트를 하기 위해 테스트 코드를 작성하는거다. 원래 흔히 생각하는 테스트는 QA 팀에서 테스트를 수행하고 버그가 생기면 개발자에게 알려주고 수정하고, 이를 반복하는거지만 테스트 코드를 작성한다는 것은 내가 수정하고 추가된 소스를 검증하기 위한 코드인 것이다. 이는 정말 많은 장점을 주는데 내가 작성한 코드를 확신 할 수 있고, 작성한 코드를 변경하므로 어디에서 또 다른 버그가 생겼는지 빠르고 쉽게 파악 할 수 있기 때문에 테스트 코드가 중요하다. 그리고 테스트 코드를 작성하면 개발 자체가 느려진다고 생각하지만 나중을 생각하면 테스트 코드를 작성하는게 나중에는 오히려 시간을 버는 작업이다.


협업

  사람 관계에서 중요한 것은 대화라고 생각한다. 조금 다른 이야기지만, it가 발전하면서 전화, 문자, 요즘 흔히하는 카카오톡 같은 사람을 대면하지 않고 이야기 하는 방법이 정말 많아졌다. 이게 나쁘다는게 아니라 나는 가끔 얼굴을 보지 않고 문자로 서로 감정이나 하고자하는 말을 이해하는데 오해가 생길 수 있다는걸 느낀다. 개발 과정에서도 마찬가지로 개발자와 개발자 또는 개발자와 기획자, 디자이너 심지어 고객과 소통을 해야 할 경우가 있는데, 이처럼 여러 분야에 여러 사람과 대화를 하면서 짧은 시간동안 서로의 생각을 모두 이해하기란 쉽지 않다. 소프트웨어 공학에서는 고객과 대화를 통해 기능을 산출해 내는 것을 사용자 요구분석이라고도 하는데, 특히 개발자들이 개발만 관심을 갖기 바쁘지 사람간에 소통을 잘 못하는 경우가 많다고 생각한다. 나 또한 그렇고...

하지만 약 2년 이상 현업에서 일을하면서 상대방이 하고자 하는 말을 이해하고 소통하고 목표하는 바를 같이 바라보는 것이 얼마나 중요한지 느낀다. 하지만 말 만큼 쉽지 않는 부분이다. 총 개발 기간이 3개월이라고 봤을때 디자인, 개발, 테스트, 배포 이런 여러 과정 중에 모든 영역을 의존(?)하는 것이 커뮤니케이션이다. 근데 할 일이 많을 수록 짧은 시간에 상대방에 의견을 빠르게 이해하고 수행하기란 어렵다. 어떻게 협업 능력을 키우냐는 정확히 모르겠지만 중요하다는 것은 알았다. 앞서 말한 3가지는 꾸준한 개발 공부로 어느정도 해결 될 수 있다고 보지만 협업은 오로지 경험을 통해서 성장하는 것 같다. 

어디까지나 지금 내 생각...

Comments