Conversation
|
우측에 있는 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hello @hemil0102, 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, titled "더 나은 프로그래머 되는 법 3주차 - 하업서" (How to become a better programmer Week 3 - Homework), appears to be the submission of a homework assignment for the third week of a study or course focused on improving programming skills. The author mentions it's a completed overdue assignment. The changes primarily involve adding a Markdown file containing answers and reflections on various software development topics covered in chapters 14 through 23 of the book "Becoming a Better Programmer".
Highlights
- Homework Submission: This pull request serves as the submission for the Week 3 homework assignment for the 'Becoming a Better Programmer' study/course.
- Reflections on Software Development: The core content is a Markdown file containing the author's personal reflections and answers to questions from chapters 14-23 of the book, covering topics like development metaphors, rules, code simplicity, technical debt, changeability, code reuse, version control, QA, code freezing, and release processes.
- Personal Insights: The author shares insights on their current work environment, comparing it to concepts from the book, discussing topics like code review (human vs. AI), the importance of understanding requirements, and the challenges of implementing best practices in a real-world setting.
Changelog
- 2025/Becoming a Better Programmer/hemil0102/14장~23장.md
- Added Markdown file containing answers and reflections on chapters 14-23 of 'Becoming a Better Programmer'.
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.
Code review time is here,
Homework answers appear,
Chapters fourteen to twenty-three,
Reflections for all to see,
Learning makes the path clear.
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
전반적으로 책의 각 장에 대한 깊이 있는 성찰과 답변이 잘 정리되어 있습니다. 내용이 풍부하고 개인적인 경험과 생각이 잘 드러나 있어 스터디 자료로서 가치가 높아 보입니다. 다만, 몇몇 부분에서 사용된 비공식적인 표현이나 오타, 어색한 단어 선택 등은 수정하면 글의 완성도를 더욱 높일 수 있을 것입니다. 아래 구체적인 피드백을 참고하여 개선해 주시면 좋겠습니다.
Summary of Findings
- 비공식적 표현 및 속어 사용: 문서 일부에서 'N빵', '쪼임'과 같은 비공식적 표현이나 속어가 사용되었습니다. 일상 대화에서는 문제가 없으나, 스터디 자료나 공유 문서에서는 보다 표준적이고 공식적인 한국어를 사용하는 것이 내용의 명확성과 전문성을 높이는 데 도움이 됩니다. 관련된 구체적인 사항은 개별 코멘트를 통해 전달드렸습니다.
- 부적절한 단어 선택: 문맥상 의미가 다른 단어가 사용된 경우('사양하는데' 대신 '지양하는데'가 적절한 상황)가 발견되었습니다. 이는 문장의 의미를 왜곡할 수 있으므로 수정이 필요합니다. 관련하여 코멘트를 남겼습니다.
- 오타 및 문법적 개선점: 의미 전달에 영향을 줄 수 있는 오타 및 문법적 오류('수행했을 꺠달았다')가 확인되어 코멘트를 통해 수정을 제안했습니다. 이 외에도 문서 전반에 걸쳐 사소한 오타(예: '왠만한' -> '웬만한', '개기' -> '계기') 및 띄어쓰기 오류(예: '것 같다' -> '것 같다', '하는 게' -> '하는게')가 다수 관찰되었습니다. 이러한 부분들은 리뷰 심각도 설정에 따라 개별 코멘트하지 않았으나, 수정한다면 문서의 전체적인 가독성과 완성도를 높일 수 있을 것입니다.
Merge Readiness
제안된 변경 사항들은 책 내용에 대한 개인적인 정리와 답변으로, 전반적으로 잘 작성되었습니다. 다만, 몇 가지 중간 정도 심각도의 이슈(비공식적 표현, 단어 선택 오류, 오타 등)가 발견되어 수정을 요청드립니다. 이러한 부분들을 개선하면 문서의 명확성과 전문성이 향상될 것입니다. 해당 이슈들이 해결된 후 병합하는 것을 권장합니다. 저는 이 PR을 승인할 권한이 없으므로, 다른 리뷰어의 검토 및 승인 후 병합을 진행해 주시기 바랍니다.
|
|
||
| ## 2. '코드의 주인은 없다'는 사실과, 다른 사람들보다 특정 인물이 더 경험이 많다는 사실 간의 균형을 어떻게 맞출 것인가? 이 문제는 프로그래머에 대한 업무 할당에 어떤 영향을 주는가? | ||
| ### 경험이 많다는 것은 회사를 꼭 오래다녔다기 보다는, 일을 많이해서 그만한 능력치가 쌓였다는 것을 말하는 것 같다. 그리고 균형을 맞춰야 한다면 어떤 관점으로 균형을 맞추는지가 중요해보인다. | ||
| 단순히 업무량을 N빵하면 경험이 많은 사람은 일을 많이해서 경험이 많고 또 그래서 일을 많이하고 싶어할 수도 있다. 따라서 경험이 많은 사람이 팀에 있다면 어쩌면 다른 사람 업무 할당이 적어질 수도 있다. |
There was a problem hiding this comment.
95행의 'N빵하면'이라는 표현은 일상 대화에서는 자연스럽지만, 스터디 노트나 공유 문서에서는 조금 더 공식적인 표현(예: '1/N로 나누면', '균등하게 분배하면')으로 바꾸는 것을 고려해 보시는 것이 어떨까요? 이렇게 하면 내용의 명확성과 가독성을 높일 수 있을 것 같습니다.
| 단순히 업무량을 N빵하면 경험이 많은 사람은 일을 많이해서 경험이 많고 또 그래서 일을 많이하고 싶어할 수도 있다. 따라서 경험이 많은 사람이 팀에 있다면 어쩌면 다른 사람 업무 할당이 적어질 수도 있다. | |
| 단순히 업무량을 1/N로 나누면 경험이 많은 사람은 일을 많이해서 경험이 많고 또 그래서 일을 많이하고 싶어할 수도 있다. 따라서 경험이 많은 사람이 팀에 있다면 어쩌면 다른 사람 업무 할당이 적어질 수도 있다. |
|
|
||
| ## 3. 모든 프로젝트는 코드가 자주 바뀌거나, 조금 바뀌거나 두 가지 중 하나에 해당한다. 후자의 경우 코드가 사용되지 않기 때문일 수도 있고, 외부의 모듈에 의한 확장으로 건강하게 설계 되었기 때문일 수도 있다. 단지 사람들이 불쾌함을 피하다보니 변하지 않은 경우일 수도 있다. 이런 종류의 융통성 없는 코드를 얼마나 가지고 있는가? | ||
| ### 융통성이 없는 코드 어떻게 보면 소위 말해 하드코딩한 코드를 가리키는 것일 수도, 어떤 특정한 경우에만 단편적으로 동작하는 코드를 하드코딩이라 하겠다. | ||
| 간단한 샘플 코드를 만들때는 하드코딩으로 동작만 확인을 빠르게 하는 편인데, 왠만하면 주먹구구 만들어진 코드는 사양하는데, 설계가 어렵고 절차가 복잡할 수록 잘못된 길로 갈 경우 하드코딩이 되었던 것 같다. |
There was a problem hiding this comment.
100행의 '사양하는데'라는 단어가 사용되었는데, 문맥을 고려할 때 '어떤 것을 피하거나 하지 않는다'는 의미의 '지양하는데'가 더 적절해 보입니다. '사양하다'는 보통 제안이나 권유를 거절하는 상황에 사용됩니다. 이 부분을 수정하면 의도하신 바를 더 정확하게 전달할 수 있을 것 같아요.
| 간단한 샘플 코드를 만들때는 하드코딩으로 동작만 확인을 빠르게 하는 편인데, 왠만하면 주먹구구 만들어진 코드는 사양하는데, 설계가 어렵고 절차가 복잡할 수록 잘못된 길로 갈 경우 하드코딩이 되었던 것 같다. | |
| 간단한 샘플 코드를 만들때는 하드코딩으로 동작만 확인을 빠르게 하는 편인데, 왠만하면 주먹구구 만들어진 코드는 지양하는데, 설계가 어렵고 절차가 복잡할 수록 잘못된 길로 갈 경우 하드코딩이 되었던 것 같다. |
| ## 5. 동시 작업을 위해 더 안전한 방식은 어느 것인가? 특정 기능을 켜고 끄는 feature-toggle과 동시 작업을 위한 브랜치 중에 어느쪽이 관리와 통합에 부담이 작은가? | ||
| ### 잘 모르는 내용으로 스킵 | ||
|
|
||
| ## 6. 저장소에 변경사항을 커밋하려는 순간 서로 다른 두 가지 작업을 수행했을 꺠달았다. 커밋을 멈추고 체인지셋을 바꾸어 커밋을 나누어야 하는가? |
There was a problem hiding this comment.
137행의 문장에 오타('꺠달았다' -> '깨달았다')가 있고, 문맥상 '수행했을'보다는 '수행했음을' 또는 '수행했다는 것을'로 수정하는 것이 더 자연스러워 보입니다. 예를 들어, '서로 다른 두 가지 작업을 수행했음을 깨달았다'와 같이 수정하면 어떨까요?
| ## 6. 저장소에 변경사항을 커밋하려는 순간 서로 다른 두 가지 작업을 수행했을 꺠달았다. 커밋을 멈추고 체인지셋을 바꾸어 커밋을 나누어야 하는가? | |
| ## 6. 저장소에 변경사항을 커밋하려는 순간 서로 다른 두 가지 작업을 수행했음을 깨달았다. 커밋을 멈추고 체인지셋을 바꾸어 커밋을 나누어야 하는가? |
| ### 아직 과제 하나를 끝까지 해보지 않았다. 그래서 출시가 얼마나 건전한지 잘 모르겠지만, 검증을 아예 안하는 것은 아니고 클라이언트, 개발팀에서 검증을 수행하고 문제점을 해결한다. | ||
|
|
||
| ## 4. 소프트웨어의 '품질'에 대해 책임지는 사람은 누구인가? 문제가 생겼을 때 '비난'을 받는 사람은 누구인가? 이 과정이 얼마나 건전한가? | ||
| ### QA가 없으므로 개발자가 해결에 대한 책임을 진다. 비난은 문제를 책임지지 않은 사람에게 발생하겠지만, 아직까지는 문제가 발생했을 때 비난보다는 조금 쪼임?을 당하는 느낌 정도이다. |
There was a problem hiding this comment.
152행의 '쪼임?을 당하는 느낌'이라는 표현은 다소 구어적입니다. 스터디 자료의 성격을 고려하여 '압박을 받는 느낌'이나 '재촉을 당하는 느낌'과 같이 조금 더 정제된 어휘로 변경하면 전체적인 글의 통일성과 전문성을 높이는 데 도움이 될 것 같습니다.
| ### QA가 없으므로 개발자가 해결에 대한 책임을 진다. 비난은 문제를 책임지지 않은 사람에게 발생하겠지만, 아직까지는 문제가 발생했을 때 비난보다는 조금 쪼임?을 당하는 느낌 정도이다. | |
| ### QA가 없으므로 개발자가 해결에 대한 책임을 진다. 비난은 문제를 책임지지 않은 사람에게 발생하겠지만, 아직까지는 문제가 발생했을 때 비난보다는 조금 압박을 받는 느낌 정도이다. |
jongfeel
requested review from
jongfeel,
TaeHyoungKwon,
ymkim97,
fkdl0048,
tttghost and
dhlee3994
jongfeel
assigned
hemil0102 and unassigned
jongfeel,
TaeHyoungKwon,
ymkim97,
fkdl0048,
tttghost and
dhlee3994
| @@ -0,0 +1,194 @@ | |||
| # 논제 | |||
| ## 1. CI/CD 구축은 어려운가?! 확실히 구축해놓으면 생기는 이점은 무엇이고 단점은 무엇이라 생각하는가!? | |||
There was a problem hiding this comment.
늦게 올려주셨지만 코멘트는 달 수 있을 것 같아서 달아봅니다.
자동화 환경 구축이 어렵다의 기준은 이전에 구축해본 경험이 있느냐에 따라 다를 것 같고요.
처음이라면 어려운 건 맞습니다. 이유는 프로그래밍 언어처럼 논리적인 코드를 작성하는 부분 보다는
자동화 수행 순서와 파이프라인 입출력에 따른 동작하는 과정에 대한 스크립트를 짜는 것이다 보니
익숙하지 않으면 어렵게 느껴지기도 할 수 있습니다.
구축해 놓으면 매번 빌드, 테스트, 배포에 대한 작업을 사람이 필요에 따라 수동으로 설정하고 동작시키고 하는 작업을 줄일 수 있습니다.
다른 책에서도 찾아볼 수 있는 예인데 매번 같은 작업을 반복해서 하고 있다면 충분히 장점을 느낄 수 있다고 봅니다.
단점은 사실 없는게 맞습니다.
자동화 환경이 필요 없는데 굳이 구축해 놓는데 시간을 들인다 정도가 단점인데
전제가 테스트 코드도 작성 안하는 거니까 CI/CD를 논하는게 문제점이라고 볼 수 있겠죠.
There was a problem hiding this comment.
늦었지만 답변 감사드립니다. 🥹
밀린 과제 수행 완료