더 나은 프로그래머 되는법 4주차 - 이동현

[dhlee3994]

모니터를 오래 보면 눈의 초점이 잘 안 맞는 경우가 있어서 안과를 갔는데, 안구 운동을 추천해 주더라고요.
책에 눈의 초점 이야기가 나와서 공유드립니다.

(출처: https://m.blog.naver.com/momnsu/221061877821)

closes #552

[github-actions]

우측에 있는 Projects, Milestone, Development를 확인 후 할당 해주세요~! 🙇

[gemini-code-assist]

Hello @dhlee3994, I'm Gemini Code Assist¹! 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 here with a summary of this pull request from @dhlee3994. This PR introduces a new Markdown file containing notes and discussion points for the 'Becoming a Better Programmer' study group. The author shares a personal anecdote about eye strain and connects it to the book's content on eye focus, including an image and an external link in the description. The added file, titled ch24~33.md, contains summaries and questions related to chapters 24 through 33 of the book, despite the PR title mentioning 'Week 4' and the file name mentioning 'Week 1'. This PR also closes issue #552.

Highlights

• Study Group Notes Added: A new file, 2025/Becoming a Better Programmer/donghyeon/ch24~33.md, has been added to the repository. This file contains notes and discussion points for the 'Becoming a Better Programmer' study group, specifically covering content from chapters 24 through 33.
• Discussion Topics Included: The added notes include specific questions for discussion within the study group, focusing on topics like defining 'completion' criteria for tasks and finding a balance between doing 'enough' and striving for 'perfectionism'.
• Key Takeaways Summarized: The file summarizes key points from the book chapters, such as the effectiveness of teaching others, the importance of ethical attitude and responsibility for code quality, maintaining good posture and taking breaks (including eye focus exercises), working 'smart' over 'hard' (using tools, automation, prioritization), and the necessity of clearly defining when a task is considered 'done'.
• Personal Reflection on Eye Health: The PR description includes a personal reflection from the author about experiencing eye strain from monitor use and how it relates to the book's content on eye focus, providing an image and a link to an external resource.

Changelog

• 2025/Becoming a Better Programmer/donghyeon/ch24~33.md
  • Added a new Markdown file containing notes and discussion points for the 'Becoming a Better Programmer' study group, covering chapters 24-33.
  • Included discussion questions on defining 'done' and balancing 'enough' vs. 'perfectionism'.
  • Summarized key points from the book chapters on various aspects 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.

---

Study the code well,
Eyes may tire, take a break,
Learn and grow stronger.

Footnotes

1. 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. ↩

[gemini-code-assist]

Code Review

Thank you for sharing your notes and reflections for chapters 24-33 of "Becoming a Better Programmer." The summary points are concise, and the discussion prompt about defining 'done' and balancing perfectionism is very relevant and thought-provoking. Your personal experience shared in the PR description regarding eye health is also a valuable reminder for all developers!

Summary of Findings

• Week Number Mismatch in File Title: The H1 title in the Markdown file ('1주차') does not align with the pull request title ('4주차'). This discrepancy could lead to confusion when navigating or referencing these notes. It's recommended to ensure the week number is consistent.
• Minor Formatting: Extra Blank Line: There is an extra blank line at line 12, between the '논의' section and the '## 내용' header. While minor, removing it could improve the document's compactness. (This low-severity issue was not raised as a direct comment due to review settings.)

Merge Readiness

The content of the notes is valuable. However, there's a medium-severity issue regarding a mismatch in the week number between the file's title and the PR's title that should be addressed to ensure clarity and consistency. Once this is resolved, the PR should be in good shape for merging. As an AI, I am not authorized to approve pull requests; please ensure further review and approval by team members if necessary.

[gemini-code-assist]

The title in this Markdown file indicates '1주차' (Week 1), but the pull request title and context suggest this might be for '4주차' (Week 4).

Could you please verify the correct week number and update the title in this file for consistency? This will help in keeping the study materials organized.

For example, if these notes are indeed for Week 4, the title could be updated as shown in the suggestion.

Suggested change

	# 더 나은 프로그래머 되는법 1주차 - ch24~33
	# 더 나은 프로그래머 되는법 4주차 - ch24~33

[jongfeel]

눈 건강을 위한 추가 그림 좋네요. 👍 👍 👍

[jongfeel]

이게 사실은 애자일 스크럼이니, 인수 테스트 요구사항 정리니 하는 거창한 단어를 쓰지 않아도
두 가지를 명확하게 정의하면 됩니다. 엑셀, 심지어 텍스트 파일에 해도 되죠

• 릴리스 버전 기준 어떤 기능이 동작해야 한다는 목록을 명시
• 각 기능마다 테스트 방법 명시

이 두 가지입니다.

저희는 요구사항별 목록 및 릴리스별 기능 목록은 google spread sheet로 관리하고
각 화면 설계나 디자인 파일은 피그마 링크 항목으로 연결시켜 놓습니다.
QA 항목의 경우는 레드마인이라는 오래된 게시판 형태의 프로젝트 관리 툴이 있는데 그걸 사용합니다.

각 팀별로 작업자들이 어느 일정에 맞춰서 릴리스를 해야 하고 어떤 기능을 테스트 해서 통과 시켜야 하는지 알고 작업하므로
공식적으로 지켜야 하는 건 지킵니다.
여기 까지가 충분하면 되는 것의 기준입니다.

그 외에 제가 따로 개발팀 내에서 지키고 있는 건 설계 리뷰, 코드 리뷰, 테스트 코드 작성, 빌드 자동화 정도의 단계를 추가하고 있고 실천하고 있습니다.
여기까지 하면 엔지니어링 협업 관점에서의 완벽주의의 기준이라고 볼 수 잇을 것 같습니다.

[TaeHyoungKwon]

• 팀이나 프로젝트에서 '완료'의 기준을 어떻게 설정하고, 그것이 실제로 잘 지켜지고 있는지,
  ---> 저희 회사에서는 배포를 기준으로, 배포 전에는 QA 까지 완료되어야 하고, 배포 후에는 LIVEQA까지 완료되어서 티켓이 닫힘처리될 때를 완료로 보고 있습니다 저희 회사에서는 잘지켜지고 있긴한데, 굳이 하나 아쉽다면, 배포 이후에 LIVEQA 가 제대로 안되는 경우는 종종 있는거 같습니다

• '충분하면 멈추는 것'과 '완벽주의' 사이에서 어떻게 균형을 잡는지 이야기해보면 좋을 것 같습니다.
  ---> 정량적으로 측정해서 할 수 있는 방법은 사실 없지 않을까 생각됩니다 어떻게 보면 주관적인 영역이기 때문에 각자 기준이 다를거 같네요 그래서, 같은 팀원들과 이걸 소통을 통해서 조정해나가는게 중요하지 않을까 생각됩니다

[tttghost]

저의 관점에서 완료의 기준은 프로젝트가 완벽하게 마무리 되지 않았더라도
같이 협업하는 사람들과 수주사와 모두가 협의가 된 상황이라면 완료라고 생각합니다.
개발자가 혹은 다른 포지션의 인원들이 좀더 살을 붙이려면 얼마든지 붙일 수 있고 그러면 완료가 계속 미뤄질 것입니다.
PM혹은 PL의 선택이 완료 시점이라 봅니다.