[TIL] 클린코드(Clean Code) - 추천사 ~ 1장. 깨끗한 코드

📆 TIL (Today I Learned) 날짜

2022.02.19

📚 오늘 읽은 범위

추천사 ~ 1장.  깨끗한 코드

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

추천사

• 심지어 자동차 업계도 대다수 활동은 제조가 아니라 유지보수다. (혹은 유지보수 회피다.) 소프트웨어는 80% 이상이 소위 "유지보수"다. 고치는 활동 말이다. 좋은 소프트웨어를 만드는 데 치중하는 전형적인 서양식 사고를 포용하는 대신, 우리는 좀 더 건축 업계의 수리공이나 자동차 업계의 수리공처럼 소프트웨어 개발자를 생각해야 한다. (p.xxiii)
• 불행히도 우리는 세세함에 집중하는 태도가 프로그래밍 기술에 핵심적인 주춧돌이라 여기지 않곤 한다. 코드에서는 일찌감치 손을 뗀다. 구현을 끝냈기 때문이 아니라 본질(substance)보다 모양새를 중시하는 가치체계 때문이다. 이처럼 부주의한 태도는 결국 문제를 일으킨다. 달갑지 않은 소식은 언제나 있기 마련이다. 깨끗한 코드를 유지하는 수준을 낮추고자 하는 연구는 업계는 물론 학계에서도 없다. (p.xxvi)
• 품질은 하늘에서 뚝 떨어진 위대한 방법론이 아니라 사심 없이 기울이는 무수한 관심에서 얻어진다. 그 활동이 간단하다고 해서 단순하다는 뜻은 아니다. 쉽다는 의미는 더더욱 아니다. 일상적이고 간단한 활동 모두가 인간의 노력에 들어 있는 위대함과 아름다움의 바탕이다. 이들을 무시하고서는 제대로 인간적일 수 없다. (p.xxvii)
• 장인 정신을 익히는 과정은 두 단계로 나뉜다. 바로 이론과 실전이다. 첫째, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득해야 한다. 둘째, 열심히 일하고 연습해 지식을 몸과 마음으로 체득해야 한다. (p.xxxii)

1장. 깨끗한 코드

• 앞으로 코드가 사라질 가망은 전혀 없다! 왜? 코드는 요구사항을 상세히 표현하는 수단이니까! 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능하다. 추상화도 불가능하다. 정확히 명시하는 수밖에 없다. 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다. (p.2)
• 궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심한다. 요구사항에 더욱 가까운 언어를 만들 수도 있고, 요구사항에서 정형 구조를 뽑아내는 도구를 만들 수도 있다. 하지만 어느 순간에는 정밀한 표현이 필요하다. 그 필요성을 없앨 방법은 없다. 그러므로 코드도 항상 존재하리라. (p.3)
• 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙(leblanc's Law)을 몰랐다. 나중은 결코 오지 않는다. (p.4)
• 나쁜 코드가 쌓일수록 팀 생산성은 떨어진다. 그러다가 마침내 0에 근접한다. (p.5)
• 우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다. (p.6)
• 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. (p.7)
• 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다. (p.7)
• javadoc에서 @author 필드는 저자를 소개한다. 우리는 저자다. 저자에게는 독자가 있다. 그리고 저자에게는 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다. (p.17)
• 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 비록 읽기 쉬운 코드를 짜기가 쉽지는 않더라도 말이다. 하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. (p.18)
• 미국 보이스카우트가 따르는 간단한 규칙이 우리 전문가들에게도 유용하다. 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if 문 하나를 정리하면 충분하다. (p.19)

보이스카우트 규칙
캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

😀 오늘 읽은 소감 및 떠오르는 생각

• 당장 다음주부터 SI 프로젝트를 시작을 앞두고 있고 프로젝트에서 PL 및 분석,설계 역할도 해야해서 그런지 요구사항이라는 단어에 많은 관심이 쏠리는 것 같다. 물론 개발 업무도 해야하기 때문에 코드에 대한 부분도 당연히 관심사다. 이런 생각을 아주 자주 해보곤 한다. 요구사항을 명확하고 상세하게 도출하고 그 요구사항을 기반으로 기능 설계를 하는 작업 모두가 결국은 제대로 된 코드를 작성하기 위한 작업이 아닐까?
• 추천사부터 1장 깨끗한 코드까지는 깨끗한 코드란 무엇이고 그런 코드를 작성해야 하는 이유에 대한 설명이었다. 2장부터 본격적으로 저자가 생각하는 깨끗한 코드에 대해 설명하고 가르치니 클린 코드라는 문파에 입문한 학생이 되었다는 마음가짐으로 스승의 가르침을 제대로 배우는 것에 전념해야겠다.

🤔 궁금한 내용 및 잘 이해되지 않는 내용

• 메타포(metaphor) : 행동, 개념, 물체 등이 지닌 특성을 그것과는 다르거나 상관없는 말로 대체하여, 간접적이며 암시적으로 나타내는 일. 유의어로는 은유가 있다.
• 휴리스틱(heuristic)
  • 문제 해결 시 명확한 실마리가 없을 때 사용하는 편의적ㆍ발견적 방법이고, 알고리즘은 일정한 순서대로 풀어 나가면 정확한 해답을 얻을 수 있는 방법이다.
  • 의사 결정 과정을 단순화하여 만든 지침. 완벽한 의사 결정을 하려는 것이 아니라 이용 가능한 정보를 활용하여 실현 가능한 결정을 하려는 것이 목적이다.
• 휴리스틱 해법 : 컴퓨터로 어떤 문제를 풀 때 경험적 지식을 이용하여 답을 구하는 방법
• 휴리스틱 프로그램 : 컴퓨터로 어떤 문제를 해결하려고 할 때, 경험적 지식을 이용하도록 유도하는 프로그램
• 프리퀄(prequel) : 영화 따위에서 기존의 작품 속 이야기보다 앞선 시기의 이야기를 다루는 속편
• 이 책의 저자인 로버트 C. 마틴(Robert C. Martin)이 클린 코드 보다 더 먼저 출간한 PPP(Agile Software Development: Principles, Patterns, and Practices)라는 책이 있는 것 같다. 클린 코드는 PPP의 프리퀄이라고 한다. PPP는 객체 지향 설계의 원칙을 설명하고 전문 개발자들이 사용하는 실무 기법을 소개하고 있다고 하니 PPP라는 책도 시간내서 읽어봐야겠다. 번역서의 제목은 "소프트웨어 개발의 지혜"(2004 야스미디어, 이용원 외 옮김) 이다.