클린코드

자료 추상화 변수를 비공개(private)로 정의하는 이유는 코드들이 변수에 의존하지 않게 만들고 싶어서다. 그렇다면 어째서 get, set 함수는 당연하게 외부에 공개(public)하는가? 알다시피 변수를 private로 설정한들 조회(get), 설정(set) 함수를 public으로 제공한다면 의미가 없는 샘이다. 변수 사이에 함수를 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스이다. 만약 휴대폰 배터리가 15% 이하일 때 절전모드를 작동한다고 해보자. public interface Phone { Double getBatteryPercent(); } if (phone...

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 착실히 따라야 한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야 한다. 형식을 맞추는 목적 코드 형식은 중요하다! 너무 중요해서 무시하기 어렵다. 너무나도 중요하므로 융통성 없이 맹목적으로 따르면 안 된다. 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 오늘 구현한 기능은 다음 버전에서 바뀔 확률을 매우 높기 때문에 가동성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 그렇다면 원활한 소통을 장려하는 코드 형식은 무엇일까? 적절한 행 길이를 유지하라 JUnit, FitNesses, Time and Money, JDepend, Ant,..

주석 주석은 순수하게 선하지 못하다. 사실상 주석은 기껏해야 필요악이다. 우리는 코드로 의도를 표현하지 못하고 실패를 만회하기 위해 주석을 사용한다. 그러므로 주석이 필요한 상황에 처하면 코드로 의도를 표현할 방법은 없을까 곰곰히 생각해보아야 한다. 코드는 변화하고 진화한다. 하지만 불행하게도 주석은 언제나 코드를 따라가지 않는다. 아니, 따라가지 못한다. 그래서 코드를 읽는 사람에게 더욱 더 혼란을 주고 해악을 미친다. 진실은 코드에만 존재한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 노력해야 한다. 주석은 나쁜 코드를 보완하지 못한다 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 표현력이 풍부하고 깜끔하며 주석이 거의 없는 코드가..

작게 만들어라 함수를 만드는 첫째 규칙은 "작게!"다. 함수를 만드는 둘째 규칙은 "더 작게!"다. 함수가 작을수록 더 좋다는 증거나 자료를 제시하기는 어렵지만 함수는 작고 명확하게 구현해야 한다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록 안에서 호출하는 함수의 이름을 적절히 짓는다면 코드를 이해하기 쉬워질 것이다. 이 말은 중첩 구조가 생길만큼 함수가 켜져서는 안 된다는 뜻이다. 당연한 말이지만, 그래야 함수는 읽고 이해하기 쉬워진다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 지정된 함수 이름 아래에서 추상화 수준이 하나인 단계만 수행한다면 그 함수는 한 가지 작업만 한다. 단순히 다른 표현이 아니라 의미있는 이름으로 다름 ..

의도를 분명히 밝혀라 의도가 분명하게 들어나있는 이름을 지어라. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 그러므로 이름을 주의 깊게 살펴 더 나은 이름이 떠오르면 개선하기 바란다. 변수나 함수 그리고 클래스 이름은 존재의 이유, 수행기능, 사용 방법을 주석으로 설명하지 않아도 알 수 있어야 한다. public Set getNumbers() { Set numbers = new HashSet(); while (numbers.size() < 7) { Integer number = (int) (Math.random() * 45) + 1; numbers.add(number); } return numbers; } 위 함수는 1부터 45까지 중복이 없는 랜덤한 7개의 숫자를..

코드는 언제나 존재한다. 여러 개발자들은 코드는 더 이상 문제가 아니라고, 새로운 기술이나 비지니스 모델의 요구사항에 집중해야 한다고 생각하는 사람도 있다. 실제로 코드의 종말이 코앞에 닥쳤다고 주장하는 사람이 없지 않다. 코드를 자동으로 생성하는 시대가 다가온다는 말이다. 그때가 되면 프로그래머는 필요가 없다. 하지만 이것은 절대로 불가능한 기대다. 인간 조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다. 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라...