Комментарии 27
а еще можно вспомнить неразбериху с метрической и английской системой, из-за которой у самолетов может закончится топливо а межпланетные зонды промахиваться мимо цели.
Но если расчет идет не на проект, а на продукт, и его потом необходимо будет поддерживать, то гораздо полезнее потратить время и аккуратно разделить эти хотелки по уровням, понять, зачем именно такой экран, почему TCP, и причем тут VueJS.
Мне представляется, что для раскрытия темы и понимания мтотивации хорошо рисовать диаграммы по какой-то такой системе (в данном случае это Archimate):
В качестве конкретного примера:
Начинаем начинаем с уровня EA и потом связываем его с SA.
заказчик называет вам как исполнителю конкретные технические решения потому, что он уже по горло наелся исполнителями, которые делают не то, что ему надо (и не то, что написано в ТЗ), а ровно то, что они [плохо] умеют делать (и желательно, чтобы это уже было сделано раньше, чтобы можно было продать второй раз.) Поэтому заказчик сам вынужден проводить экспертизу, анализ своих бизнес-процессов и всякое такое, чтобы хотя бы в третий раз избежать ситуации, когда ему вместо нужного скрипта автоматизации нужного участка продать коробочную CRM без настройки.
показывать на семисегментном экране
Потому что это вписывается в стиль интерьерачтобы по TCP общалось с этим сервером
Потому что домашняя сеть так настроена, что кроме TCP ничего не пропуститдля панели управления взять VueJS.
Потому что заказчик планирует в дальнейшем сам допиливать проект, а знает он только VueJS
И приходится всё-таки строить архитектуру «от кирпичей», увы. Хотя в общем случае, конечно, надо последовательно спускаться по абстракциям.
Т.е. если продолжать аналогию со строительством, то для дизайна лофта не обязательно делать стены из кирпичей, можно и из пеноблоков, потом облицевав их плиткой под кирпич. Указывая «стены из кирпичей» а не «кирпичные стены в стиле лофта» вы заранее ограничиваете себя в возможных вариантах, просто потому, что не попытались подумать о уровне повыше.
В случае с семисегментным экраном тоже самое — такой дизайн можно сделать разными способами, от светодиодов на плате, светящих через трафарет до шрифта на ЖК-экране. Оба этих варианта могут выглядеть так же, но первый гораздо дешевле, ярче и проще делается, чем огромные семисегментники, а второй позволяет выводить дополнительную информацию.
И в случае с сетью — нужны конкретные ограничения, а не выбор технологии без обоснования. Возможно, в каком-то случае проще будет прокинуть VPN, чем переписывать весь протокол верхнего уровня на tcp. Зная ограничение «внутри сети доступен только tcp» это решение принять можно, а видя в ТЗ строки «протокол должен быть основан на tcp» — нельзя. В итоге, заказчик влетает на дополнительные часы работы по переделке протокола, а разработчики занимаются фигней, которую можно было бы и не делать.
Я, в общем, хочу сказать, что имеет смысл вносить конкретные требования с обоснованием, а не просто «хочу VueJS». Потому что в этом случае пойди, разберись — действительно он будет это допиливать сам, или просто ему знакомый сказал, что вью это модно и молодежно, а задачу на самом деле проще решить на чем-нибудь другом.
Есть и более серьезные статьи, но и этой
https://knowledge.autodesk.com/ru/support/inventor/learn-explore/caas/CloudHelp/cloudhelp/2019/RUS/Inventor-Help/files/GUID-63FA128E-63E2-4176-8653-327BD80D8A43-htm.html
хватит, чтобы показать, что
последовательно спускаться по абстракциям
, что является проектированием "сверху вниз" - это далеко не
в общем случае
.
Если интересно, то в проектах, где не пускают архитектуру на самотек, на текущий момент популярна модель проектирования "из середины к границам". Названия могут варьироваться, но смысл один:
Этап I (Серединный уровень абстракции): Проектирование модели предметной части таким образом, чтобы она отражала объекты предметной области, их инварианты и процедуры перехода объектов из одного состояния в другой не нарушая инварианты.
Этап II (Верхний уровень абстракции): Проектирование вариантов использования получившейся модели, формируя при этом пользовательский интерфейс. Пользователем при этом может быть код более высоких уровней абстракции, или API клиент, или человек пользующийся браузером
Этап III (Нижний уровень абстракции): Проектирование деталей реализации всего написанного в предыдущих этапах под конкретную платформу, то есть под ОС, под версию языка программирования, под технический стек, под framework и т.д.
Ведь для разработки качественных абстракций также нужно потратить определенное количество труда и разных ресурсов. В примере с домом используются ранее разработанные другими людьми абстракции (стандартный кирпич с определенными характеристиками). А что если взять пример по разработке дома из деревянных бревен (не путать с брусом), размеры каждого из которых уникальны сами по себе, а характеристики зависят от сезона и места заготовки?
Здесь уже придется разрабатывать собственные абстракции, такие как технологию обработки древесины, способ укладки сруба, выбор отделочных материалов и т.д. А это значит проектирование, документирование, обучение сотрудников и т.д. Для разового проекта это не нужные дополнительные затраты, а вот в массовом производстве домов из бревен созданные ранее абстракции помогут снизить затраты, повысить качество и ускорить сроки строительства.
Так и в разработке программных продуктов. Разработка абстракций оправдана лишь либо в случае явной потребности в последующем масштабировании программного продукта, либо в случае возможности использования разработанных абстракций в других проектах. Разработка же абстракций ради хождения по ним является запудриванием мозгов заказчикам и партнерам по разработке, которая повышает риски снижения потребительских качеств продукта, его удорожания и оттягивания на неопределенную перспективу сроков сдачи продукта в эксплуатацию.
Вот система за миллионы, которой пользуются десять сотрудников в банке — это массовый продукт или уникальный? Вроде бы уникальный, но она настолько сложная и важная, что без абстракций там никуда — сложность и высокая цена ошибки не дают нам шанса делать все как пойдет.
А вот какой-нибудь опенсорс-продукт, который просто решает небольшую проблему при разработке, но которым пользуются десятки тысяч человек — это массовой продукт или уникальный? Вроде бы массовый, но все насрать, насколько он красиво построен с точки зрения архитектуры, потому что ценность его невелика (можно тоже самое чуть дольше сделать руками), и цена ошибки тоже (ну сломался и сломался, откачусь на предыдущую версию или подожду фикса).
Сдается мне, правильная пирамида абстракций важна для поддержки и доработки продукта, а уж массовый он или нет — не имеет особого значения.
Под термином «масштабируемость» как раз и подразумевается массовость производства в сфере разработки ПО. В зависимости от специфики ПО масштабировать можно по количеству пользователей, по объему данных, по объему вычислений, по количеству разрабатываемых проектов, по скорости адаптации программного кода под внешние условия и т.п.
Ну а для поддержки и доработки кода важно качественное проектирование структуры приложения, грамотная работа со структурами данных, разумное разбиение кода на отдельные процедуры, внятное документирование кода и т.д. и т.п. При отсутствии же потребности в масштабировании грамотно написанный код вполне себе можно разместить в одном слое без всяких дополнительных абстракций.
В зависимости от специфики ПО масштабировать можно по количеству пользователей, по объему данных, по объему вычислений, по количеству разрабатываемых проектов, по скорости адаптации программного кода под внешние условия и т.п.
Т.е. любое ПО которое будет развиваться — масштабируемое?
Так-то да, если ПО будет использоваться заранее обозначенным количеством клиентов и не вырастет ни по функционалу, ни по данным, его конечно, можно написать как угодно, я с этим и не спорил. Но вот только я такое ПО вижу довольно редко, если это не самописные утилиты.
Может вы все же зайдете на github и посмотрите на объем среднестатистического приложения прежде чем бросаться такими заявлениями? Можете для саморазвития взять одно из таких среднестатистических приложений и избавить их от лишних уровней абстракций. В результате вы действительно с некоторой степенью вероятности получите меньший объем кода. Но труда на такое затратите больше чем разработчики потратили на написание исходного варианта. Но не это главное. Главное то, что вы не сможете поддерживать это приложение с той же непринужденной легкостью, с которой это делали разработчики оригинального приложения пользуясь выгодой от слоев абстракции.
Насчет "Все эти абстракции нужны лишь для одного — уменьшить себестоимость производства массового продукта":
Массовость и уникальность вообще никак не связаны с абстракциями в коде. Уровни абстракции действительно связаны с удешевлением конечного продукта, но совершенно другим образом. Все ухищрения программистов, принципы разработки, шаблоны проектирования, уровни абстракции и прочее служит всего одной цели: минимизировать необходимость вносить правки в уже хорошо продуманный и отлаженный программный код следуя процессу разработки. Другими словами: "Не допускать двойной работы". Другой причины нет и другого обоснования - тоже.
Обойтись без уровней абстракции можно только в небольших проектах, которые сводятся к одному нехитрому, или хитрому, но небольшому алгоритму. Если же объем приложения больше и/или если требования к нему со временем меняются (проект живой), то приходится уже обращаться ко всему богатству приемов, придуманных программистами, позволяющих удешевить процесс разработки.
Примеров того, когда программист игнорирует это простое правило, воз и маленькая тележка. Почти каждый зрелый программист прошел через проекты, в которых ему помногу раз приходилось переписывать одно и тоже. Это действительно может привести к депрессии, так как в большинстве случаев в таких проектах это переписывание с каждым разом лишь укрепляет уверенность разработчика, что переписанные куски кода прийдется переписывать еще не один и не сотню раз, а куда больше. Просто потому что не был соблюден принцип OCP из SOLID.
Вот и думайте теперь где актуальны уровни абстракции, а где - нет.
Но когда вы проектируете абстрактный дом, чтобы в нем жить, есть смысл, прикидывая, сколько и каких комнат где вам потребуется проектировать их в метрах, потому что совсем не факт, что вы будете строить из кирпича. И только потом переводить в кирпичи, блоки, или еще что-то.
А вот уже потом, когда будет делаться конкретный план постройки, там да, придется учитывать ограничения каждого материала.
Другое дело, что может быть настолько пофиг на материал, что он выбирается по принципу «у меня бригада знакомая из газобетона строит, получается хорошо, так и себе сделаю».
И пример с кирпичами отличный, и заменить материал другим получится, и уровни абстракции с этим напрямую связаны.
Простой полиморфизм: Если побеспокоиться об уровне абстракции и работать не с кирпичами, а с абстракцией, то кирпич можно заменить на любую реализацию этой абстракции. Даже если этой реализацией окажется кусок свежих фекалий. И пользу такому дому можно найти: он будет бесить всех вокруг и разрушится после первого же дождя. Если такой замысел был изначально, то польза будет получена.
А можно придумать и другие варианты, такие как адаптеры, которые замаскируют совершенно другую реализацию, не имеющую ничего общего с кирпичом, под кирпич. Так можно построить дом из воды. Адаптерами окажутся сосуды в форме кирпичей, которые будут маскировать воду под кирпич. А дальше будет работать все тот же полиморфизм во славу великой абстракции.
В общем, не сдавайтесь в своих попытках работать с аналогиями. Это развивает
Не все аналогии из мира ИТ применимы к реальному миру. Аналогия с домом не корректна, поскольку планировочные решения завися от используемого материала. Если вы построили дом из приведённого вами материала, он в силу определения не будет является домом, да и завершить строительство вам не удастся, несущая способность у материала слишком низкая. Не надо натягивать сову на глобус.
Если мы действительно IT специалисты, то нужно уметь работать с абстракциями.
Если мы создали абстракцию "Дом" как некоторую композитную форму имеющую стены, пол и крышу, то дом из блоков, состоящих из воды в жидком агрегатном состоянии, не перестает быть домом даже если он просуществует таковым в реальном мире всего доли секунды пока его не расплескает земное притяжение. И этому примеру даже можно придумать полезное применение - красивые спецэффекты в каком-нибудь фильме. По моему я где-то такое даже уже видел.
Если мы вносим в абстракцию "Дом" понятие устойчивости и хрупкости в целом, то и в таком случае можем запустить симуляцию дома из воды. Он просто не пройдет проверку по критерию хрупкости. Но не перестанет быть домом. Просто будет домом с пометкой "непригоден". В разработке с такими понятиями приходится сталкиваться очень часто.
Если говорить про программирование, то процесс написания программы, особенно в случаях когда стоит цель автоматизировать бизнес или смоделировать что-то существующее в реальности, состоит в том, чтобы описать абстракциями все то, что лежит в предметной области. И поверьте моему опыту, я ни разу не встречал ничего такого, что нельзя было бы хоть в каком-то приближении описать, как вы сказали, аналогиями из IT.
В целом конечно, согласен со статьёй, но некоторые тезисы кажутся мне спорными.
Например, тезис
Разделить эти два уровня (требований и реализации) просто
Мне кажется спорным, ведь в этом абзаце
Потом начинаем конкретизировать требования (но не конкретные технологии).
Устройство в корпусе IP68, с питанием 230в, управляющее асинхронным приводом мощностью 800вт через частотный привод по modbus, имеющее хорошо различимый индикатор, четыре состояния которого (открыто/закрыто/в процессе/поломка) должен распознавать человек с 10 метров, имеющее удаленное управление, доступное из современных браузеров через интернет.
На мой взгляд как раз произошло такое смешение требований (степень защиты от влаги/пыли, различимость и индикаторы, удалённое управление) и технологий (питание 230в, асинхронный привод с конкретной мощностью, шина управления modbus).
И ведь все перечисленные технологии реально могут быть требованиями, например, вписать в текущую схему электросети (а вдруг она трёхфазная вообще?), использовать уже существующие детали (как раз завалялось пару асинхронных приводов, которые вроде подходят под (какие?) наши другие требования) или детали, которые возможно достать по адекватной цене, уложиться в какую-то смету, или, скажем, подрядчики умеют работать только с какими-то определёнными материалами / технологиями (а других — это поискать надо). Но могут ведь и не быть?
Можно наверное принять это за цикл обратной связи: такие-то требования приводят к таким-то ограничениям (15и-этажный дом сложновато построить из дерева), и, возможно, заказчик просто провёл какие-то предварительные исследования и часть его абстрактных требований уже оформилась в конкретно выбранные технологии, это же не обязательно означает, что он не знает, чем обусловлен выбор того или иного инструмента.
На мой взгляд как раз произошло такое смешение требований (степень защиты от влаги/пыли, различимость и индикаторы, удалённое управление) и технологий (питание 230в, асинхронный привод с конкретной мощностью, шина управления modbus).
Нет. Питание, частотник такой-то мощности и шина — это ограничения. Если мы проектируем не систему, которая должна крутить заготовку, а конкретную железку для управления, то мы не можем влиять на уровень выше.
Смешение уровней абстракции закладывает бомбу в основание вашего проекта