자료 추상화 변수를 비공개로 정의할 경우 남들이 변수에 의존하지 않게 만들 수 있어 변수 타입이나 구현을 맘대로 바꿀 수 있다. 자료를 세세하게 공개하기보다는 추상적인 개념으로 표현하는 편이 좋다. 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! 그저 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. // bad public class Point { // 직교좌표계를 사용 // 구현을 노출하게 됨 public double x; public double y; } // good public interface Point ..
형식을 맞추는 목적 코드 형식은 의사소통의 일환이다. 의사소통은 전문 개발자의 일차적인 의무다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준을 유지보수 용이성과 확장성에 계속 영향을 미친다. 적절한 행 길이를 유지하라 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 반드시 지킬 엄격한 규칙은 아니지만 바람직한 규칙으로 삼으면 좋겠다. 일반적으로 큰 파일보다 작은 파일이 이해하기 쉽다. 이름은 간단하면서도 설명이 가능하게 짓는다. 소스 파일 첫 부분은 고차원 개념과 알고리즘을 설명한다. 아래로 내려갈수록 의도를 세세하게 묘사한다. 마지막에는 가장 저차원 함수와 세부 내역이 나온다. ..
주석은 나쁜 코드를 보완하지 못한다 우리는 코드로 의도를 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. 그러므로 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 자신이 저지른 난장판을 주석으로 설명하려 애쓰는 대신에 그 난장판을 깨끗이 치우는 데 시간을 보내라! 코드로 의도를 표현하라! 확실히 코드만으로 의도를 설명하기 어려운 경우가 존재한다. 하지만 몇 초만 더 생각하면 코드로 대다수 의도를 표현할 수 있다. 많은 경우 주석으로 달려는 설명을 함수로 만들어 표현해도 충분하다. // bad // 직원에게 복지 혜택을 받을..
작게 만들어라! 프로그램의 가장 기본적인 단위인 함수 함수를 만드는 첫째 규칙은 '작게!'다. 함수를 만드는 둘째 규칙은 '더 작게!'다. if 문/else 문/while 문 등에 들어가는 블록은 한 줄이어야 하며 대게 거기서 함수를 호출한다. 그러면 바깥을 감싸는 함수가 작아질 뿐 아니라, 블록에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기도 쉬워진다. // good if (isTestPage(pageData)) // 설정 페이지와 해제 페이지를 테스트 페이지에 넣은 후 해당 테스트 페이지를 HTML로 렌더링하기 위해 // 설정 페이지와 해제 페이지를 테스트 페이지에 넣음 includeSetupAndTeardownPages(pageData, isSuite); 한 가지만 해라! 함수는 한 가..
의도를 분명히 밝혀라 변수나 함수 그리고 클래스 이름은 존재 이유, 수행 기능, 사용 방법에 모두 답해야 하며 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. 의도가 드러나는 이름을 사용하면 코드 이해와 변경이 쉬워지므로 정보를 제공하기 위한 코드의 함축성이 중요하다. // bad int d; // 경과 시간 (단위: 날짜) // good int daysSinceCreation; 그릇된 정보를 피하라 그릇된 단어, 흡사한 이름, 일관성이 떨어지는 표기법은 코드의 의미를 흐린다. // bad List가 아닐 때 accountList라고 명명하는 것 // good accountGroup, bunchOfAccounts, Accounts // bad // 1과 l, 0과 O int a = l; ..
코드가 존재하리라 코드를 자동으로 생성하는 시대가 다가온다고 하더라도 앞으로 코드가 사라질 가망은 전혀 없다! 코드는 요구사항을 표현하는 언어이기 때문에 요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라. 나쁜 코드 우리는 나쁜 코드를 헤쳐나간다. 엉킨 덩굴과 숨겨진 함정으로 가득한 늪지를 힘겹게 헤쳐나간다. 단서나 실마리를 찾으려 발버둥치지만 소용이 없다. 그 앞에는 무의미한 코드만 끝없이 펼쳐진다. 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안..
세션 관리 웹 개발을 하며 각각 세션 종류가 많아질 때마다 동일한 세션 메소드를 만들기 보다는 클래스를 만들어서 사용해보자 추상 클래스 AbstractHttpSession 구현 이후 세션에 필요한 클래스(String, int 등 모든 제네릭 가능)를 만들어서 상속받아 사용하면 됨 public abstract class AbstractHttpSession { /** * 세션에 사용되는 이름 (상속받은 클래스에서 세션에 사용될 이름을 가져오기 위함) * @return */ protected abstract String name(); /** * value를 세션에 저장 * @param value */ public void setAttribute(T value) { getSession().setAttribute..
Get - RequestParam String 코드 @Controller @RequestMapping("/example/parameter") public class ExampleParameterController { Logger logger = LoggerFactory.getLogger(getClass()); /* RequestParam String으로 파라미터 받기 http://localhost:8080/example/parameter/example1?id=test123&code=B123 */ @GetMapping("/example1") public void example1(@RequestParam String id, @RequestParam String code, Model model) { model..
