개발 도서/Clean Code

메인 컴포넌트는 모든 시스템에 최소한 하나 이상 존재하고, 다른 나머지 컴포넌트를 생성하고 조종하고 관리하는 역할을 한다. 궁극적인 세부사항 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다. 메인 컴포넌트는 시스템의 진입점으로 어떤 것도 메인 컴포넌트에 의존하지 않는다. 메인 컴포넌트는 시스템 전반을 담당하는 기반 설비를 생성하고 시스템에서 더 높은 수준을 담당하는 부분으로 제어권을 넘기는 역할을 한다. 주로 의존성 주입 프레임워크를 이용해 의존성을 주입하는 역할을 하고, 클린 아키텍처에서 가장 바깥쪽에 위치하는 컴포넌트로, 가장 지저분한 컴포넌트라고 생각하면 좋다. 결론 메인 컴포넌트는 애플리케이션의 플러그인이라고 생각하고 설계하면 된다. 언제든지 갈아끼우던가, 새롭게 만들 수 있는 ..

주석 C1: 부적절한 정보 C2: 쓸모 없는 주석 C3: 중복된 주석 C4: 성의 없는 주석 C5: 주석 처리된 코드 환경 E1: 여러 단계로 빌드해야 한다 E2: 여러 단계로 테스트해야 한다 함수 F1: 너무 많은 인수 인수는 없는게 가장 좋고, 다음 하나, 그 다음 둘, 그 다음 셋, 넷 이상은 의심 F2: 출력 인수 F3: 플래그 인수 F4: 죽은 함수 일반 G1: 한 소스 파일에 여러 언어를 사용한다 G2: 당연한 동작을 구현하지 않는다 G3: 경계를 올바로 처리하지 않는다 G4: 안전 절차 무시 G5: 중복 G6: 추상화 수준이 올바르지 못하다 어려운 부분이지만 저차원 개념은 파생 클래스에, 고차원 개념은 기초 클래스에 넣는다 세부 구현과 관련된 상수, 변수, 유틸리티 함수는 기초클래스에 넣으면..

주석은 나쁜 코드를 보완하지 못한다. 나쁜 코드를 작성하고, 주석으로 이를 설명하는 것은 좋지 않은 방법이다. 나쁜 코드를 작성하고 주석을 작성하는 대신 나쁜 코드를 좋은 코드로 변경하자. 좋은 주석 법적인 주석 정보를 제공하는 주석 의도를 설명하는 주석 의미를 명료하게 밝히는 주석 결과를 경고하는 주석 중요성을 강조하는 주석 공개 API에서 Javadocs 나쁜 주석 주절거리는 주석 같은 이야기를 중복하는 주석 오해할 여지가 있는 주석 의무적으로 다는 주석 이력을 기록하는 주석 있으나 마나 한 주석 저자를 표시하는 주석 주석으로 처리한 코드 과거의 코드를 주석으로 처리하지 말고 삭제하자. 과거 코드는 버전 관리 도구에서 언제든 확인할 수 있다. 주석으로 처리하기보다 커밋 메시지를 더 명확하게 달자. 비..

나는 주로 자바스크립트를 사용해 코드를 작성하기 때문에 함수를 굉장히 많이 사용하게 된다. 이번 장을 통해서 좋은 함수의 원칙에 대해 알아보자. 작게 만들어라 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. 20줄의 함수도 길다. 2~4줄을 가진 함수로 프로그램을 구현해보자. 각 함수가 하나의 이야기를 하게 된다. 블록과 들여쓰기 if 문, else 문, while 문에 들어가는 블록은 한 줄이어야 한다. function purchase(wallet) { if (wallet.getMoney() >= 3000) { wallet.pay(3000); } } 위의 코드처럼 if 문 안에서 동작하는 것을 하나의 함수로 요약하자. 한 가지만 해라! 함수는 한 가지를 해야 한다...

코드를 작성하면서 변수나 함수, 클래스의 이름을 짓는 것이 쉽지 않음을 매번 느낀다. 전에는 비슷한 일을 함수의 이름을 어떻게 지었지? 이 변수는 복수형인데 그동안 뒤에 s 를 붙였었나? 이전의 클래스랑 비슷한 클래스에서 살짝만 바뀌었는데 이건 어떻게 이름을 짓지? 등과 같은 고민을 수도 없이 했다. 이번 장에서는 이러한 고민들에 조그마한 도움이 될 수 있는 이름 짓는 규칙에 대해 설명을 한다. 의도를 분명히 하라 좋은 이름을 지으려면 시간이 필요하지만, 좋은 이름으로 절약하는 시간이 훨씬 많다. 의도가 명확히 드러나는 코드를 작성해야 한다. 이름만으로도 함수 및 클래스가 하는 일을 더 빨리 파악할 수 있게 도와준다. 개발자들이 코드를 작성하는 시간보다 읽는데 더 많은 시간을 보내므로 이는 개발자의 행복..

나쁜 코드란? 나쁜 코드는 생산성을 크게 낮춘다. 지금 당장 나쁜 코드로 작성하는 것이 더 빠르게 업무를 마칠 수 있을 것이라는 유혹을 줄 수 있지만 이후 유지보수할 시간이 다가오거나 새로운 기능 추가 또는 수정이 필요할 때 나쁜 코드로 인한 대가를 크게 치르게 될 것이다. 실제로 간단한 기능 수정이지만 너무 많은 부분에 의존하고 있어서 쉽게 코드를 건드리지 못하고 아예 새로 만들어야 하는 상황을 겪은 적이 있었다. 이 책에서는 나쁜 코드가 나쁜 코드를 유발한다고 한다. 나쁜 코드는 이후 더 나쁜 코드를 작성하라고 유혹한다. 시간이 없어서 나쁜 코드를 작성했다는 말은 전문가가 아니라는 뜻이다. 진정한 개발자라면, 그리고 전문가라면 최대한 좋은 코드를 작성해야 한다. 그리고 시간이 없다는 것은 핑계다. 가..