📍Description

개발자의 원칙 책을 읽으며 정리한 내용을 공유합니다. 책 링크

✏️ 1장 : 덕업일치를 넘어서

동기를 관리하는 사람은 자신의 에너지도 관리하고 지나치게 에너지를 소진하지 않으려고 노력함. 동기는 단순히 있고, 없고 하는 것이 아닌 크기가 있는 양.

'지식 노동자는 시대적 소명임과 동시에 지식 사회인 현대의 가장 기본적인 생산 요소.
지식 근로자는 스스로 성과의 방향을 설정해야 하기 때문에, 자신에게 어떤 성과가 기대되고 있는 지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안 된다' - 피터 드러커

팀워크가 좋은 팀은 의미있는 성과를 지속적으로 내며 늘 더 높은 목표에 도전함.
공동의 목표를 위해 협력할 줄 알고, 서로 배우고 가르치며, 개인과 팀 모두 성장함.

✏️ 2장 : 오류를 만날 때가 가장 성장하기 좋을 때다

오류가 발생하면 소스 코드 레벨에서 이해하자
알아낸 지식을 글로 공유하자 (이해로 끝내지 말고, 오픈소스나 블로그에 남겨두기)
장애가 발행했을 때 원인을 깊이 공부해두기
'배우는 일, 그것은 즐겁다. 생각하는 일은 더 즐겁다. 창조하는 인생이야말로 최고의 인생이다.' - 학문의 즐거움 도서 구절

✏️ 3장 : 소프트웨어 디자인 원칙

디자인이란 목적에 따라서 실제적인 계획을 세우고 구체적으로 도면을 그려 명시하는 일
제품은 '다른 사람들의 요구사항을 만족시켜주는 것'
설계란 제품이 요구사항을 만족시키는 것을 증명하는 조건을 정의하는 행위

명시적 소프트웨어 설계는 기본적으로 명시적으로 요구사항과 연결되는 설계로, 기능, 성능, 유지보수, 미적 설계 4가지의 항목으로 구성됨.

기능 설계는 SRS나 사용자 요구사항을 해결하는 1차적이고 가장 기본적인, 그래서 가장 중요한 설계
성능 설계에서는 설계의 결과물로 반드시 성능과 관련된 부분들도 표시 또는 기록해야 함
유지보수 설계에서는 유지보수를 하기 위해 필요한 수치적인 조건들을 기록하며 설계
사용자에게 물리적으로 심리적으로 즐거움과 편리함을 줄 수 있도록 제품을 미적으로 설계해야 하는데 이를 미적 설계라고 함. (현대에서는 프로토타이핑 도구를 사용하는 것으로 대체)

GUI가 가져야 하는 속성인 명확성, 판별성, 간결성, 일관성, 검출 가능성, 가독성, 이해성 중 한 가지 이상은 만족하는 지 사용성 검증을 해야 함.

소프트웨어는 늘 새로운 기능을 제공하기 때문에 이전 버전과 더는 호환되지 않아 제품을 폐기하는 경우도 많음. 그래서 반드시 서비스의 전환에 대한 설계를 해두어야 함. 소프트웨어가 실제 환경에서 실행되는 순간부터는 정말 문제없이 정해진 일들을 수행하는 지에 대한 지표를 확인하고 개선할 준비를 해야 함. 이를 서비스 개선 설계라고 함.

✏️ 4장 : 나의 메이저 버전을 업그레이드하는 마이너 원칙들

두리번거리면서 속력과 방향을 자주 확인하기
낯선 방식으로 해결하기
개구리를 해부하지 말고, 직접 만들기
남을 향한 자존심을 버리고, 나를 향한 자존감 채우기
결과를 향하면서 과정을 기록하기
의도한 실수를 반복하면서 작은 부분을 개선하기
기준을 정하기 전에 여러 답을 찾아서 공유하기
배포하기 그리고 다음 버전 준비하기
자신의 버전은 자기 스스로 올려야 함

✏️ 5장 : 이직, 분명한 이유가 필요해

체계적인 개발/조직 문화 경험하기
경험을 넘어 개발/조직 문화에 기여하기
완전히 새로운 서비스/도메인 경험하기
조직을 만들고, 관리자 역량 향상시키기
기존 환경에서 변화 모색하기 전, 책임감 있는 마무리가 중요

✏️ 6장 : 목표를 달성하는 나만의 기준, GPAM

목표를 정하고, 계획을 만들고, 실천을 하고, 평가를 진행해 결과를 확인하는 원칙 (GPAM)
S.M.A.R.T. 방법론을 통해 좋은 목표 선정하기
- Specific : 개선이 필요한 영역에 대한 구체적인 목표
- Measurable : 진행 상황에 대한 수치화(측정)가 가능한 지
- Actionable : 실행이 가능한 지
- Realistic : 현재 리소스로 현실적으로 가능한 지
- Time-related : 결과가 언제 나올 지 기한이 있는 지
개발 사이클과 GPAM 원칙을 비교해보기

✏️ 7장 : 프로덕트 중심주의

프로덕트 중심으로 목표 정리하기
반복적으로 완성하기
디테일까지 도달하기
항상 협업 모드로 작업하기 (나와 / 타인과의 교류)
망설일 바에는 실패하자
조직과 팀의 선택

✏️ 8장 : 제어할 수 없는 것에 의존하지 않기

DRY 원칙 : 똑같은 기능, 코드를 반복하지 마라
YAGNI 원칙 : 그 기능이 필요하기 전까지는 미리 만들지 말라
KISS 원칙 : 최대한 단순함을 유지하라
‘제어할 수 없는 것에 의존하지 않기 원칙’을 코드 설계에 적용하기
- 제어할 수 없는 값에 의존하는 코드들을 최대한 멀리한다
- 주요 비즈니스 로직은 모두 제어할 수 있는 값만 의존하게 해 테스트 코드 작성이 쉬운 형태로 구성한다
조직과 매니징에 적용하기
제어할 수 없는 것에 집중하다 보면 그 무엇도 해결하지 못할 수 있음. 제어할 수 있는 것에 의존하고 집중해야만 어떤 일과 상황을 만나더라도 앞으로 전진할 수 있음.

✏️ 9장 : 달리는 기차의 바퀴를 갈아 끼우기

행동 강령 세 가지
- 일단 동작하게 만든 다음 더 좋게 만들어라
- 언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라
- 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점이다
많이 읽고, 많이 쓰고, 많이 생각하자