3.2.3 Планирование в процессе конструирования приложения

Итак, когда актуальные части тактического плана разбиты на конкретные индивидуальные задачи, каждая задача закрепляется за конкретным разработчиком. Чаще всего, на каждую конкретную задачу назначается только один разработчик, который получает целый комплекс задач:

• Кодирование программного решения конкретной заданной задачи

• Тестирование созданного блока (может назначаться “тестировщикам”)

• Интеграция блока в систему

• Тестирования системы с новым блоком (может назначаться “тестировщикам”)

Когда все части плана распределены между разработчиками, неизбежно возникает необходимость дополнительной координации действий разработчиков, разрешения конфликтов которые стали очевидны только после тестов, исправления ошибок и поддержки актуальности спецификаций. Поэтому оперативное планирование и корректировка тактических планов продолжается во время конструирования приложения.

3.2.2 Политика управления сложностью при проектировании по

Программные проекты редко терпят крах по техническим причинам. Чаще всего провал объясняется неадекватной выработкой требований, неудачным планированием или неэффективным управлением. Если же провал обусловлен все-таки преимущественно технической причиной, очень часто ею оказывается неконтролируемая сложность. Иначе говоря, приложение становится таким сложным, что разработчики престают по-настоящему понимать, что же оно делает. Если работа над проектом достигает момента, после которого уже никто не может полностью понять, как изменение одного фрагмента программы повлияет на другие фрагменты, прогресс прекращается.

Управление сложностью — самый важный технический аспект разработки ПО.

 Сложность — не новинка в мире разработки ПО. Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии — единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 10⁹, или разнице в девять порядков. Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: “По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории”. Разумеется, за прошедшее с 1989 г. время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками.

Дейкстра ещё в 1972 году писал, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени.

 На уровне архитектуры ПО сложность проблемы можно снизить, разделив систему на подсистемы. Несколько несложных фрагментов информации понять проще, чем один сложный. В разбиении сложной проблемы на простые фрагменты и заключается цель всех методик проектирования ПО. Чем более независимы подсистемы, тем безопаснее сосредоточиться на одном аспекте сложности в конкретный момент времени. Грамотно определенные объекты разделяют аспекты проблемы так, чтобы можно было решать их по очереди. Пакеты обеспечивают такое же преимущество на более высоком уровне агрегации.

Стремление к краткости методов программы помогает снизить нагрузку на интеллект. Этому же способствует написание программы в терминах проблемной области, а не низкоуровневых деталей реализации, а также работа на самом высоком уровне абстракции.

Суть сказанного в том, что программисты, компенсирующие изначальные ограничения человеческого ума, пишут более понятный и содержащий меньшее число ошибок код. Чаще всего причинами неэффективности являются:

• сложное решение простой проблемы;

• простое, но неверное решение сложной проблемы;

• неадекватное сложное решение сложной проблемы.

 Как указал Дейкстра, сложность современного ПО обусловлена самой его природой, поэтому, как бы вы ни старались разработчики, они все равно столкнутся со сложностью, присущей самой проблеме реального мира. Исходя из этого, можно предложить двойственный подход к управлению сложностью:

• стараться свести к минимуму объем существенной сложности, с которым придется работать в каждый конкретный момент времени;

• сдерживать необязательный рост несущественной сложности.

Такая политика управления сложностью при разработке обычно выражается аббревиатурами KISS & DRY, которые переводятся как “Делай короче и проще” (Keep It Short and Simple) и “Не повторяй себя” (Don’t Repeat Yourself).

 Все остальные аспекты проектирования ПО вторичны, по отношению к управлению сложностью.