cleancode

개인적으로 이 주제에 큰 공감이 가서 책을 읽으며 재미가 있었다.아무런 생각없이 급하게 코드를 짜면, 남에게 보여주며 설명할 때 내가 쓴 코드임에도 나도 한참을읽으며 생각해야 했다. 또한 시간이 지난 뒤 읽으면 코드의 의미를 이해하지 못해서 한참을 들여다 보는 경우가

처음 개발을 배우면서 한 현업자 분께서 개발자는 업무시간의 절반 이상이 이름을 짓는데 쓰인다고 말씀하신 적이 있다. 처음에는 농담인 줄 알았으나 개발을 하면 할 수록 좋은 이름이 무엇인가에 대해서 고민을 많이 하게 되었다. 아래의 법칙을 바탕으로 이름을 연습할 것이다.

함수를 만들 때는 '읽기 쉽고', '이해하기 쉽고', '의도가 분명'해야한다첫째 규칙 "작게!"둘째 규칙 "더 작게!"20줄도 길다고 저자는 말한다if/else/while 에 들어가는 블록도 한 줄로!당연한 이야기지만 지키기 어려운 일이다. 함수는 무조건 한 가지 일만

주석은 '순수하게 선하지 못하다!'주석은 코드로 의도를 표현하지 못해 즉 실패를 만회하기 위해서 사용하는 것주석은 오래될 수록 코드에서 멀어진다\-> 코드는 보완하지만 보통 주석은 보완하지 않기 때문에 주석은 거짓말을 하게 됨개인적으로도 항상 주석을 습관적으로 달곤 했

당신이 만약 책을 읽는데 일정한 간격으로 들여쓰기가 되어있고, 문단 별 정리가 잘 되어있는 것이 잘 읽히는가? 아니면 무작위로 여기저기 쓰인 글이 잘 읽히는지를 생각해보면 쉽다!잘 읽혀야하는 이유는 기술의 발전은 빠르고, 오늘 구현한 기능이 다음 버전에서 바뀔 확률이

변수를 비공개(private)로 정의하는 이유는남들이 변수에 의존하지 않게 만들고 싶어서!\-> 변수 타입이나 구현을 마음대로 바꾸게 하고 싶어서왜 그렇다면 변수는 private로 선언하고 get, set 함수를 public으로 설정하는 걸까?2 번을 보면 자료구조를

기존의 오류코드는 아래와 같았습니다.보는 것처럼 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다. 아래와 같이 괴면 간단해진다. 논리와 오류코드가 섞이지 않아서다.try-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면

시스템에 들어가는 소프트웨어를 모두 개발하는 경우는 거의 없다. 즉 외부 라이브러리를 사용하게 되는데 소포트웨어 간의 경계를 깔끔하게 하는 방법들이다.인터페이스 제공자와 사용자 사이에는 긴장이 존재한다제공자는 적용성을 넓히려 한다. (많은 사람에게 판매하기 위해)사용자

애자일과 TDD 덕택에 단위테스트를 자동화하는 프로그래머들이 많아졌으며 점점 더 늘어나는 추세이다.제대로 된 좋은 테스트 케이스를 작성하는 것은 아주 중요하다.실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는

표준 자바 관례에 따르면, 클래스의 구성은<변수목록> static public 변수 -> static private 변수 -> private 인스턴스 변수(공개 변수가 필요한 경우는 거의 없다)<공개 함수>(비공개 함수는 자신을 호출하는 공개 함수 직후에 넣

"복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다."\-레이 오지, 마이크로소프트 CTO-'제작'과 '사용'은 다르다.\-> 소프트웨어 시스템은 준비 과정(애플리케이션 객체를 제작하고 의존성을 연결하는)과 런타임 로직

모든 테스트를 실행한다.중복을 없앤다.프로그래머 의도를 표현한다.클래스와 메서드 수를 최소로 줄인다.중요도 순이며 이 4가지 규칙을 따르면, 코드 구조와 설계를 파악하기 쉬워진다.\-> SRP, DIP와 같은 원칙을 적용하기 쉬워져 창발성을 촉진시킬 수 있다.논문이 있

동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇(what)과 언제(when)을 분리하는 전략이다.이 2개를 분리하는 이유는 아래와 같다.애플리케이션 구조와 효율이 극단적으로 좋아진다. \- 구조적인 관점에서 거대한 루프 하나가 아닌 작은 협력 프로그램