꾸준히 하나씩

코드는 여기저기 움직이면서 변할 수 있으므로 주석이 미아가 되는 경우가 있음.. -> 따라서 부정확한 주석은 없는 것보다 훨씬 나쁘다!! 주석은 나쁜 코드를 보완하지 못한다 주석을 써서 수습하려 하지 말고 걍 코드를 다시 손보기 코드로 의도를 표현하라! 이름 잘 지으면 웬만하면 코드로 의도 다 표현할 수 있다. 좋은 주석 제일 좋은 주석은 주석 안 다는 방법을 찾아낸 주석이다. 그래도 좀 필요한 주석들 몇가지 법적인 주석: 회사가 공통으로 지정한 주석 정보를 제공하는 주석: 반환값 설명 등 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 결과를 경고하는 주석: 특정 테스트 케이스는 꺼야 할 때 TODO 주석: 앞으로 해야할 일 정리 중요성을 강조하는 주석 공개 API에서 Javadocs 나쁜 주석 대다..

작게 만들어라! 무조건!!! 함수는 작게 만들어야 한다. 정말 최대한 짧게 만드는 게 가장 좋음. (글에서 든 예시는 5줄) 블록과 들여쓰기 if/while문 등에 들어가는 블록은 한줄이어야 함. 중첩 구조가 생겨서는 안된다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수 내 섹션 함수 내에 섹션이 나뉘는지 확인하기. 나뉘어진다면, 하나만 하는 함수가 아닌 것 함수 당 추상화 수준은 하나로! 근본 개념과 세부사항을 뒤섞지 않기!! 각 코드의 추상화된 정도를 통일해야 함. 위에서 아래로 코드 읽기: 내려가기 규칙 코드는 위에서 아래로 이야기처럼 읽히는 것! 위에서 아래로 추상화 수준이 한 단계씩 낮아진다. Switch 문 switch문은 작..

의도를 분명히 밝혀라 코드가 하는 일을 짐작할 수 있어야 한다. 1. 코드의 단순성이 아니라 코드의 함축성 2. 각 개념에 이름을 붙이기!! 예: if(x[0]==4) 대신 if(cell[STATUS_VALUE]==FLAGGED) 그릇된 정보를 피하라 1. 예를 들어, 실제 List가 아니라면 accountList라는 이름을 붙여서는 안됨. List는 특수한 용어이기 때문!! 이는 그릇된 정보를 제공하는 것.. 2. 서로 흡사한 이름을 사용하지 않도록 주의. 3. 유사한 개념은 유사한 표기법 사용! 일관성이 떨어지는 표기법도 그릇된 정보이다. 4. L과 1, O와 0가 헷갈리는 참사.. 주의하기 의미 있게 구분하라 같은 개념을 사용하지 못해 나머지 하나의 철자를 살짝 바꾸게 되면.. 철자 오류를 고치는 ..

코드가 존재하리라 코드: 요구사항을 표현하는 언어 시키는 대로가 아닌 원하는 대로 돌아가는 기계는 존재할 수 없다. 나쁜 코드 80년대 후반 Killer App을 구현한 회사가 있었으나, 급하게 마구 짠 코드로 인해 수많은 버그가 잡히지 않았고, 결국 회사는 망함. 고행(wading): 나쁜 코드에 발목이 잡혀 고생하는 것? 나쁜 코드로 치르는 대가 나쁜 코드가 쌓일수록 팀 생산성은 떨어짐, 결국 생산성은 0에 수렴하게 된다..! 원대한 재설계의 꿈 재설계를 위해 꾸려진 새로운 "타이거 팀"은 새로운 시스템을 내놓아야할 뿐만 아니라 기존 시스템에 가해지는 변경도 모두 따라잡아야 한다. 태도 관리자는 진실을 원한다. 일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다. 좋은 코드를 사수하는 것은 프로그래..