클린코드

깨끗한 코드와 오류 처리는 확실한 연관성이 있으므로 오류 처리는 상당히 중요합니다.하지만 오류 처리 코드로 인해 프로그램 논리를 이해하지 어려워진다면 깨끗한 코드라 부르기 어렵습니다.이 장에서는 오류를 처리하는 기법과 고려 사항 몇 가지를 소개합니다. 오류 코드보다 예외를 사용하라예외를 지원하지 않는 프로그래밍 언어에서는 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였기 때문에 호출자의 코드가 복잡해지고 이 단계를 잊어버리기 쉽습니다.예외 처리를 사용한다면 오류 프로그램 논리와 오류 처리 코드가 섞이지 않아 코드가 더 깔끔해집니다.// 예외 처리 미사용public void orderProduct(long productId, int orderCount) { Product pro..

저는 코드를 구현할 때 할 때 단순함과 체크 포인트를 가장 중요하게 생각합니다.체크 포인트란 신경 써야 하는 부분을 말하는데 체크 포인트를 없앨수록 단순함은 올라갈 것입니다. 그럼 어떻게 체크 포인트를 줄이고 단순함을 올릴 것이냐?여러 가지 방법이 있겠지만 가장 기본적인 객체 지향 프로그래밍과 도메인 로직, 비즈니스 로직을 구분 지어 코드를 작성하는 것이라고 생각합니다.(이제부터는 제 아주 주관적인 생각을 정리한 글입니다. 반박 시 여러분들 말씀이 다 맞습니다!) 그럼 객체 지향 프로그래밍이란 무엇일까요?객체 지향 프로그래밍(Object-Oriented Programming, OOP)은 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체로 만들고, 객체들 간의 상호작용을 통해 로직을 구성하..

자료 추상화 변수를 비공개(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개의 숫자를..

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