Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Инженерный термин для сложного, провального проекта.
Engineering term for a complex, failing project
Принцип Питера в разработке программного обеспечения используется для описания проекта, находящегося в состоянии упадка, который стал настолько сложным, что его собственные разработчики уже не могут его понять. В индустрии это хорошо известно как "тихий убийца" проектов, но к моменту проявления симптомов часто бывает уже слишком поздно что-либо предпринять. Опытные менеджеры могут предотвратить эту катастрофу, установив чёткие правила кодирования, избегающие излишне сложного кода и архитектуры. Этот термин используется в книге C++ FAQs (см. ниже) и происходит от принципа Питера – теории о некомпетентности в иерархических организациях.
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 Mythical Man Month", концептуальная целостность программного обеспечения – это мера соответствия единому, простому набору принципов проектирования. При правильной реализации она обеспечивает максимальную функциональность, используя наиболее простые подходы. Это облегчает использование программного обеспечения, упрощая его создание и изучение. Концептуальная целостность достигается, когда проектирование программного обеспечения осуществляется небольшой группой согласованных специалистов. Для поддержания концептуальной целостности дизайн должен контролироваться одной небольшой группой людей, глубоко понимающих код, включая взаимосвязь всех подпрограмм и переменных. В проектах, где отсутствует сильная команда по архитектуре программного обеспечения, задача проектирования часто объединяется с задачей реализации и неявно делегируется отдельным разработчикам. В таких условиях разработчики менее склонны жертвовать личными интересами ради интересов продукта. Сложность продукта возрастает из-за добавления разработчиками новых элементов дизайна и изменения существующих, отражающих текущие тенденции и индивидуальные предпочтения.
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.
Некомпетентность программиста
Согласно книге «Код как искусство», хорошие разработчики программного обеспечения понимают, что общение с людьми важнее, чем общение с компьютером. Исследования показали, что программисты тратят более 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.
Неопытный программист
Программисты порой принимают решения при реализации, которые работают, но приводят к нежелательным негативным последствиям. Наиболее часто встречающиеся из этих ошибок задокументированы и называются "запахами" в книге "Рефакторинг". Со временем множество подобных решений при реализации ухудшают архитектуру программного обеспечения, делая его всё сложнее для понимания.
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.