.jpg)
코드의 종말이 코앞에 닥쳤다고 주장하는 사람이 없지 않은 상황에서, 코드를 다루는 책이다.
저자는 앞으로 코드가 사라질 가망은 전혀 없다고 말한다. 왜? 코드는 요구사항을 상세히 표현하는 수단이니까!
어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다.
기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이게 프로그래밍이고 명시한 결과가 코드다.
나쁜 코드로 치르는 대가
80년대 후반의 킬러 앱을 구현하던 회사는 초창기에 커다란 인기를 끌었지만, 제품 출시 주기가 길어지더니 얼마 못가 망하고 말았다.
그들은 출시에 바빠 코드를 마구 짰다. 기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다.
시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이다.
프로그래머의 책임이란
"아니 잠깐만요! 상사가 시키는 대로 하지 않으면 짤린다구요!"
겉으로 아닌 듯 행동해도 대다수 관리자는 진실을 원한다. 일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다. 그들이 일정과 요구사항을 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다.
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.
프로그래머가 기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. 그들은 빨리 가려고 시간을 들이지 않는다. 하지만, 나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 늦어지고, 결국 기한을 놓친다.
기한을 맞추는 유일한 방법은, 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.
깨끗한 코드란
- 세세한 사항까지 꼼꼼하게 처리하는 코드
- 다른 사람이 고치기 쉬운 코드
- 작성자가 이미 모든 사항을 고려해서, 고치려고 살펴봐도 딱히 손댈 곳이 없는 코드
- 주의 깊게 짠 코드
- 읽으면서 놀랄 일이 없는 코드
- 독해하느라 머리를 쥐어짤 필요가 없는 코드
노련한 프로그래머들의 의견
켄트 백의 단순한 코드 규칙
- 모든 테스트를 통과한다.
- 중복이 없다.
- 시스템 내 모든 설계 아이디어를 표현한다.
- 클래스, 메서드, 함수 등을 최대한 줄인다.
론 제프리스
- 중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기
- 여러 기능을 수행하는 객체나 메서드를 찾는다. 객체가 여러 기능을 수행한다면 여러 객체로 나눈다. 메서드가 여러 기능을 수행한다면 메서드 추출(Extract Method) 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 실제로 수행하는 메서드 여러 개로 나눈다.
- 프로그램을 짜다 보면 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이런 상황이 발생하면 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다.
보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.
잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 꺠끗하게 유지해야 한다.
체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선 하고, 조금 긴 함수 하나를 분할 하고, 약간의 중복을 제거 하고, 복잡한 if문 하나를 정리 하면 충분하다.
