гипотеза: черновик статьи редактор скормил "Алисе" и попросил переписать.
у меня так однажды наш рп сделал с моей постановкой. я когда почитал этот прекрасный хорошо читаемый текст едва-ли не выматерился : в техническом тексте это гпт-поделие в некоторых местах поменяло объект и субъект действия.
вот и тут похоже на автоматизированный перевод и ии-адаптацию ))
скажите, вот вы пишете что зависимость от центральных библиотек декларирующие общие структуры - это типа зло. мол при изменении одной структуры - например вы упомянули заказ - требуется пересобирать всё использующие её компоненты. так?
ок. вот вы избавились от зависимости от центральной библиотеки. но структуры-то того же Order по прежнему должны быть совместимы и быть синхронизированы, чтобы не потерять данные той-же накладной где-то посередине. так?
и вот наступает день X, когда торговые менеджеры придумали очередную акцию, и требуется изменить структуру заказа (например у строчки заказа появляется доп. признак - размер кешбека скажем за данную позицию) и правила обработки накладной, скажем меняется приоритетность доставки от этого кешбека (идиотизм, но кто их торгашей вообще когда понимал зачем они что делают. в общем не важно зачем это так).
и вот вам надо поменять все dto-шки этого Order во всех сервисах которые его обрабатывают. причем сделать это надо строго ко к дню праздника Y (торговые акции они такие. и скажите спасибо что это не требования изменяющегося законодательства, тогда вообще жёстко).
и теперь вопрос: во сколько возрастают трудозатраты команд и вероятность ошибок, если команды не могут получить готовый артефакт ? каждая из команд, теперь должна не просто перекомпилить и деплойнуть свои сервисы (что в случае минорных изменений вообще можно сделать едва-ли не в автоматическом режиме), а самим ещё понять - что, и в какой структуре поменять. если отдать это им на откуп - половина поменяет не там, вторая опечается, третья тип поставит не тот, потом дебаг, созвоны, всё бегают тестируют, пишут багрепорты.... серьёзно?
у меня стойкое впечатление, что вы, в погоне за идеализированной идеей, усугубляете объективное число проблем.
несомненно, не всё в системе должно быть централизованно. но какие-то вещи обязаны быть централизованно управляемы и желательно именно техническими методами. иначе система перестает быть единой системой.
вы выбрали не самый удачный бизнес-пример, и на нем как раз ваша попытка донести, может быть и здравую (кто знает?) мысль ломается.
ну, или я "ничонепонял-нетакпонял" ? но тогда см комментарий выше о косноязычием статьи.
т.е. они думают, что кровавый ынтерпрайз в закрытых исходниках чем-то лучше школьноподелок на гитхобе? ахх-ха-ха-ха... чую запах великого облома XD)))
кроваво-ынтерпоайзнутый код он в закрытых исходниках вовсе не потому что он какой-то там хороший. он "конкретный" - решающий конкретные задачи, и потому он ценен "для бизнеса".
методика разработки. точнее вам нужна методология, которая позволяет построить свою методику, свой подход на каждом проекте. в зависимости от его тяжести, объема, сложности, и опыта и состава команды.
если хотите совет, то найдите RUP 6. Rational Unified Process v6. именно 6й версии, последней, которую выпустила компания Rational перед тем как её купила IBM.
в 7й версии эффективные манагеры голубого гиганта испоганили всё, и например из "лучших практик разработки", понятных и четко обоснованных, сделали непотребство вида "принципы бизнес ориентированной разработки", направленные видимо на повышение продаж, и с техническим качеством вообще никак не связанные. говорю как "сертифицированный специалист по RUP v7". я тогда немного затянул с подготовкой, и не успел сдать сертификацию на 6ю версию. то что я увидел в 7й меня "немного удивило".
ну и вот. методология. масштабируемый процесс, шведский стол элементов, из которых вы , понимая принципы, строите подходящий процесс разработки , на каждом конкретном проекте.
именно так, как надо тут и сейчас: от записанных на коленке FTR до тяжёлых спецификаций.
ещё хорошо поможет переход от постановки требований в формате долженствования ("система должна делать делать такую то функцию, после нажатия, и выводить....") к повествовательному стилю юзкейзов ("прецедентов использования") пользователь нажимает кнопку, система выводит это, и запускает фоновую функцию...").
к трассируемости и понятности контекста и сути - сильно поможет принцип "usecase driven development" . всё вокруг прецедентов.
концепция постепенно развивающихся и детализируются артефактов поможет делать и понимать ровно то, что что надо сейчас. не перегружаться написанием документации, а детализировать прецеденты там и когда надо. у нас был проект 2.5 года, (2 последовательных госконтракта), и у нас часть прецедентов до самого конца так и остались в форме "бриф-дескрипшена". потому что всем и так всё было понятно. а 4 или 5 прецедентов, из трёх десятков, и были прописаны подробнейшим образом, по шагам, с приложением алгоритмов обработки записей в бд).
понимание "компонентно ориентированной разработки" поможет не участвовать в холиваре микросервисы против монолита, а правильно выделять в микросервисы то что само выделяется и оставлять в маленьких монолитных сборках то, что не требуется пока выделять, или что эффективнее работает в межпроцессном взаимодействии и общей памяти. ( и никакой распиаренный DDD вам не потребуется, имхо, хотя и изучите его для кругозора. "всё говорят", "в нем что то есть", но и про инжектирование зависимостей так тоже говорили, как о какой-то "высшей сакральности", а я смотрю на это как на ещё одну обычную фабрику классов и подстановку реализации в рантайме. в общем ничего ни сакрального, ни достойного кипяткопИсания нет - простое частное решение, если конечно, вы понимаете компонентно-ориентированной подход и фабрику классов. )
ещё почитайте для общего развития "проектно ориентированное управление" Дж.Родни Тернера.
тоже плохо представляю, где вы её сейчас возьмёте, но это единственная книга по управлению проектами которую я нашел, где где внятно описано "управление по вехам" и "планирование набегающей волной". поможет понять взгляд теории управления проектами на интерационную разработку. и эта книга, имхо, как мифический человекомесяц Брукса - нестареющая классика. ну разве что её не переиздают.
за сим, доброго вам дня и хороших поисков. как найдёте решение, скажите. самим не на всех проектах удается выстроить всё как надо ) до сих пор, да. но теория сильно помогает. как говорится чем смог, тем помог. ))
указанная методика, имхо, не учитывает технический аспект.
архитектурные задачи, требующиеся для стабильной работы системы, обеспечения требуемых характеристик системы , безопасность, обеспечение инфраструктуры работы ("где джавадоки, вашу мать?! почему нет юниттестов? почему не прогнали интеграционные тесты? как так нету их ?!!!! что значит у нас апи не позволяет получить токен без участия человека??"(с)) -... короче вот такое и не только - должно идти в первом приоритете.
как бы пользователь не хотел что то очень важного, без обеспечения технических задач, погоня только за пользовательскими фичами - это как правило медленное погружение в технический ад, значительное замедление разработки, накопление снежного кома технического долга.
т.е. у нас должны быть не 4 колонки, а матрица 16 ячеек))) пересечение mscw по пользовательскому приоритету, и по техническому - с точки зрения влияния на архитектуру и технической критичности.
т.е. вспоминайте RUP - есть пользовательский приоритет, есть технический. архитектор+аналитик вместе приоретизируют задачи на итерацию потому что их взгляды противоположенны - один отстаивает потребности системы, второй - желания пользователей.
не важно как считать, rice, ice, mocsow - да хоть экспертами оцениваете по шкале критично, важно не важно - это только способы получить веса приоритета.
важно помнить, что в разработке ПО есть 2 этих взгляда. 2 разных приоритета. а вы балансирует между ними в ходе работ итерации.
1) так такой товар рассматривается как бракованный или нет?
2) если это "бракованный" товар, то какие последствия для потребителя несет покупка "заведомо бракованного" товара. т.е. например - не последует ли за признанием "бракованности" отказ от гарантий. т.е. не получится ли ситуация, когда гарантия на iPhone - "2 недели на замену"?
3) речь идет о несоблюдении РП №2240-р и №2241-р от 9 августа 2025 года. Какие последствия понесет, и кто, за несоблюдение Распоряжения Правительства ? У меня сомнения, что такая бумажка спасет продавца и/или поставщика от последствий.
Specifications не всегда подходят для сложных сценариев, не делает их "хренью". Это всего лишь инструмент, который удобно использовать, когда он подходит, и игнорировать, когда он избыточен.
Вы как раз ошибаетесь. Вы в данном предложении мыслите "сиюминутно", простите, как студент, которому надо сделать что-то на раз и забыть.
Проблема большого интерпрайз-приложения в том, что ты не знаешь в каком месте оно станет сложным через ... скажем полгода. или год.
Приложения имеют тенденцию усложняться.
И когда ты понимаешь что "тут внезапно и неожиданно стало сложно", а "спецификации" уже превратили код в нечитаемый, неразбираемый, и - главное - неотлаживаемый кусок "чего-то" - любой чих в направлении отказа от этого "новомодномолодежного API" - будет стоит денег, нервов и новых багов. Потому что они "прописаны везде".
Отсюда - это как раз именно "хрень". Потому что она обманывает тебя красивой концепцией, а потом очень сильно и больно бьет, когда в реалььной жизни ты налетаешь на сложный случай с уже написанным кодом. Причем часто после того, как человек создавший это нагромождение - когда проект ещё был простым - уже не доступен.
Исходя из этого обстоятельства - есть один очень простой выход: запрет использования этого API на серьезных проектах.
Т.е. "на всех проектах сложнее "курсовой" которую можно стереть и забыть после сдачи зачета".
1) как или откуда скачать дистрибутив ликвидбейса, если официальный сайт в "амазон клауде" и он блокирует получение файлов ? и.е. виндовый дистрибутив с официального сайта не получить
2) я правильно понимаю, что Liquibase не умеет контролировать/запоминать текущую, целевую структуру таблиц, и восстанавливать её, если что-то пошло не так? т.е. он "тупо шпарит патчи" и контролирует их выполнение, не понимая, надо ли для текущей структуры применять патч или нет, даже если это не sql, а опция " - createtable " в yaml-файле с ченджлогом?
т.е. если в работу с таблицами ликвидбейса вмешалась третья сторона или "что-то пошло не так" - мы получаем долгий изнурительный процесс восстановления структуры руками?
поясню на примере: вот прошла миграция, всё патчи/ченджлоги ликвидбейзом применены. теперь какой-то сторонний инструмент удаляет из базы таблицу. ну, так случилось. запускаем систему спрингбут с ликвидбейзом, он при старте проверяет что всё патчи применены, пишет всё хорошо, а потом мы получаем исключения при выполнении запросов, что relation в базе не существует.
как заставить ликвидбейз проверять целевую структуру бд, сравнивать её с целевой и применять изменения фрагментарно ? например - восстановить таблицу если она была "случайно" удалена?
в инфраструктуру надо вкладываться. планово, без сиюминутной отдачи, начисляя из бюджета проекта 20%, ухудшая в пользу этого формальные показатели...
потому что, если не поддерживать инфраструктуру - "оно начнет гнить". медленно, но неотвратимо приближая полный коллапс системы и процессов.
как материальная инфраструктура является чем-то малозначимые и дорогим, требующим постоянного обслуживания, не участвующим непосредственно в получении результата, но дающим вообще возможность получить результат; так и процесс должен обладать шагами, которые обслуживают вообще саму возможность получать результат длительное время.
---------
а вот почему у автора - архитектор - "невидимый" - это вопрос. может надо сделать ротацию архитекторов? чела поднять из разрабов в младшие архитекторы?
архитектор не должен быть невидимым. иначе возникает вопрос - а рп у вас вообще с головой дружит?)))
то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
где каждый второй айтишник считает своим долгом выложить фотографию своего рабочего места с MacBook и кружкой с лавандовым рафом.
В этом предложении у вас, простите, ошибка. В слове "айтишник" ))) В данном контексте, правильно писать "те, кто себя считает айтишником".
Как говорится, "Гуманитарии считают макбук лучшим инструментом для разработки. Но кто-ж их слушает - они-ж и считать-то толком не умеют". 😂
А если по теме - у нас в компании (небольшой интегратор, 100+ человек, 90% сотрудников - люди с высшим техническим образованием) макбуков, наверное, от силы штук 5 наберется.
Совпадение? Не думаю.
По моему личному впечатлению и наблюдениям, обладание высшим техническим образованием "уменьшает вероятность и желание" стать обладателем яблочной продукции "до нескольких процентов".🤷♂️
1.мне начали начислять за кодинг в 1994м. детские игровые обучающие программы для класса дошкольного развития.
2. за софт скиллы морочились всегда, только оно так не называлось, и именно отдельно в особую категорию скиллы не выделялось. просто были способности к математике, технике, психологии, работе с людьми, организаторские способности.
если сейчас софт скиллы выделают как первейшие... я согласен что это глупость, но я не вижу такого выпячивания. впрочем это может быть как засилье жаворонков, утверждающих что просыпаться рано утром полезнее и лучше. а мне повезло увернуться, а вы попали под удар.
но софт скиллы - это мастхев. к сожалению, мы живём в обществе приматов в основной своей массе не обученных рефлексии и осознанной деятельности. и ваш менеджер - тому ярчайший пример )). потому, начиная с мидла - софт скиллы - это обязательно. у нас например ты мидлом конечно станешь, но средненьким максимум (у нас 3 ступени в мидлах). без софт скиллов, контактов с заказчиком или его представителями, в лиды не пробьешься. разработка софта - командный спорт. кому нужен сферический конь в вакууме , пусть и кодящий на отлично?))
ну и вот. мастер на производстве со временем просто становился "житейски мудрее" и умел говорить с начальством. просто не заметил таких ноток в статье. "ну штошъ". сорян))
3. да не, тоже норм. у меня как инженера вообще от половины идей маркетингового онанизма подгорает. вон, глядишь, сам доберусь до статьи про микросервисы...
я, наверное, постараюсь избегать в дальнейшем написания подобных статей
а вот это вы бросьте. кто-ж будет маркетолухам противостоять и хоть где-то школоте и студентам что то рассказывать?)))
или... простите за наглость, но у меня ещё 2 вопроса :
у вас точно 25 лет опыта в индустрии?))
если так, то как можно дожить до 40+ лет и не набраться опыта во взаимодействии с менеджерами? вы не просто обязаны быть "как минимум мидлом"(и знать про особенности некоторых менеджеров ) но и тупо, по налёту лет, не просто столкнуться раз 5-10 с такими манагерами, но и научиться обрабатывать эти ситуации на уровне чуть более мудром, чем "я думаю уволиться".
отсюда вывод: или вы привираете, или написали заказную хайповую статью.
у вас исследование какое или просто чешете себе ЧСВ перед школьниками ?))
У меня вопрос : а почему вы про это всё нам тут плачетесь, а не рассказываете "это всё" вашему архитектору?
потому что тут выслушают?))) что думает по этому поводу ваш архитектор? если всё так, а я подозреваю что всё у вас действительно так, то решать менеджерский вопрос надо менеджерский и пустыми. эскалируйте факт наличия технической проблемы наверх по иерархии и пусть технически подкованные архитектор (понимающий вас), обладающий скидками и доверием уровня менеджера (ему доверяет менеджер), объясняет менеджеру, что идея, мягко говоря, плоха.
так. а не слезливой статьёй на хабре.
... а..... или вы и есть тот самый архитектор?
тогда вопрос : вы не пользуетесь доверием/уважением менеджера? тогда вы не архитектор. ему без софт скиллов и умения работать с менеджерами - никак. вы уж простите.
... или у вас менеджер играет в "я начальник ты дурак"? тогда конечно швах.
можно было бы посоветовать вам поиграть в менеджерский игры вида "дай идиоту оступиться" (сделать как хочет человек, с фиксацией рисков и опасений, и формулировкой "ну раз вы платите, и рискуете своими деньгами, то пожалуйста", а когда всё пойдёт по ...медному тазу - вытащить из загашника старое письмо ), но чую этот вариант не для вас.
...
как итог ? вы - забейте.
если менеджер невразумляемый идиот, поддающийся на маркетинговые уловки - то вашему продукту пи.... ...медным тазом, в общем... он закроется. и вас менеджер , как минимум сейчас, слушать не будет.
в лучшем случае - дайте ему почитать Брукса, и скажите, что кодогенерящие нейронки - совсем не серебряная пуля. и для вашего продукта этот вариант не применим.
юзать кодоген-нейронку - это всё равно, что нанять забесценок студента второкурсника , чтобы с ним, в режиме диалога пилить сайт. если менеджер не послушает такую аналогию - то он дурак. делайте что хотите ))) дело не в вас и не в вайб-кодинге.
студентов генерящих "правильные, красивые, задёшево, идиотические решения" приводили на предприятия всегда. ну теперь вот нейронку привели, с такой же формулировкой и посылом.так что, вот так же , по аналогии и отбивайтесь.
и самое большое инфоцыганство - это микросервисы. XD))
нет, серьезно - кто-нибудь знает что это такое?
и я не про определение и теорию, я про то, что называется "микросервисом" в реальных проектах.
насколько оно соответствует определению, насколько оно действительно решает проблемы (а не приносит кучу новых)... ?
кому удается избежать проблемы "микросервисного монолита" (когда вроде и (микро)(нет)сервисы, но все перезавязано друг на друга так, что не разобрать, и в итоге боязно хоть что-то трогать, потому что не известно что отвалится)... ?
ау! кто видел курсы "по микросервсиной архитектуре" где есть пункт - "когда не надо пилить монолит на микросервисы"?))) нет такого пункта? ну тогда вы поняли.
гипотеза: черновик статьи редактор скормил "Алисе" и попросил переписать.
у меня так однажды наш рп сделал с моей постановкой. я когда почитал этот прекрасный хорошо читаемый текст едва-ли не выматерился : в техническом тексте это гпт-поделие в некоторых местах поменяло объект и субъект действия.
вот и тут похоже на автоматизированный перевод и ии-адаптацию ))
скажите, вот вы пишете что зависимость от центральных библиотек декларирующие общие структуры - это типа зло. мол при изменении одной структуры - например вы упомянули заказ - требуется пересобирать всё использующие её компоненты. так?
ок. вот вы избавились от зависимости от центральной библиотеки. но структуры-то того же Order по прежнему должны быть совместимы и быть синхронизированы, чтобы не потерять данные той-же накладной где-то посередине. так?
и вот наступает день X, когда торговые менеджеры придумали очередную акцию, и требуется изменить структуру заказа (например у строчки заказа появляется доп. признак - размер кешбека скажем за данную позицию) и правила обработки накладной, скажем меняется приоритетность доставки от этого кешбека (идиотизм, но кто их торгашей вообще когда понимал зачем они что делают. в общем не важно зачем это так).
и вот вам надо поменять все dto-шки этого Order во всех сервисах которые его обрабатывают. причем сделать это надо строго ко к дню праздника Y (торговые акции они такие. и скажите спасибо что это не требования изменяющегося законодательства, тогда вообще жёстко).
и теперь вопрос: во сколько возрастают трудозатраты команд и вероятность ошибок, если команды не могут получить готовый артефакт ? каждая из команд, теперь должна не просто перекомпилить и деплойнуть свои сервисы (что в случае минорных изменений вообще можно сделать едва-ли не в автоматическом режиме), а самим ещё понять - что, и в какой структуре поменять. если отдать это им на откуп - половина поменяет не там, вторая опечается, третья тип поставит не тот, потом дебаг, созвоны, всё бегают тестируют, пишут багрепорты.... серьёзно?
у меня стойкое впечатление, что вы, в погоне за идеализированной идеей, усугубляете объективное число проблем.
несомненно, не всё в системе должно быть централизованно. но какие-то вещи обязаны быть централизованно управляемы и желательно именно техническими методами. иначе система перестает быть единой системой.
вы выбрали не самый удачный бизнес-пример, и на нем как раз ваша попытка донести, может быть и здравую (кто знает?) мысль ломается.
ну, или я "ничонепонял-нетакпонял" ? но тогда см комментарий выше о косноязычием статьи.
т.е. они думают, что кровавый ынтерпрайз в закрытых исходниках чем-то лучше школьноподелок на гитхобе? ахх-ха-ха-ха... чую запах великого облома XD)))
кроваво-ынтерпоайзнутый код он в закрытых исходниках вовсе не потому что он какой-то там хороший. он "конкретный" - решающий конкретные задачи, и потому он ценен "для бизнеса".
а по качеству он такой-же в основной своей массе.
мне одному кажется, что "лучше бы они не убивали unreal tournament", чем теперь пытаться всех привлекать мини-проектами ? )))
и вот, вы, от сохи, добрались, наконец, до сути.
методика разработки. точнее вам нужна методология, которая позволяет построить свою методику, свой подход на каждом проекте. в зависимости от его тяжести, объема, сложности, и опыта и состава команды.
если хотите совет, то найдите RUP 6. Rational Unified Process v6. именно 6й версии, последней, которую выпустила компания Rational перед тем как её купила IBM.
в 7й версии эффективные манагеры голубого гиганта испоганили всё, и например из "лучших практик разработки", понятных и четко обоснованных, сделали непотребство вида "принципы бизнес ориентированной разработки", направленные видимо на повышение продаж, и с техническим качеством вообще никак не связанные. говорю как "сертифицированный специалист по RUP v7". я тогда немного затянул с подготовкой, и не успел сдать сертификацию на 6ю версию. то что я увидел в 7й меня "немного удивило".
ну и вот. методология. масштабируемый процесс, шведский стол элементов, из которых вы , понимая принципы, строите подходящий процесс разработки , на каждом конкретном проекте.
именно так, как надо тут и сейчас: от записанных на коленке FTR до тяжёлых спецификаций.
ещё хорошо поможет переход от постановки требований в формате долженствования ("система должна делать делать такую то функцию, после нажатия, и выводить....") к повествовательному стилю юзкейзов ("прецедентов использования") пользователь нажимает кнопку, система выводит это, и запускает фоновую функцию...").
к трассируемости и понятности контекста и сути - сильно поможет принцип "usecase driven development" . всё вокруг прецедентов.
концепция постепенно развивающихся и детализируются артефактов поможет делать и понимать ровно то, что что надо сейчас. не перегружаться написанием документации, а детализировать прецеденты там и когда надо. у нас был проект 2.5 года, (2 последовательных госконтракта), и у нас часть прецедентов до самого конца так и остались в форме "бриф-дескрипшена". потому что всем и так всё было понятно. а 4 или 5 прецедентов, из трёх десятков, и были прописаны подробнейшим образом, по шагам, с приложением алгоритмов обработки записей в бд).
понимание "компонентно ориентированной разработки" поможет не участвовать в холиваре микросервисы против монолита, а правильно выделять в микросервисы то что само выделяется и оставлять в маленьких монолитных сборках то, что не требуется пока выделять, или что эффективнее работает в межпроцессном взаимодействии и общей памяти. ( и никакой распиаренный DDD вам не потребуется, имхо, хотя и изучите его для кругозора. "всё говорят", "в нем что то есть", но и про инжектирование зависимостей так тоже говорили, как о какой-то "высшей сакральности", а я смотрю на это как на ещё одну обычную фабрику классов и подстановку реализации в рантайме. в общем ничего ни сакрального, ни достойного кипяткопИсания нет - простое частное решение, если конечно, вы понимаете компонентно-ориентированной подход и фабрику классов. )
ещё почитайте для общего развития "проектно ориентированное управление" Дж.Родни Тернера.
тоже плохо представляю, где вы её сейчас возьмёте, но это единственная книга по управлению проектами которую я нашел, где где внятно описано "управление по вехам" и "планирование набегающей волной". поможет понять взгляд теории управления проектами на интерационную разработку. и эта книга, имхо, как мифический человекомесяц Брукса - нестареющая классика. ну разве что её не переиздают.
за сим, доброго вам дня и хороших поисков. как найдёте решение, скажите. самим не на всех проектах удается выстроить всё как надо ) до сих пор, да. но теория сильно помогает. как говорится чем смог, тем помог. ))
указанная методика, имхо, не учитывает технический аспект.
архитектурные задачи, требующиеся для стабильной работы системы, обеспечения требуемых характеристик системы , безопасность, обеспечение инфраструктуры работы ("где джавадоки, вашу мать?! почему нет юниттестов? почему не прогнали интеграционные тесты? как так нету их ?!!!! что значит у нас апи не позволяет получить токен без участия человека??"(с)) -... короче вот такое и не только - должно идти в первом приоритете.
как бы пользователь не хотел что то очень важного, без обеспечения технических задач, погоня только за пользовательскими фичами - это как правило медленное погружение в технический ад, значительное замедление разработки, накопление снежного кома технического долга.
т.е. у нас должны быть не 4 колонки, а матрица 16 ячеек))) пересечение mscw по пользовательскому приоритету, и по техническому - с точки зрения влияния на архитектуру и технической критичности.
т.е. вспоминайте RUP - есть пользовательский приоритет, есть технический. архитектор+аналитик вместе приоретизируют задачи на итерацию потому что их взгляды противоположенны - один отстаивает потребности системы, второй - желания пользователей.
не важно как считать, rice, ice, mocsow - да хоть экспертами оцениваете по шкале критично, важно не важно - это только способы получить веса приоритета.
важно помнить, что в разработке ПО есть 2 этих взгляда. 2 разных приоритета. а вы балансирует между ними в ходе работ итерации.
есть несколько вопросов, кто мог бы прояснить?
1) так такой товар рассматривается как бракованный или нет?
2) если это "бракованный" товар, то какие последствия для потребителя несет покупка "заведомо бракованного" товара. т.е. например - не последует ли за признанием "бракованности" отказ от гарантий. т.е. не получится ли ситуация, когда гарантия на iPhone - "2 недели на замену"?
3) речь идет о несоблюдении РП №2240-р и №2241-р от 9 августа 2025 года. Какие последствия понесет, и кто, за несоблюдение Распоряжения Правительства ? У меня сомнения, что такая бумажка спасет продавца и/или поставщика от последствий.
заранее спасибо.
"индусский код" - это не расизм. это явление, мем и термин. увы)
прекрасно. а где они, эти докеры?
в статье нет ни урлов, ни доступов - кроме неработающей на территории России ссылки на ютуб. добавите?
я бы предложил 2 вещи для начала продвижения:
1. ролик выдожить на официально доступные ресурсы.
2. идеально бы поднять сервер, где можно пощупать игру. простая виртуалка сейчас стоит пару чашек кода. обычно это подъемные деньги.
ну, или дистрибутивы для поднятия своего сервера и запуска клиента.
и не бросать игру. без автора, хотя бы дающего комментарии по коду - не взлетит.
ну и на всякий случай: документация и комментарии в коде. если этого нет - имхо, считайте что и нет кода в общем доступе.
Вы как раз ошибаетесь. Вы в данном предложении мыслите "сиюминутно", простите, как студент, которому надо сделать что-то на раз и забыть.
Проблема большого интерпрайз-приложения в том, что ты не знаешь в каком месте оно станет сложным через ... скажем полгода. или год.
Приложения имеют тенденцию усложняться.
И когда ты понимаешь что "тут внезапно и неожиданно стало сложно", а "спецификации" уже превратили код в нечитаемый, неразбираемый, и - главное - неотлаживаемый кусок "чего-то" - любой чих в направлении отказа от этого "новомодномолодежного API" - будет стоит денег, нервов и новых багов. Потому что они "прописаны везде".
Отсюда - это как раз именно "хрень". Потому что она обманывает тебя красивой концепцией, а потом очень сильно и больно бьет, когда в реалььной жизни ты налетаешь на сложный случай с уже написанным кодом. Причем часто после того, как человек создавший это нагромождение - когда проект ещё был простым - уже не доступен.
Исходя из этого обстоятельства - есть один очень простой выход: запрет использования этого API на серьезных проектах.
Т.е. "на всех проектах сложнее "курсовой" которую можно стереть и забыть после сдачи зачета".
UPD: скачивание дистрибутивов https://www.liquibase.com/open-source они вроде поправили. вопрос 1 отпадает. но что делать со вторым пунктом?
пара вопросов, если позволите.
1) как или откуда скачать дистрибутив ликвидбейса, если официальный сайт в "амазон клауде" и он блокирует получение файлов ? и.е. виндовый дистрибутив с официального сайта не получить
2) я правильно понимаю, что Liquibase не умеет контролировать/запоминать текущую, целевую структуру таблиц, и восстанавливать её, если что-то пошло не так? т.е. он "тупо шпарит патчи" и контролирует их выполнение, не понимая, надо ли для текущей структуры применять патч или нет, даже если это не sql, а опция " - createtable " в yaml-файле с ченджлогом?
т.е. если в работу с таблицами ликвидбейса вмешалась третья сторона или "что-то пошло не так" - мы получаем долгий изнурительный процесс восстановления структуры руками?
поясню на примере: вот прошла миграция, всё патчи/ченджлоги ликвидбейзом применены. теперь какой-то сторонний инструмент удаляет из базы таблицу. ну, так случилось. запускаем систему спрингбут с ликвидбейзом, он при старте проверяет что всё патчи применены, пишет всё хорошо, а потом мы получаем исключения при выполнении запросов, что relation в базе не существует.
как заставить ликвидбейз проверять целевую структуру бд, сравнивать её с целевой и применять изменения фрагментарно ? например - восстановить таблицу если она была "случайно" удалена?
----------
заранее спасибо.
это по сути "инфраструктура процесса".
в инфраструктуру надо вкладываться. планово, без сиюминутной отдачи, начисляя из бюджета проекта 20%, ухудшая в пользу этого формальные показатели...
потому что, если не поддерживать инфраструктуру - "оно начнет гнить". медленно, но неотвратимо приближая полный коллапс системы и процессов.
как материальная инфраструктура является чем-то малозначимые и дорогим, требующим постоянного обслуживания, не участвующим непосредственно в получении результата, но дающим вообще возможность получить результат; так и процесс должен обладать шагами, которые обслуживают вообще саму возможность получать результат длительное время.
---------
а вот почему у автора - архитектор - "невидимый" - это вопрос. может надо сделать ротацию архитекторов? чела поднять из разрабов в младшие архитекторы?
архитектор не должен быть невидимым. иначе возникает вопрос - а рп у вас вообще с головой дружит?)))
;)
то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
В этом предложении у вас, простите, ошибка. В слове "айтишник" )))
В данном контексте, правильно писать "те, кто себя считает айтишником".
Как говорится, "Гуманитарии считают макбук лучшим инструментом для разработки. Но кто-ж их слушает - они-ж и считать-то толком не умеют". 😂
А если по теме - у нас в компании (небольшой интегратор, 100+ человек, 90% сотрудников - люди с высшим техническим образованием) макбуков, наверное, от силы штук 5 наберется.
Совпадение? Не думаю.
По моему личному впечатлению и наблюдениям, обладание высшим техническим образованием "уменьшает вероятность и желание" стать обладателем яблочной продукции "до нескольких процентов".🤷♂️
по аналогии:
1.мне начали начислять за кодинг в 1994м. детские игровые обучающие программы для класса дошкольного развития.
2. за софт скиллы морочились всегда, только оно так не называлось, и именно отдельно в особую категорию скиллы не выделялось. просто были способности к математике, технике, психологии, работе с людьми, организаторские способности.
если сейчас софт скиллы выделают как первейшие... я согласен что это глупость, но я не вижу такого выпячивания. впрочем это может быть как засилье жаворонков, утверждающих что просыпаться рано утром полезнее и лучше. а мне повезло увернуться, а вы попали под удар.
но софт скиллы - это мастхев. к сожалению, мы живём в обществе приматов в основной своей массе не обученных рефлексии и осознанной деятельности. и ваш менеджер - тому ярчайший пример )). потому, начиная с мидла - софт скиллы - это обязательно. у нас например ты мидлом конечно станешь, но средненьким максимум (у нас 3 ступени в мидлах). без софт скиллов, контактов с заказчиком или его представителями, в лиды не пробьешься. разработка софта - командный спорт. кому нужен сферический конь в вакууме , пусть и кодящий на отлично?))
ну и вот. мастер на производстве со временем просто становился "житейски мудрее" и умел говорить с начальством. просто не заметил таких ноток в статье. "ну штошъ". сорян))
3. да не, тоже норм. у меня как инженера вообще от половины идей маркетингового онанизма подгорает. вон, глядишь, сам доберусь до статьи про микросервисы...
а вот это вы бросьте. кто-ж будет маркетолухам противостоять и хоть где-то школоте и студентам что то рассказывать?)))
или... простите за наглость, но у меня ещё 2 вопроса :
у вас точно 25 лет опыта в индустрии?))
если так, то как можно дожить до 40+ лет и не набраться опыта во взаимодействии с менеджерами? вы не просто обязаны быть "как минимум мидлом"(и знать про особенности некоторых менеджеров ) но и тупо, по налёту лет, не просто столкнуться раз 5-10 с такими манагерами, но и научиться обрабатывать эти ситуации на уровне чуть более мудром, чем "я думаю уволиться".
отсюда вывод: или вы привираете, или написали заказную хайповую статью.
у вас исследование какое или просто чешете себе ЧСВ перед школьниками ?))
У меня вопрос : а почему вы про это всё нам тут плачетесь, а не рассказываете "это всё" вашему архитектору?
потому что тут выслушают?)))что думает по этому поводу ваш архитектор? если всё так, а я подозреваю что всё у вас действительно так, то решать менеджерский вопрос надо менеджерский и пустыми. эскалируйте факт наличия технической проблемы наверх по иерархии и пусть технически подкованные архитектор (понимающий вас), обладающий скидками и доверием уровня менеджера (ему доверяет менеджер), объясняет менеджеру, что идея, мягко говоря, плоха.так. а не слезливой статьёй на хабре.
... а..... или вы и есть тот самый архитектор?
тогда вопрос : вы не пользуетесь доверием/уважением менеджера? тогда вы не архитектор. ему без софт скиллов и умения работать с менеджерами - никак. вы уж простите.
... или у вас менеджер играет в "я начальник ты дурак"? тогда конечно швах.
можно было бы посоветовать вам поиграть в менеджерский игры вида "дай идиоту оступиться" (сделать как хочет человек, с фиксацией рисков и опасений, и формулировкой "ну раз вы платите, и рискуете своими деньгами, то пожалуйста", а когда всё пойдёт по ...медному тазу - вытащить из загашника старое письмо ), но чую этот вариант не для вас.
...
как итог ? вы - забейте.
если менеджер невразумляемый идиот, поддающийся на маркетинговые уловки - то вашему продукту пи.... ...медным тазом, в общем... он закроется. и вас менеджер , как минимум сейчас, слушать не будет.
в лучшем случае - дайте ему почитать Брукса, и скажите, что кодогенерящие нейронки - совсем не серебряная пуля. и для вашего продукта этот вариант не применим.
юзать кодоген-нейронку - это всё равно, что нанять забесценок студента второкурсника , чтобы с ним, в режиме диалога пилить сайт. если менеджер не послушает такую аналогию - то он дурак. делайте что хотите ))) дело не в вас и не в вайб-кодинге.
студентов генерящих "правильные, красивые, задёшево, идиотические решения" приводили на предприятия всегда. ну теперь вот нейронку привели, с такой же формулировкой и посылом.так что, вот так же , по аналогии и отбивайтесь.
и самое большое инфоцыганство - это микросервисы. XD))
нет, серьезно - кто-нибудь знает что это такое?
и я не про определение и теорию, я про то, что называется "микросервисом" в реальных проектах.
насколько оно соответствует определению, насколько оно действительно решает проблемы (а не приносит кучу новых)... ?
кому удается избежать проблемы "микросервисного монолита" (когда вроде и (микро)(нет)сервисы, но все перезавязано друг на друга так, что не разобрать, и в итоге боязно хоть что-то трогать, потому что не известно что отвалится)... ?
ау! кто видел курсы "по микросервсиной архитектуре" где есть пункт - "когда не надо пилить монолит на микросервисы"?))) нет такого пункта? ну тогда вы поняли.