더 나은 프로그래머 되는법 2주차 - 권태형 #538
Conversation
TaeHyoungKwon
requested review from
jongfeel,
hemil0102,
ymkim97,
aquamagic9,
fkdl0048,
tttghost and
dhlee3994
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @TaeHyoungKwon, 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 closes issue #534 and includes the author's reflections on chapters 9 through 13 of the book 'Becoming a Better Programmer'. The changes consist of adding markdown files, each representing a chapter, with the author's thoughts and discussion points.
Highlights
- Chapter Reflections: The pull request adds the author's personal reflections and discussion points for chapters 9 through 13 of 'Becoming a Better Programmer'.
- Bug Hunting (Chapter 10): The author shares their perspective on bug prevention and debugging, emphasizing the importance of understanding code behavior at a low level and improving communication to avoid errors.
- Testing (Chapter 11): The author discusses the essence of testing as validation and shares their evolved perspective on testing methodologies, viewing them as tools to be applied based on the situation.
- Complexity (Chapter 12): The author reflects on managing complexity in codebases, relating it to how code is divided and the relationships between different parts of the system, ultimately emphasizing that complexity is often introduced by people and requires careful consideration.
- System Design (Chapter 13): The author shares their experiences with messy codebases and emphasizes the importance of maintaining the core logic of a service, even when facing unexpected changes and constraints.
- Anticipating the Unexpected (Chapter 9): The author discusses the importance of anticipating all possible scenarios, including error cases, and the need to avoid defensive coding for situations that should never occur.
Changelog
Click here to see the changelog
- 2025/Becoming a Better Programmer/taehyoung/10.md
- Added reflections on Chapter 10, 'Bug Hunting'.
- Discusses bug prevention strategies and debugging approaches.
- 2025/Becoming a Better Programmer/taehyoung/11.md
- Added reflections on Chapter 11, 'Testing'.
- Focuses on the core purpose of testing as validation.
- 2025/Becoming a Better Programmer/taehyoung/12.md
- Added reflections on Chapter 12, 'Complexity'.
- Explores the concept of complexity in codebases and its relation to human decision-making.
- 2025/Becoming a Better Programmer/taehyoung/13.md
- Added reflections on Chapter 13, 'Two Systems'.
- Discusses system design and the challenges of maintaining clean code in real-world scenarios.
- 2025/Becoming a Better Programmer/taehyoung/9.md
- Added reflections on Chapter 9, 'Anticipating the Unexpected'.
- Emphasizes the importance of handling errors and unexpected situations.
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.
A better programmer's quest,
To learn and always be their best,
With thoughts well-placed,
And knowledge embraced,
A coding journey, truly blessed.
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 personal reflections on several chapters of the book 'Becoming a Better Programmer'. The reflections cover chapters 9 through 13. Overall, the content is thoughtful and provides insights into the author's understanding and application of the book's concepts. There are no specific code changes, but rather personal notes and opinions on the chapters.
Merge Readiness
The pull request consists of personal reflections on the book 'Becoming a Better Programmer' and does not contain any code changes. Therefore, it is ready to be merged. I am unable to directly approve the pull request, and users should have others review and approve this code before merging.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 버그를 줄이는 구체적인 방법에 대해서, 본인이 생각하는 혹은 주로 사용하는 방법을 이유와 함께 말해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
어떤 기능을 구현했을 때 예상하는 결과값 혹은 실행이 일치하는지 확인해보는 방식으로 버그를 줄였는데 이번 책을 읽으면서 가장 작은 수준에서의 단위 테스트로 시작하여 통합테스트, 시스템 테스트와 같이 점점 확장되는 방식으로 테스트를 진행하는 것이 훨씬 더 효과적이라는 것을 배웠습니다. 테스트 주기가 빠를수록, 코드가 작성된 직후에 테스트를 진행 할수록 버그를 줄일 수 있다고 생각합니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 버그를 줄이는 구체적인 방법에 대해서, 본인이 생각하는 혹은 주로 사용하는 방법을 이유와 함께 말해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
요구사항에 맞는 정확한 설계, 테스트 케이스, 예외 처리 이고
이 방법들은 모두 소프트웨어 개발과 설계 기법에 소개된 내용들입니다.
구체적인 방법에 대해 책마다 예시로 소개되었지만,
책의 예시들은 실제 도메인 문제를 해결하는 것도 있지만 설명을 위한 예시들이 많으므로
실제 실무에서 적용해 보면서 버그가 생기고 해결해야 하는 방법에 대해 터득한 후
버그를 줄여나가는 방식이 현실적이면서도 맞는 방법이라고 생각합니다.
There was a problem hiding this comment.
특별한 방법은 없네요. 통제 가능한 요소를 정확하게 통제하고 이를 검증하기 위한 테스트 작성을 통해 버그를 최대한 줄이려 노력하고 있습니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 코드 기준이 아니더라도, 실생활에서 복잡도와 관련된 것을 많이 만나게 되는데, 복잡도를 잘 다뤄본 혹은 실패해본 경험이 있는지 얘기해봅시다 |
There was a problem hiding this comment.
지난 주에 근로기준법에 근거한 근로시간 계산 프로그램을 개발하면서 복잡도가 있었다고 소개해 드린 적이 있었는데요.
엑셀로도 계산하기 어려웠던 걸 파악하고 이해하면서 복잡도를 해결해 나갔던 경험이 있었습니다.
완성해서 배포하기는 했지만 짧은 시간에 많은 걸 파악하고 개발하기에 시간이 터무니없이 부족해서
도메인에 대해 이해하는 데 더 많은 시간을 썼던 것 같습니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 개인적으로 디자인 타운 에서 말하는 가치에 대해선 동의하지만, 현실적으로는 대부분 지저분한 대도시에 해당된다고 봐야할 것 같습니다. 그럼에도 디자인 타운에서 말하는 가치 중에 가장 중요하다고 생각하는 것은 어떨 것 일까요?(저는 일관성 뽑겠습니다 - 코드 분석 할 때, 이부분에서 가장 많이 헷갈림이 발생함) |
There was a problem hiding this comment.
처음부터 잘 설계된 디자인 타운 처럼 만들고 싶어하는 생각은 다들 있겠지만
어떤 이유에서인지 개발하다 보면 지저분한 대도시 처럼 되긴 하죠.
하지만 그걸 지저분한 대도시가 되지 않게 끝까지 집중해서 기능 단위의 설계 느슨한 컴포넌트 단위의 연결 등 여러 설계 기법을 유지시키면서 개발해 나가야 그래도 디자인 타운에 근접한 모습이 되지 않을까 합니다.
저는 책에 소개된 내용을 뽑자면
설계를 위한 시간과 설계를 가지고 작업하기입니다.
일관성도 중요한 보편적인 가치일 수 있지만
이걸 유지하기 위해서는 설계는 해야 하고 설계 품질이 유지되는 방식으로 나가야 일관성도 맞춰 나갈 수 있다고 생각합니다.
어떻게 보면 저도 일관성에 가까운 생각이긴 하네요.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 버그를 줄이는 구체적인 방법에 대해서, 본인이 생각하는 혹은 주로 사용하는 방법을 이유와 함께 말해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
특별한 방법은 없네요. 통제 가능한 요소를 정확하게 통제하고 이를 검증하기 위한 테스트 작성을 통해 버그를 최대한 줄이려 노력하고 있습니다.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Close #534