Add becoming a better programmer: chapter 1 to 8 review links and discussion #525
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 by jongfeel adds a summary and discussion points for the book 'Becoming a Better Programmer', specifically covering chapters 1 through 8. The author has included links to relevant issues, personal reflections on the book's content, and a proposed discussion topic related to avoiding '똥 덩어리 code' (shitty code).
Highlights
- Summary of Chapters 1-8: The pull request provides a concise summary of the key topics covered in the first eight chapters of 'Becoming a Better Programmer'.
- Personal Reflections: The author shares their thoughts on the book, highlighting aspects they found insightful and areas where the translation felt a bit strong.
- Discussion Topic: A discussion prompt is introduced, inviting others to share their strategies for preventing the creation of '똥 덩어리 code'.
Changelog
- 2025/Becoming a Better Programmer/jongfeel/Chater_1_to_8.md
- Added a markdown file summarizing chapters 1-8 of 'Becoming a Better Programmer'.
- Included links to relevant issues for each chapter.
- Added personal reflections on the book's content and translation.
- Proposed a discussion topic on avoiding '똥 덩어리 code', including the author's own approach.
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 programmer's plight,
To write code that shines bright,
Avoiding the muck,
With skill and with luck,
A clean code delight.
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 of the book 'Becoming a Better Programmer' chapters 1 to 8, including personal impressions and discussion topics. The content is well-organized and provides a good overview of the book's key points. However, there are a few areas where improvements can be made to enhance clarity and maintainability.
Merge Readiness
The pull request is in good shape to be merged, as it provides a valuable summary of the book and discussion points. There are no critical or high severity issues. The suggestions provided are aimed at improving the overall quality and clarity of the content, but are not essential for merging. Before merging, it would be helpful to address the medium severity comments to improve the overall quality of the code. I am unable to directly approve this pull request, and recommend that others review and approve this code before merging.
| 약간 거슬렸던 건 어감이 좀 센 말투가 그대로 번역이 됐다는 건데 똥 덩어리 코드와 같은 표현입니다. | ||
| 7장 제목 부터가 똥통에서 뒹굴기인데 아마 코드를 똑바로 작성해야 한다는 경각심을 주기 위한 단어 선택이지 않나 합니다. |
There was a problem hiding this comment.
Consider rephrasing this sentence for better clarity. While the sentiment is understood, the wording could be more professional. Perhaps something like: "The direct translation of some phrases, such as '똥 덩어리 코드', felt somewhat strong."
There was a problem hiding this comment.
Yes, I know. But this book author show up strong words.
| 7장에서 소개하는 똥 덩어리 코드를 짜지 않기 위해 각자 의도적으로 하는 방법이 있는지 얘기해 보면 좋겠습니다. | ||
| 저는 먼저 기능이 실행되는 흐름을 파악해 보고 거기서 어디 까지를 이번 pull request의 범위에 포함할지를 생각합니다. | ||
| 그리고 간단한 인터페이스 1개 혹은 2개를 뽑아보고 메소드를 정의 후 그 기능만 구현하고 단위 테스트 코드를 추가하는 아주 작은 사이클을 실천합니다. No newline at end of file |
There was a problem hiding this comment.
Consider adding a brief explanation of what "똥 덩어리 코드" refers to, for readers unfamiliar with the term. This will make the discussion more accessible.
There was a problem hiding this comment.
Just like spaghetti codes. It means to complex and unclear codes.
|
|
||
| ## 논의 주제 | ||
|
|
||
| 7장에서 소개하는 똥 덩어리 코드를 짜지 않기 위해 각자 의도적으로 하는 방법이 있는지 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
변수명, 함수명을 정할 때 최대한 심플하면서 알아보기 쉽게 하려고 합니다.
그리고 그런 코드 덩어리들을 구역으로 묶어서 제 코드를 보는 다른 이로 하여금 이 구역의 코드는 이런 역할을 하는구나 하게끔...
함수를 여러번 호출 하게 될 때에는 다음에 호출될 함수를 아래 두는 형식도 사용합니다.
There was a problem hiding this comment.
코드
- 요구사항에 모순되지 않게
- 작성 의도가 잘 드러나도록
DB 테이블
- 데이터 무결성을 지키자
- null=True 남용 금지
설계
- 최대한 복잡하지 않게
- 어쩔 수 없이 복잡해 진다면, 그 이유를 충분히 잘 설명할 수 있어야한다
테스트
- 테스트 fixture를 확장성 있게 만들지 못할거라면, 애초에 각 테스트 별로 fixture 코드의 중복을 허용하는게 관리 측면에서 나을 수도 있다
- 내 의도대로 동작하는지를 확인(그 외 작성하는 테스트는 작성할 이유가 없다)
|
|
||
| ## 논의 주제 | ||
|
|
||
| 7장에서 소개하는 똥 덩어리 코드를 짜지 않기 위해 각자 의도적으로 하는 방법이 있는지 얘기해 보면 좋겠습니다. |
There was a problem hiding this comment.
다른 사람이 봤을 때 걸리는 부분이 없을까? 를 생각해봅니다. 처음 이 코드를 본다고 생각하고 처음 본다면 어떤 생각의 흐름을 거칠지, 예를들어 함수명, 변수명을 보고 바로 이 기능을 이해할 수 있을지 등을 점검해봅니다.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
책 내용 정리 링크와 소감, 논의 주제를 본문에 적었습니다.
이번 책은 비교적 쉬운 편이고 내용도 이해하기 좋은 편이라
다들 어렵지 않게 얘기를 하실 수 있을거라 생각합니다.