아! 전봇대 선이 너무 복잡하다. 개발이 다 된 소프트웨어를 어느날 유지보수를 위해 열어 보았더니 너무 복잡해서 개발 당사자도 한참 소스를 분석하는 경험을 하셨을 것이다. 소프트웨어가 복잡해 지면 개발 뿐만 아니라 유지보수시 영향도가 커져서 오류의 발생율이 높아져 품질과 생산성을 떨어뜨릴 수 있다. 소프트웨어의 초기 버전은 나름 모듈화도 하고 심플하게 개발이 되었을 것이다. 그러나 계속적인 요구사항 변경과 디버깅 작업을 통해 계속적으로 복잡하게 된다. 전봇대가 처음부터 복잡하지 않았을 것이다. 계속적인 사용자의 증가와 요구사항 변경에 따라 계속적으로 선을 연결하다 보니 복잡해졌을 것이다.
개발 및 유지보수시 품질 및 생산성을 향상시킬 수 있는 방안의 하나로 기능의 단순화와 소프트웨어 구조 단순화를 들수 있다. 기능의 단순화는 요구사항 분석 단계에서 불필요한 기능을 제거하고 사용자가 원하는 기능만을 잘 정의해야 할 필요성이 있고 소프트웨어 구조 단순화는 설계단계에서 독립된 모듈의 단위의 크기를 적정하게 정의하는 것이 핵심이라 할 수 있다. 그리고 변경은 반드시 발생하기 나름이며 이 변경에 유연하게 소프트웨어 구조를 설계해야 하며 변경을 할때도 중간 중간 효율적인 구조로 재 설계하는 부분이 설계에 반영되고 소프트웨어에도 반영 되어야 한다. 전봇대도 마찬가지로 작업하면서 중간 중간 선 정리 했으면 복잡하지 않고 잘 정리되어서 나중에 유지보수시 작업 시간을 줄일 수 있지 않았을까?
개발자는 복잡하게 하는것을 좋아하는것 같다. 개발자는 자신의 소스를 하나의 작품으로 생각하고 남이 지적하면 싫어할 정도로 애착과 자부심을 갖고 있다. 그래서 자신의 작품이 남이 보기에 화려하고 심도있게 보였으며 하는 욕구가 있는것 같다. 그래서 조금은 더 새로운 기술로 조금은 더 복잡한 기교를 사용해서 코딩을 하고자 하고 더욱더 많은 기능을 넣으려고 한다. 많은 기능을 추가하면 추가 할 수록 소프트웨어가 복잡하면 복잡할 수록 그 피해는 결국 개발자의 몫이 된다. 조금은 욕심을 버리고 간단한것이 가장 좋다는 생각으로 불필요한것을 조금씩 버리도록 하자!
소프트웨어가 복잡해지면 소프트웨어 모듈간의 Call Depth 또한 깊어진다. Call Depth가 깊어지며 소프트웨어 분석이 어려워지고 유니테스트 코드를 만들기가 힘들어지게 된다. 테스트가 용이하고 유지보수가 용이한 구조를 갖기 위해서는 소프트웨어 모듈간의 Call Depth 또한 고려해야할 사항 중의 하나이다.
Filed under: Architecture & Design | Tagged: Architecture, Design
