코드유희

Clean Code - 의미 있는 이름 모두 좋은 내용이지만, 개인적으로 핵심만 정리했다. 의미있게 구분하자 애매한 -Info, -Data, -Manager, -Processor 같은 접미사는 피하자. 정확한 정보제공을 위한 단어만 사용하자. 발음과 검색이 쉬운 단어를 사용하자.  타 프로그머와 육성으로 소통하기 쉬운 단어를 사용하자. 그리고 검색이 쉬운 단어가 프로그램 수정을 더 쉽게 할 수 있다. 만약 알파벳 1글자로 사용하는 변수를 사용하려면, 메서드에서 로컬변수 혹은 Loop 의 변수 초기화 때만 사용하자. 해법 영역/문제 영역의 이름을 활용하자.  해법 영역은 컴퓨터 공학 분야를 이야기하는 것 같다. Visitor 패턴을 사용할 때는 AccountVisitor, Queue를 사용하면 JobQueue 같은 이름을 사용하자. 해법 영역에서 답을 못찾으면 구현하려는 Domain 영역에서 작명해보자. 구현에 관련된 작명. 인터페이스와 구현클래스 인터페이스와 구현 클래스 이름 중 인코딩 방식을 넣어야 한다면 구현 클래스를 추천한다.  인터페이스 : ShapeFactory 구현 : ShapeFactoryImpl 생성자 메서드  생성자를 중복정의 할때, 정적 팩토리 메서드를 사용하자. 메서드는 인수를 설명하는 이름을 사용하자. 생성자 : Complex fulcrumPoint = new Complex(23.0) 정적 메서드 : Complex fulcrumPoint = Complex.FromRealNumber(23.0); 마치며   사람들이 이름을 바꾸지 않으려는 이유 하나는 다른 개발자가 반대할까 두려워서다. 하지만 좋은 코드를 만드는 우리의 책임감이 있다면 일단 Nudge 부터 시작해야 한다. 

주석 결론 . 코드를 잘 만들면 주석을 적지 않아도 된다.   코드를 의도대로 표현하지 못해서 주석을 만드는 것이다. 표현력이 풍부한 코드는 존재 자체를 이해하기 쉽니다. 반대로 부족한 코드는 주석으로 설명이 필요하다. 그렇다면 좋은 코드를 만드는 편이 더 쉽고 빠른 개발 방법이 아닐까?   주석은 언제나 거짓말을 한다. 시간이 흐를수록 주석의 내용과 코드의 기능은 점점 멀어져간다. 프로그램은 비즈니스 요구에 따라 언제나 변한다. 이 변화를 주석에 계속해서 적는 것도 개발자의 몫인데, 과연 얼마나 많은 사람이 일관성 있게 유지할 수 있을까? 좋은 주석과 나쁜 주석 법적인 주석  저작권 등 법적인 이유로 회사나 팀이 정한 주석이 있다면 주석을 작성해야 한다. TODO 주석  아래와 같은 상황에서 작성할 수 있다. 당장 구현하기 어려운 업무를 기술 더 이상 필요 없는 기능을 삭제하는 알림. 누군가에게 문제를 봐달라는 요청. 더 좋은 이름을 제안해달라는 부탁. 앞으로 발생할 이벤트에 맞춰 수정 부탁. 소스 형상 관리 Tool.  소스 형상 관리 Tool을 잘 사용하면 나쁜 주석을 많이 피할 수 있다. 이력, 저자 같은 주석은 지우고 형상 관리 Tool을 사용하자.

함수 작게 만들어라.  함수를 작게 만들어서 좋아진다는 근거는 없지만, 저자의 경험 상 작은 함수가 좋다고 이야기 한다. 예시로는 함수의 Line 수가 2~4개로 설명하고 있다. 한 가지만 하라. 함수는 한가지를 해야 한다. 그 한가지를 잘해야 한다. 그 한가지만을 해야 한다.  함수 이름으로 여러가지 활동을 유추할 수 있다면, 그 활동을 다른 함수들로 쪼개는 작업을 해야 한다. 위에서 아래로 코드 읽기: 내려가기 규칙  내려가기 규칙을 제안한다. 한 함수의 다음 함수는 추상화 수준이 낮아져야 한다. 그러면 위에서 아래로 코드를 이야기처럼 이해할 수 있다. 서술적인 이름을 사용해라.  이름이 길어도 좋다. 비난 받아도 상관없다. 자세한 내용을 주석으로 사용하지 않을까? 서술적인 긴 이름이 주석보다 더 개발자들에게 쉽고 직관적으로 받아드린다. 길어도 좋은 이름을 선택하자. 반복하지 마라.  중복인 함수와 같은 작업하는 함수는 줄이자. 함수 작명법.  함수와 인수가 동사/명사 쌍을 이뤄야 한다. 예를들어 write(name)은 누구나 곧바로 이해한다. '이름' 이 무엇이든 '쓴다'는 뜻이다. 좀 더 나은 이름은 wirteField(name) 이다. 그러면 '이름'이 '필드'라는 사실이 분명히 드러난다. 오류 코드보다 예외를 사용해라 Try-Catch 문장을 하나의 메서드로 만들자. 오류 처리도 한가지 작업이기 때문에 오류 처리 함수는 오류만 처리한다.  함수인자  이상적인 함수 인자의 개수는 '0'개다. '0' 개로 만들기 위해 노력해라.  변환함수에서 입력/반환 인수. Stringbuffer transformer(StringBuffer in)  void transform(StringBuffer out)   저자는 1번을 추천한다. 변환 함수에서 출력 인수를 사용하면 혼란스러울 수 있다. 일반적으로 인수를 입력으로 해석한다. 상태를 변경해야 한다면 함수가 속한...

