Что такое сложность?

Недавно я закончил читать «Философию проектирования программного обеспечения», и во второй главе она исследует тему сложности программного обеспечения. 

Книга «Философия проектирования программного обеспечения» дает практическое определение сложности:

«Сложность — это все, что связано со структурой программной системы, что затрудняет ее понимание и модификацию».

Другими словами, сложность может принимать разные формы и не обязательно иметь какое-либо отношение к производительности: ваш код может быть производительным, но при этом оставаться сложным

В этой статье я хотел бы поделиться некоторыми ключевыми определениями и идеями из книги. Но сначала давайте представим себе обычную ситуацию, в которой вы, вероятно, уже бывали…

Короткая история ужасов

Давайте окунемся в ужасную историю, которую многие из вас, вероятно, пережили или еще ждут.

1. Все началось с простого приложения для управления задачами CRUD. Код был чистым, модульным и простым в обслуживании. Команда разработчиков была довольна, и система отлично работала для первых клиентов.

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

3. Интеграция календаря: Команде пришлось интегрироваться с Календарем Google и Outlook. Разные разработчики реализовали решения, что привело к противоречивым подходам.

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

5. Генератор отчетов: Для генератора отчетов разработчики использовали различные технологии: PDF-файлы, экспорт в Excel и интерактивные информационные панели. Отсутствие единого подхода превратило обслуживание в кошмар.

6. Растущая сложность: Каждая функция разрабатывалась изолированно и быстро, что приводило к зависимостям между функциями. Разработчики начали создавать «быстрые исправления», чтобы все работало, увеличивая сложность и связанность системы.

Разработка программного обеспечения не происходит в вакууме; на него влияют различные внутренние и внешние факторы. Мы все были или будем в такой ситуации.

Начало конца

Потом начались проблемы:

1. Изменения в одной части системы неожиданно повлияли на другие части.
2. Небольшие изменения потребовали внесения изменений во многие другие файлы, что затрудняло оценку.
3. Месяц за месяцем код становился все сложнее для понимания, и его часто исправляли методом проб и ошибок.
4. Производительность снизилась, и все боялись задач по техническому обслуживанию.
5. Неизбежный призыв: «Нам нужен рефакторинг».
6. Определенные задачи могут выполняться только конкретными разработчиками (классика)
7. Со временем некогда прекрасно написанное и хорошо документированное программное обеспечение превратилось в катастрофу.

Именование симптомов

Очевидно, что теперь у нас сложная система.

Теперь давайте «проанализируем» эту сложность, чтобы ее было легче выявить и смягчить.

Ну, «смягчить» означает:

"Чтобы сделать менее тяжелым, серьезным или болезненным; облегчить."

Я считаю, что сложность часто присуща коду. Некоторые вещи сложны по своей природе. Ваша роль как разработчика заключается не только в создании кода, который компьютер сможет эффективно выполнять, но и в создании кода, с которым смогут работать будущие разработчики (включая вас в будущем).

«Управление сложностью — это суть компьютерного программирования».

— Брайан Керниган

Автор упомянутой книги утверждает, что сложность обычно проявляется тремя способами, которые мы рассмотрим здесь.

Изменить усиление

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

Например, если владелец продукта запрашивает поле «приоритет» или «дата завершения», а ваши сущности тесно связаны, сколько изменений вам нужно будет внести?

Когнитивная нагрузка

Когнитивная нагрузка — это объем знаний и времени, необходимый разработчику для выполнения задачи.

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

• Понимание различных интеграций календаря (Google и Outlook).
• Освойте различные подходы к уведомлениям по электронной почте.
• Перейдите по фрагментированному коду генератора отчетов, работающему с PDF-файлами, Excel и информационными панелями.
• Интегрируйте эти разнообразные технологии и стили, чтобы найти и исправить ошибку.

Это классический сценарий «невозможно оценить», где задача может получить один балл или восемь — лучше бросьте D20 и отреагируйте соответствующим образом.

Неизвестные Неизвестные

Неизвестное неизвестное — это когда ты не знаешь того, чего не знаешь.

Это худшее проявление сложности, потому что вы можете изменить то, что не следует, и все сломается.

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

Причины сложности

Увидев ужасную историю и три основных симптома, давайте посмотрим, что вызывает сложность.

1. Зависимости

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

Определение:

Зависимость существует, когда код невозможно понять или изменить изолированно, что требует рассмотрения или изменения связанного кода.

Типы зависимостей:

• Прямой: Модуль A напрямую зависит от модуля B.
• Переходный: Модуль A опирается на модуль B, который опирается на модуль C.
• Цикличность: Модули A, B и C взаимозависимы циклическим образом.

2. Неизвестность

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

Определение:

Неясность возникает, когда важная информация не очевидна.

Примеры неизвестности:

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

Помните: сложность возрастает

• Сложность редко возникает из-за единственной «ошибки» или неправильного решения.
• Сложность нарастает «медленно» из-за плохих решений и зависимостей с течением времени.

Поскольку это происходит постепенно, легко подумать: «Только в этот раз это не будет иметь значения». Но при накоплении исправление одной или двух зависимостей не будет иметь большого значения.

«В разработке программного обеспечения все является компромиссом».
— Я не помню автора

Заключение

Я мог бы написать множество правил, стратегий и фреймворков, которые вы, вероятно, уже видели в Интернете, о том, как избежать сложности: SOLID, шаблоны проектирования, YAGNI, KISS и т. д.

Однако вы можете объединить их все в один руководящий принцип (как упоминалось в книге «Программист-прагматик»). «Легко ли изменить то, что я реализую?» Если ответ отрицательный, то вы, вероятно, увеличиваете сложность.

Простота изменения кода упрощает обслуживание, снижает когнитивную нагрузку на разработчиков, делает систему более адаптируемой и менее подверженной ошибкам.

Спасибо!