1. 커뮤니케이션

• 커뮤니케이션 부족하면 설계 품질에 문제 발생
  • 커뮤니케이션 문제 생기면 버그가 많아지는 경향
• 콘웨이 법칙
  • 시스템 구조는 조직을 닮아 간다
  • 시스템 구조가 팀 단위(릴리즈 단위) 처럼 구성
  • 역콘웨이 법칙이란게 있으나, 유명무실
• 심리적 안정성
  • 어떤 발언을 했을때, 부끄럽거나 거절당하지 않을 것이라는 확신을 느낄 수 있는 심리 상태
  • 안심하고 자유롭게 발언 또는 행동할 수 있는 상태

2. 설계

• 빨리 끝내고 싶다는 심리가 품질 저하의 함정
  • 품질을 무시하고 구현하는 과정 반복되면 조악한 코드는 점점 조악해짐
• 나쁜 코드 작성 시간 > 좋은 코드 작성 시간
  • TDD를 사용하는 편이 전체적으로 보았을 때 더 빠름
• 클래스 설계와 구현 피드백 사이클 돌리기
  • 사양 변경 시 클래스 다이어그램 그리기
  • 책무, 응집도 관점에서 문제 없는지 확인하기
  • 발견한 요소를 클래스 다이어그램에 반영
  • 설계 - 구현 피드백 사이클 돌리면 설계 품질 향상
• 단 한 번의 설계로 완벽한 구조를 만들어 내기 불가
• 성능이 덜어질 수 있으니 클래스를 작게 나누지 말자?
  • 쉰소리
  • 병목이 어딘지 모른 채 성능이 빠른 코드를 작성하는 것은 너무 빠른 최적화
  • 안티패턴
• 설계 규칙을 다수결로 결정하면 코드 품질이 떨어진다
• 설계 규칙을 정할 때 중요한 점
  • 다수결 < 시니어 엔지니어 설계
  • 설계 규칙에 대한 이유, 의도 함께 적기
  • 설계 규칙은 언제든 트레이드 오프 가능
  • 설계 규칙은 타협점에 열려 있긴 해야함.

3. 구현

• 깨진 유리창 이론
  • 유리창 하나를 깬 상태로 방치 → 범죄도시
• 보이스카우트 규칙
  • 왔을때보다 더 깨끗하게 치우고 가자
• 기존 코드 믿지 말고, 냉정하게 판단
  • 선배가 만든코드 ≠ 좋은 코드
  • 정체 파악하는 행위 필요
    • 앵커링 효과
      • 처음 제시한 수치, 정보가 기준 되어, 이후 판단 왜곡
    • 이름 없거나, 이름 모르는 것은 인지 어려움
• 코딩 규칙 사용하기
• 명명 규칙
  • 변수 이름, 클래스 이름, 메소드 이름 정하는 규칙
  • 프로그래밍 언어에 따라 달라짐

4. 리뷰

• Github의 PR 기능 활용하면 좋음
• PR 코드는 코드 히스토리, 경위를 알고 있는 사람 혹은 설계를 자세하게 알고 있는 사람이 리뷰
• 코드 설계 시점에 리뷰
• 존중과 예의
• 정기적 개선 작업 진행
  • 넘어간 결함은 대부분 특별한 대책 없이 방치
  • 이런 걸 모아서 주간 한 번씩 해소하는 것이 좋음
  • Github issue 기능 활용

5. 팀 설계 능력 높이기

• 영향력 갖는 규모까지 동료 모으기
  • 집단 구성원의 10.9% (란체스터 법칙 - 쿠프만 목표)
• 천리길도 한 걸음부터
  • 한 번에 대량을 정보를 받아들일 수 없음
  • 큰 변화에 불안, 저항 느낌
  • 매일 조금씩 지식 공유
• 백문이 불여일견
• 스터디 진행
• 스터디 그룹에서 발생가능한 문제 해결 노하우
• 리더와 매니저에게 설계 중요성, 비용 대비 효과 설명
• 설계 책임자 세우기