개발자 99% 커뮤니티에서 수다 떨어요!
TIL
2022.02.19
오늘 읽은 범위
추천사~1장. 깨끗한 코드
기억하고 싶은 내용
추천사 & 들어가면서
꼭 맞게 닫히지 않는 문이나 삐뚤어진 바닥 타일이나 지저분한 책상 등 아주 사소한 것들이 전체의 매력을 깎아 먹는다.(...) 불행히도 우리는 세세함에 집중하는 태도가 프로그래밍 기술에 핵심적인 주춧돌이라 여기지 않곤 한다. 코드에서는 일찌감치 손을 뗀다. 구현을 끝냈기 때문이 아니라 본질substance보다 모양새를 중시하는 기치체계 때문이다. 이처럼 부주의한 태도는 결국 문제를 일으킨다.
-1951년 TPM(Total Productive Management)라는 품질 관리론은 생산이 아니라 유지보수에 초점을 맞췄고, 결과적으로 아예 처음부터 유지보수하기 쉬운 기계를 만들어내는 경지에 도달했다.
TPM의 5S 규율 :
1. 정리: 적절한 명명법을 사용해 무엇이 어디에 있는지 알아야한다.
2. 정돈: 코드는 누구나 예상하는 위치에 있어야 한다.
3. 청소: 부스러기나 쓰레기는 치운다.(e.g. 과거이력이나 미래바람을 기억한 주석 혹은 주석으로 처리한 코드들)
4. 청결: 표준화. 이 청소의 방식에 그룹이 동의해야한다.
5. 생활화: 관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경하는 규율.
장인 정신을 익히는 과정. 첫번째, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식의 습득(이론). 두번째, 열심히 일하고 연습해 지식을 몸과 마음으로 체득(실전).
80년대 후반, 킬러 앱(killer app)을 구현하여 큰 성공을 한 회사는 나쁜 코드 때문에 결국 망했다.(...) 우리는 모두 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 그래도 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. ***나중은 결코 오지 않는다***
코딩의 본질이 작동하는 무언가를 만들어내는 것에 있지 않음을 생각해본다. 유지 보수가 제대로 이루어지지 않는다면 구현의 의미도 사라진다. 때문에 깨끗한 코드가 필요한 것이고, 깨끗한 코드에는 '세세한' 태도가 요구된다. 쉬운 일은 아니겠지만 이것은 선택적인 문제가 아니라고 생각된다.
1장. 깨끗한 코드
좋은 코드를 사수하는 것은 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자의 말을 따르는 것은 전문가 다운것이 아니다.
나쁜 코드는 나쁜 코드를 만든다. 데이비드 토마스David Thomas 와 앤디 헌트Andrew Hunt의 비유 : 창문이 깨진 건물은 누구도 상관하지 않는다. 창문이 더 깨져도 상관하지 않는다. 마침내는 자발적으로 창문을 깬다. 일단 창문이 깨지고나면 쇠퇴하는 과정이 시작된다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다. 깨끗한 코드는 설계자의 의도를 숨기지 않는다.
깨끗한 코드는 다른 사람이 고치기 쉽다.
론 제프리스(Ron Jeffries)의 '간단한 코드'의 규칙 :
1. 모든 테스트를 통과한다.
2. 중복이 없다
3. 시스템 내 모든 설계 아이디어를 표현한다.
4. 클래스, 메서드, 함수 등을 최대한 줄인다.
깨끗한 코드는 코드를 읽으면서 짐작했던 기능이 각 루틴이 그대로 수행한다. 코드가 그 문제를 풀기 위한 언어처럼 보인다.
80-90년대 사용하던 사용자의 모든 입력키를 기억하는 편집기 이야기 : 코드를 짜는 시간보다 코드를 읽는 시간이 훨씬 더 많다. 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 짜기도 더 쉬워진다.
보이스카우트 규칙 : "캠프장은 처음 왓을때보다 더 깨끗하게 해놓고 떠나라"
(시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해보라!)
여러 저명한 프로그래머들의 '깨끗한 코드'에 대한 정의들은 매우 흥미롭다.(특히 창문에의 비유) 나쁘게 쓰고서 남겨둔 코드는 또 다른 나쁜 코드를 불러낸다. 나도 거의 그랬던 것 같다. 오늘 작업을 시작할때 겨우 어제 작업했던 코드들을 한참동안 들여다 봐야할 때가 많았다. 그리고 그 나쁜 코드에 맞물리는 코드 역시 나쁠 수 밖에 없었고 악순환은 반복된다. 뭔가 잘못되어가고 있는 것 같다는 느낌은 들지만, 그래서 무엇이 문제고 어떻게 해야할지 모른다. 결국 그렇게 끝까지 가고나면 그때는 정말로 손을 쓸 수가 없다.
오늘 읽은 소감은?
매우 인상적이다. 1년여 동안 노마드코더에서 공부하면서 코딩으로 내가 상상하던 뭔가를 만들어낼 수 있다는 것에 큰 매력과 성취감을 느꼈다. 하지만 코딩의 본질은 만들어 낸다는 행위 자체에 있는 것이 아니라 그렇게 만들어낸 것들을 계속 유지하고 발전시켜나갈 수 있음에 있는 것은 아닐까 생각해본다. 그것이 뒷받침 되어있지 않다면 내가 짠 코드들은 하나의 프로덕트로서 생명을 유지하기 어려울 것이고 결국 내가 구현한 것의 의미마저 사라지게 된다. 그리고 이를 위한 작업의 시간은 절대 따로 주어지지 않는다. 처음부터 끝까지 '장인의 세세함'으로 깨끗한 코드를 써내려가야한다. 지금까지 나는 작동에만 집중한 코딩을 해왔다. 앞으로 이 책을 읽으면서 프로젝트 전체의 생명주기를 고려한 질 높은 코드를 짤 수 있는 개발자가 될 수 있기를 기대한다.
궁금하거나 잘 이해되지 않는 내용
Lean : 1930년 경영 모형인 "도요타 방식(The Toyota Way)"(도요타 생산 체계(Toyota Production System, TPS)에서 파생된 생산 방법(production method). 도요타(자동차 제조사)의 프로세스를 S/W 개발에 적용한 방법론을 일컫기도 한다.