코드유희

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

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

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