Add 'Becoming a better programmer' sprint 2, chapter 8 to 13 review and discussion #535
Conversation
jongfeel
requested review from
TaeHyoungKwon,
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 @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 review and discussion of chapters 9 to 13 of the book 'Becoming a Better Programmer'. The author reflects on the content, finding it repetitive yet valuable for reinforcing good practices. The PR includes links to related issues and proposes a discussion topic related to maintaining quality in software design, emphasizing the importance of a serious and professional attitude towards design rather than just following methodologies.
Highlights
- Book Review: Review of chapters 9-13 of 'Becoming a Better Programmer', focusing on topics like handling unexpected issues, bug hunting, testing, complexity, and system design.
- Personal Reflections: The author shares their thoughts on the chapters, particularly emphasizing the importance of continuous reminders about testing and the challenges of achieving good system design.
- Discussion Point: The PR raises a discussion point about maintaining quality in software design, focusing on developers' mindset and attitude towards design rather than specific methodologies.
Changelog
- 2025/Becoming a Better Programmer/jongfeel/Chater_9_to_13.md
- Added a summary of chapters 9 to 13 of 'Becoming a Better Programmer'.
- Included personal reflections on the chapters' content.
- Proposed a discussion topic about quality maintenance in software design, emphasizing developer attitude.
- Added links to related issues on GitHub.
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 we strive,
For quality to thrive,
Mindset's the key,
To mastery,
Design's art, alive.
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 personal reflections on chapters 9-13 of 'Becoming a Better Programmer'. The author shares their thoughts on the book's content, particularly regarding testing and the importance of a professional attitude towards software design. The author also raises a discussion point about maintaining quality in software projects.
Merge Readiness
The pull request is a valuable addition to the book review series. It provides a concise summary of the chapters and insightful reflections on the content. The discussion point raised by the author is thought-provoking and relevant to software development practices. The pull request is ready to be merged, and I am unable to directly approve the pull request (which I can mention), but you can give feedback about its readiness for merging based on my review and let the other reviewers decide what to do next. Users should have others review and approve this code before merging.
| ## 논의 주제 | ||
|
|
||
| 저는 13장에서 잘 된 예제인 디자인 타운 프로젝트의 설명 중에 품질 유지 부분에 대해 얘기하고 싶습니다. | ||
| 품질 유지 방법 중 하나로 페어 프로그래밍과 설계에 대한 리뷰를 언급해 인상 깊었는데 | ||
| 사실 설계 리뷰 말고 설계에 대한 개발자들의 신뢰, 주인의식, 의무감 등을 언급한 부분에 대해 | ||
| 어떤 자세로 설계하는 것이 책에서 설명한 방법일까?에 대해 의견을 나눠봤으면 합니다. | ||
| SOLID 원칙이나 의존성 분리를 해야 한다와 같은 방법론적인 설계 얘기가 아닙니다. | ||
|
|
||
| 저는 TIP에 설명된 내용이 그 핵심이라고 생각했습니다. | ||
| 설계에 대해 진지하게 대할 때 그 품질이 나온다는 부분입니다. | ||
| 그냥 일이니까 대충 해도 잘 모를 테니까 잘 몰라도 월급은 나오니까와 같이 | ||
| 진지하지 않고 세속적이거나 프로페셔널하지 않은 태도가 설계 코드에 드러나고 | ||
| 그 설계의 품질이 일관성 있게 유지가 되지 않는다고 믿는 쪽입니다. | ||
|
|
||
| 못만들어도 실행은 되고 버그가 없고 쓰는데 불편함이 없다는 자세는 자존심이 허락하지 않는 부분이기도 합니다. | ||
| 몇 년 전에 인상깊게 읽었던 소프트웨어 장인과 소프트웨어 장인정신이 어느덧 제 마음을 다잡게 된 게 아닌가 하는 생각도 드네요. |
There was a problem hiding this comment.
책에 구체적으로 맥락이 좀 나와있지않다보니 저자의 정확한 의도를 추측하기엔 좀 어렵지 않을까 생각됩니다
드러난 내용을 기준으로 봤을 땐, 내가 작성하는 코드를 장인정신을 가지고 지속적으로 품질을 유지한다 정도로 이해할 수 있을 거 같습니다
저의 개인적인 의견은 설계에는 회사와 회사의 비즈니스가 항상 반영이 되어야 한다고 생각합니다
결국, 회사에 속한 개발자라면, 회사와 이해 관계가 있는 계약 관계이기 떄문에,
회사가 어떤 상태인지, 자금과 인력은 충분한지, 어떤 비즈니스를 하려고 하는지 등등이 설계의 기준이 되어야한다는 것 입니다.
종필님이 위에서 말하는 경우 처럼 대충대충하고 월급만 받아먹자 파가 있는가 하면, 나의 커리어적인 이익을 위해서 회사, 비즈니스, 같이 일하는 동료를 고려하지 않고 특정 기술을 사용하고 설계를 주도하는 경우도 있는데요 둘다 회사와 비즈니스 관점을 전혀 고려하지 않는 것으로 볼 수 있을 것 같습니다
There was a problem hiding this comment.
저도 종필님과 같이 설계를 대하는 태도가 매우 중요하다고 생각합니다.
| ## 논의 주제 | ||
|
|
||
| 저는 13장에서 잘 된 예제인 디자인 타운 프로젝트의 설명 중에 품질 유지 부분에 대해 얘기하고 싶습니다. | ||
| 품질 유지 방법 중 하나로 페어 프로그래밍과 설계에 대한 리뷰를 언급해 인상 깊었는데 | ||
| 사실 설계 리뷰 말고 설계에 대한 개발자들의 신뢰, 주인의식, 의무감 등을 언급한 부분에 대해 | ||
| 어떤 자세로 설계하는 것이 책에서 설명한 방법일까?에 대해 의견을 나눠봤으면 합니다. | ||
| SOLID 원칙이나 의존성 분리를 해야 한다와 같은 방법론적인 설계 얘기가 아닙니다. | ||
|
|
||
| 저는 TIP에 설명된 내용이 그 핵심이라고 생각했습니다. | ||
| 설계에 대해 진지하게 대할 때 그 품질이 나온다는 부분입니다. | ||
| 그냥 일이니까 대충 해도 잘 모를 테니까 잘 몰라도 월급은 나오니까와 같이 | ||
| 진지하지 않고 세속적이거나 프로페셔널하지 않은 태도가 설계 코드에 드러나고 | ||
| 그 설계의 품질이 일관성 있게 유지가 되지 않는다고 믿는 쪽입니다. | ||
|
|
||
| 못만들어도 실행은 되고 버그가 없고 쓰는데 불편함이 없다는 자세는 자존심이 허락하지 않는 부분이기도 합니다. | ||
| 몇 년 전에 인상깊게 읽었던 소프트웨어 장인과 소프트웨어 장인정신이 어느덧 제 마음을 다잡게 된 게 아닌가 하는 생각도 드네요. |
There was a problem hiding this comment.
저도 종필님과 같이 설계를 대하는 태도가 매우 중요하다고 생각합니다.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
저는 계속해서 아는 내용의 반복이었지만
10년 전 책에 있는 내용이라면 한 번쯤 아니 한번 이상은 믿어보고 몇 가지라도 실천해 보면 좋겠다는 생각이 많이 들었습니다.
리뷰 내용 링크와 논의 주제는 파일에 적었습니다.
매 챕터마다 생각해보기의 질문에 대해 답을 하는 게 이 책을 읽고 생각을 정리하는 완성형이라는 느낌이 들어
계속해서 생각해보기 부분에 대한 답도 적어보고 있습니다.
논의 주제 외에 생각해보기의 질문들에 대해 적으신 분이 있다면
시간이 될 때 얘기해 봐도 좋겠다는 생각입니다.
Close #534