Evolutionary Desgin

Evolutionary Desgin 은 Martin Fowler와 인터뷰한 article이다.

소프트웨어 개발 방법론으로 설계를 튼튼히 하고, 개발하는 방법과 아무 디자인없이 개발하면서 점진적인 수정을 통해서 다뤄지는 두가지로 나눌 수 있다.
마틴 파울러는 처음 시작할때는 아무 디자인 없이 기능성을 바탕으로 코등하면서 시작하는
Evolutionary design방법을 소개 하고 있다.

즉, upfront 개발 디자인 방법이 썩 좋지 않다는 의견을 모으고, 디자인을 하면서 복잡성은 늘어가고, flexibility가 사라진다. 그리고, upfront 형 코드는 생각을 많이하며 refactor을 하는데 부담이 된다. 그래서, unit test와 약간의 refactoring 법칙을 통해서 보다 능률적이고 빠르게 일처리를 하고 defect를 줄이는 데 목표를 두고 있다.

well-factored 프로그램과 well-designed 프로그램의 차이는 없으며, 강조의 차이만 있다. 즉, 궁극적인 목표는 서로 같다.

코드에서 냄새가 나는 경우를 살피는 것이 중요하다. 즉, 한 메소의 라인수가 100라인이 넘어서면, 그때는 bad smell이 난다고 판단을 해야 할 것이다. 그래서, 잘 쪼개서, 버그를 쉽게 잡아내는데 있다. 크기가 크면 클수록 버그가 어디서 문제인지 알아차리기 힘들고, 직관성도 떨어지기 때문에 문제를 쉽게 처리하는 것이 중요하다.

하지만, 무조건 디자인 자체를 무시하는 것은 상당히 위험스러운 소지라고 생각이 든다. 즉, 버그의 시작은 구조적인 문제에서 시작되는데, 이는 실제 나중의 사소한 버그에도 관련이 있다. 시스템 구조의 문제를 알아차리기 위해서는 먼저 well-planed design의 detail한 부분까지 가야 구조의 문제의 일부를 겨우 알아차릴 수 있게 될 것이다.

작은 프로그램도 아니고, 여러명이서 동시에 진행하는 것이기에 잘 설계된 구조로 가야 통합이 되기 쉽기 때문으로 보인다. 점진적인 개발과 잘 설계하는 개발, 이 둘이 잘 조화되어서 개발되는 방법론이 가장 멋지지 않을까?

즉, 아주 세부적인 부분까지 계획하지 않고, 구조를 잡고, mock형태의 evolution design을 하는 것이 어떨까? 그러면서 시스템 구조는 구조의 설계대로, 코드별 설계는 설계대로, 그리고 서로간의 상호작용에 의해서 소프트웨어가 멋드러지게 개발되는 건 어떨까?

기타 참고 자료

To be explicit
from http://martinfowler.com/articles.html

음.. 이거 언제 다 보냐..