더 나은 프로그래머 되는법 4주차 - 권태형 #558
Conversation
TaeHyoungKwon
requested review from
aquamagic9,
dhlee3994,
fkdl0048,
hemil0102,
jongfeel,
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 @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
Hello team, gemini-code-assist here to provide a summary of this pull request. This PR, authored by TaeHyoungKwon, is titled "더 나은 프로그래머 되는법 4주차 - 권태형" (Becoming a Better Programmer Week 4 - TaeHyoungKwon) and aims to close issue #552. The core changes involve adding new Markdown files containing the author's personal notes, reflections, and discussion points for chapters 24 through 33 of the book "Becoming a Better Programmer", likely as part of a structured study group or weekly activity.
Highlights
- Study Notes Added: This pull request introduces a series of Markdown files containing personal notes and reflections on chapters 24 through 33 of the book 'Becoming a Better Programmer'.
- Weekly Activity Submission: The changes appear to be a submission for the 4th week of a study group focusing on the 'Becoming a Better Programmer' book, as indicated by the title and file structure.
- Closes Issue: The pull request description indicates that it closes issue #552.
Changelog
Click here to see the changelog
- 2025/Becoming a Better Programmer/taehyoung/24.md
- Adds notes and thoughts for chapter 24: 'ch24. 배움을 사랑하며 살기' (Living with a love for learning).
- 2025/Becoming a Better Programmer/taehyoung/25.md
- Adds notes and thoughts for chapter 25: 'ch25. 테스트 주도 개발자' (Test-Driven Developer).
- 2025/Becoming a Better Programmer/taehyoung/26.md
- Adds notes and thoughts for chapter 26: 'ch26. 도전 즐기기' (Enjoying Challenges).
- 2025/Becoming a Better Programmer/taehyoung/27.md
- Adds notes and thoughts for chapter 27: 'ch 27. 부진 피하기' (Avoiding Stagnation).
- 2025/Becoming a Better Programmer/taehyoung/28.md
- Adds notes and thoughts for chapter 28: 'ch28. 윤리적인 프로그래머' (Ethical Programmer).
- 2025/Becoming a Better Programmer/taehyoung/29.md
- Adds notes and thoughts for chapter 29: 'ch29. 언어에 대한 사랑' (Love for Languages).
- 2025/Becoming a Better Programmer/taehyoung/30.md
- Adds notes and thoughts for chapter 30: 'ch30. 프로그래머의 자세' (Programmer's Posture/Attitude).
- 2025/Becoming a Better Programmer/taehyoung/31.md
- Adds notes and thoughts for chapter 31: 'ch31. 더 열심히 보다는 더 현명하게' (Smarter, Not Harder).
- 2025/Becoming a Better Programmer/taehyoung/32.md
- Adds notes and thoughts for chapter 32: 'ch32. 끝나야 끝나는 것' (It's Not Over Until It's Over).
- 2025/Becoming a Better Programmer/taehyoung/33.md
- Adds notes and thoughts for chapter 33: 'ch33. 교훈 얻기' (Learning Lessons).
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,
Thoughts on code now returned,
Knowledge starts to grow.
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
안녕하세요, 권태형님. "더 나은 프로그래머 되는 법" 4주차 정리를 잘 봤습니다. 각 챕터에 대한 깊이 있는 성찰과 개인적인 경험을 공유해주셔서 감사합니다. 전반적으로 내용이 명확하고 잘 작성되었지만, 마크다운 서식과 관련된 작은 수정 사항이 하나 있습니다. 아래 피드백을 확인해주세요.
Summary of Findings
- Markdown 서식 오류:
2025/Becoming a Better Programmer/taehyoung/31.md파일의 9번째 줄에 비어 있는 리스트 항목이 있습니다. 이는 문서의 가독성을 해칠 수 있어 수정하는 것이 좋습니다. - 파일 끝에 새 줄 없음 (Low Severity): 제출된 모든 Markdown 파일(
.md) 끝에 새 줄(newline)이 없습니다. 이는 일반적인 텍스트 파일 형식 지정 규칙이며, 일부 편집기나 도구에서 일관성을 위해 요구되기도 합니다. 이 문제는low심각도로 간주되어CUSTOM_REVIEW_SETTINGS에 따라 별도의 코멘트를 추가하지 않았습니다. 향후 일관성을 위해 추가하는 것을 고려해볼 수 있습니다.
Merge Readiness
제출해주신 내용은 매우 훌륭하며, 각 챕터에 대한 깊이 있는 생각을 보여줍니다. 위에 언급된 한 가지 사소한 서식 문제(비어 있는 리스트 항목)만 수정하면 코드베이스의 일관성과 가독성이 더욱 향상될 것입니다. 저는 이 PR을 직접 승인할 권한은 없지만, 해당 수정 이후에는 병합 준비가 완료될 것으로 보입니다. 다른 리뷰어의 최종 검토 및 승인을 받아 진행하시기 바랍니다.
| - 시니어, 주니어 역량 구분을 하지 않아야한다와 관련된 제가 쓴 글을 공유합니다 | ||
| - https://medium.com/@kth5604/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-%ED%94%84%EB%A1%9C-%EC%8A%A4%ED%8F%AC%EC%B8%A0-%EC%84%A0%EC%88%98-94d3d81ca780 | ||
| - [https://medium.com/@kth5604/나는-주니어니까-라고-말하지-말자-387c2babdd75](https://medium.com/@kth5604/%EB%82%98%EB%8A%94-%EC%A3%BC%EB%8B%88%EC%96%B4%EB%8B%88%EA%B9%8C-%EB%9D%BC%EA%B3%A0-%EB%A7%90%ED%95%98%EC%A7%80-%EB%A7%90%EC%9E%90-387c2babdd75) | ||
| - |
There was a problem hiding this comment.
이 줄에 비어 있는 리스트 항목(- )이 있는 것 같습니다. 의도된 것인가요, 아니면 명확성을 위해 제거해도 될까요? 현재 상태로는 불완전한 목록 항목으로 보일 수 있습니다.
| - https://medium.com/@kth5604/%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%8A%94-%ED%94%84%EB%A1%9C-%EC%8A%A4%ED%8F%AC%EC%B8%A0-%EC%84%A0%EC%88%98-94d3d81ca780 | ||
| - [https://medium.com/@kth5604/나는-주니어니까-라고-말하지-말자-387c2babdd75](https://medium.com/@kth5604/%EB%82%98%EB%8A%94-%EC%A3%BC%EB%8B%88%EC%96%B4%EB%8B%88%EA%B9%8C-%EB%9D%BC%EA%B3%A0-%EB%A7%90%ED%95%98%EC%A7%80-%EB%A7%90%EC%9E%90-387c2babdd75) | ||
| - |
There was a problem hiding this comment.
There was a problem hiding this comment.
jongfeel
left a comment
jongfeel
left a comment
There was a problem hiding this comment.
늦게 올려 주셔서 늦게 approve 했는데
다음이 마지막 모임이기도 하니 꼭 미리 올려 주시면 좋겠습니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 이 챕터의 메인 키워드는 `안일함` 일 것 같습니다. `안일함` 때문에, 큰 코 다친 경험이 있다면 말해보면 좋을것 같습니다 |
There was a problem hiding this comment.
저도 종종 겪는 문제이긴 합니다.
크게 테스트 코드 덜 짜기, 설계 안하기 등일텐데
알고 있는 거라고 해도 다시 생각하고, 찾아보고, 적어보고 작성하는 과정에서 시간이 들게 되고 그 시간은 피할 수 없다고 생각합니다.
지금 당장은 그 시간을 덜 쓰는게 유리하다고 생각하지만, 그런 안일한 생각이 쌓이고 작업 결과가 쌓이면 나중에 다시 돌아와 시간을 쓰게 만들긴 하더라고요.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 한 때, 김포프 님이 개발자로써, managed 언어와 unmanaged 언어 둘다 학습할 필요가 있다고 주장한적이 있었는데요. 물론, 모든 언어의 특성을 위의 2가지 만으로 나눠서 바라볼 수 없지만, 개인적으로는 이분 주장에 어느정도는 동의하는 바 입니다. 이 주장에 대해서 어떻게 생각하시는 다른 분들의 의견이 궁금하네요 |
There was a problem hiding this comment.
여러 언어를 접해보고 특징을 파악하고 경험하는 건 좋다고 봅니다.
너무 한 가지 언어만 쓰면, 더 효율적이고 더 좋은 아키텍처 결정에 대해 판단할 수 있는 근거가 너무 부족해집니다.
저는 C 계열 중에 1개, javascript or python 중에 하나를 배워서 managed, unmanaged를 경허하면 좋다고 생각하고
더 추가해 객체지향, 함수형 도 하나씩 경험하면 좋다는 입장입니다.
There was a problem hiding this comment.
다른 특성을 가진 여러 언어들을 접하는건 좋다고 생각합니다.
최근에 코틀린을 사용해보고 있는데, 자바 베이스로 만들어진 언어임에도 언어의 철학이 다르니까 완전히 다른 시각으로 코드를 작성하게 되더라구요. 자바와 코틀린의 적은 차이로도 이런데 managed, unmanaged 언어처럼 근본적인 동작 방식이 다른 언어를 모두 경험해보는건 프로그래머로서의 시야를 넓히는데 큰 도움이 될것 같다고 생각합니다.
| # 논의 내용 | ||
|
|
||
| - 한 때, 김포프 님이 개발자로써, managed 언어와 unmanaged 언어 둘다 학습할 필요가 있다고 주장한적이 있었는데요. 물론, 모든 언어의 특성을 위의 2가지 만으로 나눠서 바라볼 수 없지만, 개인적으로는 이분 주장에 어느정도는 동의하는 바 입니다. 이 주장에 대해서 어떻게 생각하시는 다른 분들의 의견이 궁금하네요 | ||
| - 폴리글랏에 대해서 어느정도로 동의하는지 궁금합니다. 폴리글랏에 어느정도 동의하신다면, 폴리글랏이 되기 위해서, 어떤식으로 접근하는지 궁금합니다 |
There was a problem hiding this comment.
위의 답변의 연장이긴 한데, 팀에서 작업하는 서비스나 제품은 하나의 프레임워크와 언어를 선택했으므로 메인작업으로 가져가고
간단한 도구나 테스트 코드, 패키지 작성은 다양한 언어를 통해 접하면 의도적 폴리글랏을 할 수 있다고 봅니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 건강을 지키면서, 프로그래밍을 더 잘하기위한 혹은 업무효율성을 높이기 위한 본인만의 어떤 방법론 있다면 공유해보면 좋을 것 같습니다 |
There was a problem hiding this comment.
회사에서도 커피 머신이 있긴 하지만 사무실 밖에 나가 산책하면서 커피 한잔 사가지고 들어오는 시간을 10~15분 정도 가지면 환기도 되고 좋긴 합니다.
저는 하루에 한번은 실천하려고 노력합니다.
|
|
||
| # 논의 내용 | ||
|
|
||
| - 개인적으로, 주니어개발자, 시니어개발자의 역량을 나누는 것을 좋아하진 않지만, 면접 같은 곳에서 굳이 평가를 해야한다면, 지식이 더 많냐 아니냐를 따지기 보다는 `현명하게` 의 수준으로, 해당 개발자가 시니어의 역량을 가졌는지 아닌지를 판단하면 좋지 않을까? 라는 개인적인 생각이 있습니다 다른분들 생각도 궁금합니다 |
There was a problem hiding this comment.
지난 모임 때 논의 주제였는데
시니어라면 경험적인 지식을 바탕으로 더 많은 지식을 자랑할 것이 아니라
중요한 아키텍처나 설계 결정을 하는데 영향력을 발휘할 수 있다면 시니어 레벨이라고 볼 수 있을 것 같습니다.
|
/gemini help |
Using Gemini Code AssistThe 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
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 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. |
|
|
||
| # 논의 내용 | ||
|
|
||
| - 한 때, 김포프 님이 개발자로써, managed 언어와 unmanaged 언어 둘다 학습할 필요가 있다고 주장한적이 있었는데요. 물론, 모든 언어의 특성을 위의 2가지 만으로 나눠서 바라볼 수 없지만, 개인적으로는 이분 주장에 어느정도는 동의하는 바 입니다. 이 주장에 대해서 어떻게 생각하시는 다른 분들의 의견이 궁금하네요 |
There was a problem hiding this comment.
다른 특성을 가진 여러 언어들을 접하는건 좋다고 생각합니다.
최근에 코틀린을 사용해보고 있는데, 자바 베이스로 만들어진 언어임에도 언어의 철학이 다르니까 완전히 다른 시각으로 코드를 작성하게 되더라구요. 자바와 코틀린의 적은 차이로도 이런데 managed, unmanaged 언어처럼 근본적인 동작 방식이 다른 언어를 모두 경험해보는건 프로그래머로서의 시야를 넓히는데 큰 도움이 될것 같다고 생각합니다.
Close #552
이번주는 많이 늦었네요 송구합니다 🙇🏻