Quick Sort  Quick Sort는 빠른 Sort 중 하나로 매일 까먹어서 정리하기 위해 작성했다. 원리 QuickSort 정렬 원리  원리는 Pivot(=기준값)을 중심으로 작은 값과 큰 값을 바꾸는 방법로 정렬한다. 1차 정렬이 끝나면 정렬의 대상을 다시 분리한다.  Pivot 을 결정한다. 정렬한다. 2개로 쪼갠다. 다시 1번으로 돌아간다. 코드  그런데 정렬 갯수가 적어지면, Quick Sort 보다 일반 정렬이 더 빠르다. 그래서 Quicksort를 진행하는 Limitation을 줬다. package org . example . algorithm . sort . quicksort ; import java.util.Arrays ; import java.util.Random ; import java.util.Stack ; public class Quicksort { private static final int QUICKSORT_SORT_LIMIT = 10 ; static void swap ( int [] a , int idx1 , int idx2 ) { int t = a [ idx1 ]; a [ idx1 ] = a [ idx2 ]; a [ idx2 ] = t ; } // 퀸 정렬 static void quickSort ( int [] a ) { Stack < Integer > leftIndexStack = new Stack <>(); Stack < Integer > rightIndexStack = new Stack <>(); leftIndexStack . push ( 0 ); rightIndexStack . push ( a . length - 1 ); int ...

Clean Code - 서문  IT회사 신입들이 필독서 중 하나라는 이야기를 듣고, 늦었지만 이제부터 읽기 시작했다. 개인적으로 300 page 이상의 책을 별로 좋아하지 않지만 그래도 차근차근 chapter씩 정리할 예정이다.  Clean Code는 소통에서 시작한다.  이 책은 Clean Code를 위한 절대적인 지침서가 아니라는 전제를 밝힌다. 핵심은 팀이나 공동체가 합리적인 원칙을 세우기 위해 계속 소통해야 한다는 점이다.  유지보수 업무가 중요하다.  소프트웨어 업무의 80% 이상은 "유지보수"다. 좋은 소프트웨어를 처음부터 잘 만드는 것도 중요하지만, 계속될 유지보수 업무도 생각해야 한다. AI가 프로그래머를 대체할 수 없다.  코드는 절대 사라지지 않는다. 인간의 요구사항을 섬세하고 상세히 표현할 수 있는 수단은 프로그래머의 코드밖에 없다. 다음은 없다.  코드는 다시 반영 전보다 더 좋은 상태로 만들어야 한다. 시간에 쫓겨 대충 만들고 나중에 고치겠다는 마음은 버리자. 르블랑의 법칙처럼 나중은 없다. 좋은 코드를 책임지자.  빡센 일정과 터무니 없는 요구사항을 핑계로 Dirty Code를 만들지 말자. 요청자가 개발자들을 쪼아(?)가며 밀어붙이는 이유는 그들의 책임 때문이다. 그렇지만 좋은 코드를 사수하는 일도 프로그래머의 책임이다. 좋은 코드를 책임지기 위한 행동을 먼저 생각하자.  마무리...  서문부터 아주 뼈를 박살내는(?) 내용이 많다. 모두 내 이야기 같아 부끄럽고, 한편으로 시스템 관리업무의 중요성도 알려줘서 고맙기도 했다.

BigDeciaml With Java  이번 Post는 Java에서 금액을 저장할 때 사용하는 방법을 기록한다. 원시형(primitive) 변수로 저장하는 방법과 Java가 지원하는 Class를 정리한다. double/float  한국은 소수점 밑으로 금액이 없다. 그래서 int타입 변수로 처리하는 로직을 생각할 것이다. 하지만, 환산과 세율로 인해 소수점 곱셈이 발생하면 int타입으로는 해결할 수 없다. 그러면, 소수점을 지원하는 double과 float을 생각한다. 그런데 double과 float의 사칙연산 결과는 우리가 생각하는 것과 다르다. @Test public void 원시형 _ 사칙연산 () { double a = 0.1 ; double b = 0.2 ; double c = 0.3 ; // double 끼리 사칙연산. System . out . println ( a + b - c ); // 예상 : 0 / 결과 : 5.551115123125783E-17 System . out . println ( a * b * c ); // 예상 : 0.006 / 결과 : 0.006000000000000001 float d = 0.1f ; float e = 0.2f ; float f = 0.3f ; // float 끼리 사칙연산 System . out . println ( d + e - f ); // 예상 : 0 / 결과 : 0.0 System . out . println ( d * e * f ); // 예상 : 0.006 / 결과 : 0.0060000005 // 섞어서 사칙연산 System . out . println ( a + e - f ); // 예상 : 0 / 결과 : -8.940696738513054E-9 Sy...