오랜만에 들어보자. 20년전 노래. Avril Lavigne의 Complicated. 클릭하면 유튜브로 연결된다.

12장. 복잡도 다루기

복잡한 무언가를 작성하는 일은 너무나 쉽게 이루어진다.

Tell me, Why you have to go and make things so complicated? 노래 후렴구의 첫 가사다. 왜 자꾸 일을 복잡하게 만드는 거야? 답은... 직접 생각해보길 바란다. 단 3줄만으로도 완벽하게 기능을 구현할수 있어도 100줄로 작성하는 사람도 있다. 왜 그럴까? 또 물어봤으니... 답을 하겠다. 내가 생각하는 답은.... X도 모르거나 이해를 못해서이다. 본인이 코드를 난잡하게 짜고 있다는 생각이 들면 내가 진짜 이해를 하고 짜고 있는 것인지 생각해보자.

필연적인 복잡도는 관리해야 한다. 또한 불필요한 프로그래머들을 제대로 가르치거나 잘라버려야 한다.

과격하고 지나쳐보이는 생각처럼 보이지만, 사실 거의 대부분 이렇게 생각하고 있다.

13장. 두 개의 시스템에 대한 이야기

나쁜 설계는 더 나쁜 설계를 불러온다.

필연적으로 요구사항은 더 복잡해진다. 기초가 다져져 있지 않은 상태에서 급격한 복잡도 상승은 시스템을 한번에 시궁창으로 몰아 넣는다. 나쁘면 나쁠수록, 좋은 설계를 넣기 힘들다. 어떤 시스템이든 관리를 하지 않는다면 기능이 추가되고 복잡해질수록 응집도는 낮아지고 결합도는 높아진다. 거기에 변화하기는 어려운데 비슷한 기능을 추가해야하는 경우 코드를 복붙해와서 작업하기도 한다. 비슷한 기능에 거의 비슷한 코드, 아닐거라 기도하고 싶겠지만 나중에 수정해야할 때는 두 군데 다 수정해야한다.

필요한 경우 구조를 변경해야 할 수도 있었고, 그에 따라 설계를 간결하면서도 변경하기 쉽도록 유지하려고 노력했다.

민첩해야한다. 민첩하려면 가벼워야 한다. 코드가 마구잡이로 늘어나고 있다면 그것은 이미 잘못되었을 가능성이 높다. 필요할 때마다 구조를 간결하게 변경하는 것이, 더 오래가기 위한 방법이다. 단, 개인의 욕심에 의한 변경은 금물이다. 필요하기 전까진 그냥 두는 것이 낫다. YAGNI! 중요하고 필요한 것만 해도 인생은 짧다.

다소 가혹해 보일 수 있었지만 개발자들은 오히려 환영했다.

이 부분에서 다소 가혹하게 이야기해야 하는 것이 있다. 코드를 작성하고 PR 피드백을 받는 것이 두렵다면, 스스로 진지하게 직업에 대해 다시 생각해볼 필요가 있다. 5줄 고쳤는데 코멘트를 6개 받을 수도 있다. 이것은 소프트웨어 품질에 대한 이야기도 있지만, 같이 일하는 동료들이 함께 같이 성장하고 싶어 한다는 뜻이다. 자존심은 버리자. 아니라면 왜 이렇게 구현할 수 밖에 없었는지 정확하게 설명해야 한다. 그러면 그들은 이해하거나 더 좋은 방향을 제시해줄 것이다. 자존심 상해하고 상처받지 말아라. 그들이 왜 당신과 싸우고 싶어하겠는가?

팀이 서로 긴밀하게 작업한다면 구조 역시 적절히 통합된다.

콘웨이 법칙이라는 말이 있다. 프로덕트는 그 회사의 조직구조를 닮는다는 뜻으로 '컴파일러를 네 개의 팀이 만든다면 컴파일러는 4단계로 구성될 것이다.'라는 소름끼치는 예시가 있다. 조직이 커지고 팀이 분할될수록, 프로덕트는 점점 초기의 총명함을 잃어간다. 총명함을 잃지 않게 하기 위해서 긴밀히 커뮤니케이션하고 한 방향으로 같이 나아갈 수 있도록 노력해야 한다.