시작하기 전에🙄

학교에서 수업을 들으면서 과제를 하면서 코드를 짜고 하다보면
한 달 정도만 지나서 다시 그 코드를 들여다보면 '도대체 내가 무슨 코드를 짰던 거지?', '나 그 때는 어떻게 짰던 거지?' 싶은 것들이 있다. 분명 내가 짠 것들인데 내가 알아보지 못하는 코드들.

멘토링에서 Clean Code라는 책을 소개시켜 주셨을 때 제일 떠올랐던 생각이다. 게다가 이제는 나 코딩 하는 과제를 하는게 아니라 함께 코딩하는 팀 프로젝트를 하게 될 텐데.. 그래서 취업하기 전에 미리 읽어보면 좋을 것 같다는 생각이 들었다.

---

들어가면서

깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생을 해야 한다. 스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야 한다. 그들이 넘어지고 일어서는 모습도 봐야 한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야 한다.
이 책을 읽는 동안 마음 고생할 준비를 하기 바란다. 비행기 안에서 심심풀이로 읽어보는 "기분 좋은" 책이 아니다. 열심히, 아주 열심히 독파해야 하는 책이다.

1장 깨끗한 코드

코드가 존재하리라📁

프로그래밍 : 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업
코드 : 프로그래밍의 결과, 요구사항을 표현하는 언어

앞으로 코드를 자동으로 생성하는 시대가 올 것이기 때문에 코드를 작성하는 프로그래머도 코드도 사라질 것이라고 하는 전망이 있다. 이 이야기에 대해 코드는 사라질 일이 없다고 한다. 코드는 기계가 실행할 수 있을 정도로 요구사항을 표현하는 언어이기 때문에 코드를 통해 정밀하게 표현할 수 있다. 그렇기에 코드는 항상 존재한다고 말한다.

나쁜 코드💥

"프로그래머라면 누구나 나쁜 코드로 고생한 경험이 있다. 그렇다면 묻겠다. 어째서 나쁜 코드를 짰는가?"

"급해서? 서두르느라? 아마 그럴것이다."

"우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. ... 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다."

르블랑의 법칙 : 나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가❗

나쁜 코드가 쌓일 수록 점점 더 팀 생산성은 떨어지게 된다.

📎원대한 재설계의 꿈

팀 생산성이 계속 떨어지다보면 재설계의 단계까지 가는 경우도 있다. 현재의 모든 기능을 제공하면서도 기존 시스템에 가해지는 변경도 반영해야하는 새로운 시스템을 만들어가는 데는 10년 넘게 걸리는 경우도 있다고한다.
"시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길"

📎태도

코드가 왜 나쁜 코드가 되어버리는 걸까? '일정이 촉박해서, 갑자기 뒤엎어야 하는 요구사항이 와서 등등..' 일정을 잡아버리고 요구하는 마켓팅, 관리자의 책임인가? 프로그래머의 잘못인가? 저자는 프로그래머의 잘못이라고 한다. 마켓팅부서와 관리자가 요구하는 것은 그들의 책임이기 때문에. 반면 프로그래머의 책임에 대해서는 이렇게 말한다.

"우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.
좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다."

📎원초적 난제

나쁜 코드가 업무 속도를 늦춘다는 것을 안다. VS 기간을 맞추고 빨리 가기 위해 나쁜 코드를 만든다.

"기간을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다."

📎깨끗한 코드라는 예술?

"깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다. 깨끗한 코드를 작성하려면 '청결'이라는 힘곕게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 열쇠는 '코드 감각'이다."

그렇다면 계속 얘기해오고 있는 '깨끗한 코드'란 어떤 것일까?

📎깨끗한 코드란?

• 비야네 스트롭스트룹
  보기에 즐거운 코드
  세세한 사항까지 꼼꼼하게 처리하는 코드
  한 가지를 잘 함
  

• 그레디 부치
  가독성 강조 : '깨끗한 코드는 잘 쓴 문장처럼 읽혀야 한다.'
  해결할 문제의 긴장을 명확히 드러내야 함.
  추측이 아니라 사실에 기반해야 하며 반드시 필요한 내용만 담아야 함.

• 큰 데이브 토마스
  다른 사람이 고치기 쉬움.
  큰 코드보다 작은 코드에 가치를 둬야 함.
  인간이 읽기 좋은 코드를 작성하는 것.

• 마이클 페더스
  주의 깊게 작성한 코드
  세세한 사항까지 꼼꼼하게 신경쓴 주의를 기울인 코드

• 론 제프리스
  중복을 피하는 것
  한 기능만 수행하는 것
  명확하게 표현하는 것
  작게 추상화 하는 것

