From 1a47df20e9bb6cad03ce2a082d2a8793b891d49f Mon Sep 17 00:00:00 2001 From: SEOHEE CHOI <165611407+karnelll@users.noreply.github.com> Date: Sun, 10 Aug 2025 20:16:57 +0900 Subject: [PATCH] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../\354\265\234\354\204\234\355\235\254.md" | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 "14\354\236\245/\354\265\234\354\204\234\355\235\254.md" diff --git "a/14\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/14\354\236\245/\354\265\234\354\204\234\355\235\254.md" new file mode 100644 index 0000000..8b2af59 --- /dev/null +++ "b/14\354\236\245/\354\265\234\354\204\234\355\235\254.md" @@ -0,0 +1,43 @@ +# 14장. 점진적인 개선 + +## 인상 깊은 내용 + +**프로그래밍은 과학보다 공예에 가깝다.** + + 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다. + 초등학교 시절 선생님들도 (대개 허사였지만) 작문할 때 초안부터 쓰라고 하셨다. 깔끔한 작품을 내놓으려면 단계적으로 개선해야 한다고 가르치려 애쓰셨다. + +**대다수 신참 프로그래머는 (대다수 초딩과 마찬가지로) 이 충고를 충실히 따르지 않는다. '돌아가는' 프로그램은 그 상태가 어떻든 그대로 내버려둔다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.** + + 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. + +**점진적으로 개선하다.** + + 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다. + 그래서 나는 테스트 주도 개발이라는 기법을 사용했다. TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다. + 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. + +**소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 부수하기 훨씬 더 쉬워진다.** + +**결론** + +* 나쁜 코드보다 프로젝트에 장기적·심각하게 악영향을 미치는 요소는 없다. +* 나쁜 일정은 다시 조정할 수 있지만, 나쁜 코드는 시간이 지날수록 무게가 늘어나 팀의 발목을 잡는다. +* 너무 서두르다 보면, 이후로 영원히 악성 코드라는 굴레를 짊어지게 된다. +* 처음부터 코드를 깨끗하게 유지하는 것이 훨씬 쉽다. +* 아침에 엉망으로 만든 코드를 오후에, 5분 전에 만든 코드를 지금 정리하는 것이 가장 효과적이다. +* 코드는 항상 깔끔하고 단순하게 유지하며, 절대 썩어가게 방치하지 말아야 한다. + +--- + +## 느낀점 + +14장을 읽으며, 새로운 프로젝트에 몰두하느라 미뤄둔 리팩토링이 필요한 기존 프로젝트들이 떠올랐다. 리팩토링의 필요성을 알고 있었지만, 스스로 외면하고 있었던 것 같다. 이번 기회를 통해, 새로운 프로젝트를 시작하기 전에 시간이 지나 코드가 썩어 문드러지기 전에 기존 프로젝트부터 정리해야겠다고 다짐했다. + +특히 + +> *“아침에 엉망으로 만든 코드를 오후에, 5분 전에 만든 코드를 지금 정리하는 것이 가장 효과적이다”* + +라는 문장이 크게 와닿았다. 처음부터 코드를 깨끗하게 유지하는 것이 훨씬 쉽다는 점을 다시금 느꼈다. 앞으로는 마감 기한에 쫓겨 빠르게 구현하는 데만 집중하기보다, 코드 품질을 유지하며 개발하는 습관을 들여야겠다. + +다만, 마감 기한을 맞추는 것 또한 중요한 과제다. 결국 ‘속도’와 ‘품질’ 중 어느 쪽을 우선순위로 두어야 할지 고민이 된다. 물론 촉박한 일정 속에서는 쉽지 않겠지만, 두 가지를 균형 있게 병행할 수 있는 방법을 찾아야겠다고 생각했다.