1. 이 책의 주제는 어떤 설계인가?

품질 특성	설명	품질 관련 부가 특성
기능 적합성	기능이 요구를 만족하는 정도	기능 무결성, 기능 정확성, 기능 적절성
성능 효율성	리소스 효율과 성능 정도	시간 효율성, 자원 효율성, 용량 만족성
호환성	다른 시스템과 정보 공유, 교환 가능 정도	공존성, 상호 운용성
사용성	사용자 만족도	적절도 인식성, 습득성, 운용 조작성, 사용자 오류 방지성, 사용자 인터페이스 편의성, 접근성
신뢰성	필요할 때 기능을 실행할 수 있는 정도	성숙성, 가용성, 장애 허용성, 회복성
보안	허용되지 않은 사용자로부터 보호할 수 있는 정도	기밀성, 무결성, 부인 방지성, 책임 추적성, 인증성
유지보수성	유지보수가 얼마나 쉬운가 정도	모듈성, 재사용성, 분석성, 수정성, 시험성
이식성	다른 실행 환경에 이식할 수 있는 정도	적응성, 설치성, 치환성

• 소프트웨어 설계
  • 소프트웨어의 품질특성을 향상시키기 위한 구조를 만드는 것
• 유지보수성
  • 시스템이 정상 운용되도록 유지보수하기 얼마나 쉬운가를 나타내는 정도
  • 수정성 (변경용이성)
    • 버그를 발생시키지 않고 얼마나 쉽고 정확하게 코드를 변경할 수 있는 나타내는 정도

2. 설계 x → 개발 생산성 저하

• 레거시 코드
  • 변경하기 어렵고 버그 생기기 쉬운 코드
• 기술부채
  • 레거시 코드가 축적된 상태
• 변경 용이성 설계 하지 않음 → 레거시 코드 → 기술 부채 → 개발 생산성 저하

요인1: 버그 발생 쉬운 구조

• 낮은 응집도 구조 → 수정 누락 가능성
• 난해한 코드 → 실수 유발
• 잘못된 값 → 버그 유발

요인2 : 가독성 낮은 구조

• 이해하기 어려움
• 관련 로직 찾는데 시간 오래 걸림
• 잘못된 값의 출처 추적 어려움

나무꾼 딜레마 🪵

나무꾼이 도끼로 열심히 나무를 베고 있었습니다.
지나가던 여행자가 그 모습을 보고 있는데, 나무가 잘 베이지 않았습니다.
잘 보니 도끼의 날이 너무 무딘 것 같아서 여행자가 말했습니다.
”도끼를 갈고 나무를 베는 것이 좋지 않을까요?”
나무꾼은 대답했습니다.
”알고 있지만, 나무를 베는 것이 바빠서 도끼를 갈 시간이 없어요!”

• 즉, 제대로 설계하지 않으면 로직변경, 디버그에 많은 시간 소비
• 설계할 시간 여유조차 빼앗은 결과 초래

열심히 일했지만 생산성이 나쁨

• 성과를 내기 쉬운 구조를 설계하는데 노력하지 않았다면 열심히 일한 게 아니다.

국가 규모 경제 손실

• 설계를 안 하면 나라가 망한다?!
• 복잡하고 난해한 로직은 증식하는 특성
• 릴리즈가 불가한 정도의 생산성 저하로 손실

3. 소프트웨어와 엔지니어의 성장 가능성

• 소프트웨어의 성장 가능성을 높이는 것이 핵심
• 엔지니어의 자산
  • 기술력
  • 레거시 코드는 자산(기술력)의 축적을 방해하는 무서운 존재
• 레거시 코드는 대물림 되는 현상
• 레거시 코드는 고품질 설계 경험 막음
• 레거시 코드는 시간을 낭비하게 만듬
  • 읽고 이해하는데 많은 시간이 소비되므로, 다른 좋은 경험을 할 시간이 줄어들기 때문

4. 문제 해결하기

• 문제 인식하지 못하면 설계에 대한 생각 자체가 떠오르지 않음
• 인지하기 쉬운 문제
  • 신기능
  • 버그