• 워드 커닝햄
  읽으면서 짐작한 대로 돌아가는 코드
  명백하고 단순해 마음이 끌리는 코드
  

우리는 저자다 📝

코드를 짤 때를 살펴보면 새로운 코드를 짜는데 들이는 시간보다 기존의 코드를 읽는데 들이는 시간이 훨씬 많다.
"기존 코드를 읽어야 새 코드르 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다."

"저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다."

보이스카우트 규칙💡

"잘 짠 코드가 전부가 아니다. 시간이 지나도 언제나 깨끗하게 유지해야 한다."

'캠프장은 처음 왔을 때 보다 더 깨끗하게 해놓고 떠나라'

한꺼번에 많은 시간과 노력을 투자해 정리하는 것보다 지속적인 개선 이 필요하다.

---

느낀점✨

왜 깨끗한 코드가 중요한지, 깨끗한 코드란 어떤 것인지에 대해 쭉 읽었다. 지금까지 코드를 배우기도 써보기도 하면서 코드라는 것을 그냥 진짜 말 그대로 코드라고만 생각을 했던 것 같다. 한 번도 컴퓨터와 소통하는 언어, 다른 사람들과 컴퓨터를 통해 소통할 수 있는 언어라고는 생각해 본적이 없는 것 같다. 그렇다보니까 일단 '보기 좋고' 사람이 '읽기 쉬운' 그런 코드 보다는 당장 돌아가는 코드에 집중을 했던 건 아닐까 하는 생각이 든다.

그리고 학년이 올라가면서 수업을 듣게 되면 교수님들이 '유지 보수'에 대해 말을 하실 때가 많았다. 중요하다고. 그래서 설계를 잘 하는게 무엇보다 중요하다고. 이 책이 깨끗한 코드를 짜야 한다고 하는 이유도 같다.

"시간이 지나도 언제나 깨끗하게 유지해야 한다."

코드에 대해 다시 한 번 생각해 보게 된 것 같고, 코드를 작성하는 프로그래머의 입장, 태도에 대해서 생각하게 된 계기가 되었다.

• 프로그래머는 작성한 코드를 누군가가 읽을 수도 있다는 마음을 가지고 적어야 한다.
• 나쁜 코드로 일어난 일은 프로그래머의 책임이고 좋은 코드를 만들기 위한 것은 프로그래머의 책임이다.

처음부터 잘 하는 것은 쉽지 않겠지만, 조금은 느리더라도 처음에 잡아갈 때 깨끗한 코드를 작성하는 것을 습관으로 가져야겠다는 생각이 들었다.

---

책 나눔

같이 책을 읽은 멘티 2명 멘토 2명 해서 같이 읽은 내용중에서 인상깊었던 것, 경험 등을 나눠주셨다. 그 이야기들 중 기억했으면 하는 것들, 공감이 가는 부분들을 나눠보고자한다. 확실히 실무를 경험해 보지 않은 내가 클린 코드를 바라보는 관점과 실무에서도 경력 있으신 분들이 클린 코드를 바라보는 관점이 조금은 다르다는걸 느꼈다. 아무래도 이상과 현실은 존재하는 거니까 이 간격을 잘 메우며 현실에서 노력하는게, 그리고 이상을 실현할 수 있는 능력을 갖추는게 중요하다는 생각이 들었다.

"코드는 함께 완성해 나가는 것이기에 같이 발전시켜 나갈 수 있는 코드를 짜는 것이 중요하다"

코드는 나 혼자 자랑하려고 만드는 게 아니다. 개발하는 사람은 항상 같이 있고 만든 사람이 있다. 함께 하는 사람이 있다는 걸 기억하고 함께 좋은 방향으로 나아가야 한다.

• "좋은 코드, 좋은 코드를 말하긴 하지만 진짜 좋은 코드라는 걸 고민하며 만들어 가고 있나?"

• 실제 회사에 가면은 개발자와 회사는 항상 충동한다. 그렇기 때문에 마감 기간에 대해서 개발자는 언제까지 끝낸다는 생각을 갖고 있어야 한다. 책에서는 '처음 짤 때 부터 좋은 코드를 잘 짜자.'라고 하지만 너무 클린의 트렌드에 따라가서 가독성, 효율성에 너무 갇히지 않아도 된다.

• 그래서 과제에서, 신입사원일 때는 클린 코드를 고민해보면 좋다. 어떤 게 더 중복을 줄일 수 있을 지, 효울적일 지, 요구사항이 바뀌었을 때 바로 바꿀 수 있게 짜보는 건 어떤건지? 등등을 고려해서 연습해보면 도움일 될 것이다.