Add chapter 14 to 23 review and discussion #543
Conversation
jongfeel
requested review from
TaeHyoungKwon,
aquamagic9,
dhlee3994,
fkdl0048,
hemil0102,
tttghost and
ymkim97
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @jongfeel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
This pull request adds a review and discussion of chapters 14 to 23 of the book 'Becoming a Better Programmer'. It includes a summary of the chapters, personal reflections, and proposed discussion topics. The author, jongfeel, also provides links to related issues in their BookReview repository.
Highlights
- Chapter Summary: Provides a list of the chapters covered in this review (Chapters 14-23).
- Personal Reflections: Shares personal thoughts on specific chapters, particularly those related to developer attitude, DevOps engineering, and code freezing/release processes.
- Discussion Topics: Suggests a discussion around the acceptance level of the idea that 'nothing is constant' (from Chapter 18) and how to approach code modifications, especially in the context of refactoring.
Changelog
- 2025/Becoming a Better Programmer/jongfeel/Chapter_14_to_23.md
- Added a summary of chapters 14-23.
- Included personal reflections on the chapters.
- Proposed discussion topics related to code ownership, modification, and refactoring.
- Added links to related issues in the BookReview repository.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
In code's vast domain,
Change is the only constant's refrain,
Refactor with care,
Lest chaos ensnare,
A better program we gain.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
The pull request adds a summary and discussion of chapters 14-23 of the book. The content is well-structured and provides a good overview of the chapters and discussion points. However, I have a few suggestions for improvement.
Merge Readiness
The pull request is ready to be merged. The content is well-structured and provides a good overview of the chapters and discussion points. I am unable to directly approve the pull request, and recommend that others review and approve this code before merging.
|
|
||
| 그 때는 그게 정당한 개발의 과정이고 더 좋은 코드 개선의 시간이라고 생각해 리팩터링이라는 대의명분으로 시간을 썼지만, 지금은 한꺼번에 많은 변경을 위해 1주 이상의 시간을 따로 쓸 만큼의 큰 작업을 하지 않습니다. 정말 조금의 변경, 하루 안에 작업할 수 있고 pull request 한 번 혹은 두 번 정도로 해서 정말 미미한 개선을 개발하는 과정 중간에 넣고 개선하는 방향을 가지고 있습니다. | ||
|
|
||
| 이와 관련된 얘기를 자유롭게 해보면 좋겠습니다. No newline at end of file |
There was a problem hiding this comment.
오타가 있어보입니다. 240페이지 수정을 위한 설계 파트를 말씀하시는거죠?
There was a problem hiding this comment.
오타 맞네요.
수정 제안을 해서 main branch에 들어갈 때는 수정된 내용으로 들어갈 예정입니다.
There was a problem hiding this comment.
저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.
지난 모임에서도 태형님이 얘기해 주신 내용으로는 자신이 짠 코드는 절대 수정이 불가능하다 해서 못건드리게 하는 개발자, 그리고 같은 사례로 지수님도 주니어 개발자 시절에 그런 선임이 있었다고 얘기해 주셔서 아주 특이 케이스는 아닌 것 같다는 생각입니다.
변하지 않는 것은 없다 라는 말 자체에 대해선 100% 공감 합니다. 실제로 현업에서 일하면서, 절대로 변하지 않을 것 같았던 요구사항들이 정말 상상도 못하는 형태로 변하는 것을 생각보다 자주 경험을 하다보니, 이 말에 대해선 정말로 공감하게 되었습니다.
여기서 중요한 것은 변하지 않는 것은 없다 라는 것을 깨달은 이후에, 이를 어떻게 내 업무에, 내 코드에 적용시킬까 라는 것인데요. 제 개인적인 생각은 변하지 않는 것이 없는 것은 맞지만, 미래에 언제, 얼만큼 변할지 예상할 수 없기 때문에 일단은 현재 기준에 집중하자 라는 생각이고, 변화가 어떻게 일어날지에 대한 예측 가능성은 시간에 비례 한다고 생각 합니다.
즉, 지금 당장 어떻게 변경될지 모르니까, 현재 기준 요구사항만 고려해서 개발을 진행하고, 시간이 점점흐르면서, 프로젝트의 코드가 어느정도 성숙해졌을 때, 변화의 패턴들이 보이는 시점에 다시 재설계를 진행하는게 합리적인 방안이 아닐까 라는 생각 입니다
There was a problem hiding this comment.
추가로 책에서는 과거 퇴사한 개발자들의 레거시 코드를 못건드리는 이유는 수정할 용기가 없어서라고 했는데, 사실 수정은 할 수 있어도 얼마나 오래 걸릴지 가늠하기 어려운 문제가 더 크지 않나 생각합니다.
저도 말씀주신 내용에 동의하는 바이고, 우선순위의 문제로 볼 수 있을 것 같습니다. 나의 업무가 레거시 코드들을 관리하고, 유지보수 하는 것이 아닌 이상은 대부분의 개발자의 업무는 새로운 피쳐를 만들거나, 요구사항에 맞는 유지보수 업무를 하는 것이기 때문에, 레거시 코드를 건드려서, 굳이 나에게 이익(혹은 명분?)이 없다고 판단한다면, 우선순위에서 당연하게도 밀릴 수 밖에 없는 것 같습니다
There was a problem hiding this comment.
이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다.
수정을 위한 설계를 적용할 것인가? 에 대한 전제조건은 수정이 매우 잦아야 한다고 생각 합니다
애초에 수정이 잦지 않다면, 수정을 위한 설계를 굳이 고려하지 않아도 된다고 생각 합니다
수정이 매우 잦은지, 아닌지 여부는 요구사항 분석을 할 때부터, 확실하게 예측을 할 순 있지만, 이 또한 요구사항이 내가 예상 범위로만 변경이 될거라고, 예측하는 것이기 때문에.. 요구사항이 급변하는 환경에선 저는 어느정도 프로젝트가 성숙한 단계에 와야만 이것을 더 확신을 가지고 예측, 판단할 수 있다고 생각하는 편이고, 위에 글에서 변화가 어떻게 일어날지에 대한 예측 가능성은 시간에 비례 한다 라는 말로도 대체 가능할 것 같습니다
확실히 수정을 위한 설계가 필요하다는 확신이 든 이후에는, 이를 실천하는 구체적인 방법은 상황에 따라서, 개발자의 역량껏 적절한 방법을 고민하고, 선택하면 된다고 생각 합니다(흔히 전략패턴을 쓸지, 추상화 수준에 따라서 레이어를 어떻게 나눠서 배치할지 등)
개인적으로는, 미리부터 수정을 위한 설계를 고려하는 것을 경계하는데요. 그 이유는 순서가 잘못되었다고 생각해서 입니다. 어떤 문제(패턴)이 드러나지 않은 상황에서, 선제적으로 수정을 위한 확장적인 설계를 고려한다는게 너무 비효율적이라고 생각하고 그래서 가능하면 미리 수정을 위한 설계를 고려하지 않는 편 입니다
There was a problem hiding this comment.
주민등록번호도 변할 수 있으니 "변하지 않는 것은 모든 것이 변한다"라는 말뿐이라고 생각합니다.
다만 변화의 텀을 생각하면서 대응해야할 것 같습니다.
100%는 아니지만 많은 경우에 변화에 유연한 코드는 더 많은 양의 코드가 필요한 것 같습니다.
그래서 일정과 변화의 텀을 잘 저울질 하는 것이 중요한 것 같습니다.
There was a problem hiding this comment.
저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.
저도 다른 분들과 마찬가지로 "변하지 않는 것은 없다"라는 것에 100% 공감합니다.
그렇다고 코드를 작성하면서 모든 코드에 대해서 변화를 대비해서 작성해야 하는가 라는 말이 나올 수 있는데 이것은 현실적으로 불가능하고 비효율적이라고 생각합니다.
대신 프로젝트에 기여하는 모든 팀원들이 "변하지 않는 것은 없다"를 모두 인정하면서 변화가 일어날 가능성이 크게 보이는 부분에만 미리 조치를 취하거나, 기록을 하는 방안이 있는 것 같습니다.
|
|
||
| 추가로 책에서는 과거 퇴사한 개발자들의 레거시 코드를 못건드리는 이유는 수정할 용기가 없어서라고 했는데, 사실 수정은 할 수 있어도 얼마나 오래 걸릴지 가늠하기 어려운 문제가 더 크지 않나 생각합니다. | ||
|
|
||
| 이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다. |
There was a problem hiding this comment.
| 이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 대한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다. | |
| 이제 자신의 코드에 대한 과도한 소유욕과 다른 사람의 코드 수정의 불가능에 대한 경우는 지난 모임에 했기 때문에 책에 언급된 '수정을 위한 설계' 단락의 내용을 논의 주제로 얘기해 보면 좋을 것 같습니다. |
|
|
||
| 그 때는 그게 정당한 개발의 과정이고 더 좋은 코드 개선의 시간이라고 생각해 리팩터링이라는 대의명분으로 시간을 썼지만, 지금은 한꺼번에 많은 변경을 위해 1주 이상의 시간을 따로 쓸 만큼의 큰 작업을 하지 않습니다. 정말 조금의 변경, 하루 안에 작업할 수 있고 pull request 한 번 혹은 두 번 정도로 해서 정말 미미한 개선을 개발하는 과정 중간에 넣고 개선하는 방향을 가지고 있습니다. | ||
|
|
||
| 이와 관련된 얘기를 자유롭게 해보면 좋겠습니다. No newline at end of file |
There was a problem hiding this comment.
오타 맞네요.
수정 제안을 해서 main branch에 들어갈 때는 수정된 내용으로 들어갈 예정입니다.
|
|
||
| 그 때는 그게 정당한 개발의 과정이고 더 좋은 코드 개선의 시간이라고 생각해 리팩터링이라는 대의명분으로 시간을 썼지만, 지금은 한꺼번에 많은 변경을 위해 1주 이상의 시간을 따로 쓸 만큼의 큰 작업을 하지 않습니다. 정말 조금의 변경, 하루 안에 작업할 수 있고 pull request 한 번 혹은 두 번 정도로 해서 정말 미미한 개선을 개발하는 과정 중간에 넣고 개선하는 방향을 가지고 있습니다. | ||
|
|
||
| 이와 관련된 얘기를 자유롭게 해보면 좋겠습니다. No newline at end of file |
There was a problem hiding this comment.
주민등록번호도 변할 수 있으니 "변하지 않는 것은 모든 것이 변한다"라는 말뿐이라고 생각합니다.
다만 변화의 텀을 생각하면서 대응해야할 것 같습니다.
100%는 아니지만 많은 경우에 변화에 유연한 코드는 더 많은 양의 코드가 필요한 것 같습니다.
그래서 일정과 변화의 텀을 잘 저울질 하는 것이 중요한 것 같습니다.
|
|
||
| 지난 모임에서도 태형님이 얘기해 주신 내용으로는 자신이 짠 코드는 절대 수정이 불가능하다 해서 못건드리게 하는 개발자, 그리고 같은 사례로 지수님도 주니어 개발자 시절에 그런 선임이 있었다고 얘기해 주셔서 아주 특이 케이스는 아닌 것 같다는 생각입니다. | ||
|
|
||
| 추가로 책에서는 과거 퇴사한 개발자들의 레거시 코드를 못건드리는 이유는 수정할 용기가 없어서라고 했는데, 사실 수정은 할 수 있어도 얼마나 오래 걸릴지 가늠하기 어려운 문제가 더 크지 않나 생각합니다. |
There was a problem hiding this comment.
저 같은 경우는 얼마나 오래 걸릴지 가늠하는 것에 추가로
레거시로 남겨진 코드의 문제해결을 위한 코드의 의도가 온전히 인수인계 되었다면,
그 의도를 보존하면서 코드를 리팩토링할텐데요.
그런 경우가 아니라면 조금 어려움을 느끼는 것 같습니다.
예를 들어서 어떤 서버의 통신 불량을 해결하기 위해 작성된 코드가 있는데,
이 불량이 원인이 잘 파악되지 않는 것이라 땜빵한 코드라 한다면,
땜빵한 코드 자체가 일반적인 상황에서는 심플하지 않아보이므로,
모르는 사람은 리팩토링을 하고 싶어할텐데,
이때 단순히 이 코드가 지저분하다고 수정을 멋대로 해버린다면 큰일 날 수 있습니다.
따라서 용기가 있다면 이런 의도를 잘 물어가면서 수정할 수 있어보이고,
의도를 알 수 없다면 백업을 통해 용기를 내보는 것도 나쁘진 않은 것 같습니다.
|
|
||
| 그 때는 그게 정당한 개발의 과정이고 더 좋은 코드 개선의 시간이라고 생각해 리팩터링이라는 대의명분으로 시간을 썼지만, 지금은 한꺼번에 많은 변경을 위해 1주 이상의 시간을 따로 쓸 만큼의 큰 작업을 하지 않습니다. 정말 조금의 변경, 하루 안에 작업할 수 있고 pull request 한 번 혹은 두 번 정도로 해서 정말 미미한 개선을 개발하는 과정 중간에 넣고 개선하는 방향을 가지고 있습니다. | ||
|
|
||
| 이와 관련된 얘기를 자유롭게 해보면 좋겠습니다. No newline at end of file |
There was a problem hiding this comment.
저는 18장의 변하지 않는 것은 없다를 어느 수준까지 받아들일 수 있는지를 얘기해 보면 좋을 것 같습니다.
저도 다른 분들과 마찬가지로 "변하지 않는 것은 없다"라는 것에 100% 공감합니다.
그렇다고 코드를 작성하면서 모든 코드에 대해서 변화를 대비해서 작성해야 하는가 라는 말이 나올 수 있는데 이것은 현실적으로 불가능하고 비효율적이라고 생각합니다.
대신 프로젝트에 기여하는 모든 팀원들이 "변하지 않는 것은 없다"를 모두 인정하면서 변화가 일어날 가능성이 크게 보이는 부분에만 미리 조치를 취하거나, 기록을 하는 방안이 있는 것 같습니다.
jongfeel
deleted the
542-더-나은-프로그래머-되는-법-sprint-3-14장-23장-총-108페이지-2025-05-16
branch
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
리뷰 내용에 대한 링크와 소감, 논의 내용은 본문에 적었습니다.
Close #542