• 인지하기 어려운 문제
  • 아키텍처
  • 기술 부채
• 소스코드 독해 스킬 ≠ 기술 부채 인식 스킬
• 이상적인 형태를 알아야 문제 인식 가능
  • 이상적인 설계와 현재 설계를 비교
• 변경 용이성을 비교할 수 없는 딜레마
  • 변경 용이성은 미래에 대한 지표
  • 시간 경과해야 파악 가능

5. 코드 상태 판단 지표

• 코드 메트릭 = 소프트웨어 메트릭
  • 현재 소스 코드의 좋고 나쁨을 판단하는 지표
• 실행되는 코드 라인 수
  • 한 메소드 당 10~15줄
  • 한 클래스 당 100 줄
  • 줄 수가 많다면 메소드 / 클래스 분할 고려
    • 동작 하나하나 일관성, 정상동작하는 구조를 갖도록 클래스를 분할
    • 내부 동작을 라이브러리처럼 신경쓰지 않고 사용할 수 있도록 만들어야 함
• 순환복잡도
  • 코드의 구조적인 복잡함을 나타내는 지표
  • 조건분기, 반복처리, 중첩 → 순환복잡도 증가
  • 조기리턴, 전략패턴, 일급 컬렉션 → 순환 복잡도 감소
  • 데이터클래스는 복잡도는 0이지만 다른 클래스에 영향
• 응집도
  • 모듈(클래스, 패키지, 레이어) 내부에서 데이터와 로직이 관련되어 있는 정도
  • 응집도가 높을수록 변경용이성 높고 좋은 구조
  • LCOM으로 확인 가능
• 결합도
  • 모듈 간 의존도 나타내는 지표
  • 어떤 클래스가 호출하는 다른 클래스 수
  • 결합도가 높을수록 넓은 범위 고려해야 함 → 그니까 적은 결합도가 좋은 것
  • 결합도가 높다
    • 클래스가 많은 일을 하고 있다
    • SRP가 깨졌다
    • 의존 줄이는 방법, 클래스 분할 방법을 고려하자.
• 청크
  • 매지컬 넘버 4
    • 인간이 단기기억으로 한 번에 기억할 수 있는 개념 수
  • 청크
    • 기억할 수 있는 정보 단위
    • 장기기억이 되면 더 큰 규모의 기억 단위로 합쳐짐
  • 클래스 설계할 때 매지컬 넘버 4를 염두하고 뇌가 쉽게 받아들일 수 있도록 하자.
  • 강하게 연결된 개념을 응집
  • 각각 작은 클래스로 분할
  • 개념 관계 명확히 설정

6. 코드 분석 지원 도구

• Code Climate Quality
• Understand
• Visual Studio
• 구문 강조 코드

7. 설계대상과 비용 대비 효과

• 비용 대비 효과가 높은 부분을 리팩토링 설계 대상으로 정하는 게 좋다.

파레토의 법칙 (8:2 법칙)

• 전체 결과의 80% 가 전체 원인의 20%에서 일어난다는 법칙
• 중요하고 사양변경 빈번한 곳에 하면 가성비 좋음

코어 도메인: 서비스 중심 영역

• 서비스에서 중심이 되는 비즈니스 영역 (DDD)
• 시스템에서 가장 큰 가치 창출하는 곳
• 중요하고 비용 대비 효과가 가장 큰 곳
• 차별점을 만들며, 경쟁 우위를 만들 수 있는 곳

중점 설계 대상 선정에는 비즈니스 지식 필요

• 중요한 기능은 높은 빈도로 사양변경 일어나는 경향
• 도메인 전문가와 협력 필요
• 구조의 좋고 나쁨에만 주목하지 말고, 설계가 비즈니스 전략을 제대로 뒷받침하는지 판단하기

8. 시간 다스리는 능력자 되기

• 시스템 설계 엔지니어는 내부 구조를 그림
• 설계 본질을 아는 엔지니어는 악마(레거시 코드)를 머릿속에 그림