Бағдарламалық жасақтамадағы «Питер принципі» – жобаның күрделілігі артып, тіпті жасаушыларына да түсініксіз болатын жағдай. Алдын алу жолдары мен шешімдері.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Күрделі, сәтсіз жобаны сипаттау үшін қолданылатын инженерлік термин. Бағдарламалық жасақтамадағы Питер принципі жобаның өліміне сипаттама береді, ол тіпті оны жасаған бағдарламашылардың өзіне түсініксіз болып кеткен. Бұл салада жобаларды жайсыз өлтіретін жағдай ретінде танымал, бірақ белгілері байқалғанда, әрекет ету үшін әдетте кеш болады. Жақсы менеджерлер қажетсіз күрделі код пен дизайннан сақтау үшін нақты кодтау талаптарын белгілеп, осы апатты болдырмауға тырысуы керек. Аталған принцип C++ Сұрақ-жауаптар кітабында (төменде қараңыз) қолданылады және иерархиялық ұйымдардағы біліксіздік туралы теория – Питер принципінен алынған.
Engineering term for a complex, failing project
The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers. It is well known in the industry as a silent killer of projects, but by the time the symptoms arise it is often too late to do anything about it. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided. The name is used in the book C++ FAQs (see below), and is derived from the Peter principle – a theory about incompetence in hierarchical organizations.
Тұжырымдамалық тұтастықтың жоғалуы
"Мифтік адам-ай" еңбегінде жазылғандай, бағдарламалық қамтамасының тұтастығы – оның бір жай ғана жобалау қағидаларына қаншалықты сәйкес келетінін көрсететін өлшем. Дұрыс жасалғанда, ол ең қарапайым тәсілдерді пайдаланып, ең көп мүмкіндіктерді ұсынады. Бағдарламалық қамтамасының жасалуын және оқуын оңайлату арқылы пайдалануды жеңілдетеді. Тұжырымдық тұтастыққа бағдарламалық қамтамасының жобасы бір-бірімен келісетін шағын топтың еңбегінен бастағанда қол жеткізіледі. Бағдарламалық қамтамасының тұжырымдық тұтастығын сақтау үшін, жобаны кодты (барлық кіші бағдарламалар мен айнымалылардың өзара әрекеттесу ерекшеліктерін қоса алғанда) терең түсінетін бір, шағын топтың бақылауында ұстау қажет. Мықты бағдарламалық архитектура тобы жоқ жобаларда, жобалау міндеті көбінесе іске асырумен біріктіріліп, жеке бағдарламалық қамтамасы дамытушыларына жүктеледі. Мұндай жағдайларда, дамытушылар өнімнің мүддесі үшін жеке мүдделерінен бас тартуға бейім емес. Өнімнің күрделілігі дамытушылардың жаңа жобаларды қосуы және сән мен жеке талғам өзгергенде бұрынғыларын өзгерткенінің нәтижесінде өседі.
The conceptual integrity of software is a measure of how well it conforms to a single, simple set of design principles, according to The Mythical Man Month. When done properly, it provides the most functionality using the simplest idioms. It makes software easier to use by making it simple to create and learn. Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals. For software to maintain conceptual integrity, the design must be controlled by a single, small group of people who understand the code (including the nature of how all the subroutines and variables interact) in depth. In projects without a strong software architecture team, the task of design is often combined with the task of implementation and is implicitly delegated among the individual software developers Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product. The complexity of the product grows as a result of developers adding new designs and altering earlier ones to reflect changes in fashion and individual taste.
Бағдарламашының қабілетсіздігі
Code Complete сайтында жазылғандай, жақсы бағдарламашылар компьютермен емес, адамдармен байланыс жасаудың маңызды екенін түсінеді. Зерттеулер көрсеткендей, бағдарламашылар уақытының 50% астамын адамдармен байланысқа жұмсайды, ал нақты бағдарламалау олардың еңбек тәжірибесіне қарай 10-15% ғана уақыт алады. Қолдау бағдарламашылар өздері қолдау көрсетуге тиіс кодты түсінуге уақытының 50-60% жұмсайды, ал бір бағдарламалық жасақтаманың өмірінде орташа есеппен 10 буын қолдау бағдарламашылары болады.
Good software developers understand the importance of communicating with people over communicating with the computer, according to Code Complete. Studies showed that programmers spends more than 50% of their time communicating with people, while the actual programming may only take up as little as 15% to 10%, depending on the level of seniority. Maintenance programmers spend 50 to 60 percent of their time trying to understand the code they have to maintain and a software program will have, on average, 10 generations of maintenance programmers in its lifetime.
Бағдарламашы тәжірибесіз
Кейде бағдарламашылар жұмыс істейтін, бірақ күтпеген жағымсыз салдарлары бар іске асыру таңдауларын жасайды. Мұндай қателіктердің ең көп кездесетіні "Refactoring" кітабында тізімделген және "иіс" деп аталады. Уақыт өте келе, мұндай іске асыру таңдауларының көптегені бағдарламалық құралдың дизайнын нашарлатады, оны түсінуді қыйындатады.
Programmers sometimes make implementation choices that work but have unintended negative consequences. The most common of these mistakes are cataloged and referred to as smells in the book Refactoring. Over time, many such implementation choices degrade the software’s design, making it increasingly difficult to understand.