목차 1. 깨끗한 코드 2. 의미있는 이름 3. 함수 4. 주석 5. 형식 맞추기 6. 객체와 자료구조 7. 오류 처리 8. 경게 9. 단위 테스트 10. 클래스 11. 시스템 12. 창발성 13. 동시성 14. 점진적인 개선 15. JUnit 들여다보기 16. se
성능이 나쁜 코드불필요한 연산이 들어가서 개선의 여지가 있는 코드의미가 모호한 코드이해하기 어려운 코드네이밍과 그 내용이 다른 코드중복된 코드비슷한 내용인데 중복되는 코드들은 버그를 낳는다.나쁜 코드는 또다른 나쁜 코드를 낳는다.나쁜 코드는 생상성을 저해시킨다.결국 기
프로그래머는 누구나 나쁜 코드가 업무 속도를 늦춘다는 사실을 안다. 하지만 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 생각한다.여기서 두번째 부분은 사실이 아니다. 나쁜 코드를 양산하면 엉망진창인 상태로 인해 속도가 늦어지고, 기한을 놓치게된다.
클래스는 하나의 기능만 가지며, 어떤 변화에 의해 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.SRP 책임이 분명해지기 때문에, 변경에 의한 연쇄작용에서 자유로워질 수 있다.가독성 향상과 유지 보수가 용이해진다.실전에서는 쉽지 않지만 늘 상기해야 한다.변경을
코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다.자신이 저지른 난장판을 주석으로 설명하지 말고 개선하는 데 시간을 보내야 한다.코드로도 의도를 표현할 수 있다.코드의 변화에 따라가지 못하고, 주석은 방치된다.코드는 컴파일되어 호출되지만 주석은 그저
가독성에 필수적이다.코드를 잘못 해석하는 경우를 방지할 수 있다.코드 길이는 200이하를 유지코드 길이가 200라인 넘어간다면, 클래스가 여러개의 일을 하고 있을 수도 있다.현업에서의 대부분의 코드들도 200라인 정도를 유지한다.밀접한 개념은 서로 가까이 둔다.행 묶음
데이터 그 자체자료를 공개한다.변수 사이에 조회 함수와 설정 함수로 변수를 다룬다고 객체가 되지 않는다.(getter, setter)비즈니스 로직과 관련지료를 숨기고, 추상화 한다.자료를 다루는 함수만 공개한다.추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의
오류 코드를 리턴하지 말고 예외를 던져라현재는 예외를 던지는 것이 일반화 되었다. 처리 흐름이 깔끔하다.Exception을 상속하면 checked Exception. 명시적인 예외 처리가 필요하다.예 : IOException, SQLExceptionRuntimeExce
오픈 소스, 라이브러리를 안쓰는 프로젝트는 없다.우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다.외부 코드는 외부에서 만든 코드인데, 외부 시스템을 호출하거나 단순히 외부에서 만들어진 코드일 수 있다.우리 코드와 외부 코드를 깔끔하게 통합시키기 위해 경계를 잘
테스트 코드는 실수를 바로잡아준다.테스트 코드는 반드시 존재해야 하며, 실제 코드 못지 않게 중요하다.테스트 케이스는 변경이 쉽도록 한다. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 테스트 케이스가 있으면 변경이 두렵지 않다. 테스트
클래스를 개발할 때 기본적으로 구현을 감추고, 외부 객체와 상호작용 하는 부분만 노출한다.외부의 잘못된 사용을 방지한다.경계에서 배웠던 부분(Map)함수와 마찬가지로 클래스도 작아야 한다.함수는 라인 수로 크기를 측정했는데, 클래스는 맡은 책임의 수로 크기를 측정한다.
contruction(생성)과 use(사용)은 아주 다르다.소프트웨어 시스템은 (어플리케이션 객체를 제작하고 의존성을 서로 '연결'하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 분리해야 한다.객체의 생성과 객체를 사용하는 부분을 분리한다.객체의 생성은
하위 계층에는 없는 특성이나 행동이 상위 계층(전체 구조)에서 자발적으로 돌연히 출연하는 현상각각의 개미는 집을 지을 능력이 없지만, 작은 개미들의 상호작용을 통해 집이라는 결과물이 나온다.이처럼 작은 요소들의 상호작용의 반복이 전체 구조에 영향을 미친다.단순한 4가지
서버(코어)가 클라이언트의 요청이 완료되도록 그저 기다리기 때문에 다른 작업이 실행되지 못한다.서버의 수가 늘어나서 한번에 처리할 수 있는 작업의 수는 늘어났지만, 이 역시 받은 요청을 처리하는 동안 서버는 다른 작업을 하지 못한다.클라이언트의 요청이 완료되지 않더라도
모든 로직이 하나의 클래스에 들어가 있다.처음부터 지저분한 코드를 짜려는 생각은 없었고, 코드를 어느정도 손봤지만, 새로운 인수 유형이 들어오면서 재앙이 시작됐다.이제는 개선해야 할 때라는 것을 깨닫고, 변경 전후 시스템이 동일하게 돌아간다는 사실을 확인하기 위해 테스
오픈소스 코드 분석 어떻게 하나repository 이름과 README.md를 보고 프로젝트의 성격을 파악한다.패키지 구조를 살펴본다 ex) 멀티 모듈 프로젝트인가?필드 설정파일(build.gradle)을 보고, 어던 디펜던시(모듈)을 쓰나 살펴본다.config 패키지