clean code

이 장에서는 깨끗한 코드의 중요성과 유명한 개발자들이 정의한 깨끗한 코드를 살펴본다.나쁜 코드는 일의 생산성을 점점 낮춰서 결국엔 0에 수렴하게 한다.처음엔 시간에 쫓겨서 일단 기능만 구현해두고 코드를 정리하는 일은 나중으로 미뤄둔다. 하지만 일은 계속 쌓이게 되고 코

코드가 하는 일을 이해하기 훨씬 쉬워지며 코드가 할 일을 해석하는 시간이 상당히 줄어든다.널리 쓰이는 의미가 있는 단어를 사용하면 안된다.예를 들면 유닉스 변종을 가리키는 이름인 hp, zix, sco가 있다.실제로 List가 아니라면 List란 단어를 사용하면 안된다

함수는 최대한 작고 짧게 만들어야 한다.if, else, while 문에 들어가는 블록은 한 줄이어야 한다. 그 한 줄은 함수를 호출한다.또한 함수는 한가지 일만 해야 한다. 이는 섹션으로 나눌 수 없어야 한다는 것이다.아래는 내가 mupol에서 사용했던 현 유저의 비

사실 좋은 주석이란 존재하기 어렵다. 왜냐하면 개발자들은 주석을 유지 보수하지 않기 때문이다. 코드는 변화에 따라 계속 바뀌지만 주석은 바뀌지 않고 주석은 오히려 코드 해석에 방해가 되는 경우가 많다. 따라서 주석을 작성하기보다는 되도록 주석이 필요없도록 코드를 리팩토

코드 스타일은 가독성에 큰 영향을 끼친다 -> 유지 보수에 영향을 끼친다.큰 파일보다 작은 파일이 이해하기 쉽다.가까운 개념은 세로로 밀집하도록,먼 개념일수록 빈 행으로 구분해서 가독성을 높인다.

우리는 남들이 변수에 의존하지 않게 만들고 싶기 때문에 변수를 비공개로 정의한다. 하지만 프로그래머들은 getter, setter를 이용해서 변수를 공개하곤 한다.자료를 세세하게 공개하기 보단 추상적인 개념으로 표현하는 것이 낫다.getter, setter는 구현을 외

오류 코드를 사용하면 함수를 호출한 즉시 오류를 확인해야 한다.예외를 사용해서 논리와 오류 처리 코드를 분리하자.범위를 정의한다.try안에서 생긴 일과 무관하게 catch에서 프로그램을 일관되게 유지해야 한다는 점에서 트랜잭션과 비슷.확인된 예외는 OCP를 위반한다.만

깨끗한 클래스를 만들도록 노력해보자.테스트를 위해서 클래스를 protected로 풀어주는 경우도 있지만 이것은 최후의 수단이 되어야 한다. 클래스를 최대한 숨길 수 있는 방법을 찾자.클래스는 단일 책임 원칙을 지키도록 노력해야 한다.단일 책임 원칙(SRP) : 클래스나

제작과 사용은 매우 다르다. 소프트웨어 시스템에서는 준비 과정과 런타임 로직을 분리해야 한다.즉 시작 단계라는 관심사를 분리해야 한다. 아래의 코드는 시작 단계를 분리하지 않고 구현한 예시이다.문제점들은 다음과 같다.getService 가 MyServiceImpl과 생

이 장에서는 여러 스레드를 동시에 돌리는 이유, 그에 따른 어려움과 해결 방법, 테스트 방법과 문제점에 대해 이야기한다.동시성은 결합(Coupling)을 없애는 전략 : 무엇, 언제를 분리\-> 프로그램을 거대한 루프 하나가 아닌 작은 협력 프로그램 여럿으로 볼 수 있