반응형
2022년 노마드코더의 클린코드 북틸 챌린지에 참여했었다.
당시 남긴 TIL을 모아볼 수 있도록 정리.
https://nomadcoders.co/users/xing
김시은 – 노마드 코더 Nomad Coders
See 김시은's Profile in Nomad Coders
nomadcoders.co
TIL-1. 깨끗한 코드 (2022.02.20[일])
책 에서 기억하고 싶은 내용을 써보세요.
- 코드를 하나하나 짚어가며 저자가 코드를 고쳐간 방식을 이해하고 납득해야 가치를 발휘하는 책이다. (번역판 옮긴이 서문)
- 작은 것에도 충실한 사람이 큰 것에도 충실하다. (추천사)
- 아키텍처도, 깨끗한 코드도, 완벽을 주장하지는 않는다. 단지 최선을 다해 정직하라 요구할 뿐이다. (추천사)
- 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다! (p.2)
- 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. (p.3)
- 르블랑의 법칙 - 나중은 결코 오지 않는다. (p.4)
- 급하다면, 서둘러 끝내려면, 쉽게 짜려면, 읽기 쉽게 만들면 된다. (p.18) -> 급할수록 읽기 쉽게!!!
- 깨끗한 코드
- 세세한 사항까지 꼼꼼하게 처리하는 코드. 철저한 오류 처리
- 한 가지에 집중
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 깨끗한 코드에 관한 여러 프로그래머들의 생각을 읽어보며 그 동안 나는 생각 없이 코딩을 하고 있었던 것 같아 반성했다.
- 워낙 완독하기 힘든 책이라 들었는데, 첫 장이라 그런지 그림도 많아서 괜찮았다.
- 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다는 문장이 특히 공감됐다. 나도 당장 눈 앞에 주어진 문제만을 급하게 해결하려 하다가, 더 나쁜 코드를 만든 적이 많았기 때문이다...
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 소프트웨어 개발의 지혜 책
TIL-2. 의미 있는 이름 (2022.02.20[일])
책에서 기억하고 싶은 내용을 써보세요.
- 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다. (p.24)
- 검색하기 쉬운 이름이 상수보다 좋다. (p.28)
- 클래스 이름, 객체 이름 - 명사, 명사구 적합 (ex. Customer, WikiPage 등)
- 메서드 이름 - 동사, 동사구 적합 (ex. postPayment, deletePage 등)
- 코드를 읽을 사람도 프로그래머이니, 전산 용어, 알고리즘 이름 등을 사용해도 괜찮다. 기술 개념에는 기술 이름이 가장 적합한 선택 (ex. JobQueue) (p.34)
- 적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져오기. 해법 영역과 문제 영역 구분.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- '연속적인 숫자를 덧붙인 이름 (a1, a2 ,...)은 의도적인 이름과 정반대다.' 문장을 읽고 이거 난데? 라는 생각이 들었다. 빠르게 알고리즘 문제를 풀 때 그냥 대충 이름 짓고 넘어갔었는데 앞으로는 어떤 상황이든 의미 있는 이름을 지어야겠다.
- 많은 이름을 접하고 더 나은 이름이 생각나면 수정해야겠다.
- 이름 짓는게 중요하다는 사실은 알았지만, 이렇게 깊게 생각해 본 적은 처음이었다.
TIL-3. 함수
책에서 기억하고 싶은 내용을 써보세요.
- 함수는 작을수록 좋다. 작게 만들어라!
- 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. (p.44)
- 함수 당 "추상화 수준"은 하나로! -> 그래야 한 가지 작업만 함
- 이름이 길어도 괜찮다. 겁먹을 필요없다. 길고 서술적인 이름이 짧고 어려운 이름보다 좋다. (p.49)
- 인수 - best: 입력 인수 0개 > 1개 > ...
- 단항 함수 (인자 1개) - 인수에 질문을 던지는 경우, 인수를 무언가로 변환해 결과를 반환하는 경우 제외하면 가급적 피하기.
- 플래그 인수는 추하다. 함수로 부울 값을 넘기는 관례는 정말로 끔찍하다. 왜냐고? 함수가 한꺼번에 여러 가지를 처리한다고 대놓고 공표하는 셈이니까! 플래그가 참이면 이걸 하고 거짓이면 저걸 한다는 말이니까! (p.52)
- 오류 코드보다 '예외' 사용하면 오류 처리 코드가 분리되어 깔끔해짐 - (p.57)
- 구조적 프로그래밍
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 플래그 인수.. 많이 사용했는데 책 보면서 충격받았다.
- 위에서 아래로 코드를 읽을수록 추상화 수준이 한 단계씩 낮아지게, 구조적으로 스토리텔링을 해야겠다.
- 좋은 함수는 작은 함수!
- 코드 이해하는 게 어려웠다. 이 부분은 찬찬히 다시 복습하며 적용해 봐야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 자바 클래스 다시 한 번 복습하자.
TIL-4. 주석
책에서 기억하고 싶은 내용을 써보세요.
- 주석은 언제나 실패를 의미한다. (p.68)
- 코드로 의도를 표현해야 하며, 주석을 달 때마다 자신에게 표현력이 없다는 사실을 푸념해라. (p.68)
- 코드로 의도 표현! -> 함수 이름에 정보 담기. (p.71)
- TODO 주석 - 앞으로 할 일 남겨두기 (p.74)
- 함수나 변수로 표현할 수 있다면 주석을 달지 마라. (p.84)
내가 작성하던 나쁜 주석
- 위치를 표시하는 주석 - 슬래시(/) 잡음.. 가독성만 낮춤.
- 닫는 괄호에 다는 주석 - 주석 달지말고 함수를 줄이려 노력.
- 주석으로 처리한 코드 - 소스 코드 관리 시스템이 다 기억해준다. 망설이지 말고 삭제해라!
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 4장 마지막 부분에 목록 4-7 코드와 그것을 리팩터링한 4-8 코드. 확실히 4-8이 좋은 코드 같았다.
- 4-7은 내가 달던 주석 그 자체였다. 필요없는 주절주절한 주석을 잔뜩 달아야 이해하기 쉽다고 여겼던 것 같다. 앞으로는 그럴 시간에 코드에 의미를 담도록 해야겠다.
- 코드를 주석으로 처리한 경험이 많은데,, 소스 코드 관리 시스템이 다 기억해주니 걱정말고 삭제하라는 말이 인상깊었다. ㅜㅜ
- 난 표현력이 없었단 사실을 푸념했다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- Javadocs
TIL-5. 형식 맞추기
책에서 기억하고 싶은 내용을 써보세요.
- 어쩌면 '돌아가는 코드'가 전문 개발자의 일차적인 의무라 여길지도 모르겠다. 하지만 이 책을 읽으면서 생각이 바뀌었기 바란다. (p.96)
- "오늘" 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 끼친다. (p.96) -> 그러므로 에이 오늘은 괜찮겠지 하면서 대충 넘기지 말기! 매 순간 최선을!
- 변수 선언: 사용하는 위치에 최대한 가까이 선언. 우리가 만든 함수는 매우 짧으므로 지역 변수 - 각 함수 맨 처음에 선언. (p.101)
- 인스턴수 변수 - 클래스 맨 처음에 선언. 대다수 클래스 메서드가 인스턴스 변수를 사용하기 때문. (p.103)
- 종속 함수 - 호출하는 함수를 호출되는 함수보다 먼저 배치. 위에서 아래로 가독성 up. (p.104)
- 아무리 간단한 if문, 짧은 while문, 짧은 함수더라도 들여쓰기는 꼭 하자. (p.112)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 오늘 구현한 기능이 다음 버전에서 수정될 가능성이 매우 높다. 하지만 오늘 구현한 코드의 가독성이 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 찾아보기 힘들더라도 맨 처음 잡아놓은 구현 스타일, 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. (p.96) - 어차피 수정할건데 대충하자 마인드가 아닌, 매 순간 작성하는 코드가 나중에 큰 영향을 미칠 거라는 것을 기억하자.
TIL-6. 객체와 자료 구조
책에서 기억하고 싶은 내용을 써보세요.
- 객체 - 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다.
- 자료 구조 - 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다.
- 절차적인 코드 - 새로운 자료 구조 추가하기 어렵. 모든 함수 고쳐야 함. / 새 함수 추가하기 쉬움. 기존 자료 구조 변경하지 않으면서.
- 객체 지향 코드 - 새로운 함수를 추가하기 어렵. 모든 클래스 고쳐야 함. / 새 클래스 추가하기 쉬움. 기존 함수 변경하지 않으면서.
- 새로운 자료 타입이 필요한 경우 - 클래스, 객체 지향 기법이 가장 적합
- 새로운 함수가 필요한 경우 - 절차적인 코드, 자료 구조가 더 적합
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 자바에 익숙하지 않아 읽기 어려웠다. 객체지향 프로그래밍에 대해 제대로 공부해야 할 필요성을 느꼈다. 객체와 자료 구조가 근본적으로 양분된다는 사실과, 객체지향과 절차지향 코드의 차이점을 알게 됐다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 디미터 법칙: 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다. 객체는 자료를 숨기고 함수를 공개하므로, 객체는 조회 함수로 내부 구조를 공개하면 안 된다! (p.123)
- 객체라면 내부 구조를 숨겨야 하므로 확실히 디미터 법칙을 위반. 반면, 자료 구조라면 당연히 내부 구조를 노출하므로 디미터 법칙이 적용되지 않는다. (p.124)
TIL-7. 오류 처리
오늘 TIL 3줄 요약
- 깨끗한 코드와 오류 처리는 확실히 연관성이 있다
- 오류 코드보다 예외를 사용하라
- null을 반환, 전달하지 마라
책에서 기억하고 싶은 내용을 써보세요.
- 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. (p.130)
- Try-Catch-Finally 문부터 작성하라 (p.132)
- null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. (p.139)
- 메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. (p.140)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- null을 반환하는 메서드, 메서드에 전달한 null에 대해 다시금 생각하게 됐다..
- 오류 처리를 소홀히 하는 경향이 있었는데, 앞으로 신경 써야겠다.
- 중요하고 많은 도움이 되는 챕터같다!
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- 단위 테스트
- TDD
TIL-9. 단위 테스트
오늘 TIL 3줄 요약
- 단위 테스트 먼저 작성해라.
- 깨끗한 테스트 코드도 실제 코드 못지않게 중요하다.
- 테스트 케이스가 있으면 변경이 두렵지 않을 것.
책에서 기억하고 싶은 내용을 써보세요.
- TDD - 실제 코드를 짜기 전에 단위 테스트부터 작성하라.
- 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다. 그래서 결함율이 높아지기 시작한다. 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다. 변경하면 득보다 해가 크다 생각해 더 이상 코드를 정리하지 않는다. 그러면서 코드가 망가지기 시작한다.
- 테스트 케이스가 있으면 변경이 두렵지 않으니까! (p.157)
- assert 문 개수는 최대한 줄여야 좋다는 생각이다. (p.165)
- 테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자. (p.168)
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- "의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다." 가장 와닿은 문장. 실제 코드 외에도 신경써야 할 중요한 것들이 많다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
테스트 API를 구현해 도메인 특화 언어(DSL)을 만들자. 그러면 그만큼 테스트 코드를 짜기가 쉬워진다.
TIL-10. 클래스
오늘 TIL 3줄 요약
- 큰 클래스 몇 개 보다 작은 클래스 여러 개가 더 바람직.
- 단일 책임 원칙.
- 응집도가 높아지도록 변수와 메서드를 적절히 분리해 새로운 클래스 두세 개로 쪼개기.
책에서 기억하고 싶은 내용을 써보세요.
- 클래스 정의 - 추상화 단계가 순차적으로 내려가도록. 프로그램이 신물 기사처럼 읽히도록.
- 클래스는 작아야 한다.
- 단일 책임 원칙: 클래스나 모듈을 변경할 이유(책임)가 단 하나뿐이어야 한다.
- 큰 클래스 몇 개가 아니라 작은 클래스 여럿으로 이뤄진 시스템이 더 바람직하다.
- 응집도, 캡슐화, 결합도
- 클래스가 응집력을 잃는다면 쪼개라
- 결합도가 낮다 == 각 시스템 요소가 다른 요소, 변경으로부터 잘 격리되어 있다 == 각 요소를 이해하기 더 쉬워진다
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
- 클래스의 간결한 이름이 떠오르지 않는다면 필경 클래스의 책임이 너무 커서 그런 것.
- 지금까지 배운 내용들을 내 것으로 만들어서, 규모가 큰 프로젝트를 할 때 꼭 적용해 보고 싶다!
- 곧 완주...!
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- OCP, DIP
반응형
