추천사부터 1장까지 읽은 뒤, 마음에 와닿은 내용 정리한다. 그냥 재밌게 읽은 부분도 있고, 뜨끔했던 부분도 있고, 생각하게 되는 부분도 있었다.

코드 품질을 측정하는 유일한 척도
= 분 당 내지르는 "WTF!" 횟수
신은 세세함에 깃들어 있다.
-- Ludwig Mies van der Rohe
가장 기억에 남는 말이다.
우리는 (소프트웨어) 공장을 전속력으로 가동해 소프트웨어를 재빨리 내놓고 싶어한다.
(중략)
하지만 심지어 자동차 업계도 대다수 활동은 제조가 아니라 유지보수다.
소프트웨어는 80% 이상이 소위 "유지보수"다.
-- p.xxiii
처음 일했던 회사는 스타트업(을 표방하는 기업)이었고, 계속 신사업을 추진하고 사람들을 투입했었다. 이제 마감기일 맞췄으니 고칠부분 찾아보자-하면 다른데로 끌려가는게 다반사였던 기억에 눈물.
5S 철학 - 정리, 정돈, 청소, 청결, 생활화
-- p.xxiv
좀더 자세히 작성하면,
좋은 말들이긴 한데, 일본어에서 시작해서 영어? 덴마크어?로, 다시 한글로 번역되는 과정에서 "5S"가 맞는지는 모르겠다. 책 자체를 보면 비슷한 말을 여러번 반복한거 같기도 하고......결국 줄여서 주고받는 용어로는 애매한거 같지만 (S2는 하트를 만들기라도 하지) 내용 자체는 잘 기억하고 있어야 겠다.
아키텍처도, 깨끗한 코드도, 완벽을 주장하지는 않는다. 단지 최선을 다해 정직하라 요구할 뿐이다.
(중략)
코드는 결코 완벽하지 않으므로 자신의 코드 상태를 정직하게 말한다. 좀더 인간적이 되고, 좀 더 신의 용서를 받을 자격을 갖추며, 좀 더 세세함에 깃든 위대함에 가까워진다.
-- p.xxviii
한국에서는 정말 쉽지 않은 일인거 같다. 12년 동안 틀리는 것을 죄악시 해오는 생활을 하다가 어떻게 하루 아침에 자신의 잘못을 드러낼 수 있을까? 이제는 해야 한다는 것을 알고 있지만, 여전히 쉽지는 않은것 같다.
그래도 자전거를 처음 타는 사람이라면 100% 넘어진다.
-- p.xxxii
Clean Code와는 별개의 여담으로, 개발자 교육을 하는 입장에서 이게 정말 중요하다는 생각을 한다. 앞의 최선을 다해 정직하라 부분과도 일맥상통하는 얘기인데, 처음 하는 입장에서는 당연히 잘 못하고, 당연히 틀리는데, 틀리는게 무서워서 코드 실행도 안해보고 있는 개발자 지망생 분들이 꼭 마음에 새겨두길 바란다.
코드를 자동으로 생성하는 시대가 다가온다는 말이다. 그때가 되면 프로그래머는 필요가 없다.
(중략)
헛소리! 앞으로 코드가 사라질 가망은 전혀 없다! 왜? 코드는 요구사항을 상세히 표현하는 수단이니까!
-- p.2
그냥 ChatGPT가 생각나서 따로 적어두었다. 진짜로 100% 대체할 날이 올지도 모르겠지만, 그때가서 대체 안된 직업은 무엇이 있을까?
기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다. 이렇게 명시한 결과가 바로 코드다.
-- p.2
그들은 우리가 시키는 대로가 아니라 원하는 대로 돌아가는 기계가 나오리라 기대한다.
(중략)
절대로 불가능한 기대다. 창의력과 직관을 보유한 우리 인간조차도 고객의 막연한 감정만 갖고는 성공적인 시스템을 구현하지 못한다.
-- p.3
여기서는 유튜버 Josh Darnit의 Exact Instructions Challenge가 생각났다. 강의 첫날 OT로 맨날 써먹는 이야기기도 하고. ChatGPT 쓸 때 딴소리 하면 드는 생각이기도 하다. 내가 영어를 못해서 그러나?
Later equals never.
-- LeBlanc's Law
그래서 요즘엔 생각난거 바로바로 할려고 노력은 한다. 기한 없는 프로젝트의 장점이라고 해야하나? 잘 안되는 부분, 더러운 부분 가라치고 넘어가지 않고 최대한 붙들고 진행한다. 어쨋든 곧 완성하면 포트폴리오에 추가해야지.
생산성을 증가시키려는 희망을 품고 프로젝트에 인력을 추가로 투입한다. (중략)
새 인력과 팀은 생산성을 높여야 한다는 극심한 압력에 시달린다. 그래서 결국은 나쁜 코드를 더 많이 양산한다.
-- p.5
나름 어릴 때 장의 위치에 있을 기회가 있다보니 실감할 수 있었던 내용이었다. 프로젝트 규모에 따라 다르긴 하겠지만, 지나치게 많은 개발자는 협업의 어려움과 월급 루팡을 만들기 좋다고 생각한다.
겉으로 아닌 듯 행동해도 대다수 관리자는 진실을 원한다. 일정에 쫓기더라도 대다수 관리자는 좋은 코드를 원한다.
-- p.7
음......이건 글쓴이가 한국인이 아니기 때문에 이런 말을 할 수 있다...고 밖에 생각안된다. 저기 유튜브 가서 좋좋소라도 보고 와 주세요~
깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.
-- p.8
대학교 1학년, 코드를 보고 이해가 되어서 그 코드를 나중에 다시 칠 수 있을거라 상상하던 시절이 생각났다.
여기서는 여러 프로그래머들에게 Clean Code에 대한 의견이 정리되어 있다.
깨끗한 코드는 한가지를 제대로 한다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
가독성이 강조된 의견이다.
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로.
저자는 이 책의 주제라고 평가한 말이다.
필자는 론 제프리스의 의견을 길게 인용하였다. 몇줄만 골라두자면,
나는 주로 중복에 집중한다. 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다.
(중략)
객체가 여러 기능을 수행한다면 여러 객체로 나눈다.
메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러개로 나눈다.
이를 필자는 다시 정리하기를,
라고 하며 이 책의 내용을 요약했다고 한다.
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다.
이 책은 나와 내 동료들이 생각하는 깨끗한 코드를 정의한다.
(중략)
하지만 한 문파에서 이렇게 가르친다고 다른 문파가 틀렸다는 이야기는 아니다.
이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.
(중략)
하지만 우리 생각이 절대적으로 '옳다'라는 단정은 금물이다.
옳은 것을 찾는게 아니라 효율적이고 효용적인 방식을 찾는 것이다. 결국 견문을 넓힌다는 방향으로 접근하고 새로운 방식을 찾는다는 마음가짐으로 이 책을 접할 것.
코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다.
(중략)
비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다.
Clean Code의 중요성에 대한 강조로 마무리.
이번 부분은 Clean Code의 중요성에 대한 내용이 주되었다. 그래서 그냥 가벼운 마음으로 읽는게 가능했던것 같다. 중간에 정리하지 않은 부분에, 배우기 어렵고 고생을 한다는 부분이 있었는데, 걱정 반 기대 반.