Сложность
Сложность это все что связано со структурой программного обеспечение и мешает пониманию и внесению изменений в систему.
Типы сложности¶
Сложность в программах делится на два типа:
- Необходимая сложность (essential complexity) - сложность предметной области, от которой невозможно никуда деться и ей практически невозможно управлять.
- Побочная сложность (accidental complexity) - сложность, которая добавляется инструментами или неправильными решениями при проектировании самим программистом
Управление сложностью¶
Сложность возникает в момент когда разработчику необходимо внести изменения в систему. Если система состоит из нескольких частей, но некоторые из них никогда не меняются, то какими бы сложными они бы ни были это не влияет на общую сложность всей системы.
Ерик Эванс в книге Domain-Driven Design: Tackling Complexity in the Heart of Software говорил, что человеку сложно судить одновременно о многих вещах (высокая связанность) и также сложно понимать логически не связанные друг с другом идеи (низкая сочетаемость).
С многими проблемами мы не можем бороться, но можем их перенести в место, где у нас больше экспертизы, преимущества и рычагов, чтобы повлиять на решение проблемы.
Больше всего времени в проекте уходит на осознание бизнес области, на составление четких и непротиворечивых требований. То есть больше всего времени уходит на “необходимую сложность”, которой мы не можем управлять.
Одна из важнейших целей хорошего дизайна - сделать систему очевидной. В очевидной системе разработчик может быстро понять, как работает существующий код и что требуется для внесения изменений. Очевидная система - это система, в которой разработчик может быстро догадаться о том, что нужно сделать, не задумываясь, и при этом быть уверенным, что его догадка верна. Поэтому всегда делая архитектурные решения задавайтесь вопросом, если новому разработчику нужно будет внести изменения, насколько просто это будет сделать?
Симптомы сложности¶
- Change amplification. Простое на первый взгляд изменение требует модификации кода во многих местах.
- Cognitive load. Как много разработчику нужно знать, чтобы выполнить задачу. Более высокая когнитивная нагрузка означает, что разработчикам приходится тратить больше времени на изучение необходимой информации, и возрастает риск возникновения ошибок из-за того, что они упустили что-то важное.
- Unknown unknowns. Неочевидно какие части кода необходимо изменить для выполнения задачи, или какой информацией должен обладать разработчик для ее успешного выполнения.
Цитаты¶
Quote
Недостаток гибких решений в том, что за гибкость приходится платить. Гибкие решения сложнее обычных. И весьма разочаровывает, когда вся эта гибкость оказывается не нужна. В итоге может потребоавться лишь какая то часть ее, но невозможно заранее сказать какая. Поэтому чтобы достичь гибкости, приходится вводить ее гораздо больше, чем требуется в действительности.
-- “Refactoring: Improving the Design of Existing Code”
Quote
Рефакторинг предоставляет другой подход к рискам модификации. Возможные изменения все равно надо пытаться предвидеть, как и рассматривать гибкие решения. Но вместо реализации этих гибких решений следует задаться вопросом: “Насколько сложно будет с помощью рефакторинга преобразовать обычное решение в гибкое?” Если, как чаще всего случается, ответ будет “весьма несложно”, то надо просто реализовать обычное решение.
Рефакторинг позволяет создавать более простые проекты, не жертвуя гибкостью, благодаря чему процесс проектирования становится более легким и менее напряженным. Научившись в целом распознавать то, что легко поддается рефакторингу, о гибкости решений даже перестаешь задумываться. Появляется уверенность в возможности применения рефакторинга, когда это понадобится. Создаются самые простые решения, которые могут работать, а гибкие и сложные решения по большей части не потребуются.
-- “Refactoring: Improving the Design of Existing Code”
Quote
Простота это высшая форма сложности.
-- Леонардо Да Винчи
Quote
Сначала художник рисует плохо и просто. Потом сложно и плохо. Потом сложно и хорошо. И только потом - просто и хорошо.”
-- И.Е. Репин
Второе предложение этого высказывания, “потом сложно и плохо”, демонстрирует собою синдром второй системы.
Сложность более очевидна для читателей, чем для писателей. Если вы пишете код, и он кажется вам простым, но другие люди считают его сложным, значит, он сложный. Когда вы оказываетесь в подобной ситуации, стоит выяснить у других разработчиков, почему код кажется им сложным; возможно, из расхождения между вашим и их мнением можно извлечь несколько интересных уроков. Ваша работа как разработчика заключается не только в том, чтобы создавать код, с которым вам легко работать, но и в том, чтобы создавать код, с которым другим тоже легко работать.