Clean Code를 정리합니다.
Clean Code를 정리합니다.
15 items under this folder.
다시 핵심만 간결하게 복기하기 위한 목적으로 정리하기 때문에, 요약하는 방식으로 글을 작성한다. 역/식자의 말 절대적이라 믿으면 안된다 개선의 여지가 있을 것이라 생각해야 한다. 이 요소들을 소개하는 이유는 팀/공동체에서 서로 동의하는 합리적인 원칙을 세우기 위함이다.
이름은 어디서든 쓰인다. 많이 사용하기 때문에 잘지으면 편하다. 몇 가지의 규칙을 알아보자. 의도를 분명히 밝혀라 말하기는 쉽지. 어렵거든? 저자도 안다. 하지만 이 의도가 분명한 이름을 짓는 것은 정말로 중요하다. 결국 최종적으로 절약하는 시간이 더 많기 때문이다.
Intro 프로그래밍 초창기에는 System = Routine + Subroutine 이었다. Fortran, PL/1시절에는 System = Program + SubProgram + Function 이었다.지금은 Function만 남았다.
Intro 나쁜 코드에 주석을 달지마라. 새로 짜라. : 브라이언 W. 커니헨, P.J. 플라우거 주석은 필요악이다. 프로그래밍 언어 자체가 표현력이 풍부하다면, 혹은 우리가 치밀하게 의도를 잘 표현했다면 주석은 전혀 필요하지 않다.
형식을 맞추는 목적 코드 형식은 의사소통의 일환이다. 오랜 시간이 지나 원래 코드의 흔적을 찾아보기 어려울 정도로 변경되어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다.
우리는 private을 통해 변수를 자주 정의한다. 이렇게 하는 이유는 남들이 변수에 의존하지 않도록 만들고 싶기 때문이다. 그럼에도 불구하고 많은 프로그래머들은 get, set 함수를 당연하게 외부에 노출하는 오류를 범한다.
깨끗한 코드와 오류 처리는 화실히 연관성이 있다. 하지만 오류 처리로 인해 프로그램 논리를 이해하기 어려줘진다면 깨끗한 코드가 아니다. 오류보다 예외를 사용하라 에전 프로그래밍 언어는 예외를 지원하지 않았다.
우리는 시스템에 들어가는 모든 코드를 보통 직접 개발하지 않는다. 외부 패키지 구입, 오픈소스, 사내 팀의 제공 컴포넌트 사용 등 다양한 방식으로 외부 코드를 사용한다. 이 외부 코드를 우리 코드에 깔끔하게 통합하는 것은 꽤나 중요하다.
지난 10년 동안 우리 분야는 눈부신 성장을 이뤘다. 97년도만 해도 TDD라는 개념을 아무도 몰랐다. 그 당시 단위 테스트는 프로그램이 돌아가는지 확인하는 일회성 코드에 불과했다.
이전 장들에서는 Code, Code Block, 함수 구현 방법, 함수들의 연관 방식을 알아보았지만, 이번에는 조금더 고차원의 얘기를 할까 한다. 클래스 체계 Java Convention에 따르면 가장 먼저 변수 목록이 나온다.
복잡성은 죽음이다. 개발자에게 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다. - 레이 오지, 마이크로소프트 최고 기술 책임자(CTO) 도시를 세운다면? 도시가 돌아가는 이유는, 각 분야를 담당하는 팀이 있기 때문이다.
창발성 단순한 결합이 복잡한 결과를 나타내는 것을 뉴런 하나만으로 의미가 있을까? 뉴런이 모여 어떠한 인식을 하기 위해서는 수십억개의 뉴련이 상호작용해야 한다. 즉, 미시적인 부분의 각각의 특성만으로는 설명할 수 없는 전체로서 나타나는 복잡한 현상을 말한다.
동시성과 깔끔한 코드는 양립하기 아주 어렵다. 그럼에도 불구하고, 동시성은 왜 필요할까? 객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O. 코플리엔 동시성이 필요한 이유? 동시성은 “무엇”과 “언제”의 Coupling을 없애는 전략이다.
해당 부분은 너무 코드가 많아, 이전 상태와 이후 상태를 놓고 그 사이에서 저자가 어떠한 흐름으로 이를 처리했는지 간략하게 정리하는 것을 목적으로 한다. Intro 해당 부분에서는 출발은 좋았으나, 확장서잉 부족했던 모듈을 소개한다.
15장(JUnit)과 16장(SerialDate Refactoring)은 코드가 많고, 지배적인 내용이 아니라 판단하여 생략하였다. 17장, 냄새와 휴리스틱을 정리해본다. 개인적으로 가장 실용적이며 중요한 절이라는 생각이 든다.