한빛미디어의 후원으로 책을 받아 작성합니다.
1. 서론
프론트엔드 개발자가 된지 1년이 다 되어가는 지금, 무엇을 잘해야 잘하는 개발자라고 말할 수 있는지에 대해 고민하게 된다. 내가 '잘'한다고 생각하는 기준이 내가 되고자 하는 개발자의 모습이라고 생각한다. 하지만 잘하는 개발자라는 것은 한마디로 정의하기가 참 어려운 것 같다.
내가 중요하게 생각하는 역량을 정리하고 더 잘하는 개발자가 되기 위한 방법을 ‘더 나은 프로그래머 되는 법’에서 찾아보고자 한다.
책 서문에서는 ‘처음부터 순서대로 읽어도 좋고 원하는 장부터 선택해 읽어도 좋다. 자신에게 가장 적절해 보이는 장부터 읽기 시작하라’고 나와있다. 관심있는 챕터들을 골라 읽을 수 있어 이동시간 틈틈히 읽기 편리했다.
이 책은 5개 부로 나뉘어져있는데, 그 중 인상깊었던 챕터들을 소개해보고자 한다.
2. 본론
1부 you.write(code)
12장 복잡도 다루기
소프트웨어 복잡도를 결정하는 원인은 크게 3가지로 블롭(blob), 라인(line) 사람이다.
- 블롭(Blob, binary large object) : 블롭이란 커다란 파일 혹은 바이너리 데이터를 지칭한다. 소프트웨어 복잡도는 블롭의 크기에 따라 자연스럽게 증가한다. 하지만 크기 자체가 문제가 되는건 아니다. 요구사항에 따라 요구사항을 만족시키기 위한 큰 코드가 필요하기도 하지만 중요한건 이 코드를 어떻게 구성하는가 하는 점이다. 즉, 크기를 어떻게 분배하는지가 핵심이다. 유지 보수하기에 더 간단한 구조로 나누어 하나의 일만 처리하는 응집도가 높은 모듈로 분리해야한다. 겉보기에 단순해 보이는 것이 아니라 실제로 간결해지도록 설계해야한다.
- 라인 : ‘No code is an island’(혼자인 코드는 아무데도 없다). 복잡도는 각 블롭 안에서 홀로 커진 것이 아니라 블롭을 라인으로 연결하는 과정에서 증가한 것이다. 블롭들 사이에 연결로 블롭들간의 결합도가 불필요하게 증가하면 시스템이 경직되진다.
- 사람 : 블롭과 라인은 스스로 만들어지지 않는다. 시스템의 복잡도는 블롭과 라인의 구조를 책임지는 사람에게 있다.
복잡도를 줄일 수 있는 유일한 방법은 소프트웨어에 책임감을 가지고, 적절하지 않는 구조로 코드를 밀어넣는 상황을 피하고자 노력하는 것이다. 이 문장이 마음에 와닿았다. 개발을 하면서 컴포넌트, 함수가 중첩되거나 기능이 분산되는 케이스가 발생하는데 이를 해결할 수 있는건 결국 개발자이다. 긴박한 업무 속에서도 하나의 역할이 하나의 부분에만 위치하도록 신경쓰고 리팩토링하는 역량이 필요한 것이다.
2부 연습을 통해 완벽해진다
16장 간결하게 하기
- 좋은 간결함
- 코드 사용자가 불필요한 코드를 작성하지 않도록 복잡한 부분을 내부에 포함하는 것
- 요구 사항을 충족시키는데 필요한 만큼의 코드만 작성
- 잘못된 간결함
- 작성하고 있는 코드에 대해 충분하게 생각하지 않고 ‘주요 경우(main case)만 처리하여 오류를 내재
높은 응집도와 낮은 결합도를 만들어내는건 참 어려운 것 같다. 프로그래밍에서 ‘간결함’ 이라는 것은 정해진 공식이 없는 것 같다. 충분히 고민하고 명확한 가설을 바탕으로 짜여진 코드를 작성하기 위해서는 다양한 문제상황을 접하고 구현해보고 팀 내 규칙에 따라 피드백 받는 경험이 쌓아나가야한다.
17장 머리 쓰기
코딩을 기계적으로 해서는 안된다. 머리를 쓰라!
멍청한 코드를 작성했다는 사실을 깨닫거나 바보같은 설계임을 인식했더라도, 무력함을 느끼지 말아야한다. 실수를 인정하고 더 나은 방향을 찾는 태도를 가져야한다. 실패를 인정하고 실수를 바로잡는 용기를 가져야한다.
18장 변하지 않는 것은 없다.
코드는 변해야한다. 어떠한 코드도 완벽할 수는 없다. 제품 중에 '불변'의 코드가 있다면 그 제품은 썩어버릴 것이다.
- 용감한 수정
- 17장에 이어서 18장에서는 수정을 대하는 올바른 태도를 이야기하고 있다. 우리는 실패할지도 모르고 잘못될지도 모르지만, 코드를 정상적인 상태로 되돌릴 수 있으므로 다시 시도하면된다.
- 태도 바꾸기
- 건강한 코드 수정을 위해서는 올바를 태도가 필요하다. 코드 품질을 향상시키기 위해서는 팀, 개인 모두 변화와 개선을 두려워하지 말아야한다.
- 싸워야 할 때를 가려라
- 모든 것이 변하기 쉬운 것언 아니기에, 기술 부채는 일정량 존재한다.
시도하는 것은 부끄러운 일이 아니며 실수로부터 항상 배울 수 있다. 첫 회사일을 하면서 다른 팀원들에 비해 코드 퀄리티가 부족하다고 느껴질 때마다 힘들었다. 부족함을 많이 느꼈다. 답은 하나였다. 더 많은 주의를 기울이고 생각하면 된다. 그리고 잘못된건 바로잡고 수정하면 된다. 피하지 말자.
4부 연습을 통해 완벽해진다
31장 ‘더 열심히’보다는 ‘더 현명하게’
더 생산적인 프로그래머가 되기 위한 방법이다.
- 다른 사람의 일로 만들라
- 어떤 작업 진행 방법을 다른 사람이 알고있다면 직접 해결하려 하지말고 그의 작업 목록에 올려줘라
- 해야 하는 것을 하라
- 적절하거나 시간을 들일 가치가 있는 작업을 해라
- 예) 리팩토링과 단위 테스트는 필요하지만 작은 프로트타입이나 만들어보고 버릴 용도의 코드라면 나중으로 미뤄드는 편이 낫다.
- 거칠더라도 빠르게 해결하라
- 여러 설계 방안 가운데 어떤 것을 선택해야할지 결정할 수 없을 때에는 최선책을 골라내기 위해 많은 시간을 소모하지마라. 대신 간단하게 구현해보고 테스트해보며 적절한 해답을 찾아가라
- 작고 간결하게 유지하라
- 코드의 설계를 가능한 작고 간결하게 유지
언젠가 발생할 가능성이 있는 기능을 미리 만들어두는 것은 더 어렵고 어리석다.
주어진 상황에서 필요한 작업을 하면서도 과도하게 모든 상황을 고려하지 않는 지점을 찾는게 어려운 것 같다.
3. 결론
책을 읽으면서 가장 많이 든 생각은 '나만 고민하던 내용이 아니었다'는 것이다. 프로그래머라면 누구나 한번 쯤 해본 고민들을 다양하게 담고있어 새해를 시작하는 지금 책을 읽으면서 앞으로 1년간 어떤 역량을 기를지 어떤 방향으로 성장할지 다짐할 수 있었다.
지금 내가 생각하는 잘하는 개발자라는 것은 '명확한 코드를 주어진 시간 내에 구현하며 시도을 두려워하지 않는 개발자' 이다. 일의 우선순위를 파악하며 필요한 기능들을 구현하고, 더 나은 코드로 점진적으로 개선해나가는 것이다. 이런 개발자가 되기 위해서 효율적으로 업무를 분류하고, 명료한 컴포넌트를 설계하기 위해 고민하고 공부할 것이다.
올해가 마무리 될때 내가 얼마나 역량을 길렀는지도 수치화 해보는 시간을 가져야겠다.