앞으로 4주간, 나는 다음 3가지 목표를 이루도록 하려고 한다
- 좋은 코드에 대한 명확한 "기준" 3개 만들기
- 내가 작성한 코드에 대해 5명 이상에게 피드백 (코드리뷰) 받아보기
- 배운 좋은 코드를 회사 제품에 적용해보기 (최소 1개 커밋)
[구글 엔지니어는 이렇게 일한다] 책의 내용 중 소프트웨어 엔지니어링 vs 프로그래밍 비교가 나온다
프로그래밍은 요구사항을 코드로 구현하는 행위라면, 소프트웨어 엔지니어링은 **"문제를 정의"하고, "리소스를 고려"하여 "해결하는 행위"**이다.
그렇다면 좋은 소프트웨어 엔지니어링이란?
ㄴ 비용 대비 가치를 생각하고 일하는 것
가용한 모든 근거 자료에 적절한 가중치를 부여하고 균형점을 잡아보자.
"비즈니스 문제를 해결하는 사람"
엘리베이터가 느려요 -> 100억을 들여 새 엘리베이터를 도입? 똑똑한 개발자는 스마트한 솔루션을 제시한다
- 거울을 설치
- TV (광고판) 설치
- 홀짝층수 / 저고층 분리 등...
결국 "문제를 정의"하는 역량이 중요
- 문제 해결 역량:
- 메타 인지: 나는 어떤 사람인가? 나는 주어진 일이 있으면 어떻게든 책임을 지려고 한다. 만약 목표가 명확하지 않으면 되려 안하게 된다. 그래서 일부러 남들에게 일단 목표를 선언하고 어떻게든 하려고 한다.
- 개발자 기본 역량: 직무에 대한 기본 지식 (네트워크, 프론트엔드..)
무엇보다, 꾸준하게, 복리를 누리자.
- P1: 꼭 반영해주세요 (Request changes)
- 리뷰어는 PR의 내용이 서비스에 중대한 오류를 발생할 수 있는 가능성을 잠재하고 있는 등 중대한 코드 수정이 반드시 필요하다고 판단되는 경우, P1 태그를 통해 리뷰 요청자에게 수정을 요청합니다. 리뷰 요청자는 p1 태그에 대해 리뷰어의 요청을 반영하거나, 반영할 수 없는 합리적인 의견을 통해 리뷰어를 설득할 수 있어야 합니다.
- P2: 적극적으로 고려해주세요 (Request changes)
- 작성자는 P2에 대해 수용하거나 만약 수용할 수 없는 상황이라면 적합한 의견을 들어 토론할 것을 권장합니다.
- P3: 웬만하면 반영해 주세요 (Comment)
- 작성자는 P3에 대해 수용하거나 만약 수용할 수 없는 상황이라면 반영할 수 없는 이유를 들어 설명하거나 다음에 반영할 계획을 명시적으로(JIRA 티켓 등으로) 표현할 것을 권장합니다. Request changes 가 아닌 Comment 와 함께 사용됩니다.
- P4: 반영해도 좋고 넘어가도 좋습니다 (Approve)
- 작성자는 P4에 대해서는 아무런 의견을 달지 않고 무시해도 괜찮습니다. 해당 의견을 반영하는 게 좋을지 고민해 보는 정도면 충분합니다.
- P5: 그냥 사소한 의견입니다 (Approve)
- 작성자는 P5에 대해 아무런 의견을 달지 않고 무시해도 괜찮습니다.