Map of Dev

추상화 코드 블럭 내의 코드들을 추상화를 해야한다 왜냐하면 세부적인 건 변동할 확률이 높아서 추상적으로 먼저 안정적이게 틀을 잡아야한다. 그리고 프로그래머가 세부적인 것보단 핵심에 좀더 집중할 수 있게 해준다 예를들자면 아래 코드들과 같다 public interface Vehicle { double getFueltankCapacityInGallons(); double getGallonsOfGasoline(); } 위 코드를 아래와 같이 바꾼다 public interface Vehicle { double getPercenFuelRemaining(); } 아니면 이렇게도 가능하다 public class Point { public double x; public double y; } 위의 코드를 아래로 바꾼다 ..

정보를 제공하는 주석 때로는 기본적인 정보를 주석으로 제공하면 편리하다. 예를 들자면 반환할 값에 대한 설명이다 // kk:mm:ss EEE, MMM dd, yyyy 형식이다. Pattern timeMatcher = Pattern.compile( "\\d*:\\d*:\\d* \\w*, \\w* \\d*, \\d*"); 이왕이면 시각과 날짜를 변환하는 클래스를 만들어 코드를 옮겨주면 더 깔끔해 질수 있긴하다. 의도를 설명하는 주석 때때로 주석은 이해를 돕는 수준이 아니라 의도 자체를 알려줄 수도 있다. 예를 들자면 함수가 기능을 수행할때 그것의 코드블럭의 코드가 어떻게 그 기능을 수행하게 되는지 불분명할때 알려줄 수 있다. 의도를 명료하게 밝히는 주석 인수나 반환값 자체를 명확하게 만들면 좋긴 하겠지만, ..

나쁜 코드는 주석을 달게 아니라 새로 짜라 일단 잘 달린 주석은 그 어떤 정보보다 유용하지만, 신중하지 못한 주석은 더 이해하기 어렵게 만든다. 오히려 주석은 달면 무조건 좋은게 아니라 절대 선이 아니라 필요악임을 명심해라. 코드만으로 대게 의도를 충분히 표현할 수 있고 그렇게 되면 주석은 전혀 필요가 없다. 주석은 단지 우리가 코드로 의도를 표현하는데에 '실패' 했을 때, 만회하기 위해 선택하는 차악일 뿐이다. 그런 이유도 있지만 좀더 큰 이유는, 코드는 시간이 지남에 따라 변화하고 진화하지만 주석은 언제나 코드를 따라가지 못한다. 시간이 지남에 따라 점점 더 코드와 괴리되서 주석이 무엇과 관련되있는 것인지 조차 알 수 없는 모호한 고아로 변하는 사례가 너무나도 많다. 심지어 부정확한 주석은 주석이 아..

1. 작게 만들어라 이건 로버트 C. 마틴의 생각이다 그의 40여년간 경험상 작게 만드는게 좋다고 확신한다. 나도 동의한다. 왜냐하면 함수가 길 수록 기억해야 할 것과 집중해야 하는 요소가 많아 져서 이해하기 어려워진다. 또한 짧으면 함수들을 나열한 것처럼 작성이 되는데, 함수는 동사나 동사구를 이름으로 쓰기까지 해서 작성 결과가 마치 이야기 책을 써놓은 것처럼 작성이 되서 이해하기 매우 숩다 2~4 줄인게 좋다고한다 이것을 위해 if, while, for의 코드블록은 한 줄이여야한다. 그리고 대게 거기서는 함수를 호출한다 2. 함수는 한가지만 해야한다. 그런데 정확히 한가지를 한다는 것의 기준이 무엇인가? 리턴만 해야하는가? 조건문을 하나만 써야하는가? 답은 추상화 수준이 하나여야 한다. 세부적인 기능..

1. 검색하기 쉬운 이름을 써라 예를들어 for (int j=0; j

1. 코드의 간결성은 유지하되 함축성을 배제하라 함축성은 읽고 이해할때 읽는 사람에게 어떤 지식 가지고 있다고 가정한다. 이것은 시간이 지남에 따라 인간의 기억력에 큰 부담을 주고, 처음부터 다시 읽어야 하는 상황을 만든다 처음 보는 사람조차 이해할 수 있게 대명사를 배제하고, 코드상의 역할과 동일한 이름을 쓰고, 다른 변수간의 관계가 바로 보이는 이름을 써라 2. 오해의 가능성을 피하라 예를 들어 hp는 hypotenuse(빗변)의 휼륭한 약어처럼 보일지라도 회사명 hp와 충분히 헷갈릴 가능성이 있다 특히 대문자 O와 소문자 l은 숫자 0과 대문자 I와의 혼동을 일으킨다 또한 유사한 개념은 유사한 표기법으로 써서 이해 시의 정보로 쓰일 수도 있는데, 전혀 다른 개념을 유사하게 써서 오해를 일으키는 것도..

1. 나쁜 코드는 개발 속도를 장기적으로 0에 수렴 시킨다. 나쁜 코드는 초반엔 개발 속도가 높지만, 얼마 가지 않아서 나쁜 코드의 단점이 장점을 아득히 넘어선다. 2. 중간 관리자의 독촉이 그들이 나쁜 코드를 원하는 것으로 보여져도 사실 그들도 좋은 코드를 원한다. 단지 일정을 밀어 붙이는 이유는 그것이 그들의 책임이기 때문이다. 비유를 하자면 환자가 의사에게 멸균 과정을 생략하고 빨리 수술을 하라고 독촉을 하는 것과 같다. 그렇다고 해서 의사가 그 과정을 생략해선 안되듯이, 프로그래머도 나쁜 코드의 위험성을 모르는 관리자의 말을 그대로 따라선 안된다 3. 개발 기한을 맞추기 더 쉽다. 나쁜 코드를 써야만 개발 기한을 맞출 수 있을 것 같은 느낌은 환상이다. 결과적으론 더 안좋은 상황을 만든다 Clea..