왜?
새로운 회사에 들어가기 전,
회사의 팀에 소속되어, 원활한 협업 문화와 지속가능한 소프트웨어를 개발할 줄 아는 동료가 되고 싶어서
(내가 기억하고 싶은 내용 위주로만 작성)
소통 주의점
문서 읽는 습관은 몸에 배야 한다.
- 팀 문서와 설계 문서부터 꼼꼼히 분석하자.
제대로 질문하자
스스로 문제를 먼저 해결해보자
(문제 해결을 위한) 제한 시간을 정하자
자신이 시도한 방법을 공유하자
비동기식 멀티캐스팅 의사소통을 하자.
레거시 코드 변경 주의점
레거시 코드 변경 알고리즘을 활용하자
- 변경 지점을 확인한다
- 테스트할 지점(수정하고자 하는 코드의 진입점)을 확인한다.
- 의존성을 나눈다
- 테스트를 작성한다.
- 변경을 적용하고 리팩터링한다.
점진적으로 변경하자
- 수십개의 파일을 한번에 수정하는 변경 PR를 피해라
- 리팩터링과 새로운 기능이 뒤섞인 PR 를 피해라
- 항상 최소한의 변경 단위로, 커밋하자 -> 코드 리뷰 및 관리 편함
되도록 검증된 기술을 사용하자
장애를 대비하기 위한 방어적 프로그래밍 방안
- null 값 사용은 피해라 -> 널 객체 패턴이나 옵션 타입을 이용해라
- 불변 변수를 사용하자
- 타입 힌트와 정적 타입 검사를 활용하자 -> 객체타입으로 사용해라
- 입력값을 검사하자
- 원치 않는 입력값을 검증하는 로직 필요하고, 최대한 이른 시점에 실행을 거부하자.
- 구체적인 예외를 사용하자
- null, 0, -1 특정한 리턴값으로 에러를 표현하는 것은 금물이다. -> 구체적인 예외를 지정하여 사용하자
- 예외는 일찍 던지고, 최대한 나중에 처리하자
- 에러가 발생한 곳에서 최대한 가까운 지점에서 예외를 던지자
- 예외를 완전히 처리하거나 혹은 상위 스택으로 전파하여 -> 원하는 에러처리는 최대한 나중에 처리하자.
- 시스템에 멱등성을 부여하자
문제 원인을 찾기 위한 로깅 방안
- 로그 레벨을 사용하자
코드 리뷰 주의점
코드 리뷰 받을 준비하자
- 개별 코드 변경을 작게 유지하고, 기능과 리팩터링 작업은 서로 다른 리뷰로 분리하자
코드 리뷰 해줄 준비해라
코드 변경사항을 이해하자
- 이 변경이 왜 필요한지, 이전 코드 어떻게 동작했는지, 변경 후 동작은 어떻게 바뀌는 지 이해하자
아래 이슈사항들에 대해 포괄적인 피드백을 제시하자
- 변경의 올바름, 구현, 유지보수성, 적합성, 보안성
- 스타일 가이드, 읽기 어려운 코드
- 테스트 코드, 버그
좋은 점은 인정하자
- 칭찬도 필요하다
대충대충 리뷰는 금물이다.
- 리뷰를 빨리 승인한다면, 팀 전체에겐 오히려 검증 기회를 놓치고, 손해가 난다.
소프트 웨어 개발 전체 과정 주의점
빌드 > 릴리스 > 배포 > 롤아웃
- 빌드 : 코드를 패키지로 만듬
- 릴리스 : 패키지 생성 후 산출물 발행, 문서 업데이트, 릴리스 노트, 사용자와의 소통
- 배포 : 테스트 환경이나, 프로덕트 환경에 배포(사용자 접근 불가)
- 롤아웃 : 사용자 접근 가능
올바른 기술 설계 주의점
문제를 정의하자
- 정확한 문제를 파악하다가, 더 좋은 방식으로 문제가 해결되는 경우도 있다.
해결 방법을 조사
- 해당 설계는 최초의 방안이 아니라 최선의 방안이여야한다.
- 온라인의 수많은 문제 및 해결방법을 참조해라
설계 문서 작성 이유를 이해하자
- 문서화는 내가 모르는 것을 드러내는 방법이다.
- 문서화는 피드백 요청하는 것도 쉬워지게 한다.
- 새로 팀에 합류한 엔지니어에게 유용하다.
- 관련 팀원들이 설계 문서를 이용해 프로젝트에 대한 계획을 세울 수 있다.
설계 문서 템플릿 만들기
- 개요
- 현재의 상태와 컨텍스트
- 변경해야 하는 이유
- 요구사항
- 고려할 수 있는 해결책
- 채택하려는 해결책
- 설계와 아키텍처
- 시스템 다이어그램
- UI/UX 변경
- 코드 변경
- API 변경
- 영속 계층 변경
- 테스트 계획
- 롤아웃 계획
- 미결 사항
- 부록
진화하는 아키텍처를 위한 설계원칙
- YAGNI 원칙 : 당장 필요치 않다면 구현하지 말것
- 최소 기능 제품으로 설계하며, 불필요하게 유연한 추상화, 너무 이른 최적화 필요없다.
- 최소 충격 원칙 : 사용자를 놀래키지 말것
- 구체적인 코드를 작성하고 암묵적 요소를 제거하고, 표준 라이브러리와 패턴을 사용해야한다
- 암묵적 요소 예시
- 감춰진 인수 요구사항, 감취진 호출 순서 요구사항 등등
- 도메인 지식은 캡슐화되어야한다.
- 높은 응집도와 낮은 결합도 지향