Princip softwaru Peter - Software Peter principle - Wikipedia

Tento článek obsahuje a seznam doporučení, související čtení nebo externí odkazy, ale její zdroje zůstávají nejasné, protože jí chybí vložené citace. Prosím pomozte zlepšit tento článek představuji přesnější citace. (Srpna 2011) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

tento článek případně obsahuje původní výzkum. Prosím vylepši to podle ověřování vznesené nároky a přidání vložené citace. Výroky sestávající pouze z původního výzkumu by měly být odstraněny. (Říjen 2019) (Zjistěte, jak a kdy odstranit tuto zprávu šablony)

The Princip softwaru Peter se používá v softwarové inženýrství popsat umírající projekt, který se stal příliš složitým na to, aby ho pochopili i jeho vlastní vývojáři.

V oboru je dobře známý^{[Citace je zapotřebí ]} jako tichý zabiják projektů, ale než se příznaky objeví, je často příliš pozdě na to s tím něco dělat^{[Citace je zapotřebí ]}. Dobří manažeři se mohou této katastrofě vyhnout zavedením jasných postupů kódování, kde se zabrání zbytečně komplikovanému kódu a designu.

Název je v knize použit Časté dotazy k C ++ (viz níže) a je odvozen z Peterův princip - teorie o nekompetentnosti v hierarchických organizacích.

Příčiny

Ztráta koncepční integrity

Koncepční integrita softwaru je měřítkem toho, jak dobře odpovídá jediné jednoduché sadě principů návrhu Mýtický muž měsíc podle Fred Brooks^{[Citace je zapotřebí ]}. Pokud je provedeno správně, poskytuje nejvíce funkčnost pomocí nejjednoduššího idiomy. Usnadňuje používání softwaru tím, že usnadňuje jeho vytváření a učení^{[Citace je zapotřebí ]}.

Koncepční integrity je dosaženo, když návrh softwaru vychází z malého počtu souhlasících jednotlivců^{[Citace je zapotřebí ]}. Aby si software zachoval koncepční integritu, musí být návrh řízen jedinou malou skupinou lidí, kteří důkladně rozumějí kódu (včetně podstaty interakce všech podprogramů a proměnných).

V projektech bez silné softwarová architektura týmu, je úkol designu často kombinován s úkolem implementace a je implicitně delegován mezi jednotlivce vývojáři softwaru. Za těchto okolností je méně pravděpodobné, že vývojáři obětují osobní zájmy ve prospěch zájmů produktu. Složitost produktu roste v důsledku toho, že vývojáři přidávají nové designy a mění dřívější, aby odrážely změny v módě a individuální vkus.

Neschopnost programátora

Nejlepší softwaroví vývojáři chápou důležitost komunikace s lidmi před komunikací s počítačem Kód dokončen podle Steve McConnell. V průměru se 85 procent času programátora věnuje komunikaci s lidmi, zatímco pouze 15 procent se věnuje komunikaci s počítačem.^{[Citace je zapotřebí ]} Programátoři údržby tráví 50 až 60 procent svého času snahou porozumět kódu, který musí udržovat, a softwarový program bude mít v průměru během své životnosti 10 generací programátorů údržby.

Nezkušenost programátora

Programátoři někdy provádějí rozhodnutí o implementaci, která fungují, ale mají nezamýšlené negativní důsledky. Nejběžnější z těchto chyb jsou katalogizovány a označovány jako voní v knize Refaktorování podle Martin Fowler. Mnoho takových implementací v průběhu času degradovalo design softwaru, takže je stále obtížnější jej pochopit.

Viz také

• Anti-vzory
• Pochod smrti (projektový management)
• Greenspunovo desáté pravidlo
• Projektový management
• Proces vývoje softwaru
• Zmatek (software)

Reference

• Časté dotazy k C ++ Cline, Lomow a Girou, Addison-Wesley 1999 ISBN  0-201-30983-1
• Brooks, F., Mýtický muž-měsíc, Addison-Wesley Longman Inc., 1995.
• McConnell, S., Kód dokončen, Microsoft Press, 1993
• Fowler, M., Refaktorování, Addison-Wesley, 2000