[실용주의 프로그래머] 명세의 함정

[실용주의 프로그래머] 명세의 함정

[실용주의 프로그래머] 명세의 함정, 명세의 순환, 명세화, 예광탄, 프로토타이핑

프로그램 명세화란 어떤 요구사항을 가져와 프로그래머가 자기 기술로 작업을 시작할 수 있는 시점까지 정리하는 과정이다.

명세화는 주요한 모호함들을 제거하는 등의 방법으로 세계를 설명하고 명확하게 만드는 의사소통의 한 행위다.

명세는 맨 먼저 구현할 개발자들과 하는 대화일 뿐만 아니라, 코드를 유지보수하고 개선할 미래의 프로그래머들을 위한 기록이다.

명세는 사용자와 하는 약속이기도 하다. 즉 사용자의 필요를 명문화한 것이며 최종시스템이 그요구사항과 일치할 거라는 암묵적인 계약이기도 하다.

명세의 작성에는 굉장히 무거운 책임이 따른다.

문제는 많은 설계자들이 명세서 작성을 멈추지 못한다는 점이다. 설계자들은 사소한 세부사항까지도 고난에 차도록 시시콜콜하게 밝혀놓지 않는 한 그날 하루 일을 제대로 하지 못했다고 느낀다.

이것은 여러 가지 이유로 볼 때 실수다.

1. 어떤 명세서가 어떤 시스템이나 그 시스템에 대한 요구사항의 모든 세부사항과 미묘한 차이점들을 모조리 잡아낼 수 있으리라고 믿는 것은 순진한 생각이다.

2. 언어 자체의 표현 능력에도 문제가 있다. 어떤 다이어그램 기법도 형식적 방법도 수행할 작업을 기술하려면 여전히 자연 언어로 된 표현에 의존해야 한다. 그러나 자연 언어는 이 일에 정확하게 걸맞지는 않다.

3. 구속복(straightjacket) 효과가 있다. 코딩하는 사람에게 해석의 여지를 전혀 남기지 않는 설계는 프로그래밍 노력으로부터 모든 수완과 기술을 빼앗아버린다.

어떤 일들은 설명하기보다 실제로 하는 것이 쉽다.

명세서가 계속 상세해지다 보면 결국 그 이득이 감소하거나 심지어 줄어드는 지점에 이르게 된다는 점을 염두에 두어야 한다.

그리고 어떤 명세서를 뒷받침 해주는 구현이나 프로토타입 없이 그 명세서를 기반으로 그 위에 또 다른 명세서를 만드는 것도 조심해야 한다.

만들어질 수는 없어도 그 명세를 쓰는 일은 너무나도 쉽기 때문이다.

명세서 작성 때문에 개발자들이 코드 작성을 미루는 기간이 길어질수록 진자 코드 작성 단계로 옮겨가기는 점점 더 힘들어진다.

이런 명세의 순환에 빠지지 말라.

언젠가는 코딩을 시작해야 한다.

프로토타이핑을 해보거나, 예광탄 개발을 고려해보자.