더 나은 프로그래머 되는법 2주차 - 김지수 #549
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 @tttghost, 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, titled "더 나은 프로그래머 되는법 2주차 - 김지수", appears to be the submission for the second week of a study group or course focused on becoming a better programmer. The author, tttghost, has added a new Markdown file containing their notes and reflections on chapters 9 through 13 of the study material, along with a discussion question for reviewers.
Highlights
- Study Notes Submission: This PR submits the author's notes and reflections for the second week of the 'Becoming a Better Programmer' study group, covering chapters 9 through 13.
- Key Concepts Covered: The notes discuss important topics such as expecting the unexpected, strategies for bug hunting, the critical role of testing (including test code and CI), managing code complexity through good design, and the benefits of well-designed systems.
- Discussion Topic: The author poses a question regarding when reviewers started using test code in their careers and the significant advantages they experienced.
Changelog
- 2025/Becoming a Better Programmer/tttghost/Chapter9~13.md
- Added a new file containing reflections and summaries for chapters 9-13 of the 'Becoming a Better Programmer' material.
- Included sections on expecting the unexpected (lines 1-3), bug hunting (lines 4-7), testing (lines 8-10), handling complexity (lines 11-13), and the story of two systems (lines 14-16).
- Added a discussion question about the adoption and benefits of test code (lines 17-18).
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, a helpful gaze,
On thoughts from learning's maze.
Chapters read, insights shared,
A programmer's path, prepared.
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
김지수님의 2주차 요약 잘 읽었습니다. 각 챕터의 핵심 내용과 개인적인 소회를 잘 담아주셨네요. 특히 '논의사항'을 통해 함께 고민할 지점을 제시해주신 점이 좋습니다.
다만, 몇몇 문장에서 오타나 어색한 표현들이 발견되어 가독성을 조금 해치는 부분이 있습니다. 이에 대한 수정 제안을 몇 가지 드렸습니다. 제안된 내용을 반영하시면 글의 완성도가 더욱 높아질 것 같습니다.
Summary of Findings
- Additional Minor Improvements: In addition to the specific suggestions, a few other minor improvements could enhance the document's polish. These were not included in individual comments due to review settings focusing on medium or higher severity issues:
- Line 5: '만들뿐' could be spaced as '만들 뿐'.
- Line 17: The heading '논의사항: ' has an extra space after the colon; '논의사항:' would be more standard.
- Line 18: Several phrases could benefit from spacing for clarity (e.g., '테스트코드에' -> '테스트 코드에', '어느연차부터' -> '어느 연차부터', '개발경험상' -> '개발 경험상').
- Consider ensuring consistent sentence endings (e.g., using '-습니다' or '-다' uniformly) across all chapter summaries for a more cohesive tone.
Addressing these would further improve readability.
Merge Readiness
김지수님의 2주차 요약 잘 읽었습니다. 각 챕터의 핵심 내용과 개인적인 소회를 잘 담아주셨네요. 특히 '논의사항'을 통해 함께 고민할 지점을 제시해주신 점이 좋습니다.
다만, 몇몇 문장에서 오타나 어색한 표현들이 발견되어 가독성을 조금 해치는 부분이 있습니다. 이에 대한 수정 제안을 몇 가지 드렸습니다. 제안된 내용을 반영하시면 글의 완성도가 더욱 높아질 것 같습니다.
이러한 수정 사항들이 반영된 후에는 공유하시기에 좋은 상태가 될 것이라고 생각합니다. 저는 PR을 직접 승인할 권한은 없으므로, 다른 리뷰어분들의 확인 후 머지 진행 부탁드립니다.
| @@ -0,0 +1,18 @@ | |||
| **9장 예상치 못한 것을 예상하기** | |||
| 예상하지 못한 것은 결코 이상하다는게 아니다. 이 한마디가 크게 와 닿았습니다. 언제든 코드나 어떤 주변환경이든 예상치못한 변수가 발생할 수 있기에 미리미리 예상치 못한 걸 예상해서 대비하는 습관을 기르는 것이 중요하다 생각이 듭니다. | |||
There was a problem hiding this comment.
문장 중 '이상하다는게 아니다'라는 표현이 다소 어색하게 느껴집니다. '이상한 것이 아니다'로 수정하고, '주변환경이든'을 '주변 환경이든', '예상치못한'을 '예상치 못한'으로, 그리고 문장 마지막을 '중요하다고 생각합니다'와 같이 다듬으면 전체적으로 더 자연스러울 것 같아요. 어떻게 생각하시나요?
| 예상하지 못한 것은 결코 이상하다는게 아니다. 이 한마디가 크게 와 닿았습니다. 언제든 코드나 어떤 주변환경이든 예상치못한 변수가 발생할 수 있기에 미리미리 예상치 못한 걸 예상해서 대비하는 습관을 기르는 것이 중요하다 생각이 듭니다. | |
| 예상하지 못한 것은 결코 이상한 것이 아니다. 이 한마디가 크게 와 닿았습니다. 언제든 코드나 어떤 주변 환경이든 예상치 못한 변수가 발생할 수 있기에 미리미리 예상치 못한 걸 예상해서 대비하는 습관을 기르는 것이 중요하다고 생각합니다. |
|
|
||
| **10장 버그 사냥하기** | ||
| 더 나은 프로그래머는 더 나은 버그를 만들뿐 | ||
| 버그가 발생하지 않는 것은 아니다. 버그는 필연적인 것이며 마딱들였을때 해결하는 자세와 능력이 필요하다. 너무 영리한 코드를 짜면 오히려 버그를 잡기 힘들 수 있다. 레이어적으로 낮게 짜되 서로 커플링이 심하지 않게 짜 추후 생길 버그를 대비할수있다. |
There was a problem hiding this comment.
문장 중 '마딱들였을때'는 '맞닥뜨렸을 때' 또는 '마주쳤을 때'의 오타인 것 같습니다. 그리고 문장 뒷부분의 '커플링이 심하지 않게 짜 추후 생길 버그를 대비할수있다'는 '커플링이 심하지 않게 짜서 추후 생길 버그에 대비할 수 있습니다'와 같이 다듬으면 좋을 것 같아요. 추가로, 이 문단 내 다른 문장들과 같이 종결 어미를 '-습니다'로 통일하면 가독성이 향상될 것 같습니다.
| 버그가 발생하지 않는 것은 아니다. 버그는 필연적인 것이며 마딱들였을때 해결하는 자세와 능력이 필요하다. 너무 영리한 코드를 짜면 오히려 버그를 잡기 힘들 수 있다. 레이어적으로 낮게 짜되 서로 커플링이 심하지 않게 짜 추후 생길 버그를 대비할수있다. | |
| 버그가 발생하지 않는 것은 아니다. 버그는 필연적인 것이며 맞닥뜨렸을 때 해결하는 자세와 능력이 필요합니다. 너무 영리한 코드를 짜면 오히려 버그를 잡기 힘들 수 있습니다. 레이어적으로 낮게 짜되 서로 커플링이 심하지 않게 짜서 추후 생길 버그에 대비할 수 있습니다. |
| 버그가 발생하지 않는 것은 아니다. 버그는 필연적인 것이며 마딱들였을때 해결하는 자세와 능력이 필요하다. 너무 영리한 코드를 짜면 오히려 버그를 잡기 힘들 수 있다. 레이어적으로 낮게 짜되 서로 커플링이 심하지 않게 짜 추후 생길 버그를 대비할수있다. | ||
|
|
||
| **11장 테스트 하기** | ||
| 저는 아직 테스트코드룰 제대로 작성해 본 적이 없기에 이 부분을 제일 심도깊게 읽었습니다. 최근 테스트코드룰 제외 한 CI를 구축해본 일이 있는데 테스트코드작성에 필요성을 책울 보며 다시한번 느꼇습니다. 반복적인 일은 기계가 가장 잘 하기에... |
There was a problem hiding this comment.
이 문장에 몇 가지 오타와 수정하면 좋을 부분이 있는 것 같아요:
- '테스트코드룰' (2회) -> '테스트 코드를'
- '제외 한' -> '제외한'
- '테스트코드작성에' -> '테스트 코드 작성의'
- '책울' -> '책을'
- '다시한번' -> '다시 한번'
- '느꼇습니다' -> '느꼈습니다'
- '잘 하기에...' -> '잘하기에...'
이렇게 수정하면 내용 전달이 더 명확해지고 자연스러워질 것 같습니다. 어떻게 생각하시나요?
| 저는 아직 테스트코드룰 제대로 작성해 본 적이 없기에 이 부분을 제일 심도깊게 읽었습니다. 최근 테스트코드룰 제외 한 CI를 구축해본 일이 있는데 테스트코드작성에 필요성을 책울 보며 다시한번 느꼇습니다. 반복적인 일은 기계가 가장 잘 하기에... | |
| 저는 아직 테스트 코드를 제대로 작성해 본 적이 없기에 이 부분을 제일 심도깊게 읽었습니다. 최근 테스트 코드를 제외한 CI를 구축해본 일이 있는데 테스트 코드 작성의 필요성을 책을 보며 다시 한번 느꼈습니다. 반복적인 일은 기계가 가장 잘하기에... |
| 저는 아직 테스트코드룰 제대로 작성해 본 적이 없기에 이 부분을 제일 심도깊게 읽었습니다. 최근 테스트코드룰 제외 한 CI를 구축해본 일이 있는데 테스트코드작성에 필요성을 책울 보며 다시한번 느꼇습니다. 반복적인 일은 기계가 가장 잘 하기에... | ||
|
|
||
| **12장 복잡도 다루기** | ||
| 블롭과 라인에 대한 개념이 나오는데 결국 이 두 부분을 조율하는 것은 사람입니다. 좋은 설계를 통해 복잡도를 줄이먀 추상화 할수 있는 부분과 인터페이스화 할수있는 부분에 대해 자속적 고민을 해야 복잡도가 낮은 프로그래밍을 할 수 있다 생각합니다. |
There was a problem hiding this comment.
문장 중 '줄이먀'는 '줄이며'의, '자속적'은 '지속적'의 오타인 것 같습니다. 또한 '추상화 할수 있는', '인터페이스화 할수있는'은 각각 '추상화할 수 있는', '인터페이스화할 수 있는'으로, 문장 마지막의 '할 수 있다 생각합니다'는 '할 수 있다고 생각합니다'로 수정하면 더 자연스러울 것 같아요.
| 블롭과 라인에 대한 개념이 나오는데 결국 이 두 부분을 조율하는 것은 사람입니다. 좋은 설계를 통해 복잡도를 줄이먀 추상화 할수 있는 부분과 인터페이스화 할수있는 부분에 대해 자속적 고민을 해야 복잡도가 낮은 프로그래밍을 할 수 있다 생각합니다. | |
| 블롭과 라인에 대한 개념이 나오는데 결국 이 두 부분을 조율하는 것은 사람입니다. 좋은 설계를 통해 복잡도를 줄이며 추상화할 수 있는 부분과 인터페이스화할 수 있는 부분에 대해 지속적 고민을 해야 복잡도가 낮은 프로그래밍을 할 수 있다고 생각합니다. |
| 블롭과 라인에 대한 개념이 나오는데 결국 이 두 부분을 조율하는 것은 사람입니다. 좋은 설계를 통해 복잡도를 줄이먀 추상화 할수 있는 부분과 인터페이스화 할수있는 부분에 대해 자속적 고민을 해야 복잡도가 낮은 프로그래밍을 할 수 있다 생각합니다. | ||
|
|
||
| **13장 두 개의 시스템에 대한 이야기** | ||
| 두개의 도시에 비유해서 설명한 내용이 좋았습니다. 저는 첫번째도시에 살고 있는 느낌이긴 하지만 이 책을 보며 왜 테스트코드를짜야하며 설계를 왜 해야하는지 가장 크게 느껴진 챕터 라고 생각이 듭니다. |
There was a problem hiding this comment.
문장 중 '테스트코드를짜야하며' 부분이 어색하게 읽힙니다. '테스트 코드를 짜야 하며'로 띄어쓰기를 적용하고, '두개의'는 '두 개의', '첫번째도시에'는 '첫 번째 도시에'로, 문장 마지막의 '챕터 라고 생각이 듭니다'는 '챕터라고 생각합니다' 또는 '챕터라는 생각이 듭니다'로 수정하면 전체적으로 더 자연스러울 것 같습니다.
| 두개의 도시에 비유해서 설명한 내용이 좋았습니다. 저는 첫번째도시에 살고 있는 느낌이긴 하지만 이 책을 보며 왜 테스트코드를짜야하며 설계를 왜 해야하는지 가장 크게 느껴진 챕터 라고 생각이 듭니다. | |
| 두 개의 도시에 비유해서 설명한 내용이 좋았습니다. 저는 첫 번째 도시에 살고 있는 느낌이긴 하지만 이 책을 보며 왜 테스트 코드를 짜야 하며 설계를 왜 해야 하는지 가장 크게 느껴진 챕터라고 생각합니다. |
| 두개의 도시에 비유해서 설명한 내용이 좋았습니다. 저는 첫번째도시에 살고 있는 느낌이긴 하지만 이 책을 보며 왜 테스트코드를짜야하며 설계를 왜 해야하는지 가장 크게 느껴진 챕터 라고 생각이 듭니다. | ||
|
|
||
| **논의사항: ** | ||
| 테스트코드에 대해 어느연차부터 사용 하셨는지 궁금합니다. 이 때 개발경험상 큰 이점이 있었는지 궁금합니다. No newline at end of file |
There was a problem hiding this comment.
저는 회사가 테스트코드를 사용하고 있지 않은데, ... 그래서 신입인 지금부터 사용하고 싶어서 조금씩 도입해보려하고 있습니다.
과제에 영향을 안준다면 자체적으로 적용하는 것은 문제가 될 것 같지 않아요.
github-project-automation
bot
moved this from In progress
to Done
in 2025 Academic Conference
@jongfeel
2주차 pr 올립니다!