-
Notifications
You must be signed in to change notification settings - Fork 0
[최서희] 14장: 점진적인 개선 #34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The head ref may contain hidden characters: "14\uC7A5/\uCD5C\uC11C\uD76C"
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| # 14장. 점진적인 개선 | ||
|
|
||
| ## 인상 깊은 내용 | ||
|
|
||
| **프로그래밍은 과학보다 공예에 가깝다.** | ||
|
|
||
| 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다. | ||
| 초등학교 시절 선생님들도 (대개 허사였지만) 작문할 때 초안부터 쓰라고 하셨다. 깔끔한 작품을 내놓으려면 단계적으로 개선해야 한다고 가르치려 애쓰셨다. | ||
|
|
||
| **대다수 신참 프로그래머는 (대다수 초딩과 마찬가지로) 이 충고를 충실히 따르지 않는다. '돌아가는' 프로그램은 그 상태가 어떻든 그대로 내버려둔다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.** | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 전문가로서 돌아가는 프로그램에 안주하지 않고, 계속해서 개선해 나가는 것은 정말 중요한거 같아요 |
||
|
|
||
| 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. | ||
|
|
||
| **점진적으로 개선하다.** | ||
|
|
||
| 프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다. | ||
| 그래서 나는 테스트 주도 개발이라는 기법을 사용했다. TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다. | ||
| 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. | ||
|
|
||
| **소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 적절한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 부수하기 훨씬 더 쉬워진다.** | ||
|
|
||
| **결론** | ||
|
|
||
| * 나쁜 코드보다 프로젝트에 장기적·심각하게 악영향을 미치는 요소는 없다. | ||
| * 나쁜 일정은 다시 조정할 수 있지만, 나쁜 코드는 시간이 지날수록 무게가 늘어나 팀의 발목을 잡는다. | ||
| * 너무 서두르다 보면, 이후로 영원히 악성 코드라는 굴레를 짊어지게 된다. | ||
| * 처음부터 코드를 깨끗하게 유지하는 것이 훨씬 쉽다. | ||
| * 아침에 엉망으로 만든 코드를 오후에, 5분 전에 만든 코드를 지금 정리하는 것이 가장 효과적이다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 중요한 자세인거 같아요! |
||
| * 코드는 항상 깔끔하고 단순하게 유지하며, 절대 썩어가게 방치하지 말아야 한다. | ||
|
|
||
| --- | ||
|
|
||
| ## 느낀점 | ||
|
|
||
| 14장을 읽으며, 새로운 프로젝트에 몰두하느라 미뤄둔 리팩토링이 필요한 기존 프로젝트들이 떠올랐다. 리팩토링의 필요성을 알고 있었지만, 스스로 외면하고 있었던 것 같다. 이번 기회를 통해, 새로운 프로젝트를 시작하기 전에 시간이 지나 코드가 썩어 문드러지기 전에 기존 프로젝트부터 정리해야겠다고 다짐했다. | ||
|
|
||
| 특히 | ||
|
|
||
| > *“아침에 엉망으로 만든 코드를 오후에, 5분 전에 만든 코드를 지금 정리하는 것이 가장 효과적이다”* | ||
|
|
||
| 라는 문장이 크게 와닿았다. 처음부터 코드를 깨끗하게 유지하는 것이 훨씬 쉽다는 점을 다시금 느꼈다. 앞으로는 마감 기한에 쫓겨 빠르게 구현하는 데만 집중하기보다, 코드 품질을 유지하며 개발하는 습관을 들여야겠다. | ||
|
|
||
| 다만, 마감 기한을 맞추는 것 또한 중요한 과제다. 결국 ‘속도’와 ‘품질’ 중 어느 쪽을 우선순위로 두어야 할지 고민이 된다. 물론 촉박한 일정 속에서는 쉽지 않겠지만, 두 가지를 균형 있게 병행할 수 있는 방법을 찾아야겠다고 생각했다. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 그래서 빠르게 짜야하는 상황에서는 초반 설계 즉 팀원과 함께 지켜야 하는 코드 컨벤션이 중요한거 같아요
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 이게 진짜 어렵다고 느낍니다... 너무 막 쓰지 않는 선에서 기한이 더 중요하다는 생각이 들어요. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
공감합니다..!