Comments 20

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

UFO landed and left these words here
Но если расчет идет не на проект, а на продукт, и его потом необходимо будет поддерживать, то гораздо полезнее потратить время и аккуратно разделить эти хотелки по уровням, понять, зачем именно такой экран, почему TCP, и причем тут VueJS.


Мне представляется, что для раскрытия темы и понимания мтотивации хорошо рисовать диаграммы по какой-то такой системе (в данном случае это Archimate):

image

В качестве конкретного примера:
image

Начинаем начинаем с уровня EA и потом связываем его с SA.

заказчик называет вам как исполнителю конкретные технические решения потому, что он уже по горло наелся исполнителями, которые делают не то, что ему надо (и не то, что написано в ТЗ), а ровно то, что они [плохо] умеют делать (и желательно, чтобы это уже было сделано раньше, чтобы можно было продать второй раз.) Поэтому заказчик сам вынужден проводить экспертизу, анализ своих бизнес-процессов и всякое такое, чтобы хотя бы в третий раз избежать ситуации, когда ему вместо нужного скрипта автоматизации нужного участка продать коробочную CRM без настройки.

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

Это, конечно, замечательно, но есть (могут быть) нюансы. Может оказаться, что:
  • показывать на семисегментном экране
    Потому что это вписывается в стиль интерьера
  • чтобы по TCP общалось с этим сервером
    Потому что домашняя сеть так настроена, что кроме TCP ничего не пропустит
  • для панели управления взять VueJS.
    Потому что заказчик планирует в дальнейшем сам допиливать проект, а знает он только VueJS


И приходится всё-таки строить архитектуру «от кирпичей», увы. Хотя в общем случае, конечно, надо последовательно спускаться по абстракциям.
Не надо строить от кирпичей. Если вписывается в стиль интерьера — то надо указывать именно это, а не конкретную технологию.
Т.е. если продолжать аналогию со строительством, то для дизайна лофта не обязательно делать стены из кирпичей, можно и из пеноблоков, потом облицевав их плиткой под кирпич. Указывая «стены из кирпичей» а не «кирпичные стены в стиле лофта» вы заранее ограничиваете себя в возможных вариантах, просто потому, что не попытались подумать о уровне повыше.
В случае с семисегментным экраном тоже самое — такой дизайн можно сделать разными способами, от светодиодов на плате, светящих через трафарет до шрифта на ЖК-экране. Оба этих варианта могут выглядеть так же, но первый гораздо дешевле, ярче и проще делается, чем огромные семисегментники, а второй позволяет выводить дополнительную информацию.

И в случае с сетью — нужны конкретные ограничения, а не выбор технологии без обоснования. Возможно, в каком-то случае проще будет прокинуть VPN, чем переписывать весь протокол верхнего уровня на tcp. Зная ограничение «внутри сети доступен только tcp» это решение принять можно, а видя в ТЗ строки «протокол должен быть основан на tcp» — нельзя. В итоге, заказчик влетает на дополнительные часы работы по переделке протокола, а разработчики занимаются фигней, которую можно было бы и не делать.

Я, в общем, хочу сказать, что имеет смысл вносить конкретные требования с обоснованием, а не просто «хочу VueJS». Потому что в этом случае пойди, разберись — действительно он будет это допиливать сам, или просто ему знакомый сказал, что вью это модно и молодежно, а задачу на самом деле проще решить на чем-нибудь другом.
Все эти абстракции нужны лишь для одного — уменьшить себестоимость производства массового продукта. Для уникальных же продуктов абстракции ведут лишь к удорожанию продукта, особо не влияя на качество, при этом растягивая сроки его реализации.

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

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

Так и в разработке программных продуктов. Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах. Разработка же абстракций ради хождения по ним является запудриванием мозгов заказчикам и партнерам по разработке, которая повышает риски снижения потребительских качеств продукта, его удорожания и оттягивания на неопределенную перспективу сроков сдачи продукта в эксплуатацию.
А что такое массовый и уникальный продукт в контексте ПО, например?
Вот система за миллионы, которой пользуются десять сотрудников в банке — это массовый продукт или уникальный? Вроде бы уникальный, но она настолько сложная и важная, что без абстракций там никуда — сложность и высокая цена ошибки не дают нам шанса делать все как пойдет.
А вот какой-нибудь опенсорс-продукт, который просто решает небольшую проблему при разработке, но которым пользуются десятки тысяч человек — это массовой продукт или уникальный? Вроде бы массовый, но все насрать, насколько он красиво построен с точки зрения архитектуры, потому что ценность его невелика (можно тоже самое чуть дольше сделать руками), и цена ошибки тоже (ну сломался и сломался, откачусь на предыдущую версию или подожду фикса).
Сдается мне, правильная пирамида абстракций важна для поддержки и доработки продукта, а уж массовый он или нет — не имеет особого значения.
Так вроде бы ответ на Ваш вопрос уже сформулировал ранее? Нет? Цитирую: «Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах».

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

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

