За годы работы архитектором я видел разных клиентов, и одна из самых частых ошибок при формулировании технического задания и пожеланий заказчика — смешение разных уровней абстракции.
Приходит мужчина и говорит: — Мне нужна железка, которая будет управлять приводом двери и показывать текущее состояние на семисегментном экране, и обязательно с внешним сервером для удаленного управления, чтобы она могла общаться с этим сервером по TCP, и использовать VueJS для панель управления.
Кажется, понятно, чего хочет человек.
У некоторых даже такое техническое задание вызывает энтузиазм – человек, казалось бы, четко понимает, чего он хочет. Часто он даже указывает на конкретные контроллеры/компоненты/фреймворки/протоколы.
И по такому заказу наверняка можно изготовить необходимую железку.
И это даже сработает, если выбранные компоненты не противоречат друг другу.
А вот если расчет идет не на проект, а на продукт, и потом его нужно будет поддерживать, то гораздо полезнее потратить время и тщательно разбить эти пожелания на уровни, понять, зачем нужен такой экран, зачем TCP, и при чем тут VueJS. Вполне может оказаться, что это технологии, к которым у заказчика возникают приятные чувства из-за синдрома утенка.
Или он просто не знает, что существуют другие типы экранов.
В данном случае речь идет в первую очередь о первом уровне: устройстве, управляющем приводом, с индикацией и дистанционным управлением.
Затем начинаем уточнять требования (но не конкретные технологии).
Устройство в корпусе IP68, с питанием 230В, управляющее асинхронным приводом мощностью 800Вт через частотный привод по протоколу Modbus, имеющее хорошо видимый индикатор, четыре состояния которого (открыто/закрыто/в работе/авария) должны распознаваться по человек с высоты 10 метров, имеющий пульт дистанционного управления, доступный из современных браузеров через Интернет. И только после этого можно приступать к выбору уровня реализации, соответствующего требованиям.
Вот такой контроллер, вот такой трансивер rs485, вот такой блок питания, вот такой индикатор.
Разделить эти два уровня (требования и реализацию) легко — в большинстве случаев под одни и те же требования можно подобрать разные реализации, и это никак не изменит уровень требований.
Уровень требований может измениться, потому что реализация слишком сложна и дорога, или не приятна визуально, но не должна меняться из-за выбора более удобного для разработчика контроллера, иначе вы слишком глубоко заглянули в требования или просто поленились выяснить, почему было сформулировано такое требование.
Допустим, заказчик хочет экран с 8-сантиметровыми символами.
В этот момент архитектор или менеджер по продукту должен спросить, почему именно 8 сантиметров? В большинстве случаев получается, что у заказчика есть требование «видимость с 10 метров» внутри, но он решил упростить задачу и сразу высказал конкретное требование.
Или он просто не может смотреть на него абстрактно, потому что думает о проекте в более понятных для него объектах: абстрактный «экран, видимый с 10 метров», сложнее, чем «большое, знаете ли, такое отображение сегментов, в коробке, положу сюда, на стену повешу».
Но у заказчика по определению нет компетенции разрабатывать проекты, иначе он бы не пришел к вам.
И даже если у него есть эти компетенции, он не может использовать их в разработке именно этого проекта, потому что зачем он тогда к вам пришёл? Решения по проектам должен принимать человек, который будет за них отвечать.
Если клиент не будет нести ответственность за сроки разработки кода для определенного выбранного им экрана, ему не следует выбирать этот экран.
Задача заказчика – сказать, каким требованиям, по его мнению, отвечает выбранная им модель экрана.
Задача лица, принимающего архитектурные решения, — выбрать наиболее подходящее решение для реализации этих требований.
Это может быть светодиодный экран, ЖК-дисплей или просто 4-х цветный светофор, или доска с наклеенными надписями.
Но архитектор не должен принимать все, что говорит заказчик, как должное: если бы таким образом можно было составить достаточное для разработки техническое задание, то заказчику не потребовались бы посредники между ним и разработкой.
Описывать требования на другом уровне архитектуры, к которому они относятся — дело опасное, гарантированно похоронящее архитектуру проекта, сводящее ее не просто к описанию пожеланий, а к опасной смеси газов, которые сами по себе безопасны, но готовы взорваться.
при смешивании.
И система, реализованная с использованием этой архитектуры, рано или поздно сломается — из-за текущих абстракций, сложных модификаций или падения костылей при любом изменении функционала.
Представьте, что вы строите дом.
Основной элемент дома – кирпич.
Вы не можете купить полкирпича, но покупка пяти грузовиков кирпичей не купит вам дом.
И даже сто кирпичей не превращаются в стену.
Для строительства на самом нижнем уровне вам придется оперировать ровно одним кирпичом, не больше и не меньше.
А вот проектировать дом из кирпича, да еще и из кирпичных блоков, – очень плохая идея.
Во-первых, увеличивается сложность.
Любая память и ресурсы конечны, и лучше потратить меньше, чем больше.
Дом, в котором описано расположение каждого кирпича, слишком сложен для понимания, состоит из слишком большого количества элементов.
Рисовать сложно (вместо того, чтобы быстро рисовать отдельные комнаты, мы вырисовываем каждый кирпичик), чертежи сложно читать, 3D-модели долго рендерятся, закупка листов оперирует точным количеством кирпичей, а не тоннами.
Во-вторых, теряется гибкость: переместить один кирпичик — это уже ошибка.
Мы не даем большого простора для маневра на низких уровнях разработки, что вынуждает нас выполнять чужую работу и получать сообщения об ошибках, не критичных для нас.
Если поставить задачу «сделать стену из кирпича толщиной 30 сантиметров», то у строителя есть возможность укладывать кирпичи так, как он хочет, лишь бы при этом не нарушалась прочность или другие ограничения.
Если мы дадим ему точный чертеж расположения кирпичей, то при следующей проверке накопленная разница в толщине шва в пару миллиметров даст нам ошибку в полсантиметра в расположении конкретного кирпича, что приведет к несоответствию стены ее техническим характеристикам.
Иногда это ошибка, но в большинстве случаев неправильное положение одного кирпича ни на что не влияет, а продиктовано обстоятельствами, которые мы не смогли учесть при проектировании: например, неверными размерами кирпичей с производства.
Можно вернуть, можно из таких построить, будет проще и дешевле.
Проектирование на уровне «кирпичик за кирпичиком» лишает нас этого выбора, заставляя нас либо соответствовать идеальному результату, либо отказаться от всей работы.
В-третьих, мы не можем перейти на другой уровень, начать думать о комнатах, имея при этом лишь конгломераты бесконечно перетекающих друг в друга кирпичей и какие-то пространства между ними.
Кирпичи для нас важнее, чем пространство между ними; это только отсутствие кирпичей, а не места для жизни.
Кажется, что дом строится ради комнат, но всякое желание изменить стену в комнате настолько сложно, приводит к такому количеству операций по перемещению кирпичей и возведению нового порядка кладки, что мы почти перестаем это делать.
: проще согласиться с неудобной стеной, чем постоянно передвигать туда кирпичи - вот на плане.
В-четвертых, идея замены базового элемента нетерпима.
Все построено из кирпичей, вы считаете расстояния в кирпичах, вы считаете стоимость в кирпичах, вы считаете вес в кирпичах, вы считаете теплопроводность стены в кирпичах.
Это удобно, поскольку не создает ненужных единиц измерения или ненужных абстракций.
Теплопроводность кирпича легко переносится на расстояние, а стоимость легко определяется исходя из расстояния.
Но построить дом из других материалов невозможно: придется перестать полагаться на кирпичи, а это портит всю картину мира.
Хотя при правильном разделении слоев абстракции вы прекрасно спроектируете помещения в метрах, посчитаете стоимость в рублях, нагрузку на сваи в тоннах, посчитаете теплопроводность в Вт/(м·К), и только на последнем уровне При проектировании решаем, что взять – кирпич, газобетон или бетонные панели.
А если заказчику не нравится решение, измените его, не затрагивая остальную часть проекта.
Работа над архитектурой — это преодоление уровней абстракции.
Видеть эти уровни – качество, необходимое хорошему архитектору.
Теги: #архитектура #Управление продуктом #Системный анализ и проектирование #дизайн #проектирование и рефакторинг #уровни абстракции
-
Можно Ли Заработать На Парковке Доменов?
19 Oct, 24 -
Бесплатный Vpn От Thepiratebay
19 Oct, 24 -
Защита От Воров Контента
19 Oct, 24 -
Проблемный Глонасс
19 Oct, 24 -
Перегрузка И Специализация. Тонкий Момент
19 Oct, 24
