[노개북] 클린코드 TIL(2022.02.19)

DAY 2

🚀 오늘 읽은 범위 : 추천사 ~  1장 깨끗한 코드

---

 🔥 책에서 기억하고 싶은 내용

기능을 추가할수록 코드는 엉망이 되어갔고, 결국은 감당이 불가능한 수준에 이르렀다. 회사가 망한 원인은 바로 나쁜 코드 탓이었다.

프로그래머라면 누구나 당연히 나쁜 코드로 고생한 경험이 있다. 그렇다면 묻겠다. 어째서 나쁜 코드를 짰는가? 급해서? 서두르느라? 아마 그랬으리라. 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕먹을까 봐, 지겨워서 빨리 끝내려고, 다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고...... 모두가 겪어본 상황이다. 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. (p.4)

... 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그 때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다. (p.4)

일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다.(p. 7)

나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.(p. 7)

원초적 난제
나쁜 코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 곧바로 늦어지고, 결국 기한을 놓친다. 기한을 맞추는 유일한 방법은 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.(p. 7)

깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨긋한 코드를 작성할 줄 안다는 뜻은 아니다.(p. 8)

깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다.(p. 9)

... 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다.(p. 18)

보이스카우트 규칙
한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.(p. 19)

 

 

 

 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보자!

생산성 저하

 처음 이 책을 읽었던 작년 8월의 나는 이제 막 회사생활을 시작했던 한 달 차 신입사원이었다. 기술교육을 받고 있었던 터라 기존의 소스코드를 파악하지도 못했고, 나의 소스코드가 개발 프로젝트에 들어가지도 못한 때였다. 2021년 8월의 나는 그저 나쁜 코드를 작성하지 않는 개발자가 되어야겠다고 생각했다.

 회사에는 나처럼 비전공자이고 국비과정 수료생이었던 입사동기들 중 한 명에대해서 얘기해보고자 한다.(A라고 부르겠다.) 기술교육이 끝나고 메인이 아닌 작은 기능을 개발하나는 업무를 받게 되었다. 첫 개발이라고 주니어 개발자 분과 팀장님께서는 코드 리뷰하는 시간도 챙겨주셨었는데, 그때 A는 공지사항 부분을 맡았었고, pagination과 file upload & download까지 해야 하는 상황이었기 때문에 꽤 많이 어려워했었기 때문에 그분이 개발한 부분을 코드 리뷰하는 시간이 상당히 길었다.

 A는 깨끗한 코드란 무엇인가에 대한 고민은 전혀 해보지 않는 사람이었다. (클린코드에 대한 개념은 아마 지금도 없을 것이다.) naming부터 시작해서 controller와 service 단에 남발되어 있는 System.out.println();은 정말 보는 사람으로 하여금 ‘이 사람은 본인이 짠 소스코드를 주석처리만 할 줄 알고 정리할 줄은 모르는 사람이구나`라는 생각을 게 만들었다.

 생산성저하에 대한 부분에서 A라는 사람의 실력이 낮음으로 이야기를 시작한 이유는, 그 사람이 작성했던 sysout이 들어있는 코드가 몇 개월이 지난 지금 다른 개발자들을 괴롭히고 있기 때문이다. 첫 개발업무 수행 당시, 팀장님께서는 A의 실력 향상을 위해 NCP storage bucket에 파일을 업로드하고 다운로드하는 common API를 만들어보라고 이 개인 과제로 던져주셨다. A는 그 과제를 수행하다가 업무를 제대로 마치지 못한 채로, 어영부영 다음 업무를 맡았다가 결국 스스로 자신의 실력에 한계를 느끼며 퇴사했지만, A가 남긴 Storage API method는 우리 회사 개발자들을 괴롭히고 있고, 어디서 어떻게 사용되고 있는지조차 제대로 파악이 되지 않아 결국 내가 직접 새로운 API를 만드는 수밖에 없었다.

내 인상은 어떨까?

코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야한다.(p. 11)

이 문장을 읽고 나는 “코드에는 프로그래머의 인상이 담긴다”는 것을 깨달았다. 역지사지로 생각해보니, 내가 남긴 코드는 다른 사람에게 어떤 인상을 주고 있을지 생각해보면 설레기도 하고 걱정도 생긴다.

우리는 저자다

Javadoc에서 @author 필드는 저자를 소개한다. ... 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.(p. 17)

이 부분을 읽으면서 스프링 개발자가 이 글을 만약 본다면 꼭 소개하고싶은 Plugin이 있어서 소개하고자 한다. 바로 GitToolBox라는 플러그인인데, line 별로 가장 마지막 commitor를 표시해준다. 회사에서 기존의 코드를 읽다가 이해가 안 가는 부분이 있으면 그 범인(?)을 찾아가 바로 물어볼 수 있기 때문에 한 프로젝트를 여러 명이 개발할 때 범인 찾기에 도움을 주는 플러그인이다.

 

 

 

🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면?

CPU자원을CPU 자원을 낭비하는 코드도 우아하지 못하다.(p. 9)

• 이 책을 두번째로 읽다 보니 자원을 낭비하는 코드는 어떻게 생겼는지가 궁금해졌다. 가짜 개발자에서는 벗어난 것 같아서 기분이 좋다. 검색해보면 아마 스레드나 트랜잭션에 대한 예제 코드가 나올 것 같은데 뭐라고 검색하면 나올까?

메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 ...(p. 14)

• 메서드 추출 기능은 최근에 스프링부트 스터디를 시작하면서 프로젝트 환경설정부터 시작하는 기초내용을 공부하면서 처음 써봤다.
• 1 회독을 할 때는 이 기능이 무엇인지 전혀 몰랐기에 책에 작게 ‘무엇인지 궁금하다. 뒤에 나오나?’라는 메모를 남겨뒀었다. 2 회독을 하는 지금은 이 기능을 써봤고 개쩌는편리함에 반해있는 상태이다. (단축키 : ctrl + Alt + M )