Comments 65
Есть история когда программист капрпел над стартапом 2 года стараясь использовать все имеющиеся bestpractice, а когда вышел на рынке ниша уже была заполнена. В тоже время предприниматель не умея программировать нанял дешёвых кодеров которые наговнокодили ему стартап по принципе работает и ладно за 3 месяца, а через год стартап уже был популярен и предприниматель греб бабло лопатой, а потом нанял лучших программистов чтобы они переписали его старпап на лучшие "рельсы". И для этой истории оговаривали мораль что лучше выпустить не самый лучший стартап и по мере роста его совершенствовать нежели опоздать с выходом на рынок.
Поэтому чистая архитектура это прекрасно для программистов, но не каждый за неё готов платить.
и ключевое здесь, как мне кажется,
а через год стартап уже был популярен
ибо нет смысла стараться делать мёд, если потребители продукта - мухи.
Именного так есть. Прежде всего задача любого программного продукта решать четкие задачи, и конечного пользователя мало интересует какой там набор паттернов под капотом
С одной стороны согласен конечно
Однако проблема в том, что этот продукт, собранный из ***** и веток на скорую руку, обрастает десятками сильносвязных между собой сервисов которые к тому же крайне редко как либо документируются, да наверное и смысла их докумментировать особо нет т.к. реализация каждый месяц меняется
И вот когда вся логика реализации перестает помещатся в память верховного программиста этого чудо продукта, компания попадает в производственный ад, как раз то описанный в книге чистый код, когда каждая фича мало того что долго выпускается так еще и тянет за собой охапку багов
Я пару раз с таким увлекательным легаси поработал, опыт конечно интересный, но больше не хочется))
Начинать надо с простого
Просто бери и пиши
А через год пиши снова с нуля, но уже с чистой архитектурой, микросервисами и поэтессами
Это большие деньги, но можно увидеть взлетел проект или нет. А на конкурентном рынке деньги не так важны как сроки
Время - деньги. Поэтому, сроки - это тоже деньги в итоге.
Соглашусь с вами, что надо начинать чуть ли не с прототипа, но сильно задерживать полное переписывание кода очень опасно. Потому что можно дойти до стадии, когда переписать эту гадость с миллионом фич станет практически невозможно с точки зрения разумного количества людских ресурсов и сроков. Поэтому надо с первых дней запуска уговорить менеджмент на то, что переписывать код надо, и делать это надо как можно скорее, сразу после того, как скорость стихийного массового появления новых фич хоть немного стабилизируется.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
Это история из книг американских менеджеров. Но она в основе ИТ стартапов.
Также стоит обратить внимание, что история предполагает переписование кода если стартап начал набирать популярность. Таким образом и поддерживаемость сохранится и ТТМ будет высоким.
На этом этапе выясняется, что переписывание — это x10 к стоимости, рискам и времени, а новые фичи нужны вчера. Также, опытным путём, выясняется, что можно не переписывать, а с грязной архитектурой дальше жить — тоже можно и даже вроде без рисков и расходов в моменте. Так и живут.
Потом правда выясняется, что программисты плохие и сразу всё хорошо не сделали. Но это уже другая история.
Как раз идея в том, чтобы при наборе популярности стартапа, привлекать более опытных разработчиков которые исправят положение.
Если приложение RuStore было популярным ещё на этапе идеи и была железобетонная уверенность, что приложение "взлетит". Для других стартапов нет уверенности в успехе и вкладываться в большую команду синиоров это дорого и может быть неэффективно. А если идея пролетит то подарок синиором будет значителен.
Тема статьи согласны ли платить за ЧА. Так вот: по моему мнению на этапе МВП, с непроверенной гипотезой, вкладываться в бородатых синиоров мало желающих. Если стартап успешен - без вложения в ЧА жить будет тоскливо.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Я был в стартапе где говнокодили, это привело:
1) Куча багов из-за которых завалили презентации инвесторам и не получили инвестиции и потеряли доверие как инвесторов так и клиентов
2) Не продуманность проекта, нам срочно нужно привлекать клиентов какой-нибудь акцией через неделю, а фич для промо нет и их пилить 3 недели
3) Отсутствие гибкости в проекте - мы добавили поле в БД, у нас отвалилась половина запросов. У нас был платежный сервис, внезапно про бухгалтерию вспомнили через полтора года существования стартапа и именно когда нужно было отчитаться по всем транзакциям
4) У нас не было продуктолога и прожекта, в итоге, что делать и как делать и вообще виденья продукта не было. Была только куча обещаний инвесторам от CEO. О некоторых, мы даже и не слышали до момента, когда нам начинали говорить, что мы могли бы и сами догадаться, что что-то надо было сделать раньше.
Стартап выжил, хотя был на грани. Конкурентны, которые не старались тяп-ляп и в продакшен нас обошли и заняли рынок.
а есть история о том как один недопрограммист говнокодил свой стартап без принципов солид, кодил кодил как потом понял что его код превращается в мишуру из говна и палок, в которой исправлять нарастающие баги ещё сложнее чем добавлять необходимые фичи и в итоге понял, что у него не хватит мозгов доделать стартап хотя бы до мвп чтобы выпустить его на рынок, а другой кодер знал принципы солид и читал про архитектуру и писал свой стартап с самого начала с пониманием основ чистого кода и его стартап успешно дошел до состояния мвп да ещё и так что там оставалось место на новые усовершенствования?
Есть реальная история как говнокодили и в итоге не то что, не захватили рынок, а не смогли сделать даже первую версию. Потому что из-за говнокода просрали все сроки, делается одно, отваливается другое и т.д. Я эту историю знаю лично, в отличии от неких книг американских менеджеров. Поэтому в истории типа - можно говнокодить чтоб захватить рынок верю слабо. Возможно это мой личный опыт, который нельзя распространять на всю индустрию. С другой стороны адепты захвата рынков никакой статистики не приводят вообще.
Конечно, всегда есть некий компромисс между time to market и техдолгом, между потребностями пользователя и красивостями. Но на практике я вижу что мифический захват рынка становится универсальным оправданием для криворукости.
Это случайно не та история, где тот недопрограммист говнокодил потому, что не это было его сильной стороной, а потом он стал управленцем в одной компании и стал руководить работой других кодеров, а через 10 лет начал инвестировать в стартапы, где все было сделано по солид с пониманием основ чистого кода?
Опытный программист имеет наработанный каркас позволяющий писать приложение своего профиля. Хуже если он собирается сменить профиль. Но и тут можно найти образцы. На моем предыдущем месте так и сделали. Скачали , скомпилили из них свое. Результат на мой взгляд очень позитивный.
Анекдот же такой есть.
А разве использование архитектурных паттернов не позволяет клепать даже с нуля продукт гораздо быстрее? Это как строить дом самому, по наитию, или использовать типовой проект и типовые блоки
Архитектура в software engineering и архитектура зданий это абсолютно разные вещи. Во втором случае к вам не придут после заложенного фундамента и не скажут, что дом то должен быть на самом деле круглый, а не квадратный. После десяти построенных этажей вам не скажут, что надо сейчас сделать пять, а верхние пока отрезать. Или сделать так, чтоб каждый чётный этаж пока что не был виден жильцам и тд
Чистая архитектура не сама цель, а средство. Вот например если мы уже имеем продукт у которого есть клиент, но он не оптимален и вызывает этим много проблем, тут уже есть смысл стремиться к чистой архитектуре и красоте. Так что если вы готовы за это платить, милости просим покупайте, а иначе можно и другой подход применить.
Всё это хорошо, но за 15 лет в IT я не видел не одного проекта, смотря на который хотелось бы восхищаться тем какой он технически прекрасный. У каждого из нас руки по локоть в крови, а чистая архитектура это далеко не только техника
Исходники движка Doom?
тут я все же про итерпрайз, c играми ситуация немного иная
Там тоже хватает эпических багов и костылей. Например, изначально все монстры генерировали снаряды во время выстрела на одной высоте. Позже, в аддоне были добавлены монстры иной высоты, которым требовалось генерировать снаряды на другой высоте. В итоге в коде выстрела теперь происходит следующее: перед выстрелом поднимаем позицию монстра над землёй, создаём снаряд, возвращаем монстра на его старую позицию. Это оказалось проще закостылить так, хотя казалось бы :)
Спасибо, хорошая статья.
Важным, как мне кажется, является мысль что нужно думать об архитектуре, а не прикладывать шаблоны.
В том числе пытаться понять, почему нужны те или иные ограничения и где границы их применимости.
Иначе люди со вкусом обсуждают о преимуществах монолитного строительства перед кирпичным вне всякого контекста.
Еще Я бы сказал, что достойным местом для использования интерфейсов являются случаи оправданного полиморфизма.
Статья интересная, и как тут верно заметили в комментариях - не все решается архитектурой. Есть еще софт-скилы, заинтересованность в проекте, желание развиваться и другие важные качества членов команды, без которых не будет хорошего TTM
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
1. Для поддержки чистоты архитектуры всего то нужен тимлид, который будет мерджи с говнокодом разворачивать.
2. Архитектура заранее известна в любом нормальном фреймворке.
3. Интерфейсы как правило обусловлены бизнес задачей, например несколько платежных шлюзов или обжект стор. В большинстве остальных случаев их применение надуманно.
Этого достаточно, что бы даже через 15 лет, когда все устареет любой нормальный кодер смог без проблем вносить изменения. Важны не софтхард скилы, а грамотный процесс разработки ПО
Это не ЧА дорогая - это кодеры, которые вообще не шарят в архитектуре - дешëвые. Проблема проработки архитектуры состоит в том, что если почти вся команда этого не умеет, то один человек, читавший Мартина или Нила Форда, особо ничего не сделает. Вся команда будет клепать фекальный код без тестов и разделения на слои. С другой стороны, аналогичная команда, владеющая навыками TDD, пишущая чистый код много лет, прорабатывающая архитектуру, будет справляться с аналогичной работой за примерно такое же время. Просто представителей первого типа команд - большинство. И они упорно будут доказывать, что ЧА - это долго, дорого и своих денег не стоит.
Но, будем откровенны: для стартапа такие команды вполне подойдут. Там, зачастую, нет ничего сложного. Но выход на рынок гарантирует возможность, как минимум, привлечь инвестиции, чтобы заменить команду и переписать проект.
Роберт Мартин находится на вершине пищевой цепи современного программирования. Ввиду развития скриптовых и сверхвысокоуровневых языков, код может писать почти любой человек, и внизу этой цепочки есть множество кодеров, готовых работать за низкую зарплату. А спрос на автоматизацию сейчас охватывает все сферы жизнедеятельности человека. Поэтому, стоит понимать, что ЧА - это, всë-таки, инструмент более сложной автоматизации, чем сайт-визитка или простенький стартап. Я бы условно разделил спрос на написание скриптов и, непосредственно, программирование. Когда вам нужно написать скрипт для продажи чего-либо, парсер, или что-то в этом духе, то мы имеем дело со скриптами. Когда перед нами стоит комплексная задача автоматизации, то мы говорим о программировании.
Не стартапами едиными... В энетерпрайзе всё тоже весьма плохо, в том числе и с чистой архитектурой.
Засилье эффективных менеджеров, ничего не понимающих в разработке, но имеющих своё мнение, которое они вынуждены демонстрировать, чтобы быть успешными. Правда, такая чайка живёт обычно недолго. Нагадит здесь, летит в другое место повторять успешный опыт. Отрицательный отбор. Рыба гниёт с головы.
Низкое качество требований. Отчасти из-за той же некомпетентности менеджеров, которые не знают, как работает их часть бизнеса, не говоря уже о смежных частях. Отчасти из-за недооценки и загруженности функциональных сотрудников, которые коллективно много знают, но не имеют права голоса и времени, чтобы донести своё видение. Отчасти из-за проблем с аналитиками, которые гордо называют себя системными, но на деле не могут справиться даже со сбором и фиксацией бизнес-требований.
Большое количество формализма в принятии решения, бюрократия. Слишком много откровенно лишних телодвижений, необходимых для доведения в прод чего бы то ни было.
Большое количество систем, сервисов и команд их создающих. Сложно договориться даже о простейшей интеграции между двумя смежными системами. Нет общих подходов и архитектуры всей информационной инфраструктуры компании (мозаичность решений).
Люди башни из слоновой кости, которые не могут даже пояснить за стрелки на их диаграммах, потоки данных это или зависимости.
Feature rush, но это свойственно любому бизнесу и было сказано про стартапы. Но в случае кровавого энетерпрайза это накладывается на все прочие проблемы.
Множество ограничений по доступным технологиям. "Я понимаю, что здесь лучше подойдёт MongoDB, но у нас можно только MS SQL Server или Oracle". Подставьте любые другие технологии.
Часто проблемы с инфраструктурой. Она большая, множество legacy оборудования, которое нужно подружить с более новым. Что-то постоянно падает.
Куча проблем, связанных с безопасностью. Тебе постоянно что-то запрещают. От тебя требуют каких-то странных вещей, например, резко дерзко закрывают доступ в репозиторий пакетов и требуют, чтобы ты дал полный список пакетов, к которым тебе необходим доступ. Любая дырка в файрволе может превратиться в недели согласований, а потом выясняется, что нужно ещё парочку проковырять и пробросить их через другие VLAN.
И как альфа и омега всего этого звездеца — всё те же эффективные менеджеры. Они повсюду и у каждого из них свой глюк.
Ну, формально описание проблем больше напоминает IT отдел, нежели Энтерпрайз разработку. Я бы, в рамках своего мнения и опыта, не стал бы называть Энтерпрайзом комплекс работ по автоматизации бизнес-процессов предприятия. Энтерпрайз, в моëм понимании, подразумевает продукт собственной разработки, который требует обслуживания и нуждается в развитии (включая изменение). Интеграция сторонних решений и работа с ПО, закрытым для изменения кода - это не просто не Энтерпрайз - это вообще не разработка.
Однако, на старте карьеры я сталкивался именно с Энтерпрайзом, который страдал от менеджмента. Но это очень редкое явление. Поверьте, на рынке можно на одну такую вакансию со страдающим проектом, найти 99 продуктовых компаний с нормальным вовлечением бизнеса в продукт и приятным процессом. Могу сказать, что в моëм опыте не только менеджмент был виновен в страданиях продукта. Зачастую, проблема была в том, что на обслуживание нанимали человека с минимальным опытом (то есть, в тот момент - меня). Ни мой опыт, ни мой доход не позволяли мне тогда изменить ситуацию с продуктом. Поэтому, людям, которые столкнулись с описываемыми вами ощущениями, я могу посоветовать только найти другое место работы с нормальным сеньором во главе команды, чтобы получить опыт. Поскольку, если у человека нет опыта и возможности продавливать полезные изменения, он не будет расти.
Я про энерпрайз и в Вашем понимании. Свои внутренние продукты, а от сторонних аутсорс, коробок и т.п. давно уже отказались. И я не про одно место, а про несколько в последние годы. Например, средний банк или сотовый провайдер большой тройки.
Банки и сотовые операторы - это особый вид Энтерпрайза. Плюс, айти ими не ограничивается. Рекомендую попробовать инди-разработку.
Эм, а это куда? :) Если серьёзно, что Вы под "инди" понимаете? Инди-игры я знаю, но их разработка, это скорее стартап на коленке в нерабочее время. Или иначе pet-project.
Инди (индюшатники) - это проекты, за счëт которых живëт компания, при условии, что они не доросли до стадии портала/платформы. Например, Авито трудно назвать инди-проектом, но с него он начинал. Хотя, думаю, Авито, Озон, WB сохраняют тенденции инди-энтерпрайза с большой свободой команд. Слышал от коллег, что в X5 group много проектов в режиме Энтерпрайз-стартапов. Самолëт, некоторые проекты Сбера типа Дом клик или Звук.
Я бы, скорее, у названных проектов выделил общую черту, что это чисто коммерческие проекты/продукты/сервисы без особого внимания регуляторов, как у банков и мобильных провайдеров. К сожалению, WB и X5 мне точно не подходят, так как знаю их подноготную от бывших своих подчинённых. Сбер тоже к таким компаниям относится весьма двойственно. Ни плюшек материнской компании, ни свободы действий, и "давай-давай-давай". Да и в принципе я не ищу сейчас работу, меня устраивает место, где я работаю.
Не поймете меня неправильно. Даже подчёркивая проблемы энтерпрайза и других компаний, я отдаю себе отчёт, что они как-то выживают и даже приносят прибыль, несмотря на весь "песок" в своих механизмах. За 30 лет я привык к подобным вещам и просто стараюсь трезво оценивать действительность, что и где возможно, а что нет.
Сначала, вы говорите, что ваша разработка страдает от отсутствия свободы действий команды, эффективных менеджеров и бюрократии, а теперь - что ваша разработка критически и скептически относится к коммерческим энтерпрайз-продуктам других компаний. Вы не замечаете здесь проблему?
Нет. Тем более, что это обобщённый опыт за последние 10-15 лет и несколько компаний. Да, разумеется вещи вроде сервера БД покупаются, а не разрабатываются самостоятельно, но софт, например, система автоматизации кредитования крупных компаний, разрабатывается самостоятельно, а не покупается коробкой/сервисом, хотя переговоры с подобными поставщиками ведутся в познавательных интересах.
У нас с Вами, видимо, просто разный опыт и понимание терминов. Для меня энетерпрайз это, например, Сбер, X5, Билайн, РБК, любой коммерческий банк, Касперский и т.д. Это не инди, не стартап, не Рога и копыта со своей конфигурацией 1С и т.п.
Какие примеры энетерпрайза в Вашем понимании этого термина Вы можете назвать?
Хороший вопрос. Полагаю, для Энтерпрайз разработки нужен центр в виде продукта, который полностью покрывает свои расходы на сопровождение. А также, важно соблюдение стандартов качества, которые ограничивают разработчиков и побуждают их идти по пути эволюционного развития продукта. И, ещë, важна команда, которая имеет определëнную свободу принятия решений. Поскольку, без этого разработка превращается в конвейер. Поэтому, всë перечисленное вами, кроме 1С.
Но, опять же, не все продукты банков самоокупаемые. Не все дают свободу команде разработки (самоуправление), не все продукты имеют вектор расширения в эволюционном масштабе. Давайте говорить откровенно: язык C вышел из недр коммуникационной компании в виде эволюции языка B, который облегчал написание кода. Сейчас это стандартный язык для написания компиляторов и интерпретаторов новых ЯП. Это как динозавр, чьи потомки стали голубями, накидывающимися на семечки. При том, что AT&T были связаны с военными в США, и их логотип присутствует на некоторых объектах времëн холодной войны. Но, когда разработчикам дали свободу самоуправления, они создали нечто большее, чем просто скрипт запуска ракеты. По сути, на языке C написаны компиляторы и интерпретаторы языков, на которых функционируют сайты продажи корма для собак или карбоновых удочек. Это эволюция, это продукт. Но, что ещë более важно: это исследовательская работа. Программирование - это исследовательский научный процесс (по мнению Роберта Мартина, как минимум). Поэтому, я бы сказал, что Энтерпрайз разработка - это исследовательский процесс. Например, он может исследовать рынок. Так, разработка продукта кикшеринга превратилась в настоящий бум проката электросаиокатов. Переросла в каршеринг. Исследование рынка доставки сделала возможным существование сервисов Яндекс еды и маркетплейсов типа озона.
А вот, например, платëжные системы эволюционируют медленно. Исключение - блокчейн, который навëл шороху в консервативной банковской системе. Поэтому, допустим, разработку и обслуживание платëжных систем банков я за Энтерпрайз не считаю. У неë нет потенциала развития и свободы для действий команды. А вот то же Альфа Страхование я бы назвал Энтерпрайзом, поскольку это один из первых страховых онлайн продуктов на рынке.
Вас понял, но у нас, действительно, разное понимание этого термина Э. Вы о продукте, я о размере организации и принципах управления такими организациями, а также количестве денег и возможностях, которые эти ресурсы дают ей. В Э-организациях есть разные продукты и проекты. Последние 10-20 лет, например, стали популярны внутренние стартапы. Э-организации разные бывают. Я работал в тех, которые "наелись" коробками и аутсорсом, проблемами и большими расходами, которые с ними связаны, и, в итоге, пришли к экономической целесообразности внутренней разработки. Однако, поскольку это их непрофильная деятельность, в них есть масса проблем, которые я описал в первом своём ответе. С другой стороны, Касперский, например, изначально создавался на написание коробок, но также представляет собой Э-организацию в силу своего размера и мирового масштаба. Хочешь не хочешь, а приходится внедрять иерархию и привлекать сторонних менеджеров, что даёт те же "болезни", что и, скажем, в МТС или ВТБ. В Яндексе и Озоне пока не работал, сказать точно, что там внутри творится не могу, но могу точно сказать, что HR-ы и процесс отбора там отстойный, поскольку многолетний опыт эпизодического общения с ними я уже имею.
Энтерпрайз, если дословно, это предприятие. В том самом, несколько архаичном для русского языка смысле, как некая активность, сопряженная с преодолением каких-то трудностей. Размер здесь не главное - с равным успехом это термин может использоваться как для небольших стартапов, так и корпораций-гигантов.
Enterprise Architecture это история про архитектуру бизнесов. Информационные системы и приложения лежат уровнем ниже. А в самом низу находятся различные технологии.
Потому я и рекомендую индюшатник. Когда от твоих навыков зависит толщина икры на бутерброде, это реально окрыляет. И даëт немного другой экспириенс.
Что самое смешное, эти все Чистые Архтектуры были популяризованы Робертом Мартином на опыте его единственного успешного проекта - обучающие/экзаменующие системы (он сам об этом и пишет в своих статьях-книгах).
Когда тебе сначала показывают всякие слайды с кнопочками Next> Next> Next>
а потом аналогично делают опросник вида A[ ], B[ ], C[ ], D[ ] или A( ), B( ), C( ), D( ) и опять Next> Next>
Проект на десяток страниц строк кода, даже если с комментами. Любой первокурсник на PHP за пару вечеров напишет.
И ни в одном проекте вроде даже уровня "магазин онлайн заказов с отгрузкой со склада по типу 1Ски" он в реальности никогда в своей жизни толком потом и не участвовал, сразу после успеха обучалки-экзаминалки рванул писать чумовые книги с Откровениями О Том Как Надо Правильно Архитектуры и Код, и вот это вот все.
Ну а менеджеры, псевдоархитекторы и прочие сектанты в мире уши и развесили, этож какие теперь возможности карьрерного роста и прочих дивидендов по продаже этого гербалайфа.
И все теперь сидят в лужах из пафоса и глупости, и мучаются с этими вашими MVVM. И никого же не смущает же, почему Model и View по аж два раза в Model-View-ViewModel, а почему? Явная же избыточность и непродуманность прямо на старте.
Но нет, только так и НАДО, ибо строго по заветам Ильича, Клары Цеткин и Барбары Лискофф!
Барбара кстати сама говорила, что немного в шоке от того, к чему пришла индустрия с подачи Дяди Боба - она в своей, в общем-то проходной, работе ни на какие такие откровения не претендовала, а сам принцип это просто цитата из более ранней работы её коллеги. Она использовала его скорее как гипотезу, нежели аксиому. В следующей публикации несколькими годами позже, с подачи своего науч.рука, принцип был оспорен. Но Мартина это ни сколько не смутило. Что их всех объединяло? - общая тусовка.
Ну, фиг его знает, у меня на проекте вполне себе чистая архитектура, привнесённая в запущенный проект мной. Новая часть кода сделана по ЧиА, а старая постепенно переносится из дремучего легаси в новую парадигму. Да, получилось много классов, но они маленькие, сконцентрированные на своей задаче, разбитые по слоям. Но в чём проблема? Так или иначе этот код должен был где-то быть, его было бы не меньше, но без ЧиА в легаси это большие классы на несколько сотен строк, а в новом коде это много классов до сотни строк каждый. Сборок тоже много, но это уже шаблон для новых модулей и разработчики привыкли подглядывать, в имеющиеся модули, чтобы понимать, какие сборки им сделать в новом модуле, что в них помещать, а что нет. То есть система работает, код писать и поддерживать проще, так как есть предсказуемость и системный подход. Да, мне пришлось поработать сверхурочно 2-3 месяца, но мне было интересно. Да, это модульный монолит, но это было сознательное решение и желательное изменение.
Смысл MVVM тоже прекрасно понятен, хотя в последних нескольких проектах я его не использую, так как разработка у меня серверная, а не desktop/mobile, как было раньше. Очень удобный шаблон, когда у вас есть возможность навесить bindings, как это, например, в WPF. И Ильичи, будь то Владимиры или Леониды, тут ни при чём. Или вы предлагает использовать подходы RAD времён Delphi и WinForms?
Delphi по умолчанию использует MVC подход
Я не знаю, что там сейчас использует Delphi, и живо ли оно вообще. Я с ним работал с 1-ой по 7-ую версии. Тогда там никаким MVC ещё не пахло. У тебя была форма, которую ты набирал из компонентов в визуальном редакторе, у тебя были события, связанные с компонентами, и у тебя были обработчики этих событий. Главный рекламируемый паттерн Delphi в те времена был "х** х** и в продакшен", который по вумному тогда назывался RAD (rapid application development). То есть верхом разработки было поместить весь или почти весь код в обработчики этих событий. В одном обработчике можно было найти и работу с экранными элементами, и запросы к базе данных, и вычислительные алгоритмы, и всё остальное прочее (хотя это "прочее" в те времена не блистало разнообразием).
Так вот про MVC почти никто в те времена не задумывался. По крайней мере статей в профильных (бумажных) журналах про шаблоны проектирования и прочую теорию в те времена особо-то и не было. Ко всему прочему Delphi Pascal, хотя и имел в своём составе интерфейсы, так необходимые практически для каждого шаблона проектирования, но их реализация оставляла желать лучшего. В библиотеках и примерах кода они просто не использовались, а многие программисты на Delphi даже в теории не знали про их существование.
К чему это я? А к тому, что любая рефлексия того, что каждый из нас делает каждый день, очень важна и полезна для профессионального роста каждого из нас. Поэтому меня и не радует отношение "все эти ваши паттерны-шматерны, принципы, подходы, никому не нужны!". Подобное отношение приводит в пределе к RAD. Или иными словами спаггети-коду, говнокоду.
Лучше задумываться над тем, что и как ты делаешь, и тогда ты растёшь, чем упрощать всё до эмоциональных аргументов и анекдотов и топтаться на месте.
При этом никто не запрещает тебе вынести логику отдельно от класса окна и оставить в обработчиках событий лишь работу с окном и "сигналы". А MVC в Delphi, по умолчанию, потому что создание визуальной составляющей окна идет отдельно от остального кода (пусть и скрыто). Т.е. Delphi подход из коробки отсекает код создания визуальных элементов и кода, который несет смысловую нагрузку (бизнес процесс).
dfm - структура окна - View
класс окна - Controller
Данные для работы программы, структуры данных - Model - отдельно
Конечно, никто ничего не запрещает, и всегда можно натянуть сову на глобус при большом желании. Вот только в MVC модель обновляет View, а в Delphi (как я его запомнил) ничего подобного не было. Были обработчики событий (Control) экранных элементов, в которых происходило и изменение View и изменение анемичных Model.
Ещё раз, я расстался с Delphi году в 2012. В ту пору его авторы начали дрейф в сторону CLR и Delphi Pascal, как ещё одного CLI-языка. Поэтому рассказываю, как оно было в то время. Структура формы была не заточена под MVC или любой другой осознанный шаблон. Собственно в то время кроме MVC и MVP никто ни о чём не слышал. Подход, который продавали вместе с Delphi был — RAD. Что это за зверь, и как структурировался код в 90% проектов, я рассказал. Кстати, серверной разработки на Delphi не было в принципе, а под клиент-серверными решениями подразумевалось desktop-приложение, в качестве клиента, и какой-нибудь Sybase или MS SQL Server, в качестве сервера.
Была серверная разработка, ещё году в 2006: Soap, Intraweb, CGI. Сейчас и вовсе из коробки REST (RAD Server) и куча других фреймворков.
То, что Delphi позволяет RAD разработку, форма, обработчики событий и т.д. это не плохо и не минус, а MVC или MVVM реализуется легко (как раньше, так и сейчас).
Перепутал я год. Правильно, в 2005 я с Delphi закончил и перешёл на C#. Старый уже, память плохая. :) Как раз .NET Framework 3 вышел.
А RAD хорош только для маленьких короткоживущих проектов. Для остальных проектов — это ад. Никому не пожелаю в таких участвовать.
Могу сказать только то, что вы сильно ошибаетесь.
У нас просто разный профессиональный опыт. И я Вас прекрасно могу понять. Пока дальше первого языка и среды разработки не глянешь, всё кажется просто и логично. Стоит расширять кругозор и спокойно относиться к чужому опыту и мнению.
Во-первых, если что, минусы ставлю вам не я.
Во-вторых, несмотря на то, что Делфи мой первый язык, он не единственный, на котором у меня есть опыт работы. С C# я поработал не мало и знаю что и как работает. В том числе, я работал и с WPF. Я участвовал в крупных проектах на этом языке. В какой-то момент, стаж работы на Делфи и С# сравнялся, но я сознательно ушел к Делфи.
Clean Architecture, SOLID и святой Uncle Bob. Так и есть. Основной бизнес Дядюшки Боба - чтение лекций на тему CA, а не создание всяких систем. Об этом надо всегда помнить, когда читаешь его опусы :)
В защиту MVVM скажу, что название, действительно, не слишком удачное, но разделение обязанностей в ней вполне адекватное.
всё упирается только в компетентность и опыт разработчика. я даже простой стартап делаю через тестирование, с хорошими DAL абстракциями, компонентами, сервисами, потому что мне так проще и быстрее - когда уже 10 таких проектов сделал както не хочется говнокодить, просто дольше, потому что считаешь примерно сколько времени тратишь на отладку, это когда ты на работе можно за счёт работодателя поотлаживать в своё удовольствие, а когда делаешь проект на заказ и знаешь что поддерживать его будешь тоже ты то начинаешь считать деньги. и деньги экономятся на правильной архитектуре без овернижениринга, интеграционных и юнит-тестах, стабильных инструментах таких как EntityFramework, Swagger, MSIdentity, Newtonsoft, Blazor, HangFire итд, и в итоге получается быстрее и дешевле писать красивый код. к чистой архитектуре есть вопросы, я бы скорее делал акцент на перенос ошибок с уровня выполнения на уровень компиляции, меня это больше интересует чем чистота архитектуры. прежде чем писать какой-либо интерфейс я думаю смогу ли я нажать на этом методе F12, прежде чем мокать чтото подумаю как я потом буду поддерживать эти моки и не проще ли просто запустить методы DAL на тестовой базе, вобще с опытом приходит чутьё на точное понимание границ допустимости чистоты архитектуры... а то работал в одном очень крутом проекте, там такая чистота архитектуры была, что когда чтото в базе менялось приходилось 18 файлов комитить... такая чистота тоже нахрен не нужна
Почему-то складывается такое общественное мнение в среде программистов, что НЕ (чистая архитектура или DDD) = говнокод. Крайне спорное утверждение, можно и в стиле DDD и чистой архитектуры такой говнокод написать, что замучаешься разгребать. И наоборот, простой, понятный, производительный код не обязательно должен следовать каким-то практикам.
Вы за это заплатите! Цена Чистой Архитектуры. Часть 1