클린코드, 워낙 유명한 책이고 바이블처럼 여겨지는터라 기대를 갖고 읽기 시작했다. 처음 서문과 추천사만 보고 '오오.. 드디어 나도 코딩의 진리를 깨우치게 되는 건가'라는 설레발을 쳤다.
하지만 기존에 알고 있던 내용은 너무나 뻔하게 보이고, 모르는 내용은 당최 무슨 말인지 알수가 없었다.
- JAVA중심으로 쓰여져서 그런지
- 아니면 번역이 어색한건지
- 내 내공이 부족한건지
이유는 모르지만 10장까지 읽고 나서 크게 얻은 것은 없다는 느낌이다.
특히 1번일수도 있겠다는 생각이 든게 Udemy에서 Poco Jang님의 클린코드 자바스크립트와 클린코드 리액트 강의가 매우 유익했기 때문에 이 책을 보면 강의에서 얻지 못했던 새로운 것을 배우지 않을까 하는 기대를 했기 때문이다.
하지만 뒤로 가면 갈수록 내용은 난해해지고 책을 대충쓴? 느낌이 들어 아쉬움이 컸다.
제일 공들여 쓴 부분이 서문이 아닐까 생각했으니..
그래도 책을 읽으면서 매주 대훈, 원장, 기선 님과 스터디를 진행 했고 그 과정에서 배우는 것들이 많이 있었다. 특히 테스트 작성이나 주석처리 처럼 주로 혼자서 코딩을 하는 내가 신경을 많이 안쓰던 부분을 숙고해볼 수 있었던 계기가 되어서 좋았다.
스터디 기록 보존 및 참고를 위해 스터디 기록 정리를 복붙하는 것으로 클린코드 후기를 마친다.
스터디 1회
목적
- 1~4장 리마인드 겸 복습
- 서로의 생각을 가볍게 공유
진도
- 깨끗한 코드
- 의미있는 이름
- 함수
기억에 남는 소감
1. 깨끗한 코드
- 이 책의 7p 전까지는 나쁜 코드를 짤 수 밖에 없었던 이유가 기획자의 책임도 있다고 생각했다. 아니였다. 온전히 개발자 책임 100%였다. 기획자는 나에게 정보를 구하고 계획을 정했고 현실성을 자문했다. 나는 나쁜 코드로 쓰지 않고 좋은 코드로만 작성하려는 시간까지 계획과 현실성에 포함시킨 대답을 했어야했다. - 원장님
- 한 마디로 읽기 쉽고 유지보수가 가능한 코드가 깨끗한 코드이다. - 데빌님
- 코드를 작성할 때에는 늘 누군가 보고 있다고 생각하고 작성해야 한다고 본다. - 기선님
- 사소한 것에서 발휘하는 정직이 바로 프로 정신, 장인 정신이 아닐까 싶다. 우리는 코드, 개발의 프로 지망생들이다. 코드에서 조차 제대로 정리하지 못한다면 프로라 말할 수 있을까? 부끄럽게 만드는 문구다. - 곽대훈
2. 의미있는 이름
- 이 코드가 어떤 기능을 하는 지 함수나 클래스에서도 명칭으로 충분히 밝힐 수 있게끔 작성하는 것은 중요한 것 같다 - 원장님
- 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다 - 데빌님
- 주석을 사용한다면 본인이 의도를 제대로 표현하지 못한 것 - 기선님
- 좋은 이름으로 리팩토링 하는 것은 중요하다. 피드백을 두려워하지 말자. 언제나 명심할 보이스카웃 규칙! - 곽대훈
Questions
- Interface Class를 Interface라는 사실을 남에게 알리고 싶지 않다는데 이유가 뭘까..?
- 진짜 이름 길게 써도 돼요..? 너무 길면 또 안되지 않을까?
3. 함수
- 플래그도 인수에 넣지 말아야하는구나.. 가끔 넣었던 것 같은데 그러지 말아야겠다. - 원장님
- 중첩 구조가 생길만큼 함수가 커져서는 안된다. 들여쓰기가 1단, 2단 수준이어야 한다. 그렇다면 함수는 얼마나 작아야 하는가? 한 가지만 해야한다. - 데빌님
- 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. - 기선님
- 함수의 return 하나는 너무 팍팍한 것 같다. early return + 최종 return 하나 정도는 괜찮지 않을까? - 곽대훈
Questions
- 함수를 잘게 쪼개서 작성해야 하나?
스터디 2회
목적
- 4~6장 복습 및 생각 공유
- 미션 공유
진도
- 주석
- 실습 1 (2023-02-02)
- 형식 맞추기
- 객체와 자료구조
기억에 남는 소감
4. 주석
기억에 남는 부분
- 주석을 90% 잘써도 10% 이상하게 쓰면 전체적으로 주석이 쓸모없게된다는 말이 인상적이었음 - 원장 -
- 주석이 필요한 상황에 처하면 코드를 변경할 수 없을지를 고민해라 - 데빌님
- 주석을 미래형으로 쓴다? 이것을 해야된다! (TODO) - 기선님
- 법적인 주석, TODO 주석 필요… 끄덕끄덕 👍 - 곽대훈
- 주석에 외부 api spec 에 대해 명시하는 건 어떻게 생각하시나요?
실습 1 (2023-02-02)
같이 서로 리뷰해봐도 좋을 듯?
기억에 남는 부분
- 기선님이 니꼬와 가장 똑같았던게 기억에 남는다! - 원장 -
- 데빌님
- 기선님
- 데빌님 덕분에 js destructuring 문법 알게됨 - 곽대훈
5. 형식 맞추기
기억에 남는 부분
-
내가 편하게 쓰는 코드 포맷팅이 이런 불편함의 역사로 만들어진 것은 생각 못했다. - 원장 -
-
원래 코드는 사라져도 개발자의 스타일과 규율은 사라지지 않는다
그런데 나의 역량이 업그레이드 되면서 스타일이 계속 변한다면? - 데빌님 -
형식을 맞추어서 작성해야한다. 회사는 정해주지 않을까요? - 기선님
- 팀에 같이 장단점 논의해보면서 가져가는게 좋지 않을까요?
-
처음 부터 스타일을 제대로 잡아 놓지 않으면 깨진 유리창이 되기 쉽겠다 - 곽대훈
6. 객체와 자료구조
기억에 남는 부분
- 처음에 개발을 시작할 때 모든 것은 객체라고 배웠다. 근데 저자가 모든 것이 객체라는 것은 미신이라고 했을 때 충격을 많이 받았다. 진리가 깨진느낌. - 원장 -
- 새로운 자료 타입이 필요한 경우 클래스와 객체 지향 기법이 적합하고, 새로운 함수가 필요한 경우에는 절차적인 코드와 자료 구조가 더 적합하다. - 데빌님
- 전반적으로 어려움 ㅠ 어떤 언어에 따라 최적의 사용방법을 찾는게 방법일 듯 ㅠㅠ - 기선님
- 모든게 꼭 객체 지향적이어야 하는 것은 아니다, 객체 지향과 절차 지향의 트래이드 오프를 알고 적절히 사용하자. - 곽대훈
스터디 3회
목적
- 7~10 장 생각 서로 공유 및 리마인드
- 시간되면 서로 실습 2 리뷰
진도
- 오류 처리
- 경계
- 단위 테스트
- 클래스
기억에 남는 소감
7. 오류 처리
기억에 남는 부분
- 원장님 : Try-Catch-Finally 문부터 작성하라
- 데빌님 : 예외를 던질 때는 전후 상황을 충분히 덧붙인다. 그러면 오류가 발생한 원인과 위치를 찾기 쉬워진다.
- 기선님: 오류보다 미확인 예외를 사용하기! 에러처리에 대한 필요성을 배우게 된 날.
- 곽대훈: null 은 이 사회의 악이다
8. 경계, 9. 단위 테스트
기억에 남는 부분
- 원장님 : 결국 테스트 슈트를 폐기하지 않으면 안 되는 상황에 처한다. 하지만 테스트 슈트가 없으면 개발자는 자신이 수정한 코드가 제대로 도는지 확인할 방법이 없다. 테스트 슈트가 없으면 시스템 이쪽을 수정해도 저쪽이 안전하다는 사실을 검증하지 못한다. 그래서 결함율이 높아지기 시작한다. 의도하지 않은 결함 수가 많아지면 개발자는 변경을 주저한다. 변경하면 득보다 해가 크다 생각해 더 이상 코드를 정리하지 않는다. 그러면서 코드가 망가지기 시작한다. 결국 테스트 슈트도 없고, 얼기설기 뒤섞인 코드에, 좌절한 고객과, 테스트에 쏟아 부은 노력이 허사였다는 실망감만 남는다.
- 데빌님 : 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. FIRST규칙
- 기선님: 테스트 코드는 빠르고, 독립적이어야 하고 어떤 환경에서도 반복 가능해야 한다. 빠름이 중요!
- 곽대훈: 이때까지 학습테스트를 단순히 혼자 공부용으로 만들어 놓고 Disabled 하는 경우가 많았다. 그렇게 하지 않고 그대로 나둬도 이후 버전 변경시 용이하게 사용할 수 있겠다
10. 클래스
기억에 남는 부분
- 원장님 : 도구 상자를 어떻게 관리하고 싶은가? 작은 서랍을 많이 두고 기능과 이름이 명확한 컴포넌트를 나눠 넣고 싶은가?아니면 큰 서랍 몇 개를 두고 모두를 던져 넣고 싶은가?
- 데빌님 : 함수는 물리적인 행 수로 크기를 측정하지만 클래스는 맡은 책임을 기준으로 크기가 작아야 한다
- 기선님: 클래스를 작게 분리하면 변경하기 쉽다! (우리가 서랍 정리를 잘해야 하는 듯이?)
- 곽대훈: 한 가지의 책임을 가지게해서 응집도를 늘리고, 추상화로 구현을 격리하여 결합도를 느슨하게 한다면 OOP 원칙(SRP, OCP, DIP 등)이 자연스레 따라오겠구나
