트위터에서 신간 소식을 보고 마치 게임 캐릭터의 능력치 정보 창과 같은 책 커버 디자인이 흥미롭다는 얘기를 회사 점심시간에 꺼냈다가, 선뜻 주문해주셔서 회사 서재에 이 책이 한 권 생겼다.
글을 정리하기 전 써보는 간단한 후기는...
1. 당연한 말의 지분이 생각보다 높다. (당연한 말이지만, 이라는 수식을 굉장히 자주 사용한다.) 사실 개인적으로는 당연한 말이더라도 그 말을 그럼에도 해야하는 이유나 목적이 분명하게 설명될 경우 아무 문제가 되지 않는다고 생각한다. 그런데 이 책은 당연한 말을, 그 말이 당연한 이유만 붙여 설명할 뿐이다.
2. 제목에 충실하게, 글이 굉장히 넓고 얕다. 술술 읽으며 시니어 개발자는 이런 생각을 하는구나, 읽기 위해 이 책을 펴는 것이 가장 적합하다.
지은이가 제시하는 개발자의 역량은 다음과 같은 키워드로 정리된다.
- 구현 기술
- 코드 이해 역량
- 아키텍처 설계 역량
- 업무 관리 역량
- 글쓰기와 발표 역량
- 리더/팔로워로서의 협업 역량
이를 중심으로 책을 읽으며 2년차 개발자로서 지난 날을 돌아보고, 현재와 앞으로 할 일을 정리해보는 시간을 갖기 위해 책을 읽어봤다. 이 책은 읽고 요약하기 보단 나중에 다시 한 번 읽고 싶을 만한 문장을 남겨놓는 쪽으로 정리를 했다.
구현 기술
개발자가 얼마나 구현 기술을 활용할 수 있는가?
구현 기술의 적용
어떤 기술을 도입할 때 보수적으로 고민하면서 고려해야할 것들이 있다.
- 신뢰왇 동료
- 회사 내에서 동료, 리더의 신뢰를 얻은 후 기술 도입을 주장해야 한다.- 혼자서 어떤 기술을 새로 도입하고, 기존의 코드를 바꿀 수는 없다.
- 타당성
- 특정 기술을 적용하려는 타당한 이유를 제시할 수 있어야 한다. - 점진적 적용
- 동작하는 서비스, 시스템에 새 구현 기술을 도입할 때에는 점진적으로 적용해야 한다. - 시장 상황
- 도입하려는 기술을 능숙하게 사용할 수 있는 인력을 충분히 구할 수 있어야 한다.
사실 내가 쓰는 크로스 플랫폼 모바일 앱의 기술이 굉장히 마이너해서, 이 기술을 사용하는 회사를 만나기는 커녕 내 이력서를 통해 그 프레임워크의 이름을 처음 들어봤다는 사람들을 훨씬 많이 보게 된다. (사실상 이전 회사에서 1년 정도 썼고, 여러 플러그인도 써봤지만 이를 필요로 하는 회사가 없으니 내 이력서에서는 그냥 분량을 채우는 역할만 하게 된 것이다.)
유지 보수와 개발 비용
어떻게 유지 보수하는 비용을 줄일 수 있을까?
코드 품질 관리가 곧 결국 비용 문제에 직결된다.
코드 이해
유지 보수를 하기 위해서는 기존 코드를 이해하는 과정이 늘 선행된다.
이 코드 이해를 하는데 소요되는 비용을 어떻게 줄일 수 있을까?
코드 시각화
중요한 점. 코드를 다이어그램으로 시각화할 때 모든 상세 내용을 전부 표시하려고 하면 안 된다. 불필요한 요소는 생략하여 분명하게 다이어그램의 목적을 수행하고, 의도된 정보를 제공하게 한다.
UML
- 액티비티 다이어그램
- 코드 실행 흐름을 이해하는 데 도움이 된다. - 시퀀스 다이어그램
- 런타임의 객체/프로세스 간 상호 작용을 이해하는 데 도움이 된다. - 클래스 다이어그램
- 코드의 정적 구조를 이해하는 데 도움이 된다.
응집도와 결합도
왜 응집도를 높이고 결합도를 낮추어야 할까?
응집도를 높이고 결합도를 낮춘다는 것은 구성 요소 간 상호 작용을 최소화하는 것이다.
응집도
- 응집도가 높다는 것은 곧, 역할과 기능이 같은 코드가 분리된다는 것이다. 이는 자연스럽게 클래스 코드의 길이가 줄어들고 메서드 단위로 작성되어 가독성이 좋다는 것이다. 또한 그만큼 역할과 책임의 범위가 분리되어 유지 보수에 유리하다.
결합도
- 응집도가 높다고 해서 반드시 결합도가 낮은 건 아니다. 코드를 역할에 따라 분리하여 응집도를 높였으나, 그 분리된 요소 간의 의존이 발생하고 굉장히 의존성이 높다면 결합도는 증가하는 것이다.
레거시 코드
레거시 코드는 왜 무서운가?
- 테스트가 없는 코드, 이전 버전의 프레임워크를 사용해 개발한 코드 등 보다 넓은 의미의 단어로 쓰인다. 그러나 어떤 의미로 사용되더라도 레거시 코드는 수정하기가 어려운 코드라는 핵심적인 특성을 갖는다.
테스트 코드
테스트 코드를 작성하는 게 쉽지만은 않다. 하지만 테스트가 주는 이점을 고려하면 테스트 코드 작성 능력을 길러야 한다.
- 테스트 코드가 없는 조직은 수동 테스트를 진행한다. 하지만 이런 QA는 다양한 경우의 수를 확인하기 어렵다.
- 테스트 코드가 있다고 해서 모든 문제를 완벽하게 없애는 건 아니다. 그러나 적어도 테스트를 통과한 코드는 문제가 없다는 것을 확신할 수 있다는 강력한 이점이 있다.
- 테스트 커버리지는 7-80% 정도를 이루면 코드를 안정적으로 유지할 수 있게 만든다. 그렇다면 테스트 커버리지를 어떻게 넓힐 수 있을까?
TDD (Test-Driven Development)
테스트 코드를 만들고 이 테스트를 통과할 수 있는 구현을 진행하여 소프트웨어를 개발하는 방법론.
