Software Peter 원칙
Software Peter principle |
 |
소프트웨어 피터 원리는 소프트웨어 엔지니어링에서 너무 복잡해져서 자체 개발자도 이해할 수 없는 프로젝트를 설명하기 위해 사용됩니다.
업계에서는[citation needed] 프로젝트의 사일런트 킬러로 잘 알려져 있습니다만, 증상이 나타날 때는 이미[citation needed] 너무 늦어져 버리기 일쑤입니다.우수한 관리자는 불필요하게 복잡한 코드와 설계를 피할 수 있는 명확한 코딩 방식을 확립함으로써 이러한 장애를 방지할 수 있습니다.
이 이름은 책 C++ FAQ(아래 참조)에서 사용되며, 계층적 조직의 무능에 대한 이론인 피터 원칙에서 파생되었습니다.
원인들
개념적 무결성의 상실
Fred[citation needed] Brooks의 The Mything Man Month에 따르면 소프트웨어의 개념적 무결성은 소프트웨어가 단일하고 단순한 설계 원칙 세트를 얼마나 잘 준수하는지 보여주는 척도입니다.적절하게 수행되면 가장 간단한 관용구를 사용하여 가장 많은 기능을 제공합니다.소프트웨어를 쉽게 만들고 학습할[citation needed] 수 있도록 함으로써 소프트웨어를 더욱 쉽게 사용할 수 있습니다.
개념적 무결성은 소프트웨어 설계가 소수의 동의자에[citation needed] 의해 진행될 때 달성됩니다.소프트웨어가 개념적 무결성을 유지하기 위해서는 코드를 깊이(모든 서브루틴과 변수가 상호작용하는 특성 포함) 이해하는 소규모 단일 그룹에 의해 설계가 제어되어야 합니다.
강력한 소프트웨어 아키텍처 팀이 없는 프로젝트에서는 설계 태스크가 구현 태스크와 결합되어 개별 소프트웨어 개발자에게 암묵적으로 위임되는 경우가 많습니다.이러한 상황에서 개발자들은 제품의 이익을 위해 개인의 이익을 희생할 가능성이 적다.개발자가 새로운 디자인을 추가하고 패션과 개인의 취향 변화를 반영하여 이전 디자인을 변경함으로써 제품의 복잡성이 커집니다.
프로그래머의 무능력
Steve McConnell의 Code Complete에 따르면 우수한 소프트웨어 개발자들은 컴퓨터와의 통신에서 사람들과의 의사소통의 중요성을 이해하고 있습니다.평균적으로 프로그래머 시간의 85%가 사람들과 소통하는데 소비되는 반면,[citation needed] 불과 15%만이 컴퓨터와 소통하는데 소비된다.유지 보수 프로그래머는 유지 보수해야 할 코드를 이해하는데 시간의 50~60%를 소비합니다.소프트웨어 프로그램에는 평균 10세대의 유지 보수 프로그래머가 평생 사용됩니다.
프로그래머 미숙
프로그래머는 때로는 실행이 가능하지만 의도하지 않은 부정적인 결과를 초래하는 구현을 선택하기도 합니다.이러한 실수들 중 가장 흔한 것은 마틴 파울러의 리팩터링이라는 책에서 분류되고 냄새로 언급된다.시간이 지남에 따라 이러한 많은 구현 선택은 소프트웨어의 설계를 저하시키고 점점 더 이해하기 어렵게 만듭니다.
「 」를 참조해 주세요.
레퍼런스
- Cline, Lomow 및 Girou, Addison-Wesley 1999의 C++ FAQ ISBN0-201-30983-1
- Brooks, F., The Infired Man-Month, Addison-Wesley Longman Inc., 1995.
- McConnell, S., Code Complete, Microsoft Press, 1993
- Fowler, M., Refactoring, Addison-Wesley, 2000
