Сложность должна обитать где-то

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

Мы пытаемся избавиться от сложности, обуздать её и ищем простоты. Я думаю, что представлять себе суть вещей таким образом это ложный путь. Сложность обязательно должна где-то обитать.

Есть одна вещь из дисциплины построения устойчивых систем (resilience engineering), которая научила меня концепции необходимой вариативности ^[1] (requisite variety) из кибернетики: только сложность может держать под контролем другую сложность.

Когда вы имеете дело с инструментами сборки, проявляются и становятся очевидными несколько моментов:

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

И этого никак не избежать. Сложность должна обитать где-то. Она всегда сопровождает разработчиков в процессе решения проблем, независимо от того, осознаёте вы это или нет.

К сожалению, если мы боремся со сложностью подобно последнему пункту в списке (мы всегда боремся с ней тем или иным образом), обёртки становятся частью "ландшафта" нашей системы. Сложность не ложится в спячку. Она становится частью общего приобретаемого опыта, и разработчики с пользователями вынуждены приспосабливаться к ней.

Они создают временные решения, когда видят несоответствия между парой конфликтующих концепций. Эта необходимая сложность может быть перемещена куда-то — назад в инструмент (или новый инструмент) — или выдавлена путём реконструкции частей. Каждое такое структурное изменение требует определённых усилий и дополнительных подгонок для того, чтобы люди увидели сложность, поняли сложность и научились справляться со сложностью. И в некоторых случаях сделанные изменения не упрощают сущности, они усложняют их создавая новые несоответствия между представлениями в головах разных людей, и это несоответствие порождает новые обёртки. Непреднамеренная сложность (accidental complexity) является просто необходимой сложностью ^[2] (essential complexity), в которой проявился её возраст. Сложность невозможно избежать, она всё время меняется. Сложность должна обитать где-то.

В книге Дизайн привычных вещей ^[3], Дон Норман упоминает о концепциях "Внутренних знаний" (Knowledge in the head) и "Внешней информации" (Knowledge in the world) (подобные концепции в академическом исследовании представлены в работе Roesler & Woods Designing for Expertise ^[4]). Внутренние знания — это факты и связи между ними, которые вы узнали, изучили и которые находятся в вашей памяти. Внешняя информация — это всё остальное: информация в виде текста, знаки в дизайне (вы узнаёте кнопку включения питания просто смотря на её символ и знаете, что она может быть нажата, поскольку выглядит как кнопка) и прочее. Одна нетривиальная вещь состоит в том, что интерпретация внешней информации зависит от культуры контекста, и, вдобавок, она основана на внутренних знаниях (вы знаете, что кнопка включения питания может быть нажата потому, что вы вообще знаете о кнопке в принципе).

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

Типичная ловушка, с которой мы сталкиваемся в процессе проектирования ПО, проявляется в фокусировании на том, насколько "простым" является для нас чтение и понимание конкретного фрагмента кода. Однако фокусирование на простоте чревато множеством затруднений, поскольку сложность не может быть удалена: она может быть только перемещена. Если вы её перемещаете из своего кода, куда она тогда денется?

Когда мы проектировали Rebar3, мы ощущали что инструмент может быть сделан простым в использовании. Отправной точкой для этой простоты являлось общее соглашение о предполагаемой структуре проектов на Erlang/OTP. Пока вы следуете этим правилам, всё отлично работает. Мы вынесли некоторую часть сложности на внешний уровень. Правила всегда были бы изучены (как мы думали), но теперь инструмент зависел от понимания и принятия всеми этих правил. В погоне за упрощением использования инструмента для разработчиков уже освоивших эти правила, мы усложнили использование для новичков и тех, кто ещё находился в процессе изучения. Другие инструменты самого разного назначения в других экосистемах — подобно нам — также выбирают свои компромиссы.

Эта ловушка скрыта и в архитектуре ПО. Когда мы перенимаем какую-то технологию, скажем, микросервисы, мы пытаемся сделать их так, что каждый сервис в отдельности был бы достаточно прост. Но как только эта простота станет чересчур ограничивающей, а ваше приложение будет стремиться вырваться за принудительные рамки простоты, оно должно развиваться куда-то. Если оно не уложится в каждый из микросервисов, то куда оно денется?

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

Не имея какого-то определённого места, она расползётся по всем уголкам внутри вашей системы, и в вашем коде и в головах ваших коллег. А поскольку люди меняют интересы, перемещаются и уходят из проекта, понимание сложности разъедается со временем.

Сложность должна обитать где-то. Если вы принимаете её и отводите для неё подобающее место, соответственно ей проектируете вашу систему и отношения внутри организации, сосредотачиваетесь на приспособлении к ней, зная, что она существует, сложность может однажды стать сильной чертой вашей системы.

Автор: Nick Linker

Источник ^[5]