본문 바로가기
프로그래밍 놀이터/Tips

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

by 돼지왕 왕돼지 2018. 11. 11.
반응형

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


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


-

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

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

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

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



-

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

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


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


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

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

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



-

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



-

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

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

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



-

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

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

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

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




반응형

댓글