3줄 요약
- 언제나 코드를 작성할 때 주의깊게 작성하기. 타성에 젖지 않기.
- 어제보다 나아진 코드를 작성하려고하기.
- 계속 연습하기
오늘 읽은 범위
추천사 ~ 1장 깨끗한 코드
책에서 기억하고싶은 내용
- 이 책에 나오는 모든 지침은 로버트 C.마틴이 이미 밝혔듯이 절대적이라 생각하면 안되며, 언제든지 개선의 여지가 있다고 생각하는 편이 바람직하다. 여기서 핵심은 팀이나 공동체에서 서로 동의하는 합리적인 원칙을 세우기 위한 소통에 있다. [xviii]
- 사소한 곳에서 발휘하는 정직은 사소하지 않다 [xxii]
- 책임 있는 전문가라면 프로젝트를 시작할 때 생각하고 계획할 시간을 확보해야 한다. [xxii]
- 제조업이란 메타포에서 재작업은 비용을 뜻하지만 소프트웨어 설계에서 재작업은 가치를 가져온다. [xxviii]
- 깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생을 해야 한다. 스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야 한다. 그들이 넘어지고 일어서는 모습도 봐야 한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야 한다. [xxxii]
- 요구사항을 모호하게 줘도 우리 의도를 정확히 꿰뚫어 프로그램을 완벽하게 실행하는 그런 기계 말이다. [3]
- 이전 버전에 있었던 버그가 다음 버전에도 그대로 남아있었다. 프로그램 시동 시간이 길어지고 프로그램이 죽는 횟수도 늘어났다. 프로그램을 쓰다가 하도 화가 나서 닫아버렸던 날을 기억한다. 그 후로는 다시 사용하지 않았다. 회사는 얼마 못가 망했다.[4]
- 회사가 망한 원인은 바로 나쁜 코드 탓이었다.[4]
- 우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도깜을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그 때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.[4]
- 사용자는 요구사항을 내놓으며 우리에게 현실성을 자문한다. 프로젝트 관리자는 일정을 잡으며 우리에게 도움을 청한다. 우리는 프로젝트를 계획하는 과정에 깊숙히 관여한다. 그러므로 프로젝트 실패는 우리에게도 커다란 책임이 있다. 특히 나쁜 코드가 초래하는 실패에는 더더욱 책임이 크다.[7]
- 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.[7]
- 자신이 의사라 가정하자. 어느 환자가 수술 전에 손을 씻지 말라고 요구한다. 시간이 너무 걸리니까. 확실히 환자는 상사다. 하지만 의사는 단호하게 거부한다. 왜? 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까. 환자 말을 그대로 따르는 행동은 (범죄일 뿐만 아니라) 전문가답지 못하니까. 프로그래머도 마찬가지다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.[7]
- 깨끗한 코드는 언제나누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살펴봐도 딱히 손 댈 곳이 없다.[12]
- 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라. [14]
- 이 책은 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다 [16]
- 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 비록 읽기 쉬운 코드를 짜기가 쉽지는 않더라도 말이다. 하지만 기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. [18]
- 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라. [19]
- 시간이 지날수록 코드가 좋아지는 프로젝트에서 작업한다고 상상해보라! 전문가라면 너무도 당연하지 않은가! 지속적인 개선이야말로 전문가 정신의 본질이 아니던가? [19]
- 예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다. 책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다. 이 책 역시 마찬가지다. 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.[20]
읽은 소감과 떠오르는 생각
- 전문가와 비전문가의 차이는 디테일이라는 생각이 최근에 많이 들었는데, 이 책을 다시 읽으니 이러한 내용이 많이 나와 신기했다.
- 프로젝트를 시작할 때 반드시 생각하고 계획할 시간이 포함되어 있도록 계획을 짜야겠다.
- 소프트웨어 설계에서의 재작업이 개발자에겐 가치가 있다. 하지만 기획자들에게는 당장의 보이는 모습이 중요하다고 생각한다. 그래서 비용이라고만 생각하는 것 같다. 소프트웨어의 재작업을 가치있게 생각하는 곳에서 일하고 싶다는 생각도 든다.
- 추천사를 읽으면서 조던피터슨의 말 중 "다른 사람과 경쟁하지말고 어제의 나와 경쟁하라", "언제나 진실만을 말하라"가 생각났다. 코드를 거짓없이 투명하게 어제의 내 코드보다 나아지게 써야겠다고 생각했다.
- 항상 알고있지만 상황이 닥칠 때마다 받아들이기 힘든 => 고통이 있어야 성장도 있다는 것.
- 2023년 3월부터 GPT3.5 turbo가 나오고 그 이후 GPT4가 나오면서 개발에 있어서 AI의 역할이 점점 커지고 있다. 하지만 LLM은 요구사항을 명확히 주지 않으면 답도 명확하게 주지 않는다. 클린 코드라는 책을 쓰면서 독자는 그 시점에도 알고 있었던 것 같다. 디테일과 정확한 요청같은 것들은 기계도 대체할 수 없다는 것을. 개발자는 사라지지 않는다. 하지만 디테일과 정확한 요구사항을 생각하지 않는 개발자는 사라질 것 같다. 디테일과 정확한 질문과 표현을 할 수 있는 개발자가 되어야겠다.
- 나중에 한다는 말은 안한다는 말과 같다.
- 이 책의 7p 전까지는 나쁜 코드를 짤 수 밖에 없었던 이유가 기획자의 책임도 있다고 생각했다. 아니였다. 온전히 개발자 책임 100%였다. 기획자는 나에게 정보를 구하고 계획을 정했고 현실성을 자문했다. 나는 나쁜 코드로 쓰지 않고 좋은 코드로만 작성하려는 시간까지 계획과 현실성에 포함시킨 대답을 했어야했다.
- 내 코드를 누군가 볼 때 주의깊게 썼다는 인상을 줄 만큼 작성해야 CleanCode다.
- 언제부터인지는 모르겠는데 클린코드라는게 심플한 코드라고만 생각했다. 아닌 것 같다. 레오나르도 다빈치 작품처럼 한땀한땀 소중하게 만든 코드가 클린코드였다.
- 하나의 메서드는 하나의 기능만 하게끔!
- 읽기 쉽게 코드를 작성하는 것이 시간이 오히려 걸릴 것이라고만 생각했는데 전체적인 작성에서는 오히려 읽는 시간을 줄여줘서 전체 시간은 줄어들 것 같다.
- 저자는 보이스카우트에 진심인 것 같다... 그래서 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라를 적어놔야할 것 같다. 30페이지 안팎에서 얼마나 반복을 하는건지;;;;
- 저자는 코드에 진짜 진심인 사람이 맞는 것 같다....... 코드오타쿠같다.....
- 클린코드를 지향한다는 사람이 많은데 이 말이 얼마나 무거운 말인지 느낌.
궁금한 내용이나 잘 이해되지 않는 내용
- 아직 없다.
나 원장이 아니다