[clean code] 1일차

 

 

날짜 : 2022.04.23

범위 : 추천사 ~ 1장.깨끗한 코드 [ p 0 ~ p 20 ]

 

---

 

(p xxiv) 5S 철학 [이 부분은 책을 읽어가면서 알아가는 방식을 취하자!] ... 中 정리 또는 조직   정돈 또는 단정함 물건마다 모두 제자리가 있다. 청소 또는 정리 과거 일력이나 미래 발람을 기억한 주석또는 처리한 코드는 있으면 안된다. 이미 코드가 어렵다는 반증이다. 청결 또는 표준화 생활화 또는 규율

 

 

 

(p xxv) 추천사 ... 中 프레드 브룩스가 충고했듯이  우리는 아마도 7년마다 한 번씩 소프트웨어를 새로 짜서 끔찍한 괴물을 치워버려야 할지도 모르겠다. 어쩌면 7년이 아니라 7주, 7일, 7시간 단위로 코드를 고쳐야 할지도 모르겠다. 세세함은 바로 여기에 있다.

회사 레거시 코드에 대한 고찰

변경이력이 2년 이렇게 되는 코드가 있는데 삭제하고 리팩토링 절차를 거치는 것이 좋은 생각일까? 

기존의 코드를 수정하지 않고 새로운 코드로 점차 변해갈 수 있도록 변경해야한다. 

 

단, API 에서는 하위호환을 지키는 것이 중요하다. 앱개발의 경우에는 해당 버전을 강제로 업그레이드 시키지 못하는 경우가 있다. 이 경우 API에 대한 변경사항은 다소 위험해질 수 있는 요소가 있다. 이런 관점에서 생각해보면 API호출 구성은 그대로 두되 함수의 구성을 변경하는 방식으로 진행해야 올바른 결과를 얻을 수 있으므로 구분해서 구성해야 할 것이다. 

 

 

(p xxxii) 장인정신에 관하여 ... 中 장인정신을 익히는 과정은 두 단계로 나뉜다. 바로 이론과 실전이다. 첫째, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득해야 한다. 둘째, 열심히 일하고 연습해서 지식을 몸과 마음으로 체득해야 한다.

전자공학과 출신인 나는 대학교에서 실습시간이 이론시간의 3배정도 되는 시간이었고 이론보다는 실무에 조금 강했을지 모른다. 하지만 장인정신처럼 이론과 실습은 분명 동일한 비중의 가치를 가진다. 

실습은 사람을 일정 단계까지 빠르게 성장시켜주는 부분이 있다. 하지만 문제가 생기는 경우 대부분은 이론에서 배운부분이 문제가 되는 경우가 굉장히 많았던 것 같다.

가장 아쉬움은 실습보다 이론이 더 많아야 실제 실무에서 대학교에 배운 과거 기억을 통해 '아! 이래서 문제였나?' 하는게 좀 더 좋은 방향이라고 생각한다. 

혹시나 이론이 어려워서 대학교 과정을 소홀히 하고 있다면, 실제로 내손에 떨어지는 작품이나 물건이 없어서 만들고 싶다면, 조금해하지 않아도 된다고 생각한다. 

실습은 선배, 지인, 전문가들을 통해 접근법을 배우는 방법은 수 없이 많지만

교수님이라는 전문가의 이론은 그때 아니면 쉽게 배울 수 없을지 모른다.

 

 

(p 2) 헛소리! 앞으로 코드가 사라질 가망은 전혀 없다! 왜? 코드는 요구사항을 상세히 표현하는 수단이니까! ... 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다.

명확한 요구사항은 명확한 코드의 필수 조건이다 

 

명확하지 않은 요구사항은 명확한 코드를 만들 수 없다.

 

명확한 요구사항에 대해 http://www.kstqb.org/sw/lreb.asp 요런 시험을 준비해 보는 것도...

 

 

(p 4 ~ p 6) 그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다.  ... 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.  ... 이제 두팀이 경주를 시작한다. 타이거 팀은 기존시스템 기능을 모두 제공하는 새 시스템을 내놓아야 한다. 그뿐만이 아니다. 그동안 기존 시스템에 가해지는 변경도 모두 따라잡아야 한다. 새 시스템이 기존 시스템기능을 100% 제공하지 않는 한 관리층은 기존 시스템을 대체하지 않을 테니까. 때때로 경주는 아주 오랫동안 이어진다. 10년이 넘게 걸리는 경우도 보았다. 새시스템이 기존 시스템을 따라잡을 즈음이면 초창기 타이거 팀원들은 모두 팀을 떠났고 새로운 팀원들이 새 시스템을 설계하고 나선다. 왜? 현재 시스템이 너무 엉망이라서.

지금 시도하는 부분이 레거시 제거 코드를 만드는 것이지만 과연 성과가 있을까? 

효과적으로 하려면 어떻게해야할까?

 

부분적으로 리팩토링 후 한번 더 하는 방식을 채택하는 것이 좋은 방향으로 생각된다.

 

 

(p 7) 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다. 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다. 우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있다. 특히 나쁜코드가 초래하는 실패에는 더더욱 책임이 크다. ... 비유를 하나 들겠다. 자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 전문가 답지 못하니까.

개발자는 engineering management 능력을 겸비했을때 비로소 한 단계 성장한 개발자가 되는 것으로 생각해왔다. 이번 시간을 통해 생각에 대한 확신을 받는 시간이 기분이군.

 

 

(p 12) 요점은 인간이 읽기 좋은 코드를 작성하라는 말이다.

이 책의 저자가쓴 다른책인 리팩토링 읽어보면 매번 나오는 말!

 

읽기 좋은 코드가 되어라!

코드를 설계도라고 생각하고 작성하고 있다. 하지만 uml 을 통해 좀 더 추상화된 설계도도 있어야한다는 의견이다!