Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
dhlee3994 merged 2 commits into from
Jun 13, 2025
Merged

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7ddfc61
Move ch1~8 to 더나은프로그래머되는법
dhlee3994 May 29, 2025
f640e3b
Add ch24~33
dhlee3994 May 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
0 ...-Driven Design Quickly/donghyeon/ch1~8.md → ...ng a Better Programmer/donghyeon/ch1~8.md
View file
Open in desktop
File renamed without changes.
25 changes: 25 additions & 0 deletions 2025/Becoming a Better Programmer/donghyeon/ch24~33.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# 더 나은 프로그래머 되는법 1주차 - ch24~33
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot May 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

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


## 논의

팀이나 프로젝트에서 '완료'의 기준을 어떻게 설정하고, 그것이 실제로 잘 지켜지고 있는지,
'충분하면 멈추는 것'과 '완벽주의' 사이에서 어떻게 균형을 잡는지 이야기해보면 좋을 것 같습니다.
Comment on lines +5 to +6
Copy link
Member

@jongfeel jongfeel May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

이 두 가지입니다.

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

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

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

Copy link
Collaborator

@TaeHyoungKwon TaeHyoungKwon May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Contributor

@tttghost tttghost May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


저는 회사에서 팀 단위로 일하지 않고 도메인 전문가와 1:1로 이야기하다보니 구체적인 인수 조건(Acceptance Criteria, AC)를
명확하게 정의하려고 노력합니다. 그리고 모든 AC가 통과되면 '완료'했다고 간주합니다.
그런데 AC에 없어도 사용자 편의 기능이 생각나면 최대한 기능을 넣어주려고 하다보니 의도치 않게 야근을 하는 경우가 생기기도 합니다.
그래서 '충분하면 멈추는 것'과 '완벽주의' 사이의 균형이 어렵게 느껴지는 것 같습니다.


## 내용

- 남을 가르쳐보는 것도 효과적이다.
- 기술적 기량만큼 태도, 특히 윤리적인 태도 역시 중요하다.
- 윤리적인 프로그래머는 생산물의 품질에 대해 책임을 질 줄 알아야한다.
- 항상 바른 자세로 프로그래밍하자.
- 자주 휴식을 취하고 걸어 다니며, 눈의 초점을 조절하자.
- '열심히'보다는 '현명하게'하자.
- 적절한 도구를 사용하고, 바퀴를 재발명하지 않으며, 다른 사람에게 위임하고, 꼭 필요한 일만 하는 것이 현명하게 일하는 방법이다.
- 우선순위를 설정하고 가장 긴급하거나 가치가 높은 일에 집중하자.
- 자주 해야하는 작업은 가능하다면 자동화하자.
- 작업의 완료 상태를 명확하게 정의하는 것은 중요하다. 이는 언제 작업을 멈춰야 할지 알려준다.