Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
В вычислительной технике модель хаоса — это структура разработки программного обеспечения. Её создатель, использовавший псевдоним L. B. S. Raccoon, отмечал, что модели управления проектами, такие как спиральная модель и модель водопада, хотя и хорошо справляются с планированием и управлением персоналом, не предлагают методов для исправления ошибок или решения других технических проблем. В то же время, методологии программирования, будучи эффективными в устранении ошибок и решении технических проблем, не помогают в соблюдении сроков или реагировании на запросы заказчиков. Данная структура призвана восполнить этот пробел. Теория хаоса была использована как инструмент для понимания этих проблем.
In computing, the chaos model is a structure of software development. Its creator, who used the pseudonym L. B. S. Raccoon, noted that project management models such as the spiral model and waterfall model, while good at managing schedules and staff, didn't provide methods to fix bugs or solve other technical problems. At the same time, programming methodologies, while effective at fixing bugs and solving technical problems, do not help in managing deadlines or responding to customer requests. The structure attempts to bridge this gap. Chaos theory was used as a tool to help understand these issues.
Жизненный цикл разработки программного обеспечения
Модель хаоса отмечает, что фазы жизненного цикла применимы ко всем уровням проектов – от всего проекта до отдельных строк кода. Весь проект должен быть спроектирован, реализован и интегрирован. Системы должны быть спроектированы, реализованы и интегрированы. Модули должны быть спроектированы, реализованы и интегрированы. Функции должны быть спроектированы, реализованы и интегрированы. Строки кода должны быть спроектированы, реализованы и интегрированы. Важное изменение в подходе заключается в том, можно ли рассматривать проекты как единое целое или необходимо рассматривать их по частям. Никто не пишет десятки тысяч строк кода за один приём. Они пишут небольшие фрагменты, по одной строке за раз, проверяя, что эти фрагменты работают. Затем они наращивают систему на их основе. Поведение сложной системы возникает из совокупного поведения её более мелких компонентов.
The chaos model notes that the phases of the life cycle apply to all levels of projects, from the whole project to individual lines of code. The whole project must be defined, implemented, and integrated. Systems must be defined, implemented, and integrated. Modules must be defined, implemented, and integrated. Functions must be defined, implemented, and integrated. Lines of code are defined, implemented and integrated. One important change in perspective is whether projects can be thought of as whole units, or must be thought of in pieces. Nobody writes tens of thousands of lines of code in one sitting. They write small pieces, one line at a time, verifying that the small pieces work. Then they build up from there. The behavior of a complex system emerges from the combined behavior of the smaller building blocks.
Стратегия хаоса
Стратегия хаоса — это стратегия разработки программного обеспечения, основанная на модели хаоса. Основное правило — всегда решать самую важную задачу в первую очередь. Задача — это незавершенное задание по программированию. Самая важная задача — это сочетание значимости, срочности и надежности. Значимые задачи предоставляют пользователям рабочую функциональность и ценность. Срочные задачи важны, поскольку в противном случае они заблокируют другую работу. Надежные задачи, после решения, подтверждены тестированием и вызывают доверие. Разработчики могут затем безопасно переключить свое внимание на другие задачи. Решить задачу означает довести ее до стабильного состояния. Стратегия хаоса напоминает подход программистов к завершению проекта, когда у них есть список ошибок для исправления и функций для реализации. Обычно кто-то расставляет приоритеты оставшимся задачам, и программисты выполняют их по одной. Стратегия хаоса утверждает, что это единственный правильный способ работы. Стратегия хаоса была вдохновлена практиками разработки в Go.
The chaos strategy is a strategy of software development based on the chaos model. The main rule is always resolve the most important issue first. An issue is an incomplete programming task. The most important issue is a combination of big, urgent, and robust. Big issues provide value to users as working functionality. Urgent issues are timely in that they would otherwise hold up other work. Robust issues are trusted and tested when resolved. Developers can then safely focus their attention elsewhere. To resolve means to bring it to a point of stability. The chaos strategy resembles the way that programmers work toward the end of a project, when they have a list of bugs to fix and features to create. Usually someone prioritizes the remaining tasks, and the programmers fix them one at a time. The chaos strategy states that this is the only valid
way to do the work. The chaos strategy was inspired by Go strategy.
Связь с теорией хаоса
Есть несколько связей с теорией хаоса. Модель хаоса может помочь объяснить, почему программное обеспечение так сложно предсказать. Она объясняет, почему высокоуровневые концепции, такие как архитектура, нельзя рассматривать обособленно от низкоуровневого кода. Она предлагает подход к определению дальнейших действий, исходя из стратегии хаоса.
There are several tie ins with chaos theory. The chaos model may help explain why software tends to be so unpredictable. It explains why high level concepts like architecture cannot be treated independently of low level lines of code. It provides a hook for explaining what to do next, in terms of the chaos strategy.