Т.е. любое ПО которое будет развиваться — масштабируемое?
Так-то да, если ПО будет использоваться заранее обозначенным количеством клиентов и не вырастет ни по функционалу, ни по данным, его конечно, можно написать как угодно, я с этим и не спорил. Но вот только я такое ПО вижу довольно редко, если это не самописные утилиты.
Ок. Попробую по-другому. Большинство прикладных программных продуктов можно написать с минимальным количеством собственных интерфейсов и абстрактных классов, при это вовсю используя разработанные другими людьми интерфейсы, такие как jdbc или http.
как строитель могу дополнить что кладка стен измеряется в м3. А количество кирпичей в штуках, зная что в 1м3 кладки что-то там 400шт. Но это наглядно показывает что каждый должен делать то в чем разбирается
Так все правильно, когда вы проектируете дом применительно к постройке дома из кирпичей, вы измеряете как раз в кубических метрах и штуках кирпичей.
Но когда вы проектируете абстрактный дом, чтобы в нем жить, есть смысл, прикидывая, сколько и каких комнат где вам потребуется проектировать их в метрах, потому что совсем не факт, что вы будете строить из кирпича. И только потом переводить в кирпичи, блоки, или еще что-то.
Справедливости ради аналогия с кирпичами просто была не корректна. При проектировании дома необходимо знать какой будет использоваться материал, просто заменить один материал другим в готовом проекте не получится.
При проектировании дома на уровне «хочу 5 комнат на двух этажах, и чтобы там были две ванные в разных концах коридора, и большую двухэтажную гостинную» — не надо знать. В этом и смысл поста: если вам пофигу, из какого материала будет дом, то не надо сразу закладывать кирпичи, надо сначала спроектировать абстрактно, в комнатах и метрах, а потом выбирать материал.
А вот уже потом, когда будет делаться конкретный план постройки, там да, придется учитывать ограничения каждого материала.

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

В целом конечно, согласен со статьёй, но некоторые тезисы кажутся мне спорными.


Например, тезис


Разделить эти два уровня (требований и реализации) просто

Мне кажется спорным, ведь в этом абзаце


Потом начинаем конкретизировать требования (но не конкретные технологии).
Устройство в корпусе IP68, с питанием 230в, управляющее асинхронным приводом мощностью 800вт через частотный привод по modbus, имеющее хорошо различимый индикатор, четыре состояния которого (открыто/закрыто/в процессе/поломка) должен распознавать человек с 10 метров, имеющее удаленное управление, доступное из современных браузеров через интернет.

На мой взгляд как раз произошло такое смешение требований (степень защиты от влаги/пыли, различимость и индикаторы, удалённое управление) и технологий (питание 230в, асинхронный привод с конкретной мощностью, шина управления modbus).


И ведь все перечисленные технологии реально могут быть требованиями, например, вписать в текущую схему электросети (а вдруг она трёхфазная вообще?), использовать уже существующие детали (как раз завалялось пару асинхронных приводов, которые вроде подходят под (какие?) наши другие требования) или детали, которые возможно достать по адекватной цене, уложиться в какую-то смету, или, скажем, подрядчики умеют работать только с какими-то определёнными материалами / технологиями (а других — это поискать надо). Но могут ведь и не быть?


Можно наверное принять это за цикл обратной связи: такие-то требования приводят к таким-то ограничениям (15и-этажный дом сложновато построить из дерева), и, возможно, заказчик просто провёл какие-то предварительные исследования и часть его абстрактных требований уже оформилась в конкретно выбранные технологии, это же не обязательно означает, что он не знает, чем обусловлен выбор того или иного инструмента.

На мой взгляд как раз произошло такое смешение требований (степень защиты от влаги/пыли, различимость и индикаторы, удалённое управление) и технологий (питание 230в, асинхронный привод с конкретной мощностью, шина управления modbus).

Нет. Питание, частотник такой-то мощности и шина — это ограничения. Если мы проектируем не систему, которая должна крутить заготовку, а конкретную железку для управления, то мы не можем влиять на уровень выше.
Only those users with full accounts are able to leave comments. Log in, please.