개발자 필독서 중에서도 당연시 언급되는 클린코드. 1장부터 다시 보았다
#1 Intro
당신의(혹은 당신의 팀의) 시간과 비용과 노력을 위하여
"좋은 아키텍처가 비싸다는 생각이 든다면, 나쁜 아키텍처를 시도해봐라."
현재 가장 좋은 코드라고 판단이 된다는 것은 후에 변경될 가능성의 존재를 무시해도 괜찮다는 의미가 되진 못할 거다. 그렇다고 변경될 가능성을 지나치리 신경써 확장성을 가지고자 작성하면 그것도 좋지 않다
개발의 진척도가 조금만 지나도 더 이상 쓰지 않는 코드, 무의미한 파라미터의 처리가 난감해진다. 이 레거시 코드 처리의 난처함은 필연적이며, 그나마 가장 깔끔한 길을 찾기 위하여 모두를 위한 가이드라인이 이 책이라고 생각한다.
뼈대의 규칙은 바뀌지 않는다
작성자는 꽤나 오랫동안 다양한 개발경험을 겪으며 한 가지의 사실을 깨달았다.
모든 프레임워크, 패러다임, 언어를 불문하고 지키게 되는 불변의 규칙이 존재한다. 문제는 그것을 사람들이 좀처럼 인지하지 못했다는 거다.
#2 1장, 클린아키텍처가 왜 필요한가
프로그램을 동작하게 하는 게 어렵나
개발새발은 고등학교-대학생도 가능하다 (저자왈)
프로그램을 제대로 만드는 게 어렵다
프로그래머에게 필요한 교양- 사교력과 통찰력을 생각보다 챙기질 않더라.
훈련과 헌신이 필요함에도 그러한 열정을 가지려는 전문가의 열망이 부족하다.
그러한 개발자들 속에서, 제대로된 시스템을 갖추어 유지보수 하도록 하자.
악의 조건을 가진 프로그램이 무엇이었는가? 강한 연관을 지녔고, 그것도 복잡하게 얽혔으며, 이로 인한 사소한 변경조차 긴 기간이 걸린다. 기간만 오래걸리겠는가, 그 과정으로 인하여 팀의 사기도 무너져버릴 것이다.
그럼 좋은 프로그램이란 건 무엇이겠는가, 결함률이 낮고 제대로된 시스템(아키텍처)를 통해 최소한의 인력만으로도 원활히 진행될 수 있는 것이다.
제대로 갖추지 못했다면
즐겁기가 어렵다. 개발이 아니라 싸우는 느낌이었을 것이다.
#3 1장, 설계와 아키텍처라는 건
설계 == 아키텍처?
True라고 생각하고 설계와 아키텍처를 구분지으려고 하지 말자. 두 개는 개별로 존재하지 못하니까
그리고 이런 설계-아키텍처의 최종적이고 이상적인 목표는 다음과 같다
필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하자
토끼와 거북이
설계는 뒷전으로 출시가 급한 토끼가 된 개발자가 과연 언제까지 달릴 수 있을까. 일단은 만들고 돌아가자는 생각을 했다면, 맘처럼 안 될 것이다. 하나의 완수이후에는 그것을 기반으로 계속 얹어가야 할 뿐 뜯어고칠 여유가 없다.
그래서 저자는 TDD의 경우를 언급한다. 테스트주도 개발 방식과, 적용하지 않은 개발 방식의 비교는 굉장히 컸다. 어떻게 컸는지를 유추할 수 있는 한 마디를 강조했다.
빨리 가는 유일한 방법은 제대로 가는 것이다
이 책은 이런 걸 말하고 싶다
위와 같은 필요성을 배경으로하여 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지, 개발자가 장기간에 걸쳐 수익을 창출하는 시스템을 만들기 위한 기반이 무엇인지.
#3 소프트웨어 시스템의 두 가지 가치: 행위와 구조
구현과 버그 수정이 개발자의 직업인가
프로그래머는 이해관계자의 요구를 구체화 하도록 하는 일을 한다. 그 과정에서 문제가 생긴다면 버그 수정을 하기도 하겠지만.. 진짜 그게 개발자의 모든 본분인가?
소프트웨어의 뜻을 다시보자
Soft + ware : 유연한 제품, 즉 기계의 행위가 유연하고 부드럽게 변경될 수 있도록 하는 것이라 생각해 보자.
개발자는 이 '변경'이란 것이 마치 퍼즐로 느껴진다. 해마다 규모가 커지는 이 퍼즐판에서 조각조각 분해하고 끼워맞추는 데에 대한 시간적 금전적 비용은 줄어들 수가 없다. 이해관계자의 요구가 매 해마다 같은 규모의 요구를 한다더래도 지금의 퍼즐판에선 도저히 맞추어낼 수 없는 모양일 수도 있단 거다.
우선순위를 잘 생각하자
1. 긴급하고 중요한
2. 긴급하지는 않지만 중요한
3. 긴급하지만 중요하지 않은
4. 긴급하지도 중요하지도 않은
개발자 입장에서는 긴급 = 동작(작동), 중요 = 아키텍처 라고 생각해야한다.
예를들어 이해당사자는 '동작하는 제품'을 원할텐데, 당신은 현 상황에서 그 동작을 위해 아키텍처를 포기해야한다. 즉, 출시된 현 시점 이후의 변경에 대해서는 동작하지 않을 수도 있는- 그런 제품의 탄생을 예고해야하는 것이다.
그러면 이해당사자는 당신을 나무랄 것이다. 이 지경이 될 때까지 왜 관리를 처음부터 제대로 하지 않았냐고.
1장 끄읕