Programowa zasada Petera
Software Peter jest używana w inżynierii oprogramowania do opisania umierającego projektu, który stał się zbyt złożony, aby mógł go zrozumieć nawet jego własny programista.
Jest dobrze znany w branży [ potrzebne źródło ] jako cichy zabójca projektów, ale zanim pojawią się objawy, często jest już za późno, aby cokolwiek z tym zrobić [ potrzebne źródło ] . Dobrzy menedżerowie mogą uniknąć tej katastrofy, ustanawiając jasne praktyki kodowania, w których unika się niepotrzebnie skomplikowanego kodu i projektu.
Nazwa ta jest używana w książce C++ FAQs (patrz poniżej) i wywodzi się z zasady Petera – teorii o niekompetencji w hierarchicznych organizacjach.
Powoduje
Utrata integralności pojęciowej
Integralność koncepcyjna oprogramowania jest miarą tego, jak dobrze jest ono zgodne z pojedynczym, prostym zestawem zasad projektowych, zgodnie z The Mythical Man Month autorstwa Freda Brooksa [ potrzebne źródło ] . Prawidłowo wykonana zapewnia największą funkcjonalność przy użyciu najprostszych idiomów . Ułatwia korzystanie z oprogramowania, ułatwiając jego tworzenie i naukę [ potrzebne źródło ] .
Integralność koncepcyjna jest osiągana, gdy projekt oprogramowania pochodzi od niewielkiej liczby zgadzających się osób [ potrzebne źródło ] . Aby oprogramowanie zachowało integralność koncepcyjną, projekt musi być kontrolowany przez pojedynczą, małą grupę ludzi, którzy rozumieją kod (w tym naturę interakcji wszystkich podprogramów i zmiennych) dogłębnie [ potrzebne źródło ] .
W projektach bez silnego zespołu zajmującego się architekturą oprogramowania , zadanie projektowania jest często [ łasica słów ] łączone z zadaniem implementacji i jest pośrednio delegowane pomiędzy poszczególnych programistów [ potrzebne źródło ] . W takich okolicznościach programiści są mniej skłonni do poświęcania osobistych interesów na rzecz interesów produktu [ potrzebne źródło ] . Złożoność produktu rośnie w wyniku dodawania przez programistów nowych projektów i modyfikowania wcześniejszych w celu odzwierciedlenia zmian w modzie i indywidualnych gustach [ potrzebne źródło ] .
Niekompetencja programisty
Dobrzy programiści rozumieją, że komunikacja z ludźmi jest ważniejsza niż komunikacja z komputerem, zgodnie z Code Complete autorstwa Steve'a McConnella . Średnio 85 procent czasu programisty spędza na komunikowaniu się z ludźmi, podczas gdy tylko 15 procent spędza na komunikowaniu się z komputerem. [ potrzebne źródło ] Programiści zajmujący się konserwacją spędzają od 50 do 60 procent swojego czasu, próbując zrozumieć kod, który mają obsługiwać, a program będzie miał średnio 10 pokoleń programistów zajmujących się konserwacją [ potrzebne źródło ] .
Brak doświadczenia programisty
Programiści czasami dokonują wyborów implementacyjnych, które działają, ale mają niezamierzone negatywne konsekwencje. Najczęstsze z tych błędów są skatalogowane i opisane jako zapachy w książce Refactoring autorstwa Martina Fowlera . Z biegiem czasu wiele takich wyborów implementacyjnych pogarsza wygląd oprogramowania, czyniąc je coraz trudniejszym do zrozumienia.
Zobacz też
- Antywzorce
- Marsz śmierci (zarządzanie projektem)
- Dziesiąta reguła Greenspuna
- Zarządzanie projektami
- Proces tworzenia oprogramowania
- Zaciemnianie (oprogramowanie)
- Często zadawane pytania dotyczące C++ autorstwa Cline, Lomow i Girou, Addison-Wesley 1999 ISBN 0-201-30983-1
- Brooks, F., Mityczny miesiąc osobowy , Addison-Wesley Longman Inc., 1995.
- McConnell, S., Kompletny kod , Microsoft Press, 1993
- Fowler, M., Refaktoryzacja , Addison-Wesley, 2000