코드 작성

14.1 개발자의 일상적인 하루

프로그래머가 되는 것은 쉽고 즐거워. Project Manager가 작업을 조직하고, 제품의 기능 목록은 Product Owner가 책임져. Scrum Master가 미팅을 조직해. 모든 조직적인 프로세스는 최대한 공식적이고 표준화되어 있어.

아침에 출근하면, 차나 커피 한 잔을 만들어서 컴퓨터 앞에 앉아. 공동 채팅을 열어보고, 긴급 메시지가 없는지, 누군가 아프진 않는지 확인해. 모든 게 괜찮으면 일을 시작해.

JIRA 사이트를 열어 팀의 모든 작업 목록: 프로젝트 백로그와 현재 스프린트의 백로그가 저장되어 있어. 작업은 이미 우선순위에 따라 Scrum Master/TeamLead나 Product Owner에 의해 정렬되어 있어.

제일 위에 있는 작업 — 가장 우선순위 높은 것을 선택하고 작업을 시작해. 이를 위해 작업을 In Progress 상태로 변경해야 해. 몇 번의 클릭으로 할 수 있어. 이제 시간이 가기 시작했어.

작업 설명에는 보통 추가 정보나 문서 링크가 추가돼. 작업에는 필수적인 모든 정보가 있어야 해. 이 정보를 갖추는 것이 매니저의 역할이야.

뭔가 잘못되었으면 작업(태스크)을 매니저에게 다시 배정할 수 있어. 그리고 댓글에 어떤 질문이 발생했는지, 어떤 정보가 부족한지를 적어.

14.2 코드 작성

작업 설명을 검토해서 무엇을 해야 하는지 이해했어. 좋아, 이제 작업에 착수해. 여기서는 CodeGym에서의 공부 경험과 팀 내 작업 경험이 도움이 돼.

새로운 기능이 준비되고, 그것이 확실하다고 판단되면, 코드를 Git에 올려야 해. 이는 IDE에서 몇 번의 클릭으로 할 수 있어. 너의 경우엔 WebStorm에서. 코드를 먼저 로컬 저장소에 커밋하고, 그 다음에 중앙 Git 저장소로 푸시해.

대부분 마지막 작업은 Pull Request를 통해 이뤄져. Git을 통해 팀 리드에게 코드 리뷰를 요청해. 코드가 괜찮고, 지적할 사항이 없으면, 팀 리드가 너의 pull request를 승인(accept)하고, 메인 작업 브랜치에 포함시켜.

팀 리드에게 "이건 할 수 없습니다"라는 말은 하지 않는 것이 좋아. 이런 말은 특히나 팀 리드가 "이건 할 수 있다"고 확신할 때, 그리고 아마도 유사한 작업을 여러 번 해봤기 때문에 더 짜증나게 해.

어떻게 할지 모르겠다면, "이걸 하려고 2시간/2일을 보냈지만, 되지 않았습니다"라고 말해. 팀 리드는 기쁜 마음으로 네게... 어떤 방향으로 구글링해야 할지 알려줄 거야.

이게 바로 현대적인 제품 개발의 전반적인 그림이야. 코드 작성은 전체 작업의 작은 부분에 불과해, 하지만 모든 것이 잘 조직되어 있어서 너를 방해하는 것이 없어. 그러니까 프론트엔드 공부를 시작해봐 — 프로그래머로 일하는 게 마음에 들 거야.