첫 부분엔 개발자로서의 열정을 강조해서 구체적인 내용은 없는 정신론적인 책인 줄 알았지만, 뒷부분에는 실용적인 부분이 꽤나 있어서 기억나는 부분 위주로 정리를 하려고 한다.
TDD
일단 첫 번째로 기억이 남는 부분은 TDD에 관한 이야기이다. 필자는 TDD를 이용할 것을 강조한다. TDD를 이용하면 QA 시간이 줄어들고, 효율적으로 개발을 할 수 있다고 한다.
나도 최근에 TDD를 이용해 보았는데 나 같은 경우에는 테스트 도구에 익숙하지 않아서 그런가, 테스트를 작성하는 데 꽤 많은 시간이 들었다. 테스트를 작성하고 나서도 테스트 코드에 확신이 없어서 내가 원하는 바를 테스트하고 있는 것이 맞는가? 하는 의문이 들었다. 리팩토링을 할 때마다 함수의 내용이 변경되니까 테스트를 계속해서 변경해야 하는 점도 힘들었다. 그래서 개발 일정이 급한 경우에는 테스트 코드를 생략하고 나중에 시간이 있을 때 거꾸로 테스트 코드를 짜는 식으로 진행하곤 했다.
하지만 테스트 코드를 짜는 것이 좋다는 생각에는 동의한다. 문제가 발생하지 않으면 다행이지만, 문제가 발생한 경우 콘솔을 사용하여 계속해서 값을 넣어 봐야 했기 때문이다. 다른 사람들은 테스트 코드를 어떻게 짜는지, 그리고 테스트 코드는 어떤 식으로 짜는 게 좋은지에 대한 공부가 필요해 보인다. 테스트 주도 개발이라는 책을 읽고, 저번 syncSwift에서 들었던 강의를 바탕으로 테스트 코드에 대한 개념을 정리해야겠다. 이 책에서는 TDD의 중요성을 강조하기만 하고 구체적인 실현 방안이 없어서 조금 아쉬웠다. 테스트 코드의 도입을 반대하는 동료를 설득하기라는 주제로 글을 써도 즐거울 것 같다.
개발 도서
이 책에서는 독서를 통한 자기 계발을 강조하면서 개발 도서를
-
특정 기술에 대한 서적(특정 언어나 소프트웨어 이용 방법)
-
특정 개념에 대한 서적(새로운 개념이나 패러다임, ex - 테스트 주도 개발, 도메인 기반 개발, 객체 지향 설계)
-
행동 양식에 대한 서적(소프트웨어 개발 이외의 프로페셔널에 관한 책)
-
혁명적 서적(일하는 방식이나 개인의 가치관을 바꾸는 책)
의 4가지로 분류한다. 필자는 혁명적인 서적부터 읽기를 권하는데 나 또한 동의한다. 특정 기술은 계속해서 변화하므로 큰 틀을 먼저 공부하고 기술을 필요할 때마다 공부하는 것이 좋다고 생각한다. 커리어를 위해서라면 4-2/3-1의 순서로 권하지만 나는 개인적으로 행동 양식에 대한 서적은 추상적인 가치관에 대해 이야기하는 것이라고 생각해서 실용도가 좀 떨어진다고 생각한다. 한 두 권 정도는 괜찮지만, 여러 권을 읽을 필요는 없다고 생각한다. 소프트웨어 장인 정신은 3번 행동 양식에 대한 서적에 속한다.
혁명적 서적의 추천 도서는 다음과 같다.
-
실용주의 프로그래머 (1999년, 앤드류 헌트 Andrew Hunt, 데이비드 토마스 David Thomas 저)
-
The Mythical Man-Month (1975년, 프레드릭 브룩스 Frederick Brooks 저)
-
디자인 패턴(GoF) (1994년, 에리히 감마, Erich Gamma외 4인 제)
-
테스트 주도 개발 (2002년, 켄트 백 Kent Beck 저)
-
익스트림 프로그래밍 (1999년, 켄트 백 저)
-
클린 코더 (2011년, 로버트 C. 마틴 저)
-
소프트웨어 장인정신 (2001년, 피트 맥브린 저)
-
리펙토링(1999년, 마틴 파울러 Martin Fowler외 5인 저)
이 책에서는 펫 프로젝트의 중요성을 강조하기도 한다. 아마 토이 프로젝트와 비슷한 개념 같아 보인다. 본인이 흥미 있는 분야에, 시간 제약과 기술적 제약 없이 프로젝트를 체험해 볼 수 있는 기회이기 때문이다. 펫 프로젝트 관련해서는 구체적인 지침을 적어 주어서 체크리스트로 이용하면 될 듯하다.
-
프로젝트 아이디어 찾기
-
기능 상세화
-
백로그에 할 일 정리
-
작업 분할
-
우선순위 생각
-
대략적인 일정 추산
-
사용자 스토리 작성
-
그 외의 것들
-
테스트
-
애플리케이션 배포(deploy)
-
버전 컨트롤
-
지속적인 통합
-
사용성
-
사용자 인터페이스
-
코드 베이스
-
설계
-
데이터베이스
일다 펫 프로젝트의 중요한 점은 재미있어야 한다는 것이다. 아이디어는 이미 갖고 있으니 펫 프로젝트를 통해 프로그램을 만드는 일도 시작해 볼 생각이다.
채용
채용에 대해 써 놓은 부분도 인상 깊었다. 나는 구직자의 입장이기 때문에 구직자가 고려해야 할 사항에 관해서 관심이 갔다.
- 관리층이 개발자를 신뢰하는지를 확인하기
면접관이 실무 개발자들이 아니라 관리자, 아키텍트, 팀 리더들로만 이루어져 있다면 고위 직급들에 의해서 모든 결정들이 이루어지는 회사일 수 있다.
- 다단계 면접이 아니라 원샷 면접
원샷 면접이라면 지원자들을 확인할 시간이 없을 수가 있다. 다단계 면접이라면 지원자들의 서로 다른 측면을 보려는 것이다. 프로페셔널을 채용하는 데 진지하다는 의미이다.
- 면접관의 질문을 분석하면 대개 면접관이 중요하게 생각하는 것을 반영한다.
주어진 질문지를 읽기만 하고 짧은 질문만 내놓는다면 그 면접관은 새로운 아이디어를 듣거나 논쟁하고 싶지 않다는 이야기이다. 회사 분위기가 폐쇄적일 수 있다. 현실 세계나 구체적인 문제에 관해서 열린 대화를 하는 것이 좋다.
지원자도 면접에서 회사에 대해 정보를 얻을 수 있어야 회사에 오래 다닐 수 있다고 생각하기 때문에, 이러한 지침들은 매우 유용했다. 또한 채용 공고를 보고 회사에 대한 정보를 얻을 수 있다는 사실도 굉장히 흥미로웠다.
이 책을 읽고 무작정 아무 회사에 들어가기보다는 내가 원하는 커리어를 염두에 두고, 차근히 준비해서 나의 최선을 다하고 싶다는 열망이 커졌다. 회사에 들어가서 같은 열정을 가진 사람들끼리 함께 동기부여받고 함께 성장해 나가보고 싶다. 이를 위해서는 내가 원하는 커리어를 명확하게 설정하는 것이 좋겠다는 생각이 들었다.
