분석 마비

주의 - 소프트웨어 공학에서 이야기하는 “분석 마비(Analysis Paralysis)” 와 그 해결책으로 나온 애자일 개발 방법론과는 약간 다른 주관적인 관점에서 느낀 내용을 바탕으로 이야기함.

현재까지 내가 생각한 소프트웨어 개발의 과정과, 그 모순

• 일반적인 소프트웨어 개발 과정: 설계 → 검증 → 구현
• 검증만 두번 하는 것 같다는 생각을 하게 됨
  • 설계를 검증하는 걸 이미 가운데 단계에 했으니
  • 구현은 생산적인 결과를 도출하지 않는 무의미한 과정이 되어버림
  • 자꾸 좀 더 완벽한 설계만을 찾게 되는 문제 발생.

문제점과 그 핵심

• 근데 오만한 생각임. 자료구조를 검증하지 않음.
• 근데 사실 검증하는 타겟 자체가 다름
  • 자료구조의 설계 검증 → 구현을 통해서 가능
    • 구현력에 따라 자료구조 설계의 검증 결과가 달라짐
  • 알고리즘의 논리 검증 → 수학을 통해서 가능
    • 논리력에 따라 알고리즘 설계의 검증 결과가 달라짐
• 계약에 의한 설계
  • 책임을 이용해 개념을 정의한다.
  • precondition과 postcondition 만 지키면, 해당 기능은 정상 동작을 보장하는 것.

실제 소프트웨어 개발 과정

1. 책임 분석 & 자료구조/알고리즘 설계
2. 자료구조/알고리즘 검증 & 알고리즘/자료구조 설계
3. 알고리즘/자료구조 검증 & 테스트 코드 작성
4. 테스트 코드 검증 & 구현

자료구조의 검증 방법

1. 주어진 책임에 의한 요구사항을 적절히 만족시키는가?
2. SOLID 를 적절히 준수하였는가?