더 나은 프로그래머 되는법 3주차 - 이동현 #547
Conversation
dhlee3994
requested review from
TaeHyoungKwon,
aquamagic9,
fkdl0048,
hemil0102,
jongfeel,
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 @dhlee3994, 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
Hello team, Gemini here (or gemini-code-assist, if you prefer!). I've analyzed this pull request from @dhlee3994. The primary goal of this PR, based on the title and description, is to add notes and discussion points covering chapters 14 through 23 of the book "Becoming a Better Programmer". The author mentions finding the book increasingly interesting. The changes involve adding a single new Markdown file containing these notes and a specific discussion topic.
Highlights
- Book Notes Added: This pull request introduces a new file containing notes and summaries for chapters 14-23 of the book 'Becoming a Better Programmer'.
- Discussion Point: YAGNI vs. Extensibility: A key discussion topic is presented, exploring the challenge of balancing the YAGNI principle ('You Aren't Gonna Need It') with designing for future extensibility, particularly when domain knowledge is limited.
- Key Programming Principles: The notes list several important principles from the chapters, including the need to formalize team rules, recognize their potential to change, value code consistency, write only necessary code, avoid premature generalization, think before coding, and understand that passing tests doesn't equate to perfect software.
Changelog
- 2025/Becoming a Better Programmer/donghyeon/ch14~23.md
- Added a new Markdown file.
- Includes notes and summaries for chapters 14-23 of 'Becoming a Better Programmer'.
- Contains a discussion section on balancing YAGNI and extensibility.
- Lists key programming principles derived from the chapters.
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.
Read the code and learn,
Chapters teach a better way,
Grow as programmer.
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
This is a well-structured and thoughtful summary for chapters 14-23 of 'Becoming a Better Programmer.' The discussion question in the '논의' section regarding the balance between YAGNI and designing for extensibility is particularly insightful and a common challenge for developers. The key takeaways listed in the '내용' section are clear, concise, and capture important software development principles. Overall, this is a valuable contribution. Great job!
Summary of Findings
- Missing Newline at End of File: The Markdown file
2025/Becoming a Better Programmer/donghyeon/ch14~23.mdis missing a newline character at the very end (after line 23). It's a common convention in text files, including Markdown, to end with a newline. This can prevent issues with some tools or when concatenating files. As this is considered a low-severity issue, a direct review comment was not added per the repository's review settings. - Title Punctuation Suggestion: In
2025/Becoming a Better Programmer/donghyeon/ch14~23.md, the main title on line 1 uses an equals sign:# 더 나은 프로그래머 되는법 = ch14~23. For more conventional Markdown title styling, you might consider using a colon or a hyphen, for example:# 더 나은 프로그래머 되는법: ch14~23or# 더 나은 프로그래머 되는법 - ch14~23. This is a minor stylistic suggestion (low severity), so a direct review comment was not added per the repository's review settings.
Merge Readiness
This pull request appears to be in good shape and the content is well-prepared. The Markdown file provides a clear summary and a thought-provoking discussion prompt. While I am unable to approve pull requests directly, based on this review, there are no critical or high-severity issues that would prevent merging. The minor points noted in the findings summary can be addressed at the author's discretion.
| ## 논의 | ||
|
|
||
| 같은 코드라도 도메인 특성, 의도에 따라 YAGNI가 되기도, 확장성 설계가 되기도 하는 것 같습니다. | ||
| 간단하게 예를 들면, 인터페이스와 구현체가 1:1 대응이 될 때, 의도적인 추상화라면 '확장성 설계'가 될 것이고, | ||
| '그냥 인터페이스가 있으면 좋으니까'라면 YAGNI가 될 것 같습니다. | ||
|
|
||
| 좀 억지스러운 예제라고 느끼실 수도 있지만 그만큼 저는 YAGNI와 확장성 사이의 균형을 잡는 것이 어렵다고 생각하는데요. | ||
| 특히나 도메인에 대한 충분한 이해가 없는 경우에는 정확한 판단이 매우 어려운 것 같습니다. | ||
|
|
||
| 여러분들은 어떤 기준으로 둘을 구분하시나요? | ||
| 너무 추상적인 질문이지만 평소에 궁금했었던 내용이라 논의내용으로 선정했습니다. |
There was a problem hiding this comment.
종필님 논의 내용과도 비슷한 맥락의 논의라고 생각되는데요
도메인에 대한 충분한 이해가 있다고 하더라도, 섣부른 확장성 있는 설계는 신중하게 결정해야한다고 생각하는 편 입니다. 책에서 코드는 변한다에 대해서 저도 동의하는 바인데, 어떻게 보면 변경 가능성이 있냐 없냐의 확률 문제로 볼 수있을거 같고, 도메인에 대한 충분한 이해가 있는 전제에서는 어떤 부분에서 확장성이 필요하다는 예측이 맞을 가능성이 높기 때문에, 그 확률을 믿고 가볼 수 있을 것 같습니다
그렇지 않다면, 확률의 측면으로 볼 때, 일단 YAGNI가 맞을 것 같습니다
결론은 확률의 문제인데, 제 경험 상에서는 처음부터 섣부르게 판단해서 일반화하고, 확장성을 고려하는 것 보다는, 코드가 충분히 성숙해졌고, 어떤 패턴들이 보일 때, 귀납적으로 판단하여서, 확장성을 고려하는 설계를 적용하는게 더 성공확률이 높았던 것 같습니다
|
|
||
| ## 논의 | ||
|
|
||
| 같은 코드라도 도메인 특성, 의도에 따라 YAGNI가 되기도, 확장성 설계가 되기도 하는 것 같습니다. |
There was a problem hiding this comment.
저도 이 부분 분간이 어렵습니다.
당장 필요한 구현만 하라고 하는데,
일을 하다보면 확장성을 생각해야 나중에 일할 때 편할 것이라 생각이 들어 미리 작업해야 하나를 망설입니다.
그래서 저는 약간 기준이,
나중에 일할 것을 대비해 미리 작업하되 이로인해 현재 추가할게 어려워지거나 마무리가 안된다 느껴지면...
그 작업은 안하고, 확장보다는 지금 할 것에만 집중하자라고 되돌아가는 것 같습니다.
반면에 지금 미리 확장을 추가해도 지금 하는 일에 영향이 적다면,
구현해둬도 무리가 없던 것 같아요.
| 같은 코드라도 도메인 특성, 의도에 따라 YAGNI가 되기도, 확장성 설계가 되기도 하는 것 같습니다. | ||
| 간단하게 예를 들면, 인터페이스와 구현체가 1:1 대응이 될 때, 의도적인 추상화라면 '확장성 설계'가 될 것이고, | ||
| '그냥 인터페이스가 있으면 좋으니까'라면 YAGNI가 될 것 같습니다. | ||
|
|
||
| 좀 억지스러운 예제라고 느끼실 수도 있지만 그만큼 저는 YAGNI와 확장성 사이의 균형을 잡는 것이 어렵다고 생각하는데요. | ||
| 특히나 도메인에 대한 충분한 이해가 없는 경우에는 정확한 판단이 매우 어려운 것 같습니다. | ||
|
|
||
| 여러분들은 어떤 기준으로 둘을 구분하시나요? | ||
| 너무 추상적인 질문이지만 평소에 궁금했었던 내용이라 논의내용으로 선정했습니다. |
There was a problem hiding this comment.
저는 확장성도 고려해야 겠지만 지금 필요한 동작을 하는 코드를 단순한 설계를 통해 구현하자 쪽에 더 가깝습니다.
언급하신 단어로는 YAGNI죠.
그리고 먼저 코멘트를 단 태형님 의견에 동의하는게 처음에는 어떻게 확장될지 예측해서 만들었어도
코드가 생성되고 나면 패턴과 정리 방향이 보이는 때가 옵니다.
저도 그때가 확장성을 고려하는 설계를 적용해야 될 때라고 봅니다.
반대의 상황이라면
동작하는 코드의 덩어리들을 만들어 둔 게 없는데 어떤 디자인 패턴을 쓰면 좋을지를 고민하는 게 예시라고도 볼 수 있겠죠.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
읽을 수록 재밌는 책이네요 :)
closes #542