더 나은 프로그래머 되는법 3주차 - 김영명 #548
Conversation
ymkim97
requested review from
TaeHyoungKwon,
aquamagic9,
Copilot,
dhlee3994,
fkdl0048,
hemil0102,
jongfeel and
tttghost
|
우측에 있는 |
![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
Hello! Gemini here, providing a summary of this pull request for a quick overview. This PR, authored by ymkim97, is titled "더 나은 프로그래머 되는법 3주차 - 김영명" which translates to "Becoming a Better Programmer Week 3 - Kim Young-myung". Based on the title and description, the intent is to submit the author's summary and reflections on chapters 14 through 23 of the book "Becoming a Better Programmer" as part of a reading group or study. The author specifically mentions finding Chapter 21, which discusses collaboration with QA teams, particularly impactful and highlights the importance of this relationship.
Highlights
- Reading Group Submission: This pull request appears to be a submission for a reading group focused on the book 'Becoming a Better Programmer', covering chapters 14 through 23.
- Chapter Summaries and Reflections: The main content added is a detailed summary and personal reflection on key concepts from chapters 14 to 23 of the book, including topics like software development metaphors, rules, conciseness, thinking, code change, reuse, version control, QA collaboration, code freezing, and releasing software.
- Emphasis on QA Collaboration: The author specifically highlights Chapter 21, '골키퍼 있다고 골 안 들어가랴' (Even if there's a goalkeeper, the goal will go in?), which discusses the crucial relationship and collaboration between developers and QA teams.
- Discussion Points Included: The submission includes specific discussion points for the reading group, focusing on the software development metaphors from Chapter 14 and useful Git commands beyond the basics from Chapter 20.
Changelog
- 2025/Becoming a Better Programmer/ymkim97/chapter14~23.md
- Added content summarizing chapters 14-23 of 'Becoming a Better Programmer'.
- Included personal reflections on the chapter contents.
- Added specific questions for group discussion.
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.
Chapters read and learned,
Code wisdom now is earned,
Ready for review.
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.
Pull Request Overview
This PR introduces a new markdown document that summarizes chapters 14–23 of "더 나은 프로그래머 되는 법," discussing key programming concepts and collaboration insights learned by the author.
- Adds a comprehensive chapter summary with quotes and reflective commentary
- Includes a discussion section to prompt further dialogue on programming practices and QA collaboration
There was a problem hiding this comment.
Code Review
안녕하세요! '더 나은 프로그래머 되는 법' 3주차 스터디 내용에 대한 PR을 잘 보았습니다. 14장부터 23장까지의 내용을 잘 정리해주셨고, 특히 21장 QA와의 협업에 대한 감상을 자세히 적어주신 점이 인상 깊었습니다. 논의 내용도 흥미로운 질문들로 구성되어 있어 스터디에 좋은 기여가 될 것 같습니다.
코드 자체는 마크다운 파일이라 기능적인 부분보다는 내용의 가독성과 구성에 초점을 맞추어 검토했습니다. 전반적으로 깔끔하게 잘 작성되었으나, 몇 가지 사소한 개선 사항이 있습니다. 본 리뷰에서는 설정에 따라 medium, high, critical 심각도의 이슈에 대해서만 인라인 댓글을 작성했습니다. low 심각도의 이슈는 findings_summary에만 포함하고 인라인 댓글은 생략했습니다.
별도의 스타일 가이드가 제공되지 않아 일반적인 마크다운 작성 관례에 따라 검토를 진행했습니다.
Summary of Findings
- 파일 끝 개행 문자 누락: 마크다운 파일의 마지막에 개행 문자가 누락되었습니다. (Medium severity, commented)
Merge Readiness
PR에 포함된 마크다운 파일은 내용 구성이 좋고 가독성도 뛰어납니다. 발견된 이슈는 파일 끝 개행 문자 누락 하나로, 이는 medium 심각도에 해당합니다. 이 부분을 수정하면 머지하기에 충분히 좋은 상태가 될 것 같습니다. 저는 PR을 직접 승인할 권한이 없으므로, 다른 리뷰어분들의 추가 검토 및 승인 후에 머지하시면 됩니다.
| ## [논의 내용] | ||
|
|
||
| - 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! | ||
| - 20장에서는 버전 관리에 대한 이야기가 나오는데, 개발하시면서 add, commit, push, pull을 제외한 어떤 명령어를 유용하게 사용하시는지 궁금합니다. 저는 stash로 작업했던 것들을 임시적으로 보관하는 것을 많이 사용하는 것 같습니다. |
There was a problem hiding this comment.
유용성의 측면에서 보자면, rebase -i 만큼 유용한 건 없지 않을까 생각되고요
저는 cherry-pick 도 많이 사용 합니다
아마도 이건 잘 모르실 텐데, rerere 라는 기능이 있습니다 설명은 아래와 같습니다
rerere 기능은 이전 충돌 해결 작업들을 기억하고 있다가 유사한 문제가 발생하면 이를 다시 적용 합니다.
반복적인 merge conflict resolve 작업을 해야하는 상황일 때, 위 옵션 설정해두고 사용하면, 이전에 conflict resolve 한 기록을 가지고 있다가 동일한 상황에선 자동으로 resolve 해줍니다
다만, 이전에 conflict resolve 를 할 때, 잘못 resolve 한 경우라면, 잘못 resolve 한것 그대로 적용하니 이부분은 주의해서 써야합니다
요 링크도 참고 하면 좋겠네요
There was a problem hiding this comment.
깃을 잘 다루는 것은 아니지만 rebase를 가장 유용하게 사용하고 있습니다.
|
|
||
| ## [논의 내용] | ||
|
|
||
| - 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! |
There was a problem hiding this comment.
저는 과학 > 스포츠 > 집안일 >>>>> 예술 > 놀이 순으로 순위를 매길 수 있다고 생각 했고, 그 이유는 기본적으로 개발자들의 대부분이 회사에서 고용되어서, 비즈니스 가치를 창출하는 제품을 만드는 일을 하고 있기 때문이고, 대부분 혼자가 아닌 여러 팀원들과 함께 일하기 때문 입니다
| ## [논의 내용] | ||
|
|
||
| - 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! | ||
| - 20장에서는 버전 관리에 대한 이야기가 나오는데, 개발하시면서 add, commit, push, pull을 제외한 어떤 명령어를 유용하게 사용하시는지 궁금합니다. 저는 stash로 작업했던 것들을 임시적으로 보관하는 것을 많이 사용하는 것 같습니다. |
There was a problem hiding this comment.
깃을 잘 다루는 것은 아니지만 rebase를 가장 유용하게 사용하고 있습니다.
|
|
||
| ## [논의 내용] | ||
| * 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! | ||
| * 20장에서는 버전 관리에 대한 이야기가 나오는데, 개발하시면서 add, commit, push, pull을 제외한 어떤 명령어를 유용하게 사용하시는지 궁금합니다. 저는 stash로 작업했던 것들을 임시적으로 보관하는 것을 많이 사용하는 것 같습니다. No newline at end of file |
| > 최종 결과물을 테스트하지 않았다면 출시해서는 안 된다. | ||
|
|
||
| ## [논의 내용] | ||
| * 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! |
There was a problem hiding this comment.
저도 비슷한 느낌이 들었습니다. 저는 오케스트라같다고 생각했어요.
필요한 음악에 따라서 악기의 구성이 달라지고, 어떤 음은 강하게, 어떤 음은 약하게,
악보라는 조리법에 맞춰서 연주해야 아름다운 음악이 나오죠.
스포츠와 오케스트라의 공통점이라면 지휘자가 꼭 필수는 아니지만 있기도 하며,
대게는 객관적인 위치에서 뭔가 조율이 필요하다는게 소프트웨어와도 같아 보인다 생각합니다.
|
|
||
| ## [논의 내용] | ||
|
|
||
| - 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! |
There was a problem hiding this comment.
저는 연구성으로 한다면 과학쪽에 무게를 주면 좋을 것 같고
팀으로 성과를 내서 사용자를 기쁘게 하는 소프트웨어라면 스포츠에 가깝다고 볼 수 있을 것 같습니다.
그리고 둘 다 잠깐 하고 버리는게 아니라 계속 동작하게 만들 생각이면 집안일을 겸하면 좋지 않을까 정도로 얘기해 볼 수 있을 것 같네요.
| ## [논의 내용] | ||
|
|
||
| - 14장에서 소프트웨어 개발이란 무엇인지 여러 은유를 통해 저자의 생각을 드러냈고, 생각해보기에서 어떤 은유가 가장 자신과 맞아떨어지는지가 있었습니다. 저는 스포츠라고 생각하고 위에 생각을 적어보았는데, 이에 대해서 다른 분들은 어떤 것이 가장 본인과 잘 맞는다고 생각하시는지 이야기를 나누면 좋을 것 같습니다! | ||
| - 20장에서는 버전 관리에 대한 이야기가 나오는데, 개발하시면서 add, commit, push, pull을 제외한 어떤 명령어를 유용하게 사용하시는지 궁금합니다. 저는 stash로 작업했던 것들을 임시적으로 보관하는 것을 많이 사용하는 것 같습니다. |
There was a problem hiding this comment.
git 명령어라면
- git log
- git status
- git diff
- git switch
- git reset
- git merge
- git branch
- git restore
등을 더 사용하고 있습니다.
언젠가 git cheat sheet라는 걸 봤을 때 명령어 한 두개 빼고 모두 사용하고 있는 걸로 확인한 적도 있네요.
그런데 태형님이나 영명님이 얘기하는 rebase와 stash는 자주 사용하는 것 같지는 않습니다.
rebase는 commit 순서 정렬 목적에는 좋지만
나중에 시간 순서나 작은 단위 커밋이 중요한 때 파악이 어렵다는 점 때문에 (조작이 가능하므로) 저는 추천하지는 않고
대안으로는 작은 단위의 pull request 생성과 자주 git merge를 수행하자 쪽으로 가이드를 주고 있습니다.
rebase 금지는 아니지만 히스토리 조작은 하지 말자 쪽에 가깝습니다.
git statsh 역시 충돌 없이 사용하면 로컬에서 파일 관리하기에는 좋긴 한데
명시적으로 git checkout을 통해 여러개의 작은 branch로 관리하고 git merge하는 과정에서 commit 로그를 남기는 쪽이
제가 가이드하는 작은 단위의 pull request에 부합하므로 그렇게 자주 쓰지는 않습니다.
전 일단 작업하던 것 때문에 git pull 명령이 충돌날 때만 git stash를 쓰는 것 같네요.
github-project-automation
bot
moved this from In review
to Done
in 2025 Academic Conference
Chapter 14 ~ 23장
이번에 살짝 늦게 업로드해서 죄송합니다.
해당 스프린트에서는 21장 <골키퍼 있다고 골 안 들어가랴>를 정말 감명 깊게 읽었습니다.
아직 QA팀과 협업해 본 경험은 없지만 저자의 경험으로부터 나오는, 서로 다른 팀 간의 협업에 대한 조언이 정말 중요하게 느껴졌습니다.
QA의 중요성을 어느정도 유추는 하고 있었지만, 생각보다 훨씬 중요하고 개발자와 아주 밀착한 관계라는 것을 배웠습니다.