더 나은 프로그래머 되는법 2주차 - 김영명 #536
Conversation
ymkim97
requested review from
jongfeel,
TaeHyoungKwon,
hemil0102,
aquamagic9,
fkdl0048,
tttghost,
dhlee3994 and
Copilot
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @ymkim97, 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 summarizes chapters 9 through 13 of the book 'Becoming a Better Programmer' by ymkim97. The summary covers key concepts from each chapter, including handling unexpected errors, debugging strategies (such as binary search using git bisect), the importance of testing (including TDD), managing complexity in code, and the impact of software architecture on system maintainability and development processes. The author also raises questions for discussion regarding the practical application of git bisect and strategies for naming tests.
Highlights
- Error Handling: Chapter 9 emphasizes anticipating unexpected situations and writing code that can recover from errors, including considerations for threading and application shutdowns.
- Debugging Strategies: Chapter 10 discusses various debugging techniques, including the use of binary search (with
git bisect), writing tests to expose assumptions, and utilizing logging effectively. - Testing Importance: Chapter 11 highlights the importance of testing to reduce feedback loops and improve software quality, covering unit, integration, and system tests, and touching on TDD principles.
- Complexity Management: Chapter 12 addresses managing complexity by focusing on code organization and distribution, ensuring each component has a clear role and responsibility, and minimizing inter-component dependencies.
- Software Architecture: Chapter 13 contrasts two system architectures, a poorly designed "dirty metropolis" and a well-designed "design town", emphasizing the importance of clear structure, consistent design decisions, and the YAGNI principle.
Changelog
- 2025/Becoming a Better Programmer/ymkim97/chapter9~13.md
- Added a summary of chapters 9-13 from 'Becoming a Better Programmer'.
- Included key concepts from each chapter: error handling, debugging, testing, complexity, and architecture.
- Added discussion points about
git bisectusage and test naming strategies.
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 bisect command,
A search through commits we scan,
For bugs we must find.
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 provides a summary of chapters 9-13 from 'Becoming a Better Programmer'. The author reflects on the chapters, focusing on testing and code design. The summary includes key takeaways and personal reflections. Overall, it's a well-structured summary with insightful points.
Merge Readiness
The pull request is a summary of the book chapters and doesn't contain any code changes. It is ready to be merged, as it provides a good overview of the material covered. 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.
Pull Request Overview
This PR adds a new markdown document summarizing the key points from Chapters 9 to 13 of the book "더 나은 프로그래머 되는 법", offering insights into topics such as testing strategy, bug hunting, complexity management, and design principles.
- Added a full markdown file containing chapter summaries and personal reflections.
- Organized the content into well-defined sections with headings and bullet points.
Comments suppressed due to low confidence (1)
2025/Becoming a Better Programmer/ymkim97/chapter9~13.md:9
- [nitpick] Consider adding a space between '두' and '가지' for correct Korean spacing (i.e., '두 가지').
저자의 두가지의 시스템에 대한 경험을 통해 설계가 얼마나 중요한지 다시 한번 생각하는 시간을 가질 수 있었습니다.
Co-authored-by: Copilot <[email protected]>
| > 필요해질 때까지 설계상의 결정을 미루라. 요구 사항을 파악하기 전까지 구조 설계를 하지 말라. 추측하지 말라. | ||
|
|
||
| ## [논의 내용] | ||
| * 이진 탐색 전략을 이용할 수 있는 Git 명령어(git bisect)를 이번에 처음 알게 되었습니다. 기능이 매우 흥미롭게 보이는데, 실제로 사용해본 경험이 있으신 분이 있는지 궁금합니다! |
There was a problem hiding this comment.
저도 처음 알게 되었습니다.
실제 쓰게 된다면 commit log가 많아야 할텐데
저의 경우는 commit 단위와 pull request 단위의 큰 차이가 없어서 쓸 일이 없을 것 같기도 하네요.
보통 one pull request에 one to four commits 로 합니다.
4 commits로 bisect 한다면 명령어 두 번이면 되겠군요
There was a problem hiding this comment.
존재는 알고 있었지만, 실무에서 직접 활용해본적은 없는데, 딱히 활용할만한 상황이 없어서 그런것 같네요
There was a problem hiding this comment.
저도 이번 기회에 처음 알게 되었고 간단히 검색해보았을 때는 스크립트를 통해 버그여부를 확인해 탐색을 한다고 하는데 언젠가 필요하다면 한 번 사용해보고 싶네요.
There was a problem hiding this comment.
전에 pro git 스터디할 때 그냥 훑고 넘어간 정도라서 사용해보지는 않았습니다.
|
|
||
| ## [논의 내용] | ||
| * 이진 탐색 전략을 이용할 수 있는 Git 명령어(git bisect)를 이번에 처음 알게 되었습니다. 기능이 매우 흥미롭게 보이는데, 실제로 사용해본 경험이 있으신 분이 있는지 궁금합니다! | ||
| * 책에서는 테스트 이름을 어떻게 작성할지 어느정도 설명해주는데, 실제로 다른 분들께서는 어떤 식으로 이름을 작성하시는지 경험을 공유해보고 싶습니다. |
There was a problem hiding this comment.
테스트 메서드 이름을 문장 형태로 만듭니다.
테스트 케이스가 몇 백개가 되는 데 하나 실패한거 찾아서 읽으려면 문장 형태로 되어 있는 게 좋긴 하더라고요,
예를 들면
Add_two_numbers_test()와 같은 식으로요
There was a problem hiding this comment.
제 개인적으로는 팀내 팀원들이 식별할 수 있다면, 어떤 방식을 써도 괜찮다는 입장입니다 딱히 어떤 방식을 썼을 때 더 좋다 나쁘다 에 대해서 못느끼다보니 요렇게 생각하게 된 것 같네요
There was a problem hiding this comment.
저는 성공 케이스는 ~~ 여야한다, ~~ 해야한다 등으로 끝맺고, 실패 케이스는 예외 종류까지 명시하고 있습니다. (e.g. ~~하면 XXException 예외가 발생한다. )
| > 필요해질 때까지 설계상의 결정을 미루라. 요구 사항을 파악하기 전까지 구조 설계를 하지 말라. 추측하지 말라. | ||
|
|
||
| ## [논의 내용] | ||
| * 이진 탐색 전략을 이용할 수 있는 Git 명령어(git bisect)를 이번에 처음 알게 되었습니다. 기능이 매우 흥미롭게 보이는데, 실제로 사용해본 경험이 있으신 분이 있는지 궁금합니다! |
There was a problem hiding this comment.
전에 pro git 스터디할 때 그냥 훑고 넘어간 정도라서 사용해보지는 않았습니다.
|
|
||
| ## [논의 내용] | ||
| * 이진 탐색 전략을 이용할 수 있는 Git 명령어(git bisect)를 이번에 처음 알게 되었습니다. 기능이 매우 흥미롭게 보이는데, 실제로 사용해본 경험이 있으신 분이 있는지 궁금합니다! | ||
| * 책에서는 테스트 이름을 어떻게 작성할지 어느정도 설명해주는데, 실제로 다른 분들께서는 어떤 식으로 이름을 작성하시는지 경험을 공유해보고 싶습니다. |
There was a problem hiding this comment.
저는 성공 케이스는 ~~ 여야한다, ~~ 해야한다 등으로 끝맺고, 실패 케이스는 예외 종류까지 명시하고 있습니다. (e.g. ~~하면 XXException 예외가 발생한다. )
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Chapter 9 ~ 13
이번에도 정말 재밌게 읽었고, 실제 경험으로 풀어나가는 것을 통해 많은 중요 포인트들을 배울 수 있었습니다.