Комментарии 254
Глубокие соболезнования вашей компании в том, что принимать технические решения и руководство разработкой доверили людям, которые не понимают элементарных принципов, на которых базируется управление качеством продукта и все смежные процессы.
Похоже, что у вас формальный руководитель, который занимает чужое место и уверен, что любая дичь ему будет прощена.
А может и не формальный, а засланный конкурентами. Мне кажется, что сейчас самый простой способ в IT-компаниях избавиться от конкурента - это через засланного казачка убедить руководство конкурента оседлать хайп AI и перейти на nocode/lowcode/vibe.
Это же классика - как MS заслал казачка а Нокию. И всё. Нокии не стало.
И всё. Нокии не стало.
А Нокия-то и не в курсе. Продала отдел мобильных телефонов и дальше себе работает.
Если вы про тот микропрыщик, который остался от всемирного гиганта, то да, работает себе.
Revenue €19.22 billion (2024)
Вы правы, микропрыщик.
Падение с 70 в 2007 до 20 в 2025. При инфляции доллара 50 процентов.
Всего-то в 5 раз упали.
Всего-то в 5 раз упали.
Альтернативная история: выкачиваем все деньги из прибыльного инфраструктурного подразделения на бессмысленное поддержание на плаву тонущего потребительского подразделения и в результате теряем все. Не знаю, как по мне - так они блестяще вышли из ситуации, сбросив проблемные активы и выйдя в стабильный плюс. Мне хочется порассуждать о том, как можно было не допустить эпических масштабов катастрофы когда-то важнейшего потребительского подразделения, но это к успешному спасению здорового инфраструктурного подразделения на самом деле не относится.
Точно бессмысленного? Нокия была царем и богом на рынке телефонов. Рынок телефонов в тех пор вырос на порядки. И этот рост уже тогда ожидался.
Я бы тоже отдавал все чтобы остаться царем и богом на рынке телефонов. Это же буквально половина всех денег мира.
А то что спасли какую-то мелочь не стоящую внимания. Почему это кому-то может быть интересно? Это небольшой ни на что не влияющий в мире бизнес. Пусть живет. Или пусть умрет. Кому какое дело?
"Нокия была царем и богом на рынке телефонов"
Только практически никто из тогдашних царей не выжил. Моторола, Сименс, Сони, Эриксон - все облажались. Выжили корейцы (лыжа и сумсанг), которые в начале нулевых были во второй-третьей линии.
А 2к лет назад Римская империя не знала себе равных.
Просто пришли два короля- Apple и Google и порвали всех в клочья, в том числе Блэкбери. У Нокии был единственный вариант если клепать андроид смартфоны. Но тогда он был бы один из многих. Будь там Элоп, не будь там Элопа- все одно, поезд уехал.
Вы же слышали про Самсунг? Они совсем не "одни из". Они держат огромный сегмент телефонов. И хорошо на этом зарабатывают.
Оправдания вида "да все равно ничего нельзя было сделать, рынок так изменился" для слабых. Проиграли рынок значит проиграли. Другим стоит учиться на их ошибках.
При этом Samsung пробовали делать аппараты на WinMobile (успешно в свое время), на своей собственной системе Bada (не провал, но и не взлетело настолько, насколько хотелось) и на Android. То есть они не ждали, что успех придет как бы сам собой, а пробовали разные стратегии. Одна из них сработала совершенно очевидно, остальные плавно сошли на нет и закрылись. Тем же Nokia никто не мешал точно так же пробовать - да они даже и пробовали, но как-то робко, а при малейшей перспективе успеха пугались и дальнейшие попытки расширить и углубить намечающийся успех немедленно работу в этом направлении прекращали.
Хорошая книжка в тему
Элоп пришел в 2010, Нокиа тогда уже упала до 56, если посмотреть график видно, что падение началось до Элопа.
А теперь погуглите в каком году айфон появился.
Хорошо, я имел ввиду их телефонный бизнес, который сошёл на нет и который, да, они продали. На телефонный бизнес и нацеливалась MS.
утверждать, что Noikia == телефончики - это такое... как Smasung == телевизоры
Второй раз, имелся ввиду именно телефонный бизнес Нокии.
Если бы кто-то развалил телефонный бизнес Самсунга, можно было бы написать "всё, и нет Самсунга", подразумевая телефонный бизнес.
В нулевых Нокиа только на телефонах и поднялись.
Это было бы не точное определение. Нокиа это компания со более чем 100 летней историей. В нулевых она просто приобрела большую известность среди обычных потребителей, за счет производства мобильных. Что в свою очередь стало возможным за счет того, что они сосредоточились на радиосвязи, начиная с 60х годов. И до бума потребительской мобильной связи они активно поставляли решения как для военных, так и для бизнес потребителей. Включая первый базовые станции для мобильной связи. Да и сами мобильные они с 80х производят.
Легко не ищется, но бОльшая часть дохода у них была от продаж мобильных телефонов.
Казачок из MS пришел в Нокию уже на пожар. На тот момент, она со своим maemo уже проиграла Apple с Айфоном и Google с андроидом
Это же классика - как MS заслал казачка а Нокию. И всё. Нокии не стало.
В тред вызывается Ведущий Мобильный Аналитик. А пока, давайте, попробуем вспомнить, в каком состоянии были Nokia на тот момент, когда начали искать спасение в сотрудничестве с Microsoft. Состояние было, иносказательно, таким: неуправляемое пике из экзосферы - поначалу запас высоты был настолько огромен, что курс на практически неизбежную коллизию почти никто не мог и точно никто не хотел видеть, а значит продолжали радостно держать штурвал от себя, по некоторым вполне объективным метрикам видя, что высота все еще огромна, и беспокоиться на перспективу ближайшего десятилетия вроде как не о чем. Второй момент заключается в том, что Microsoft искали аппаратного производителя носителей собственной (уже тогда очевидно провальной) операционной системы, к которой никто из крупных вендоров, включая значимых и успешных в свое время производителей устройств под WinMobile, интереса не проявил, а значит Microsoft точно не были заинтересованы в утоплении Nokia. Тем не менее, на тот момент Nokia уже были в тупике, глупо пропустив очевидную тогда тенденцию перехода на смартфоны - они не смогли своевременно предложить вменяемые аппараты с сенсорным экраном, а историческая завязка на Symbian, который совершенно уже не соответствовал изменившимся обстоятельствам, так и не дала возможности включиться в смартфонную гонку на равных с аппаратами на Android, который тогда тоже не сказать, что был отполирован до идеального блеска, а значит не оставлял шансов другим игрокам не просто вклиниться, а серьезно откусить долю рынка. Но этот тупик еще не был так явно заметен со стороны, да и выйти из него гигантской Nokia ресурсов хватило бы не на одну попытку. Занимательное в этой истории не то, как она закончилась, а то, как невероятно быстро она закончилась. Too big to fail Nokia по самым пессимистичным сценариям должны были упасть на дно, но оставаться в категории "другие" еще многие годы, как это было с куда как менее значимыми для рынка телефонов Sony, например.
Интересно, этот текст написан на телефоне или компе? Думаю, что на компе)
По сути же, вроде всё верно, но. Если держать всё время руль от себя, то теоретически сделаешь мертвую петлю, только головой вовне. Но казачок, навязав свою мертворожденную ОС и упорно не меняя её, поставил руль прямо точно в момент полностью вертикального падения и так его и держал всю дорогу до матушки, понимаешь, земли.
Интересно, этот текст написан на телефоне или компе? Думаю, что на компе)
Верно, на компьютере с полноразмерной клавиатурой. Так удобнее. Но так бывает не всегда, порой куда как более длинные комментарии пишутся с телефона. Значительно, несопоставимо менее удобно, но телефон - вот он, в руках, а компьютер? Компьютер стоит где-то дома на столе.
По сути же, вроде всё верно, но. Если держать всё время руль от себя, то теоретически сделаешь мертвую петлю, только головой вовне.
Вы правы. Аллегория же не обязана быть дословно верной и логически безупречной. Задача аллегории в иносказательном донесении смысла, а не в буквальной тождественности. Отсюда такие вот алогизмы.
Но казачок, навязав свою мертворожденную ОС и упорно не меняя её, поставил руль прямо точно в момент полностью вертикального падения и так его и держал всю дорогу до матушки, понимаешь, земли.
Задачи уничтожить Nokia не было, ровно наоборот. Уничтожение Nokia было крайне невыгодно для Microsoft, потому что Nokia были практически единственным носителем их новейшей операционной системы, с которой они собирались захватить рынок телефонов и на какое-то время вспыхнувших планшетов. Для Nokia в свою очередь партнерство с Microsoft давало шансы с ноги открыть дверь на изменившийся рынок телефонов, из которого они, еще недавно будучи номером один, полностью выпали. Ну а что совокупность управленческих решений вместо почти гарантированого успеха привела к уничтожению - это совсем другой, длинный и увлекательный разговор. И про гениальную операционную систему тоже. Два гиганта не смогли своей мощью продавить нежизнеспособные, неинтересные рынку решения, от чего сдулись и ушли в небытье - у Microsoft в небытье ушла разработка и выпуск мобильных ОС, а у Nokia - разработка и выпуск мобильных телефонов. Живые и здоровые подразделения остались.
На всякий случай сообщаю, что текст этого комментария написан на телефоне - нет, не на кнопочном Nokia, будь этот кнопочный Nokia хоть дважды смартфоном аж на операционной системой Symbian.
Очень много компаний, где принимают решения в лучшем случае хорошие финансисты и менеджеры и не разбирающиеся в бизнес-процессах, которые приносят компании прибыль. Сейчас вайб-кодинг ещё не так распространен, чтобы о нем знали все. Но, как мне кажется, то ли ещё будет..
Согласен. Вся фундаментальная проблема в том, что бизнес в использовании ИИ-помощников видит не увеличение доходов (вау, эта фича при текущих показателях даст нам буст 1000%), а видит как исключительно уменьшение, сокращение расходов. Концептуально. Базово. Это уже на костном уровне, в мозге. Не помощник, а дешевая замена. Основа всего получается в итоге: на этом можно сэкономить. Т.е. давайте сократим 10 программистов и заменим их на ИИ-подписку за 20$/мес. Как по мне, сколько ни встречал схожих подобных ситуаций, где начинали "резать, кроить и пороть", в большинстве случаев означался приход "эффективных менеджеров".
Чисто финансово-менеджерский подход руководителей: мы же покупаем услугу, которая дешевле, чем держать программиста. А то, что сами иногда продают "гнилую колбасу" забывают. Услуга тоже может быть не идеальна.
Да, но в данном случае у автора мир кардинально перевернулся с вайб-кодингом и с требованиями руководства:
Как виделось future в голове у автора: программист пишет код, затем скидывает в ИИ "проверь на ошибки, плиз".
Как вышло на самом деле: ИИ пишет код, скидывают программисту "проверь на ошибки, плиз"
очередное нытье деда с завышенным ЧСВ с супепупер по его мнению важным продуктом.
Обитатели плато Крюгера приветствуют отважного покорителя пика Даннинга!
Вам же остаётся чуть-чуть допилить
А вы это раньше никогда не слышали, если про дедов рассуждаете?
Фразочка-то сама с длинной бородой.
Вариант её, который мне лично сильнее всего запомнился:
- а вот я хочу работать с RedMine, мы в банке с ним работали, я к нему привыкла. Уберите ваш сервер и поставьте RedMine
- это, наверное, хорошая программа, но она использует Linux, PostregSQL, Ruby и Ruby-on-Rails. Это, наверное, хорошие программы, но каждая из них очень сложная, а я на профессиональном уровне не знаю ни одной из них, и при возникновении любых проблем не только не смогу за конкретный срок их решить, но даже не смогу понять в какой их них четырёх эта проблема случилась.
- глупости вы говорите, у нас никогда в банке проблем с ним не было! Но если вы такой неуверенный, я приглашу мужа. Он хороший специалист, он вам на сервере всё поставит, а вы просто будете ни за что получать деньги
- у вас просто отличный муж. А ещё у вас замечательная семья. Давайте так и сделаем, но ещё мы устроим вашего мужа на четверть ставки - на обслуживание этого сервера, он будет ничего не делать и ваша семья будет ни за что получать деньги!
- вы совершенно испорченный человек, с вами невозможно работать!!!
Дальнейшее было тоже забавно. Она всё же нашла, где поставить свой Redmine, и кто будет за него номинально отвечать (аутсорсник. То есть вопросы типа "не работает! все отделы стоят! Исправить за 5 минут!!!" будут равнодушно покрываться договором с "3 дня на реакцию". именно на реакцию, а не на исправление. Там тоже умеют писать договора).
Потом она запретила пользоваться старым сервером, потому что все по привычке писали туда. Потом она запретили на новом баг-трекере писать "техническую муру", потому что "директору это непонятно и не интересно. Пишите когда будет готово и кто за задачу отвечает, а мусор ваш сюда не тащите!". Но "тащить мусор" на старый сервер запретила ещё жестче.
Плакали всей маршруткой ;)
Так в результате контора закрылась то? Если нет - начальница все правильно сделала. Как удобно ей.
начальница все правильно сделала. Как удобно ей.
Это безусловно. Но зачем они она такие подлые интриги устраивала (в частности она заставила кадровичку нарушить ТК и влепить мне штраф по окладу за то, что я сорвал сроки по задаче, которая не входила в мои обязанности, и для которого другое юр-лицо мне должно было дать доступ, который - думаю вы уже угадали - дали после дедлайна).
А я все ждал, что она вспомнит, что такое быть честным человеком, подойдет и просто скажет: "увольняйся, у меня есть человек на твое место и я тебе все равно съем". Я бы уволился, не то место было, чтобы держаться вопреки замдиру. Мы оба бы съэкономили кучу времени и усилий!
Но видимо в банке людям действительно удаляют мозг и вместо него вставляют слизня...
При том, что лично она, в отличие от некоторых её фавориток, вовсе не халявщица и не дура была. В финансовой сфере она реально работала как лошадь и даже больше. Правда, нюанс, на отдельном договоре, а не на окладе.
И ещё момент забавный был. Обсуждали какие-то принципиальные, структурные недостатки проекта, и я сказал что-то вроде того, что у нас нет тех-лида для рискованных переработок проекта от самых его оснований (а там не то, что тех-лида не было... После недружественного поглощения соседним отделом нам цены в три раза уменьшили под обещание привести в 10 раз больше покупателей. На герметичном рынке, где один новый подписчик был событием... Про это даже программеры знали, а уж владельцы-финансисты обязаны были... Так что реально близко к грани работали по деньгам даже после жёстких сокращений). И прозвучало что-то такое ободряющее типа "О! Я совершенно в вас уверена. Ваш опыт однозначно позволяет вам взять на себя обязанности тех-лида!". Я в тот момент её любил, восхитительная точность формулировок!
Смешно, что пока я там был, мне со всех сторон говорили, что этот проект себя не окупает, что надо его закрывать... Меня почему-то считали каким-то секретным бойцом во внутренних интригах замдиректоров, и все пытались уничтожить, потому что "не на моей стороне? ну значит точно на чужой!"
контора закрылась то?
да нет, тилипается себе, рассказывает, как будто нейронки прикручивать к финансовым данным, и сделает самого экспертного эксперта.
там, как бы, соскакивать особо некуда. один конкурент умеет намного меньше, другой стоит намного дороже, и оно всё катится по накатанной, ну или так оно было во времена ковидные
в принципе, тот наш проект он и в лучшие дни не был основной cash cow конторы, а уж после того "обесценивания" и вовсе. Я совершенно серьёзно ожидал, что когда меня уйдут, проект и в самом деле закроют. Вот выпустят моё дембельское - и сразу рубильник дёрнут.
Что проект живым-то держали для того, чтобы я там оставался полу-программистом БД и десктопов, полу-админом, полу-веб-сайтером, полу-поддержкой. Когда вроде каждый отдельный пункт недостаточно большой, чтобы целого человека на него ставить. Закрыть этот ненавистный (якобы) проект, выгнав последнего человека из его команды, было бы самым логичным шагом, и я этого ждал. Его наработки, возможно, можно было бы раздербанить на несколько специализированных программ с одной простой функцией и системой монетизации "за каждый документ", а не "за месяц/год/бессрочно". Потому что такое уже начиналось, и вопреки моему скепсису показало себя неплохо. Логично бы было пройти эту дорогу до конца.
через полгода после моего увольнения выпустили обновление, из двух пунктов, одним из которых была половина моего дембельского аккорда. Вторую половину так и не выпустили, хотя я уходя минимум трем начальникам передал черновик договора на бесплатное, хотя и с условиями, использование чужого API. Видимо, этот черновик очень мешал продолжать просвещать директоров про "самого бесполезного человека в компании". А может быть я слишком хвастаюсь, но когда тот самый директор перед моим увольнением проходя мимо спрашивал, чем я занимаюсь, и я сказал что вот почти готовы две новые фичи, у неё лецо знатно перекосилось, и она тогда быстро перевела разговор на важные и неотложные срочные проблемы :-) Подозреваю, что они так и осталась в исходниках и в бинарниках, но в скрытом состоянии.
Ещё через год был релиз, в котором, я подозреваю, была наконец сделана видимой функция, которая там была уже лет 5 (поддержка Libre/Open Office), но которую запрещали делать видимой, чтоб не пугать и не путать пользователей. Хотел скачать и посмотреть по обоим пунктам, но обнаружил, что начисто забыл внутренние пути WWW-сервера, по которым всегда можно было скачать релиз "без СМС и регистрации", а имевшиеся у меня материалы компании я на самом деле стёр в день увольнения. Так и осталась эта небольшая загадка навечно неразгаданной.
Последнее, что я слышал - ещё раз, это всё про проект, который "даже тебя одного не окупает, в убыток работаем"! - звонок с просьбой подсказать, как его собрать без HASP-защиты, чтобы продавать для Линукса. Не думаю, что у них это получится, но если им не жаль пытаться - мне тоже не жаль.
Специфика жанра .. Всё огорожено, никаких новых конкурентов. Ваши фичи начальству не нужны, им и так есть что на крутон намазать.
вою, рыдаю, огорчаюсь, смиряюсь... И все равно не понимаю.
подлости-то зачем делать и людей подставлять?
я ведь на тот момент уже задокументировал несколько нарушений ТК, оставалось только заказное на почте оправить. Если бы не выдали налом украденное на окладе - отправил бы. А отвечала бы в первую очередь трудовичка, которая эти нарушения исполняла. Неплохой, в принципе человек, хотя "мне приказали" не оправдание. А потом, возможно, пришлось бы отмазывать бузгалтершу и на взятках отдать больше, чем украли у меня.
И вся эта дрянь вместо того, чтобы после корпоратива новогоднего сказать мне "уходи, у генералов есть свои дети" и я бы гораздо проще и даже быстрее ушёл.
Нет, опыт по своему интересный был, и пару анекдотов утащил для маршрутки. Но - не понимаю :-) "Зачем делать сложно то, что проще простого?" :-)
Рукавлицо
Нельзя строить интерфейс без четких требований и продуктовых ожиданий.
можно, четкие требования это миф. Это перекладывание ответственности и работы UX архитектора на другую сторону
Нельзя, чтобы интерфейс строил дизайнер по принципу "я так вижу и так нейронка закодила" - а потом уже команда подстраивалась под созданный от балды интерфейс.
С 1 стороны вы правы, нельзя. С другой моя команда ровно так часто и делает, хотя я могу объяснить пару сотен решений детально, но переварить это все равно люди не смогут быстрее чем за пару месяцев
Давайте так - иногда так делать можно. У меня комментарий чуть ниже, я сам честно признаюсь, что, например, внутренние админские интерфейсы сплавляю делать нейронке.
С другой стороны - вам НУЖЕН архитектор/лид, чтобы он сказал, где так можно делать, а где нельзя. В хорошей, осознанной команде, где все понимают риски, иногда можно не слишком строго соблюдать границы, но в общем, это редкость, и все равно должен быть человек, который отвечает за решения - и это вряд ли UX-дизайнер (если он не лид, конечно, мало ли, может, продукт от интерфейса пляшет)
Ага, наша команда тоже часто так и делает, но почти всегда потом получает по лбу этими граблями: "ок, реализовано то у нас вот так, а как надо было?"
Вы работали с АСУ ТП системами? После них дизайн любой дичи вам покажется милым зоопарком.)
...про хайп, что бы довести до абсурда нужно вайбкодинг внедрить на каких-нибудь чувствительных АСУ ТП, АЭС например - мигом поубавится рвения для внедрения "новых фич" с конкретной фамилий автора-руководителя)
Вот вам карта, Билли!
Очень печально.
У меня проект по предоставлению доступа к зарубежным LLM, и я сам по факту много использую их для программирования на прод... внутренних админских инструментов и микросервисов типа "одна функция нужна". Мне, как специалисту с 20-летним опытом, очевидна грань между работой "красиво" и "устойчиво и прозрачно".
Чтож, хотя я обычно негативно смотрю на то, что кодинг с LLM называют хайпом, после этой истории вынужден признать - внедрение LLM по маркетинговым материалам без консультации со специалистом по ИИ может реально разрушить существующий продукт и процессы. А почему? Потому что техдир/продакт и пр. не может наступить себе на самооценку и сказать "Я не специалист по ИИ, может, найдем хорошего эксперта?" Не-е-ет, сольем пару месяцев команды за несколько лямов рублей, но эксперта искать не будем...
Можно программировать на прод, используя LLM, только соблюда гигиену. Только придерживаться парадигмам тестирования и использовать контуры DEV -> TEST -> PREPROD -> PROD. Но менеджеры всё время гонят, гонят time2market и некоторые этим принебрегают.
Да, но я бы использовал нейронку для локальных кусков кода. Имхо с позиции моего опыта - архитектуру сложного приложения ей давать нельзя.
А по моему опыту и с локальными кусками так себе выходит. Но мне помогает гуглить "то не знаю что", в т.ч. образцами кода, которые я в 95% случаев полностью переписываю в итоге (хотя иногда у меня таки поднимается бровь, когда оно что-то вменяемое действительно генерит).
Ещё у меня коллега мой код ревьюит в т.ч. с помощью chat gpt. И я вам скажу, выходит неожиданно круто.
Вероятно есть истинная причина. которую не озвучивают: владельцы бизнеса ищут способы быстро вернуть свои инвестиции, а приходится содержать зрелую команду хороших специалистов, которая пройдя огонь и воду вывела продукт на плато стабильности. Теперь надо сократить расходы на ЗП, а для этого надо заменить суперзвезд на спецов подешевле, для чего надо внедрить новую "подходящую" хайп-технологию.
Поэтому у вашего босса есть кредит доверия, что бы проталкивать эту фигню. К сожалению это неизбежный этап и вероятно они своего добьются. Так что...
Мы дошли до той редкой точки (не побоюсь этого слова! (с)), когда команда не тушит пожары, а развивает систему (спасибо мне, хорошему, что не шёл всегда на поводу у продакт менеджеров).
И потом вот:
У нас одна часть проекта на PHP, другая на FastAPI (Python), фронт на VueJS.
Перевожу: "Я великий, уникальный, никем не понятый, очень крутой разработчик, программист. Хочу быть незаменимым. Хочу, чтобы бизнес от меня зависел. Хочу, чтобы кланялись и просили. А я бы с умным видом выбирать что и как делать. А тут бизнес решил заменить говномонолит из костылей на что-то, а баба-яга против!
И почему Вы собственно решили, что он из костылей? И почему Вы обзываетесь на монолиты - монолит это не обязательно зло, если он хорошо отлажен и работает как часы. И потом, часть высоконагруженного кода у нас вынесена в микросервисы, а в остальном - всё ок, работает как по "феншую".
А насчёт бабы-яги, то да - против. А что, всёгда нужно "за", если бизнес так решил?
Монолит по определению не может быть одновременно и на PHP, и на Python ¯\_(ツ)_/¯
И, кстати, заставить подобный зоопарк работать - нужно быть достаточно неплохим спецом. И менять работающее приложение, пусть даже оно и "говномонолит из костылей", на что-то новенькое бизнесу никто запретить не может. Тут просто стоит вопрос - под чью ответственность :)
Да и вообще, если вдруг бизнес решил самовыпилиться таким экзотическим способом - флаг ему в руки!! Я бы уже начал искать другой аэродром, а ТС, вон, старый ещё пытается спасти.
Я не сказал, что у нас монолит и на PHP и на Python одновременно. У нас ядро на PHP (это монолит, да, но разбит на модули), а на Python основной отдельно стоящий сервис. Взаимодействие между ними через API. Плюс, есть микросервисы для высоконагруженного кода. Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
С бизнесом у меня отношения простые - его задача прибыль, но! не в ущерб инженерии, а в остальное ему нос совать не нужно. У меня у самого был свой бизнес, поэтому челом бить перед ним я не собираюсь. Просто очень часто плохую работу отдела продаж пытаются компенсивать за счёт издевательства над разработкой - типа тут результат можно почувствовать гораздо быстрее. В этой плоскости собственно драма и развивается.
Но Вы правы - запретить бизнесу самовыпилиться - никто не может. Я уже начал обновлять резюме.
Я не считаю такой "зоопарк" чем-то необычным
В чем тогда принципиальное соображение против добавления Lovable ? В зоопарке может быть больше 2 животных.
Мы бы больше сочувствовали бы автору статьи, если бы у него уже не было зоопарка. Но в данном случае у него уже есть зоопарк, он научился за ним ухаживать, но категорически против нового животного, т.к. "у нас и так все хорошо", а это новое "ходит не так, кушает не то, рычит по другому".
И еще вопрос - а почему раньше автор не был против зоопарка? Почему это случилось именно сейчас?
У Вас серьёзный аргумент. Конечно, частично это так, я привык к своему зоопарку и пытаюсь отбрыкаться от новых экзотических животных. Но в оправдание скажу, что этот зоопарк достался нам в наследство и его архитектуру разрабатывали не мы. Я лишь потратил более 3-х лет, чтобы привести его в нормальное рабочее состояние и выстроить все процессы фактически с нуля. Не только в команде, но и между различными отделами.
Раньше он был гораздо более "зоопаркистей" - это легаси... и легаси очень древнее. С другой стороны - с легаси можно жить, а вот с тех.долгом - весьма сложно. Поэтому пару последних лет у нас ушло на уничтожение сорняков - годами копившийся тех.долг, огромный бэклог багов, очистку авгиевых конюшен в виде огромных пластов "мёртвого кода" и написание сотен страниц технической документации. И это совершенно потрясающий опыт, имеется ввиду - приведение легаси в рабочее состояние. По факту - это наш "бэби" (мой и моей команды), поэтому я и принимаю в штыки любую попытку опять всё вернуть в состояние хаоса.
Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
Вот и ответ, "почему монолит". Тем более, "созревший". И тут надо смотреть на стоимость переделки (новые хотелки, новые законы итд) и стоимость просто поддержания работы при росте нагрузки. Представь, что каждый месяц клиентов х2 (для понимания, это прогрессивная шкала). Через сколько кончится ваш сервер с монолитом? Через сколько кончится "топовая" железка? И что дальше? У меня такой опыт есть. (веб, фронт+бэк в одном). Где был 1 сервер с монолитом, их уже 20, раскидывание по ендпоинтам "этот набор запросов сюда, этот туда", через nginx, апстримы - минимум по 2 сервера, за счёт одного кода можно балансировать (что-то у нас этот блок перегружен, докинь сюда пару серверов незагруженного блока)
Живём? Нет, самое слабое место уже давно стала БД. Добавляем proxysql, все запросы на чтение без предварительной записи кидаются на слейвы, их можно поднять хоть 100, но мастер тоже не бесконечен. Плюс нужен dba, контролирующий запросы, индексы итд.
Но проблема понятна была уже 2 года назад, и идёт постепенный распил на микросервисы, часть уже вынесена, что позволило чуть меньше беспокоиться. Правда, база по прежнему одна, но и в этом направлении продавливаю изменения.
Чел, ты немного устарел. Монолиты снова в моде, так как с микросервисами наигрались ;)
Перевожу: "вы все дураки и не лечитесь, а я одна умная, в белом пальто стою красивая".
Может пора менять работу? Продукт есть и стабильно развивается. Зоопарк тот ещё. Найдя новый проект принесёшь больше пользы и научишься чему-то новому.
Команда большая, стоите дорого, фичи пилите медленно.
Да, отгонял эту мысль долго, но похоже нужно начинать готовить почву для следующей станции
Для начала все-таки стоит попытаться донести свои мысли до начальства. Расписать плюсы и минусы, собщить во сколько компании обойдется утекшая база или верчно ломающийся прод, а также дикий неподдерживаемый говнокод из-за которого разбежится вся команда. Объяснить границы преминимости инструмента.
Я не написал это в статье, но я пытался это сделать: и объяснял и уговаривал и приводил доказательства. Увы, тяжело логикой переформатировать головы людей, влюблённых в вайб-кодинг. Да им и всё-равно - я уйду, а они останутся.
Да я сам влюблен в вайб кодинг. Но одно дело это прототип или пет проект, а другое дело большой стабильный проект,
Сейчас много историй как ключи утекают или счет потом сливают в минуса в навайбкоденных проектах. Возможно стоит подкинуть таких историй для размышления.
У вас же есть техдир или это вы и есть? Техдир должен принимать это решение а не CEO.
что он принесёт? код на PHP🤡?
Хоть и избито уже, но добавлю. По приданию, во времена золотой лихорадке больше все обогатились производители лопат.
Так и тут, На всех хайпах в айти, больше всего вижу появление всяких фирм, которые предлагают какие то чудо утилиты, которые обязательно перевернут процесс программирования. На рубеже веков это были визуальные редакторы кода. Это типа когда не надо писать код, а только мышкой диалоги собираешь, ну и код можно писать, если хочешь. Потом выясняется, что код не можно, а нужно писать. Figma вот, хорошо забытое старое.
Про блокчейны и ICO так вообще добавить нечего. Смартконтракты и прозрачность должны были решить вообще все проблемы в мире. От учета монеток, до владельцев произведенных банок сгущенки.
Потом вот помню бум стартапов, которые рождали всякие проекты, которые почему то не решали какие то прикладные задачи, а больше порождали проекты призванные чего то то там улучшить в программировании. Мне кажется тогда стали модными хакатоны. На выходных завайбкодил поделие, привлек инвесторов и свалил в закат на свой остров.
Сейчас вот ИИ способное по запросу выдать код змейки или даже крестики нолики. И это будет даже работать. Имхо, почему бы в git-e не хранить историю запросов и сидов, в место кода. Экономия места же! :) Причем, через год обновили модель, она на тот же самый запрос выдаст более оптимальный и более безбажный код, с современным интерфейсом. Не надо ничего переписывать, не надо оптимизировать. Код и продукт эволюционируют со временем. Это же вообще сказка :)
Не мудрено, что и ИИ бум рождает чудо инструменты, которые решат все ваши проблемы. Главное пережить время бурления, а там и новый бум подберется со спины.
Не подсказывайте им...
Имхо, почему бы в git-e не хранить историю запросов и сидов, в место кода.
Потому что промпты сами по себе не описывают состояние, а описывают запросы на изменение.
Возможно скоро появятся какие-то промпто-подобные способы описания текущего состояния приложения. Чтобы из набора фраз "А теперь добавь кнопку!" "А теперь перекрась её в зеленый" генерировалось состояние "Зеленая кнопка слева по центру", из которого уже потом будет генерироваться полное приложение.
По приданию, во времена золотой лихорадке больше все обогатились производители лопат.
По "преданию".
На всех хайпах в айти, больше всего вижу появление всяких фирм, которые предлагают какие то чудо утилиты, которые обязательно перевернут процесс программирования.
Имхо, это все же не лопаты. Лопатами можно было копать и добывать золото. Это были работающие рабочие инструменты.
Современный хайп ИИ у нас вызывает больше ощущения "посоленого рудника", застолбили рудник, насобирали там немного золота (или добавили) и продают как будто там исследованная золотая жила без каких-либо проблем.
В некоторых случаях покупка такого рудника реально оправдана (и тогда можно сбабахать сайт за пару недель с затратами в 10 раз меньше и рубить бабло, пока конкуренты год пилят сурьезный проект), но во многих выливается в эпик фэил (и что самое обидное - выясняется это уже в конце пути, когда время и деньги уже потрачены).
. На рубеже веков это были визуальные редакторы кода. Это типа когда не надо писать код, а только мышкой диалоги собираешь, ну и код можно писать, если хочешь.
В итоге блюпринты стали вполне нишевой штукой в дизайне и геймдеве, почему бы и нет? Мне (и многим другим) удобнее собрать воркфлоу из нод в ComfyUI, чем писать такой же код на питоне и потом постоянно рыться в папках, пытаясь найти что в итоге сгенерилось.
Наш начальник показывает нам на собраниях как он сам (sic!) "запилил" за пару дней крутую фичу, остаётся только интегрировать её в основной продукт
А теперь пусть выкидывает
Если ведёт себя как джун, пусть получает критику как джун
Это очень по менеджерски: закрыть ладошками глаза и повторять: "не вижу проблем, не вижу проблем"
Как по мне, у nocode подхода слабая проработка. Он может и займет свое место когда-то, но пока:
Удобная отладка и отладчик. В обычном подходе это решено, в nocode в зачаточном состоянии чаще всего. Условный возврат к отладке принтами и бесконечным логом.
Контроль за форматом передаваемых данных. Очень часто есть какая-то блок-схема алгоритма, между блоками подразумевается передача данных, а какие там данные и в каком формате - не видно. Упражнение "попробуй собери из всех вышестоящих блоков операции присвоения и запомни".
Инструменты снижения ошибок. В nocode чаще всего отсутствуют области видимости переменных - т.е. будто все переменные глобальные - и ведь когда-то так было и в обычных ЯП, но ушли, уж очень много неявных ошибок это порождает.
Инструменты управления сложностью кода и навигацией. Для обычного подхода придумали разделение на модули/пространства имен/классы с очень быстрыми переходами. Придумали разделение MVC. В nocode же часто - это бесконечных размеров блок-схема. Встречал блок-схему в 6 экранов в ширину и 10 в высоту - и вот кликаешь на ней "развернуть условный переход" - а потом минуты ищешь, куда-же от него ветки развернулись.
Контроль роста потребления ресурсов. Для обычного подхода есть много раз разобранные структуры данных с быстрым поиском/вставкой, разобранные практики, как плохо. Без этого nocode решения часто притягиваются к алгоритмам O(n^2) и поэтому при выходе из прототипа, когда n вырастает в сотни-тысячи раз - это проще выкинуть и переписать.
Системы контроля версий. Они все разрабатывались для текстов. Сравнить 2 участка кода и показать изменения - не проблема, трехстороннее сравнение - не проблема, а вот сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема.
Без этих инструментов проблематично удержать сложность сколь-нибудь большого проекта.
сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема
припоминаю в эпоху популярности WYSIWIG-редакторов UML-диаграм (типа Rational Rose и проч.) похожая проблемка всплывала - только часть из них умела сохраняться в струкрутированный текстовый формат (обычно самодельный), но и в нём были автогенерируемые служебные идентификаторы (типа GUID'ов), которые обновлялись при каждом чихе, так что diff между соседними версиями выглядел "полосатым" на весь экран.
По идее nocode-диаграма тоже может в текстовый файл сохраняться, наработки есть же. Правда, разницу глазами в таком формате может быть неудобно смотреть.
Все эти визуальные игры заканчиваются тем, что визуал - обычно плоские схемы, а структура ПО минимум трехмерная по ощущениями, а то и 10^n-мерная по своим вложенностям.
а вот сравнить 2 блок-схемы и как-то показать это для выбора разработчику - проблема.
Идея для стартапа! )
А что за "нажал и оно развернулось"? Мне такое очень нужно
Идея для стартапа! )
Так себе идея то. Я тут согласен с TemaAE, что как-то показать различия получится в трехмерности. И даже тут идея далека от инженерной - скорее она на стадии исследований. И в конце будет "чтобы кодить на нашей суперплатформе за доширак нужно докупить VR и GPU обвес эдак на пару тыс уе".
Плюсом в коде мержить помогает его структурированность, которая сейчас либо отсутствует в схемах, либо в зачаточном состоянии - визуальный инструмент не перепрыгнет это ограничение, надо в любом случае вводить структурированность в блок-схемы.
А что за "нажал и оно развернулось"? Мне такое очень нужно
Ветки условий у if. Но отображение этого немного жертвует честностью, т.к. если свернуть все ветки, то низ схемы уже показать не выйдет, т.к. к нему входящее соединение будет из ниоткуда.
Для циклов норм подходит. Т.к. его можно представить как связанные блоки в начале и конце тела цикла, и между ними удачно все скрывается.
Вам бы с этим текстом- да к руководству повыше того придурка-любителя "но-код-программирования"- к тому, кому есть дело именно до бизнеса, а не до своих бонусов за то что "внедрил и ускорил".. но скорее всего этот товарищ хорошо умеет в уши лить, раз с таким подходом до сих пор при должности..
В общем- всё печально, сочуствую.
Low code для коротко живущих ad-hoc фич и точно не для core, только стандартные решения (кастомизация это очень дорого) и без возможности сопровождения или развития (проще сделать заново).
Если начальник понимает это, то ок.
Я навидался low code систем разных поколений. Всё одно и то же.
Low code для коротко живущих ad-hoc фич и точно не для core, только стандартные решения (кастомизация это очень дорого) и без возможности сопровождения или развития (проще сделать заново).
Ну мы на low-code делаем ERP-системы на lsFusion для розничной торговли (вот демка). Уже 10 лет. И прекрасно все кастомизируем под разных клиентов, имея при этом базовую версию. У самых крупных клиентов 2000 одновременно работающих пользователей, миллиарды записей и базы под 10ТБ. Что мы делаем не так ?
По-моему, тут дело не в no-code ни разу. Если вы не можете договориться с менеджментом насчёт стабильности и стоимости принимаемых решений - делать в этой компании нечего. Не сломаются об no-code, сломаются ещё обо что-то.
У каждого решения есть стоимость: сейчас Вы описали, что внедрение новой технологии стоит "2 года и 2 миллиона долларов". Если бизнес считает, что это надо сделать за 2 дня и пачку доширака - вы вряд ли договоритесь.
Но если Вас всё же готовы слушать - имеет смысл доносить в терминах бизнеса: да, мы снижаем ttm, но бэкенд становится дороже вдвое, а стабильность падает, дорожает QA. Если бизнес вдруг и такое устраивает - жмём друг другу руки, нанимаем 2-3 новых отдела и с готовностью принимаем "новые вызовы".
Видимо, для ad-hoc аналитики, 342й формы отчётности или 191го способа расчета скидки на акции low code годен. Но только там. При грамотном расчёте это всё видно (не прогнозе, а разборе результатов за год)
нанимаем 2-3 новых отдела
Вы все перепутали. Не нанимаем два отдела, а увольняем половину отдела.
Вам же Главный Начальник сказал: "Вам же остаётся чуть-чуть допилить"
А если вы сделаете вид, что с этим не справились, то значит вы не профессионал, а луддит и саботажник. У каждой проблемы должно быть приятное и удобное имя и фамилия, они ваши
работаю на большом проекте, которому уже под 20 лет. сотни тысяч строк кода, десятки тысяч закрытых воркайтемов, пофикшеных багов.
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
разработка новой фичи - надо знать как заюзать существующий код, чтобы не изобретать велосипед и не копипастить.
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
ИИ должен стать архитектором и техлидом на проекте, чтобы эффективно работать. пока же нейронки явно не готовы для этого.
и вот хоть убей не представляю как на таком проекте можно использовать ИИ.
для любого изменения нужно понимать архитектуру и код проекта
Не надо делегировать LLM архитектуру. Для архитектуры есть собственная живая нейросеть, обычно неплохо работает.
LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.
Для начала неплохо бы написать юнит тест который этот баг воспроизводит. Если сам уже понял шаги - заставить LLM сгенерировать код юнит-теста не проблема.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
Повторить пункт два до тех пор пока LLM и ты сам не поймешь и не убедишься в чем баг
Дальше просишь LLM сгенерировать фикс, можно для верности уточнить какой фикс ты хочешь
Профит.
LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."
вот именно что я не могу представить себе таску, которую я могу вот так описать. разработка - всегда постепенный процесс.
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор. это нафиг не надо, это времени не занимает. основное время на большом проекте занимает внедрение фичи в существующую архитектуру, поиск зависимостей, рефакторинг существующего кода.
Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".
"фигануть дофига" это конечно хорошо, но как я уже писал в фиксе бага главное анализ истории изменений, а не сделать так чтобы он не проявлялся.
например если это креш изза доступа по null reference, недостаточно поставить проверку на null, я такой фикс обычно не пропускаю, надо понять почему раньше работало, а сейчас появился этот null.
типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там.
У меня эта картинка уже на макросе
пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор
Это рутина, зачем набирать код самому если это может делать LLM. Просто из за хейта LLM? Меня на 90% устраивает кодярник от LLM, я 50 строк кода набираю медленней чем несколько фраз.
это нафиг не надо, это времени не занимает
У меня написание юнит тестов занимало довольно существенную часть времени. Намного больше чем написать "сделай тест который проверяет кейс с такими-то шагами".
в фиксе бага главное анализ истории изменений
Чтобы не нужно было делать "анализ истории изменений" люди пишут юнит тесты. Которые отломаются если вы сломаете полезный функционал. И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Это рутина, зачем набирать код самому если это может делать LLM.
Чтобы не превратиться из человека в безмозглый придаток БЯМ, например. Кончится инторнет и всё, вайб-кодер превратился в тыкву.
И не зачем руками историю поднимать и думать "ой зачем же он так сделал".
Действительно, зачем думать?
Действительно, зачем думать?
«Не надо думать — с нами тот, кто всё за нас решит!» ©
Чтобы не превратиться из человека в безмозглый придаток БЯМ, например. Кончится инторнет и всё, вайб-кодер превратился в тыкву.
А против этого сценария надо присматривать локально развёрнутые LLM и видеокарту помощнее.
А я вот прямо сейчас наблюдаю, как хорошие в прошлом разработчики, подсев на LLM (в частности из-за того, что менеджмент форсирует скорость разработки), начинают терять навык критического мышления и не могут решить элементарную проблему самостоятельно (когда LLM тоже не помогает). И это очень пугает, так как я ожидал, что подобное может произойти где-то в будущем, но не думал, что даже текущие синьоры начнут так активно деградировать. Наблюдаю это в организации с более чем 2000 разработчиками, так что выборка неплохая такая.
Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
как не пишите код на ассемблере, а пользуетесь одними компиляторами?
переход на компиляторы не забрал алгоритмические задачи с разработчика. Да и и с переходом на компиляторы и сам вектор того же дебага поменялся. Редко когда вы одновременно использовали компилятор, но возвращались в ассемблер для дебага и т.п.. То есть, ваш пример будет работать, когда разработчики смогут 100% переключится в AI как среду для разработки / отладки. Тогда сменится и парадигма самой работы и мышления под эту работу.
Интересно, как же их держат на работе если они "деградировали и не могут решить задачу"?
Никогда не работали в энтерпрайзе? Ну и как, держат десятки тысяч индусов, которые пишут спагетти-код, работающий буквально на честном слове и на пределе серверных мощностей? Кодовая база через пару лет становится настолько нечитаемой, что проще всё переписать с нуля, чем пытаться что-то исправить.
В результате код, который при хорошем подходе мог бы служить основой 10–15 лет, устаревает уже через 3–4 года. Просто из-за решения менеджмента сэкономить и использовать дешёвые ресурсы — будь то недорогие индусы или, как сейчас, AI. Потому что большинство менеджеров в современном мире ориентируются на годовые результаты: сэкономили в этом году миллион — отлично.
Они не думают(ну или все же думают - но такие уж правила игры) о том, что через два года из-за этого решения операционные издержки вырастут на тот же миллион в год, а через пять лет придётся вложить 2–3 миллиона в полное обновление. Это уже будет “проект”, на который выделят деньги, и никто даже не задумается, что никакого проекта не потребовалось бы, если бы изначально не пытались сэкономить.
Это комплексная проблема. Я сейчас смотрю на AI как на замену индусам для MVP. Видел это ещё в конце нулевых и в десятых: клиенты нанимали индусов, те быстро набрасывали хоть как-то работающий продукт, а потом, если бизнес выстреливал и требовал масштабирования, наступал затык. Индусы исчезали, а разработка отдавалась западным разработчикам, которые всё переписывали с нуля.
Есть у меня и примеры, когда код изначально писался по всем правильным принципам, но потом передавался в поддержку дешёвым командам — и за 1–2 года код просто убивался в ноль.
Поэтому все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки. И не стоит потом удивляться, что на собеседованиях всё равно будут проверять реальные навыки программирования, а не «вайб-кодинг» — и вы просто не сможете пройти такое собеседование.
переход на компиляторы не забрал алгоритмические задачи с разработчика. Да и и с переходом на компиляторы и сам вектор того же дебага поменялся.
Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов, целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Переход на вайб кодинг так же не забирает алгоритмические задачи с разработчика, вам по прежнему нужно понимать какой алгоритм вы хотите, нужно мочь объяснить это LLM, нужно понимать что вам нагенерировали, как оно работает какая тут сложность и т. д.
Просто из-за решения менеджмента сэкономить и использовать дешёвые ресурсы — будь то недорогие индусы или, как сейчас, AI.
Не надо смешивать мухи с котлетами. Желать менеджеры могут что угодно, мы сейчас не на стадии когда LLM заменят разработчиков. Мы сейчас на стадии что LLM это инструмент для разработчиков.
Я сейчас смотрю на AI как на замену индусам для MVP.
Не правильно смотрите. Генератор MVP это лишь одно из применений. Другое применение - это инструмент для разработчиков ускоряющий написание кода.
все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки
У вас очень странное представление об LLM. В вашем мире есть две крайности. Крайность 1 - я луддит разраб и всё пишу руками. Крайность 2 - я тупой менеджер и отдал разработку некоему "AI".
По 1-му пункту - ну ок каждый пишет как он хочет но зачем? LLM тупо экономят время, писать те-же тесты руками - зачем, карл, зачем???
По 2-му, сейчас нету полноценных "AI" которым можно "отдать разработку". Ну ок тебе пообещали что некий "AI" заменит всю команду - ну уволь свою команду и купи мега-про-подписку, но нет, начинается какая-то х*ня описанная в статье когда "AI всё сделал надо только пофиксить мелкую багу"
конвенции вызовов,
Смеюсь. Как раз потребовал знать.
Вот в ассемблере их знать не надо. Как хочешь - так и делаешь. А в компиляторах ты должен уметь прочитать объявление функции и несколько флагов компиляторов и по ним распознать что и куда будет помещено при вызове функции. Иначе на первом же вызове DLL можно словить очень интересные эффекты. Особенно, если она написана на другом языке.
Тот же COM/Automation, ошибки в вызове какой-нибудь функции Excel можно искать весьма долго, если не знать, как оно должно работать "внизу".
Нет, конечно в Hello World всего этого не нужно. Но для того оно и в ассемблере не нужно. Один макро-вызов и всё.
...и это я еще не сказал про ошибки в библиотеках и самих компиляторах. Вот их без "CPU panel" отловить иногда на порядки сложнее, чем сверить команды процессора с тем, какие должны были быть.
архитектуру процессора
Из недавнего. Комитет C++ исключил из стандарта слово volatile и потребовал от комитета C сделать то же самое (иначе обратная совместимость нарушится). Программисты всяких embedded-железяк на Cи взвыли - у них там половины программа на этом слове держатся. В ответ на что им сказали, что слово это было временной заплаткой и кое-как работало на тупых компиляторах и тупом железе 1980-х, а сейчас и то и другое стало умным, и это слово перестало по факту работать. На что эмбедщики сказали, что с железяками работают они, и если бы прямо вообще все сломано, то они первые бы заметили.
На самом деле весьма интересная дискуссия, стоит чтения просто из общего интереса. Как раз и про компиляторы и про архитектуры.
А ещё есть всякий там gamedev с его упарыванием по cache locality...
Ну и еще можно вспомнить про возврат значения из функции, через return (в C и более поздних) или привоения функции (Фортран, а из него Бейсик и Алгол-Паскаль). Казалось бы, чистой воды абстракция и вкусовщина, а на само деле прямое отражение архитектур тогдашних компьютеров. Впрочем, практической пользы такая археология, в самом деле, наверное не несёт.
целую кучу разных оптимизацией
...убило развитие процессоров: теневые регистры, суперскалярность и внеочередность и прочее обумнение когда-то простых железок. Так что старые оптимизации внезапно стали затормаживать программы, хотя лет 30 назад ускоряли.
и целую кучу специализированных алгоритмов.
...убило появление стандартных документированных библиотек. Не было бы библиотек - писали бы вы те же алгоритмы на модных новых языках. Есть библиотека - не надо знать про алгоритм, вызывай готовую функцию. И опять же, без разницы откуда вызывать, из ассемблера, плюс-плюса или шарпа.
Вот в ассемблере их знать не надо. Как хочешь - так и делаешь.
Ага, а расскажите пожалуйста как это самое "как хочешь" будет потом работать при линковке с другим бинарем написанным другим разрабом который тоже делал "как хочешь". Сейчас вы можете extern C написать и ни о чем не думать. И это еще без учета разных архитектур где вообще всё по разному, сейчас вам ваш тулчен соберет что под x86 что под arm, а раньше это всё руками приходилось переписывать.
...убило развитие процессоров: теневые регистры, суперскалярность и внеочередность и прочее обумнение когда-то простых железок.
Зачем ходить глубоко? Возьмите те-же inline, rvo (nvro), оптимизация хвостовой рекурсии, сейчас это всё компилятор делает. Раньше вы сами это были вынуждены делать руками. Если вы написали функцию в которую вы идете через call никакой ассемблер вам её автоматом на инлайн не подменял.
Сейчас вы можете extern C написать и ни о чем не думать
какая милая добрая уверенность...
если не ошибаюсь, zlib под win32 (или ssleay, или еще кто, не помню) собирается в трёх не совместимых по ABI вариантах, и все они типа extern "C"
Как раз extern "C" вот вообще ничего про конвенции не говорит, а только отсутствие name mangling
Так-то во всех стоящиx рассмотрения макроассемблерах есть аналоги extern "C". Более того, есть даже макросы для ООП-вызовов. Любители под win32 графические программы на таких пишут, по сути такая ассемблерная программа почти не отличается от старого способа написания Win32/C++, где разбор сообщений делался мега-switch'ем на препроцессорных макросах.
при линковке с другим бинарем написанным другим разрабом
да как и со своими функциями - берем ассемблерный исходник этого другого бинаря, смотрим по каким регистрам и адресам памяти он распихал параметры, и повторяем в точке вызова
или вы хотите сказать, что тот другой бинарь писался не на ассемблере? но тогда это как раз мой пойнт! именно появление компиляторов (в той другой либе) вместо асма заставило вас учить конвенции выхзова
Раньше вы сами это были вынуждены делать руками.
Да, но я не считаю, что это "убило оптимизацию", я считаю ровно наоборот.
На асме я её или пишу или нет. Нет даже самого понятия хвостовой оптимизации! либо я запилил цикл (которым хвостовая рекурсия является) - либо не запилил. Мне просто нафиг не надо знать, что такая теоретическая концепция бывает. Я циклы пишу. Или не пишу.
Максимум мне нужно освежить школьный урок про переписывание рекурсивный функции в цикл, но я в свое время и сам догадался, тут ничего сверхсложного.
Все просто и определённо, или я написал цикл, или нет.
А вот именно в случае с компилятором мы начинаем играть в лотерею. То ли захочется компилятору оптимизнуть, то ли не захочется. И так в сотне мест программы.
В зависимости от левой пятки компилятора у меня теперь - именно теперь, а не на асме - может получиться 2^N разных программ из одних и тех же исходников.
И вот именно теперь - именно из-за появления компиляторов и привносимой ими случайности! - мне надо знать про существование таких оптимизаций, потому что неопределенность повысилась в разы, и чтобы бороться с неопределённостью (или не бороться, там где не мешает) мне нужно знать, откуда может прилететь неожиданная чужая модификация программы. И какие у неё могут быть последствия. И стоит ли про это думать, или последствия неожиданных изменений моей программы в данном конкретном месте меня не огорчат. И вот чтобы все это понимать теперь мне надо учить возможные типы оптимизаций, чтобы оценивать в какое месте программы какая бомба может прилететь, и где нужно заранее строить защитный бункер, а где пусть прилетает не жалко.
Как раз на асме всего этого нет. Там правда и много чего другого нет. Поэтому в целом компиляторы выгоднее, само собой. Но эта выгодность имеет цену. И одна из частей этой цены, что теперь сборка программы стала случайным процессом, и чтобы контролировать эту случайность надо учить типы оптимизаций вообще и конкретно под использованный компилятор.
если не ошибаюсь, zlib под win32 (или ssleay, или еще кто, не помню) собирается в трёх не совместимых по ABI вариантах, и все они типа extern "C"
Вот чтобы не иметь себе мозги и делают более высокоуровневые языки. Но конечно есть люди которым нравится мозго*ство, у них еще и утиный синдром обычно они предпочитают заниматься им на том уровне который был когда они входили в профессию, а каждый новый уровень считается "для лохов" и "деградацией".
какое счастье, что в большинстве языков это всё знать не нужно..
Ну да, в других языках сжатие делается с помощью магии.
в большинстве языков это всё знать не нужно..
«В наше время этим не гордились!» ©
Обязан ли водитель знать досконально устройство всех видов двигателей и коробок?
Так и тут, есть задачи "движок перебирать", а есть "каждый день перемещаться из точки А в точку Б". Это про разное, и механику для переборки двигателя ПДД не важно например. У всех своя сфера, не стоит обобщать по своему опыту всех.
Переход с ассмеблера на высокоуровневые языки забрал с разработчика необходимость знать архитектуру процессора, конвенции вызовов
Вы, очевидно, не понимаете что пишете. Ассемблер если и видели, то на картинках. Возможно даже, что и на компилируемых языках никогда не разрабатывали.
целую кучу разных оптимизацией и целую кучу специализированных алгоритмов.
Перечислить эту кучу вы, естественно, не сможете.
Вы, очевидно, не понимаете что пишете.
Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора. На лицо абсолютная деградация. x86 и ARM совершенно разные! Чтобы printf позвать надо сискол сделать на x86 это int 80 или syscall на арм это svc.
Перечислить эту кучу вы, естественно, не сможете.
Вот вам несколько примеров:
Ручное управление регистрами
Ручно разворачивание циклов (чтобы избежать лишних cmp jmp на коротких циклах)
Замена медленного деления на эквивалент
Ветвление без условий через setcc, cmov, and, xor
Ручной prefetch данных
Ручное выравнивание кода и данных
Оптимизация под конкретные CPU
Очевидно вы ничего из этого не знаете и даже не подозреваете о существовании. Теперь расскажите, мешает ли вам ваша деградация работать разработчиком или нет.
Вы очевидно вообще не понимаете что такое ассемблер и что такое архитектура процессора.
Вы абсолютно правы.
Для того, чтобы убедиться в полной моей некомпетентности достаточно прочитать мою последнюю статью :)
Вот вам несколько примеров:
Хоть бы автовекторизацию вспомнили для приличия, а то «замена медленного деления на эквивалент» в 2025 году. Словно у LLM спрашивали.
Что из перечисленного «специализированные алгоритмы»?
То, что оптимизирующий компилятор пытается оптимизировать это секрет Полишинеля. Когда производительность действительно важна, приходится по-старинке делать всё самому. Так же, как и 30 лет назад.
Когда производительность действительно важна, приходится по-старинке делать всё самому.
Это 0.01% случаев. Большинство разработчиков в ассемблер залазит примерно 0 раз за всю карьеру. Это не означает что они деградировавшие идиоты. Это означает что для большинства задач это не нужно.
> Когда производительность действительно важна, приходится по-старинке делать всё самому.
Это 0.01% случаев.
Ну то есть Кармак прав.
Что из перечисленного «специализированные алгоритмы»?
Прочитайте определние порятия "алгоритм". Что из вышеперечисленного не подходит под "алгоритм"? Или по вашему алгоритм это только quicksort или A* а остальное это не алгоритм?
Те же вопросы на манипуляции битами вообще раньше на собесах спрашивали, сейчас это уже почти нигде не надо.
Что из вышеперечисленного не подходит под "алгоритм"?
С точки зрения программы на ассемблере не подходит абсолютно всё.
Пункты 2 - 7 это рефакторинг и/или оптимизации, которые погромисты делают ручками во время разработки. Довольно базовые, к слову. 1 — декларации переменных в ЯВУ никуда не делись.
сейчас это уже почти нигде не надо.
Вы не видели, значит не нужно, понял. Потом будете сидеть удивляться что это вам чатгопота какой-то x & -x нагенрировала.
MVP
Индусы исчезали, а разработка отдавалась западным разработчикам, которые всё переписывали с нуля.
Если так, то всё хорошо. "сделать прототип и с нуля написать нормально" это суть мвп. Чаще же "ну мы вот уже сделали что-то максимально быстрое, а теперь это нужно отрефакторить до нормального кода". Не учитывая, что начинать там нужно вообще с архитектуры, по итогу того как выстрелил мвп. И выбора подходящего языка. И вот тут "тянуть код" - в корне неверно, если не сделан полный анализ и "язык сохраняем, архитектуру меняем тут и тут, эту половину кода переписать с нуля, тут мертвые фичи выкидываем", и всё это планом работ.
Поэтому все, кто сейчас бездумно перекладывает всю разработку на AI, постепенно превратятся в те самые дешёвые индусские команды, пишущие код за копейки. И не стоит потом удивляться, что на собеседованиях всё равно будут проверять реальные навыки программирования, а не «вайб-кодинг» — и вы просто не сможете пройти такое собеседование.
Вполне резонное опасение, но в LLM уже содержатся рекомендации по архитектуре тоже, люди очень много об этом писали и в итоге датасеты сформированы на эту тему вполне удовлетворительные.
Достаточно время от времени спрашивать ИИ-ассистента, хорошая ли в проекте архитектура - и можно получить в ответ рекомендацию использовать определённый паттерн проектирования, совет разрезать большой класс на части, порядок в документации или расстановку приоритетов в большом количестве запланированных фич.
Т.е. подход дробления проекта на фичи и очень раннее планирование с помощью ИИ себя вполне может окупать, если это не какие-то слабоизученные экспериментальные области или что-то, защищённое патентами и НДА с минимумом доступного кода в открытом доступа.
Ну а те кто не задают таких вопросов, с большой вероятностью не интересовались ими и без LLM, так что он их не испортит, а просто раскроет слабые стороны и даст им набросать лапши побыстрее.
И насколько вы сами деградировали после того как не пишите код на ассемблере, а пользуетесь одними компиляторами?
А я теперь пишу дизассемблеры!
Это рутина, зачем набирать код самому если это может делать LLM.
а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.
основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.
1 процент времени - это значит вы за 8-ми часовй день набираете код меньше 5 минут. Верю, я поверил.
Если бы не NDA, я бы показала вам коммиты, которые делают мои индусы после 3–4 дней (а то и недель) работы 🙂. Там и на 5 минут изменений в день не наберётся.
А если серьёзно — вот нужно внести буквально пару изменений, но в очень большой продукт уровня энтерпрайз. 10 строк — в одном модуле, ещё 10 — в другом. Итого 20 строк, большую часть из которых можно просто скопировать из документации.
Реальность для очень хорошего сеньора: 10–15 минут на ознакомление с изначальным запросом, от 2 часов до нескольких дней — на анализ того, как эти изменения повлияют на продукт в целом и на разных пользователей. Как лучше внедрить в код. Если нужно - обновить blueprints. В 50–60% случаев потребуется ещё пара встреч с инициатором изменений, чтобы уточнить детали и согласовать, что адаптированное решение действительно будет для него работать.
Добавьте к этому код-ревью, тестирование (которое порой может быть весьма долгим) — и в итоге на эти 20 строк, которые можно набрать за 2–3 минуты, уходит 4–5 часов аналитической работы.
от 2 часов до нескольких дней — на анализ того, как эти изменения повлияют на продукт в целом и на разных пользователей
Только вот это не задача разработчиков. Это задача аналитиков / продакт менеджеров.
Если бы не NDA, я бы показала вам коммиты, которые делают мои индусы после 3–4 дней (а то и недель) работы 🙂. Там и на 5 минут изменений в день не наберётся.
Что вам сказать - это печально. У вас видимо лютое легоси и сапорт без новых фичей. Даже средняя фича это обычно строк 300-500 кода, крупные по несколько тысяч минимум в разных частях проекта на фронте на беке в ядре и тд.
Добавьте к этому код-ревью, тестирование (которое порой может быть весьма долгим)
Код-ревью - сильно, не просто сильно а оочень сильно ускоряется LLM. Раньше у меня каждое замечание - это головняк (подправить в куче мест какую-то мелочь, подправить тесты, протестировать заново). Теперь большую часть правок делает LLM включая тесты => код ревью ускорилось раза в 3.
Тестирование - аналогично, написание юнит тестов, e2e тестов и прочих тестов ооочень сильно упрощается LLM. Если у вас вдруг еще нету тестов или индусы сидят и тестируют всё руками - самое время начать их писать (генерировать LLM - опишите ей ваши тест кейсы она нагенерит на них кодярник).
Только вот это не задача разработчиков. Это задача аналитиков / продакт менеджеров.
а зачем тогда в том дивном мире будущего, описываемом вами, чистые разработчики(а скорее даже кодеры)? Они перестанут быть нужны. Если следовать парадигме "вайи кодинга", то людей со скилами аналитиков / продакт менеджеров (а еще лучше - technical product/program managers) будет более чем достаточно. Плюс архитектор. Данные собрали, AI скормили, агентов запустили, результаты отправили дальше если нужно. Все...
Тестирование - аналогично
тестирование и базовый скелет - вот это да. Эту рутинную работу просто замечательно выполняет LLM.
а зачем тогда в том дивном мире будущего, описываемом вами, чистые разработчики(а скорее даже кодеры)?
Я не описываю "мир будущего" я описываю мир настоящего. Что будет в будущем - будущее покажет. Сейчас разработчики нужны для того же что и всегда - разрабатывать фичи. Продакт решает что делать (для кого, кто ЦА, каую боль решает, какая планируется прибыль, ROI etc.). Разработчик решает как делать и собственно делает. В настоящий момент нужны и те и другие.
Я не описываю "мир будущего" я описываю мир настоящего.
Вы описываете совершенно другую грань мира настоящего.
Разработчик решает как делать и собственно делает.
За пределами уеба разработчику жизненно важно знать, как эта фича впишется в несколько уровней системы над фичей и несколько уровней системы под фичей. Поэтому да, приходится совмещать задачу аналитиков и PM в одном лице.
то людей со скилами аналитиков / продакт менеджеров (а еще лучше - technical product/program managers) будет более чем достаточно. Плюс архитектор.
Если их назвать одним словом, это будет «разработчик». :-)
У вас видимо лютое легоси и сапорт без новых фичей.
Ви таки будете смеяться, но любой написанный сегодня код через 5 лет станет жутким легаси.
Не любой, а тот в котором забросили архитектуру и забили на техдолг ради сиюминутной выгоды. Если у вас это так, не значит что везде так.
Тратить неделю на то чтобы разобраться куда что добавить в собственной код базе с котороый вы работаете на ежедневной основе - это не нормально! Это говорит о том что с кодбазой большие проблемы.
Тратить неделю на то чтобы разобраться куда что добавить в собственной код базе с котороый вы работаете на ежедневной основе - это не нормально!
С учётом современного отношения к текучке, когда через 5 лет от группы, писавшей этот код, остались рожки да ножки? Да вы оптимист. Нет, единственное спасение для мало-мальски прикладного кода хорошего, но не исключительного качества — это OSS, когда люди, писавшие код, в общем, где-то рядом.
Вот я и говорю, что после пятнадцати лет работы над проектом моя ценность заключается не в том, чтобы налабать 100500 строк кода за полчаса, а в том, что я лично присутствовал на том митинге, на котором приняли решение вызывать вон тот метод с вот эдаким подвыподвертом, и могу рассказать, по какой причине приняли именно такое решение (хотя другое с первого взгляда кажется сильно более логичным — но был нюанс). Удачи, ChatGPT, сделай мне смешно.
я лично присутствовал на том митинге, на котором приняли решение вызывать вон тот метод
Поздравляю! Теперь вы не разработчик а просто очень дорогая замена вики-движка.
и могу рассказать, по какой причине приняли именно такое решение
А можете и не рассказать так как теперь у вашей конторы bus factor равный единице.
Все неочевидные решения должны быть задокументированы во внутренней вики, в jira таске и в коде в виде юнит-теста на эдакий подвыподверт.
А можете и не рассказать так как теперь у вашей конторы bus factor равный единице.
Зато у меня отличная job security.
Все неочевидные решения должны быть задокументированы во внутренней вики,
И это тоже проходили. Задокументировать‑то они задокументированы — вот только по мере роста вики возникает та же самая проблема: никто не знает, где (в смысле «на какой странице»).
в виде юнит-теста
Юнит‑тест демонстрирует что так есть, ни не говорит ничего о том, почему так есть.
Только прикладной. Код качества уровня stdlib не становится legacy.
Только вот это не задача разработчиков. Это задача аналитиков / продакт менеджеров.
При таком уровне разделении труда вы на одни согласования потратите месяцы. Нет, в кровавом ынтерпрайзе разработчик совмещает в себя все эти навыки.
Добавьте к этому код-ревью, тестирование (которое порой может быть весьма долгим) — и в итоге на эти 20 строк, которые можно набрать за 2–3 минуты, уходит 4–5 часов аналитической работы.
Поэтому у меня значительная часть коллег так до сих пор и не научились печатать вслепую. :-)
1 процент времени — это значит вы за 8-ми часовй день набираете код меньше 5 минут. Верю, я поверил.
Вообще‑то да. Остальное время я думаю, какой именно код я буду набирать в эти 5 минут. Лазаю по исходникам остальных частей системы, смотрю «а если я сделаю вот так — то не поломается ли вот это?»
зачем набирать код самому если это может делать LLM.
Простите, а кто за Вас набирает промпт?
фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое
Вот кстати LLM уже неплохо это могут. Поднять историю изменений в куске кода, найти нужные MR, найти и прочитать связанные тикеты в jira. Скомпоновать все вместе и выдать отчет "кто, когда и зачем это делал". И все это за 2-3 минуты пока я себе кофе наливаю.
ага, это если все вот это все нормально где-то в тикете описано. А на деле 60% информации в реальности была получена разработчиком в ходе обсуждений (записей которых нет), а даже то, что есть можно трактовать совершенно по разному.
Настраивать процессы. Долго, дорого и больно. Но нужно.
Я в процессах уже лет 15. Люди не совершенны. У вас никогда не будет идеальных процессов — как бы вы этого ни хотели. А если и будет, то лишь на короткое время, при удачном стечении обстоятельств.
В реальности я вижу только один путь — логировать абсолютно всё (разговоры, чаты и т.п.) и скармливать это AI. Но тут мы упираемся в этические и юридические проблемы (которые, кстати, вскоре только ужесточатся), влияние на команды, и главное (т.к. бизнес решает) — в стоимость такого решения. Потому что мы ещё даже близко не видим реальной стоимости AI.
Что я имею в виду под “реальной стоимостью AI”? Я буквально вчера разговаривал с коллегой из большой компании, которая активно использует GitHub и Copilot. Кто не знает: примерно месяц назад GitHub объявил, что “баста, карапузики, танцы закончились” — бесплатно останется только базовая модель (сейчас это GPT-4.1), причём без гарантированных мощностей. То есть в часы пик будут и задержки, и непредсказуемые ответы.
Всё остальное — включая GPT-4.1 с гарантированными ресурсами — теперь считается premium requests. Количество таких бесплатных запросов зависит от типа подписки. Стоимость запросов тоже зависит от используемых моделей. К более продвинутым моделям, например GPT-4.5, нужно 50 premium requests и получается $2 за один запрос.
GitHub должен был начать взимать оплату за это с прошлой среды. Что-то пошло не так — интерфейсы пока не готовы, но, как сказали персональному менеджеру компании в пятницу(у меня такой звонок запланирован на следующей недели ;-)), если бы деньги начали списывать, то уже к третьему дню сумма за использование premium-запросов составила бы около $800(это с учетом, что на их подписке 300 premium-запросов в месяц уже бесплатные). А ожидаемые расходы за месяц — минимум $8000 (без учета стоимости базовых лицензий на copilot).
И тут менеджмент немного приуныл, потому что:
Существенного роста продуктивности(что бы прям в разы) они еще не увидели.
Доступ к Copilot сейчас есть только у 25% разработчиков в их компании.
То есть, при 100% покрытии сумма может легко дойти до полумиллиона долларов в год. А скорее всего — даже больше, если все начнут активно использовать тот самый “вайб-кодинг”.
Так что нас ещё ждёт много интересных открытий в ближайшие годы. GitHub — это только первый звоночек. Все остальные пока просто прожигают деньги инвесторов, субсидируя ресурсы.
Когда стали разбираться в коде новой компании, то выяснилось, что большая часть написана китайцами, а добил их комментарий перед злобной реализацией некого алгоритма на несколько страниц: «описание алгоритма смотри в тетрадке у Чуня». Где тот Чунь уже было неясно :)
звучит красиво.
тут еще такой вопрос. ваша LLM работает локально или вы предоставляете доступ наружу для всего кода и документации проекта?
главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?
Открываешь редактор с поддержкой ИИ (cursor, trae), делаешь проект, добавляешь туда код. Всё, ии его способен проанализировать и под "заюзать" он может предложить варианты. Рефакторинг можно сделать там же, порой получается неплохо. С багами сложнее, ряд багов он показывает сразу при правильном запросе, но многие баги - ручками или как тут рядом расписали.
Но не надо превращать ии в архитектора, и не надо пытаться им заменить программиста. Это инструмент, как круиз-контроль в авто - удобно, помогает, водителя не заменит.
Где пункт в опросе "уже вайб-кодю и счастлив"? Но конечно не так как у автора.
Самому вайбкодить когда четко понимаешь что почему и зачем делегируешь LLM - это норм. Поддерживать то что там навайбкодил кто-то там еще без опыта разработки - не норм.
И да, это война.
Я бы на месте начальника уволил бы такого воена. "Уходя - уходи".
Если есть возможность - не будь Дон-Кихотом, уходи... посмотри на зуммеров.
Можно посчитать TCO обоих подходов, сделать PoC и передать уровнем выше? Начальники, которые подставляют доходы владельцев не задерживаются.
Не вижу проблемы. Любой велосипед требует поддержки даже больше, чем нормальные решения. Всем же очевидно, что это не более, чем велосипед? Если введут no-code, от этого процесс только усложнится: нужны будут эксперты, чтобы это поделие увязать со всеми остальными системами, потребность в разработке только вырастет. Оно еще и проблем будет регулярно подкидывать, которые в рамках no-code просто не решаются. No-code это надстройка, красивая панель управления, но чем сложнее система, тем больше обслуживающего персонала требует, и тем более дорогой и квалифицированный это персонал должен быть, это простая истина. Через пару лет посмотрят на то как все стало медленно и дорого, и выкинут этот no-code. Делов то.
Кажется, вы потворствуете такому подходу, потому что разруливаете все проблемы, который принес no-code подход.
Начальство видит: всё [почти] работает, а вы брюзжите (простите).
Если вы и так готовы уволиться, может, пора отпустить ситуацию и перестать все и всех спасать? Порветесь ведь...
Когда придет очередной баг, просто скажите "насяльника, шайтан-машина кодила-кодила, а логов нет. Не могу починить".
Когда развалится пайплайн, просто просигнализируете "насяльника, шайтан-машина пайп поломала, починить не могу".
Когда упадет прод... Ну вы поняли )
Столкнувшись с реальными проблемами, а не с вашими рассказами, быть может, начальство изменит мнение.
Ваше предложение абсолютно логично, но я человек, более того - я человек старой закалки. Я не могу плохо работать, это не моё. У меня в команде лозунг: либо мы работаем хорошо, либо.. очень хорошо. Других вариантов нет, кто не согласен - я не держу.
Но Вы правы, пора отпустить ситуацию (за пинок - спасибо). Видимо это мысль - главное, что я вынес из всех коментариев.
Ваша статья напомнила классику: ))
"- Нам нужно начертить семь красных линий – продолжает Марковьева – Они все должны быть строго перпендикулярны, к тому же некоторые нужно изобразить зеленым, а ряд линий прозрачным цветом. Хочу узнать ваше мнение – это реально?
- Нет – отвечает Смешков.
- Ну, давайте не будем торопиться отрицать, Смешков – говорит Сидоряхин. – перед нами поставлена Задача, нужно найти способы ее решения. Вы же профи! Не давайте повода, считать вас непрофессионалом!"
Полный текст по ссылке, если Хабр пропустит - https://smartbluebird.livejournal.com/28979.html
Интересно, а зачем эта адаптация случилась? Есть же the expert (на ютубе куча видео)
В смысле, зачем эта самая "куча видео" экранизировала старый рассказ из ЖЖ?
Киньте ссылку на старый рассказ (выше не старый судя по дате)
Самое раннее, что нашёл, было вот тут.
Основная проблема автора, насколько можно понять, заключается в том, что он и бизнес, в лице CEO говорят на разных языках. Доводы для бизнеса также должны быть в рамках, которые могут быть им поняты.
Нет смысла упирать на качество архитектуры проекта, его отлаженность и прочее. Это всё технические термины и менеджеры их могут не понимать или не воспринимать всерьёз. Тут скорее надо указать на потенциальные потери бизнеса когда продакшен встанет колом из-за очередных навайбкоденных фич. На то, что доработки станут дороже в процессе расширения присутствия ИИ-кода в кодовой базе проекта.
Было бы неплохо уговорить руководство не класть все яйца в одну корзину, а выделить для вайб-кодинга отдельный проект, не самый критичный, но чтобы эффект от него можно было прочуствовать. И там всё и протестировать, без разрушения кодовой базы основного проекта.
а потому что не хочу быть заложником криво сделанных решений, за которые потом же и буду отвечать.
Отвечать должны:
Тот кто сделал.
Тот кто решил нанимать тех кто сделал.
Если отвечать будут не эти лица, то все печально в этой компании, давно надо было уходить!
Вы просто ретроград и сопротивляетесь всему новому. Вон, в 90-е годы все бегали и говорили: "Разработчики скоро будут не нужны, бизнес нарисует диаграммки в UML, опишут логику в sequence-диаграммах, нажмут кнопочку, код сгенерируется и всё будет работать". А потом ещё бегали и говорили: " Нам не нужны разработчики и админы, мы утащим всё в облако, в dreamweaver нарисуем интерфейс, он нам всё сгенерирует, фронтвэы не нужны будут".
И только один Фредерик Брукс молча улыбается, наблюдая за очередным увеличением продаж его книги, которую он написал полвека назад.
Фредерик Брукс молча улыбается
с небес
Не знаю, может, мне тоже книгу написать?
Сложность уходит с экрана - но не из системы. Она просто становится невидимой.
Спасибо, бро! Отличная формулировка. Я впервые с невидимой сложностью столкнулся в Borland'овских IDE, где обещали мышкой научить рисовать UI. Рисовать было круто, а вот потом в той лапше кода крутиться было не очень :(
Выглядит как недопонимание. Начальник изначально задал слишком высокую планку внедрения ИИ, а вы приняли диаметрально противоположную позицию. И теперь бодаетесь, вместо поиска компромисса.
Очевидно, что начальник видит проблему с медленным time to prod при текущем подходе. Не всегда подход "делаем или хорошо или ещё лучше" себя окупает. Иногда намного важнее быстро зарелизить MVP и захватить долю рынка, чем прийти с отличным решением когда все уже попилено. Или выпустить MVP как гипотезу, и посмотреть насколько востребовано и как пользуются, чтобы понять куда копать дальше. "Старая закалка" она же "ригидность" здесь только мешает. Могу сказать, что даже в банках для ряда фичей бизнес осознанно приоритезирует скорость над качеством, и нормально относится к негативным последствиям. Это новая реальность везде, кроме каких-то очень специфических продуктов (АЭС, Луноходы, медицина, но это не точно).
Также, при всех недостатках, AI невозможно игнорировать. LLM сделали огромный скачок за последние 3 года, а сейчас в него ещё и вложили все деньги мира. Вероятность ещё одного скачка весьма велика. Да даже и текущего уровня, при наличии нормального окружения, хватит чтобы ускорить целый ряд рутинных задач. И вашего менеджера наверняка напрягает, что "ригидный" техлид удерживает всю команду от получения продакшн опыта в очень перспективном направлении. И пока конкуренты (на самом деле почти все) активно осваивают AI, пусть даже как инвестицию, вы лишаете себя этого опыта. И если AI "выстрелит", то вся команда мгновенно устареет вместо плавной трансформации.
Наконец, внедрение AI это ещё одна сложная и интересная инженерная задача, и именно так у этой инициативе надо подходить. Понять какую проблему хочется решить (TtP), посмотреть на каких задачах можно применить сейчас, как адаптировать архитектуру под дальнейшее внедрение, какие новые метрики понадобятся для data driven решений, набросать с начальником роадмап и начинать постепенное внедрение. Ещё можно заранее посмотреть какие no-code/low-code решения есть на рынке помимо Loveable - может вам что-то больше понравится.
Конечно, воплотить такой подход в жизнь будет психологически тяжело, учитывая сколько усилий было потрачено на войну с AI. А тут, получается, назад надо сдать. Но, на мой взгляд, умение переосмыслить ситуацию, умение адаптироваться - это как раз и есть свойства хорошего инженера.
Грамотные мысли, если на все это есть время: пощупать, посмотреть, оценить итд. А не CEO пытается тушить АИ-штукой проекты, что фирма не вывозит текущим штатом.
У Вас разумные аргументы, но я не против AI - команда во всю использует его в своей повседневной работе: помощь в написании документации, поиск багов, генерация черновых Unit и API тестов, POC на скорую руку и т.д. В этом году мы уже зарелизили парочку AI фичей, которые были очень нужны нашим клиентам. Но... для руководства "уже" - это всегда поздно, ведь всё нужно было ещё вчера/позавчера/год назад. Когда у руководства не получается что-то улучшить в отделе продаж - оно часто пытается "навести порядок" в отделе разработки.
Сваливайте с этой работы, фирма обречена закончиться. Когда CEO начинает лезть в разработку - это показатель, что в фирме какие-то проблемы и CEO пытается найти "серебрянную пулю". Судя по вашим расказам, он стремится сделать разработку дешевле, видимо при текущей цене фирма её не вывозит.
__
Что касается отношения к этой всей ситуации, то тут ситуация выглядит так: ваша задача донести до CEO, что использование Lovable несет риски стабильности работы, сложности внедрения (вы не знаете её апи и так далее), сложности поддержки (надо разбираться в их апи и костылить, разработчики с рынка не знают эту штуку итд).
Если CEO после этого говорит, да ничего, мол разбересь итд - значит фирма находится в такой ситуации, что получить более быструю скорость внедрения костылей сейчас важнее, чем столкнуться с проблемами дальше. А звоночек, что фирма заканчивается.
__
Если у вас есть технический директор, то вместо хабра лучше пойти с этой статьей к нему. Если вы и есть технический директор, то уточните у бухгалтерии состояние фирмы, и если там все плохо - то сваливайте первым.
Автор, я бы не стал спорить с CEO, а просто вспомнил бы лучшие традиции итальянской забастовки https://ru.m.wikipedia.org/wiki/Итальянская_забастовка
Заодно можно будет максимально формализовать действующую систему, uml диаграммы, автотесты, вот это всё. Ибо работа через no/low code инструменты требует максимально чёткого и прозрачного понимания всех процессов, бизнес логики, дата флоу и пр.
Понимаю вашу боль. Но может настал момент научиться защищать свою позицию. Научиться более сильно доносить аргументы: например, сделать тест с фичей из no-code и классическим методом. Показать плюсы\минусы, свести ко времени, затратам, рискам и деньгам.
У нас одна внутренняя систма написана на Retool. Да, действительно разработка быстрее, однако интерфейс выходит... ну, для внутренних пользователей сойдёт.
Если не считать внеапного сексизма посреди статьи, автора поддерживаю.
Вспоминаю BPM. Как руководство настаивало внедрить camund-у. И какая дичь из этого вышла.
У кого-нибудь был позитивный опыт внедрения BPM?
У меня вопрос : а почему вы про это всё нам тут плачетесь, а не рассказываете "это всё" вашему архитектору?
потому что тут выслушают?))) что думает по этому поводу ваш архитектор? если всё так, а я подозреваю что всё у вас действительно так, то решать менеджерский вопрос надо менеджерский и пустыми. эскалируйте факт наличия технической проблемы наверх по иерархии и пусть технически подкованные архитектор (понимающий вас), обладающий скидками и доверием уровня менеджера (ему доверяет менеджер), объясняет менеджеру, что идея, мягко говоря, плоха.
так. а не слезливой статьёй на хабре.
... а..... или вы и есть тот самый архитектор?
тогда вопрос : вы не пользуетесь доверием/уважением менеджера? тогда вы не архитектор. ему без софт скиллов и умения работать с менеджерами - никак. вы уж простите.
... или у вас менеджер играет в "я начальник ты дурак"? тогда конечно швах.
можно было бы посоветовать вам поиграть в менеджерский игры вида "дай идиоту оступиться" (сделать как хочет человек, с фиксацией рисков и опасений, и формулировкой "ну раз вы платите, и рискуете своими деньгами, то пожалуйста", а когда всё пойдёт по ...медному тазу - вытащить из загашника старое письмо ), но чую этот вариант не для вас.
...
как итог ? вы - забейте.
если менеджер невразумляемый идиот, поддающийся на маркетинговые уловки - то вашему продукту пи.... ...медным тазом, в общем... он закроется. и вас менеджер , как минимум сейчас, слушать не будет.
в лучшем случае - дайте ему почитать Брукса, и скажите, что кодогенерящие нейронки - совсем не серебряная пуля. и для вашего продукта этот вариант не применим.
юзать кодоген-нейронку - это всё равно, что нанять забесценок студента второкурсника , чтобы с ним, в режиме диалога пилить сайт. если менеджер не послушает такую аналогию - то он дурак. делайте что хотите ))) дело не в вас и не в вайб-кодинге.
студентов генерящих "правильные, красивые, задёшево, идиотические решения" приводили на предприятия всегда. ну теперь вот нейронку привели, с такой же формулировкой и посылом.так что, вот так же , по аналогии и отбивайтесь.
или... простите за наглость, но у меня ещё 2 вопроса :
у вас точно 25 лет опыта в индустрии?))
если так, то как можно дожить до 40+ лет и не набраться опыта во взаимодействии с менеджерами? вы не просто обязаны быть "как минимум мидлом"(и знать про особенности некоторых менеджеров ) но и тупо, по налёту лет, не просто столкнуться раз 5-10 с такими манагерами, но и научиться обрабатывать эти ситуации на уровне чуть более мудром, чем "я думаю уволиться".
отсюда вывод: или вы привираете, или написали заказную хайповую статью.
у вас исследование какое или просто чешете себе ЧСВ перед школьниками ?))
1. Я действительно имею 25 лет опыта работы в веб-программировании. Мой первый проект был сделан в далёком 1999 г.
2. Почему-то последние 15 лет все заморочились этими софт-скилами. В моё время человек просто приходил в команду работать и от него (как от инженера) требовалось не заниматься "выстраиванием" отношений, а в первую очередь честно и грамотно выполнять свою работу. Да и про такое явление как "выгорание" никто слыхом не слыхивал. Но сегодня почему-то считается, что "софт-скилы" - это MUST и даже важнее "хард-скилов" и их нужно "прокачивать" в первую очередь. Нужно учиться выстраивать отношения в команде, между командами, с начальством и т.д. У меня достаточно "мягкий" характер, чтобы в моей команде все чувствовали "кайф" от нашей совместной работы и каждый имеет свою долю уважения и респекта, более того, я открыт и для критики и для новых (полезных) идей. Но с начальством у меня всё наоборот - там я совсем не "мягкий" и более того - не собираюсь этого делать ни сейчас, ни в будущем. На мой взгляд, начальство должно получать правдивую обратную связь, а если им это режет глаза, то что ж...
3. Я правда не провожу никакого исследования и ничего там себе не чешу. Просто наболело. Но Ваша мысль мне понятна - я, наверное, постараюсь избегать в дальнейшем написания подобных статей.
по аналогии:
1.мне начали начислять за кодинг в 1994м. детские игровые обучающие программы для класса дошкольного развития.
2. за софт скиллы морочились всегда, только оно так не называлось, и именно отдельно в особую категорию скиллы не выделялось. просто были способности к математике, технике, психологии, работе с людьми, организаторские способности.
если сейчас софт скиллы выделают как первейшие... я согласен что это глупость, но я не вижу такого выпячивания. впрочем это может быть как засилье жаворонков, утверждающих что просыпаться рано утром полезнее и лучше. а мне повезло увернуться, а вы попали под удар.
но софт скиллы - это мастхев. к сожалению, мы живём в обществе приматов в основной своей массе не обученных рефлексии и осознанной деятельности. и ваш менеджер - тому ярчайший пример )). потому, начиная с мидла - софт скиллы - это обязательно. у нас например ты мидлом конечно станешь, но средненьким максимум (у нас 3 ступени в мидлах). без софт скиллов, контактов с заказчиком или его представителями, в лиды не пробьешься. разработка софта - командный спорт. кому нужен сферический конь в вакууме , пусть и кодящий на отлично?))
ну и вот. мастер на производстве со временем просто становился "житейски мудрее" и умел говорить с начальством. просто не заметил таких ноток в статье. "ну штошъ". сорян))
3. да не, тоже норм. у меня как инженера вообще от половины идей маркетингового онанизма подгорает. вон, глядишь, сам доберусь до статьи про микросервисы...
я, наверное, постараюсь избегать в дальнейшем написания подобных статей
а вот это вы бросьте. кто-ж будет маркетолухам противостоять и хоть где-то школоте и студентам что то рассказывать?)))
Почему-то последние 15 лет все заморочились этими софт-скилами.
У меня достаточно "мягкий" характер, чтобы в моей команде все чувствовали "кайф" от нашей совместной работы
Вам может не нравиться это новомодное словечко, но если у вас в команде всё так, как вы пишете, то какие-никакие софт-скиллы у вас таки есть, советую свыкнуться с этой мыслью. Тем более, если собираетесь искать работу: уделите время саморефлексии (посмотрите на себя со стороны) и подумайте, в каких ситуациях вы эти скилы применяли - насобираете кейсов для интервью на лидерскую позицию.
Но с начальством у меня всё наоборот
Сам себе злобный буратино, получается.
Причём тут нейро-кодинг и то, что вас заставили делать?
Когда условный жс заменяется нокодом, нам больше не нужны спецы по жс, нам нужны спецы по нокоду.
Нужно ли изучать жс? Да. Но жс - база. Знаешь жс - кодишь.
Нужно ли изучать нокод? Да. И их много. Знаешь нокод - конфигуришь тот, который знаешь. Видишь другой, учишься конфигурить его. При этом, круто, если его делал не идеолог с особым видением и философией, а чувак, у которого все логично в голове.
А еще становимся заложниками платформы, техподдержки, ограничений платформы. Подсесть на нокод, практически гарантированно обеспечит текучку кадров.
С вайбкодингом ситуация немного другая, там свои проблемы.
Поделюсь своей историей.
Я работал Flutter-разработчиком и мне была поставлена задача - сделать редизайн существующего приложения на Flutter, которое уже давно было в проде. Работая с кодовой базой проекта, я постоянно натыкался на различные недоработки и костыли в коде, после чего было решено провести масштабный рефакторинг. Огромным трудом добившись хорошой(как я считаю) архитектуры, переписав огромное количество кода и написав более 60 тысяч строк кода я начал подбираться к финишной прямой данной задачи. Находить и исправлять баги стало легко, для добавления новых фич больше не приходилось затрагивать 100500 других модулей - одним словом - красота.
Потратив 4 месяца, и вложив все свои силы и навыки в код, я был "приятно" удивлен, когда начальство мне сообщило: "Замораживай текущую работу и переписывай все с помощью Курсора на React Native. Ведь Курсор может сделать все то же самое, что и я, только в 10 раз быстрее - зачем я потратил столько времени на код? Какая разница, хороший он или нет.".
В итоге, все мои усилия - впустую. "Писать" фулл проект через нейронку, да еще и на RN(который я, кстати, не знаю) я конечно же отказался. Хорошо только то, что разошлись с компанией мы мирно и без скандалов, так что хотя бы нервные клетки сэкономил.
О, это классика. Менеджеры разного уровня время от времени, насмотревшись презентаций про «успешный успех», приходят с такими идеями.
Могу привести аналогию с фастфудом.
No-code/low-code — это фастфуд. Можно ли построить бизнес на фастфуде? Конечно! Особенно если вы франчайзер и продаёте фастфуд-решения, а не сам фастфуд.
Фастфуд не получает звёзд Мишлен.
И, наконец, если у вас есть сеть ресторанов и вы хотите сократить расходы за счёт превращения её в фастфуд, то у вас не будет ни сети ресторанов, ни фастфуда.
Так точно
У фастфуда конкретная задача - за небольшую стоимость выдать большое количество калорий, чтобы человек мог трудиться и приносить прибыль
Здесь аналогично. Фастфуду не нужны звезды мишлен - им важна быстрая прибыль
Фастфуду не нужна красивая подача к бургеру - им нужно продать как можно больше бургеров, пока могут. Как только бургеры продавать становится нерентабельно - фастфуд закрывается
Ну и из фастфуда не сделать ресторан высокой кухни - целевая аудитория не поймёт, зачем им гренка за 10 баксов. За 10 баксов можно получить 2-3 хороших бургера, а это энергия почти на весь день
Да ща наберут 25 летний молодняк, которым, как бешенной собаке - семь верс не крюк, обосруться и начнут в рил код, попутно доложив, что ии не может в архитектуру, только уже набрв 30 летних. Старикам тут не место.
Я вижу ценность подобных решений только в некоторых аспектах деятельности, а именно, для создания прототипов для презентаций, проверки каких-то идей и концепций, возможно для создания простейших лендингов для максимально-срочного реагирования на какую-то ситуацию на рынке.
Иначе, всё что было навайблено, превратится в такие дремучие легаси, что поддерживать это всё станет просто невозможно.
Поэтому, совет. Если манагер влип в зависимость от AI-наркоты, то вряд ли его уже можно вытащить обратно в какие-то разумные сроки. Поэтому, можете смело навайбить кало-код, попросить у наркомана дополнительную премию, пока он под AI, и бежать с тонущего корабля куда глаза глядят как только он потребует первую новую фичу после первоначального вайба.
Так ведь решение простое. Не осуждайте не предложив ничего взамен. Попробуйте такую связку: ваш стек+figma+cursor. И производительность и контролируемость.
Как нибудь я опишу свою систему которая позволяет ускорять мои проекты)
Моя жена — любит следовать моде и быть “в тренде”, но она - женщина и ей это идёт (более того, она знает в этом толк), но мужчина ответственный за стабильность продукта - не может себе такого позволить
После этого предложения как-то сразу утратилось всё доверие к автору — сразу выдаёт ретрограда, который говорит, что он не ретроград
Показал моей жене Ваш коментарий, а также парочку других, где на меня навешали ярлык "сексиста". Она от души посмеялась и сказала - "пиши, пиши еще!" - где я о тебе ещё столько нового узнаю ))
Моя жена следует моде и трендам (не всем, конечно) - потому что это её профессия. Она - модный журналист, т.е. журналист "по моде".
Спасибо за интересную статью, недавно как раз обсуждала похожую тему с коллегами. Опытные инженеры с 20-30 годами сейчас действительно стоят на интересной развилке индустрии.
Это реальное требование по вакансии разработчика, на этой неделе встретила: Knowledge of Vibe Coding and familiarity with cutting-edge industry trends.
То есть тренды никуда не денутся - вопрос в том, что с ними делать. Я в опросе выбрала "нет, потому что мне это интересно".
Лично я не разработчик, работаю в тестировании ПО, и очень хочу внедрить ИИ решения в тестирование. Но загвоздка в том, что я в банке, и у нас из-за соображений безопасности внешние платформы ИИ не доступны в рабочей сети. Есть только собственное веб-приложение, под капотом которого chat-gpt - спросить что-то можно и все.
Но я подумала, если бы мне дали доступ к ИИ инструменту и сказали "попробуй", я бы начала с POC + MVP (то есть концепт и минимальный продукт), конечно не трогая старую систему. А дальше уже по результатам демо обсуждать, что делать: интеграция в легаси, построение новых решений или гибридный вариант. Но думаю, что делать все равно придется. Делать ли ИИ-интеграцию - вопрос уже решенный, вопрос только "как".
Спасибо за отзыв. Мы с нашими QA инженерами во всю используем GPT и даже сделали (пока POC) небольшую программу для внутреннего пользования - скидываем в GPT скриншот страницы, а он генерит все степы для для E2E тестов, затем пишет код для тест-кейса и сам запускает его. Пока всё ещё очень сырое, но на обычных CRUD страницах результат очень даже не плохой. Я считаю, что это очень перспективное направление, потому что ручное написание QA автомации очень трудоёмкий процесс, к тому же E2E сами по себе вещь хрупкая.
да вы молодцы! надо и мне к этому подобраться, попробовать
сделали (пока POC) небольшую программу
Осталась самая мелочь — сделать не «небольшую POC» программу, а большую live fire программу — и вот тут-то Данила-мастер осознаёт, что не выходит каменный цветок.
Пока нео-луддиты борятся с ИИ - компании внедряют роботов.
Вообще именно такие, как у автора статьи, истерики и вопли о своей человеческой уникальности буквально заставляют компании внедрять автоматику. Ибо зачем условному директору или менеджеру все эти "войны", больничные, отпуска, все эти проблемы связанные с людьми? Не нужны. Бизнес это про увеличение прибыли и уменьшение костов. Людей в этом уравнении нет.
Прогресс не остановить. Люди будут заменены машинами.
Во славу Омниссии.
h+
Прогресс не остановить. Люди будут заменены машинами.
Хотелось бы, чтоб в первую очередь были заменены директора и менеджеры - сократить парочку таких с высокими зарплатами - вот и прибыль увеличена.
Если всё может работать без участия человека и заливать лут прямо в карман собственников, то директора и менеджеры тоже не нужны (потому что их специальность - управлять людьми, которых из проекта убрали).
все время, забываю, как называлась статья, написанная зарубежным автором, по шаблону "вам не нужна %эта технология%, вы не %вон та корпорация добра%", с последующими длительными разъяснениями, почему так, а потом следующая связка технология-контора, и так далее.
нужно продолжение того древнего монумента, с вот этими вот пунктами про "no/zero"-code и прочие передовые, на сегодняшний день, технологии, наподобие всяких там агентов и прочего.
Оно?
Originally introduced in You Are Not Google by Ozan Onay
https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
От себя скажу как нынешний руководитель и сам в прошлом исполнитель:
Приказы вышестоящего руководства не обсуждаются
Почему? Потому. Руководство будет само виновато за свои действия, для них они должны быть обоснованны. Единственное что возможно сделать - предложить свою точку зрения и причины с вытекающими. Не согласны? Заявление на стол. Вы исполнитель, не более, не в вашей компетенции не соглашаться с работой, вы не инноватор для компании, не обязаны но можете, не поддержали ваши идеи? делайте так как сказали, не хотите делать? см. выше (Заявление на стол). Смысл не исполнять того что от вас требуют? Дальше будут ругани, несогласия и т.д. и т.п., вместо вас найдут более компетентного человека в этой сфере. Просрут? Это их вина будет, не ваша.
компетентного в когнитивных протезах? натурально слабоумного что ли приведут?
Я тоже скажу как нынешний руководитель и сам в прошлом (да и пока всё ещё) исполнитель - безмолвные исполнители нужны только на самых нижних должностях и то, только там, где нет эмоциональной связи с продуктом, либо в большой корпорации. У нас не так, мы за свой продукт переживаем - слишком много в него вложено душевных сили и энергии.
Я это называю «за ваши деньги — готов приняться за имплементацию любых, даже самых идиотских, ваших решений»
А я вообще не понимаю в чём суть проблемы. Если бардак нельзя остановить, то его надо возглавить!
Firefox не отображает форму
Причина - кастомный шрифт через их CDN. Почему не грузится? Нигде не написано. В логах - тишина. Надо фиксить.
В каком месте вы здесь видите проблему? ПО пользователя несовместимо с новым инструментом, пользователь не готов идти в ногу с новейшими решениями индустрии. Вы уверены, что вам по пути с этим пользователем? Да, деньги пользователя не пахнут, но надо же и себя уважать - пусть пользователь остаётся за бортом истории.
События обрабатываются на стороне клиента
Отладить невозможно. Иногда форма говорит "успешно отправлено", а запрос не ушёл. Где баг? Гадать - не перегадать, будем фиксить.
Зачем? Смотри выше - ПО пользователя не удовлетворяет высоким требованиям вашего действительно великолепного решения. Если пользователь продолжает настаивать, что он хочет что-то у вас приобрести - отправьте его покупать новый современный компьютер с современным ПО, а если и это не поможет - порекомендуйте ему нанять на постоянной основе компьютерного мастера, который будет решать проблемы с его неэффективно работающим компьютером.
Мне кажется, что это лучшее, что вы реально можете сделать в компании - чуть-чуть поддержать саботаж руководства, постоянно подсвечивая "потеря этих 20% прибыли - да, это минус, но эта прибыль не вписалась в новые тренды. наша компания за новые тренды? значит это допустимая потеря. Если же для компании важны деньги этих динозавров - значит над придётся с горем в душе отказываться от трендов в пользу денег".
Главное только особо не переусердствовать :))
можно ещё "неподходящие тикеты" на руководителя переводить.
итог будет примерно таким же.
ПО пользователя не удовлетворяет высоким требованиям вашего действительно великолепного решения. Если пользователь продолжает настаивать, что он хочет что-то у вас приобрести - отправьте его покупать новый современный компьютер с современным ПО, а если и это не поможет - порекомендуйте ему нанять на постоянной основе компьютерного мастера, который будет решать проблемы с его неэффективно работающим компьютером.
А откуда Вы знаете, что мне не так давно говорила поддержка Хабра?
Раз уж была поднята эта тема, то поделюсь взглядом частично со стороны на одну компанию с которой приходилось работать.
Решили они делать новый продукт, веб и мобильное приложение, упор на много пользователей и всё такое, в принципе ничего кардинально нового или слишком сложного, просто нужно нормально сделать и тянуть определенный масштаб. Окей, помогли им сделать эстимейт с поверхностным планом разработки. Команда из пары разработчиков (один фронт, впрочем в идеале нужно два, один бэк, один мобильный) справилась бы за 6 - 9 месяцев, в зависимости от конечного варианта (там небольшая вариативность предусматривалась). Бюджет в целом выходил довольно скромный, даже когда поверх этого в смену попадали продакты и прочие дополнительные люди.
В итоге, началу работы по сему плану дорогу перебежали инвесторы, которым захотелось чтобы в руководстве был кто-то из «опытных людей из тех-индустрии», для чего они достали там кого-то из телекома лол. «Опытный человек из индустрии» продал всем, что описанный в плане типовой подход это старое неэффективное говно от луддитов и для луддитов, а реальные пацаны всё делают сейчас на low-code/no-code решениях и в итоге привлекли относительно именитого международного вендора делать всё по всему модному феншую.
Спустя полтора года оказалось, что потрачены уже миллионы долларов, ничего не доведено до состояния «готово до релиза», часть функциональности отсутствует или не работает, то что есть сделано и работает или выполнено плохо, или выглядит мрачно, или работает через задницу. Часто всё сразу в разных пропорциях. При этом работала команда чуть ли не в дюжину разработчиков.
В результате начались разборки мол как же так и по результатам оказалось, что не только всё плохо сделано и медленно при этом делалось, но куча проблем в принципе не особо решаемы на выбранных инструментах, и стоимость сопровождения потом на этих выбранных low-code/no-code платформах оказывалась неадекватной для подобного продукта.
Я не сомневаюсь, что у любого инструмента есть отличные юзкейсы, где они себя хорошо и эффективно показывают, но этот фап на модные решениях это канонический пример забивания гвоздей микроскопом.
... а впрочем, бог с ним этим всем
Наш начальник хочет no-code. Я - нет.
А зачем ты споришь с начальником словами, которые он не понимает («уйду», «CI/CD», et cetera)?
Надо вот так: «слышь, начальник, хочешь — ладно, готовь проект, обоснование, включая финансовое, подписывайся своей личной ответственностью, утверждай наверху, каждому заверенную копию утвержденного решения, лучше через приказ директора, в котором так и будет написано ‘ответственный: твои ФИО’, и погнали; выгорит — молодец, не выгорит — к нам даже не подходи, гори своей жопой один»
Просто будет дороже.
Вспоминается сразу эпоха лет 20 назад . работал я тогда руководителем ит в энергосбыте города Екб, подрядчик мне делал сайт и личный кабинет по моему тз. Какой-то шаблонизатор простой и своя цмс, все работало ровно как мне надо. Потом общались с директором и разговор был на тему что появились цмс типа вордпресс и конторы на них делают сайты за 5тр и два дня. Но потом заказчик хочет форму обратной связи свою, и сильно удивляется что сделать одну эту форму будет стоить минимум 50 т.р. в его уже готовом сайте.
В этом самом WordPress разве нет типового модуля для формы обратной связи, и эту форму каждый раз заново выпиливают из цельного ствола дуба ассемблера?
типового модуля для формы обратной связи
Проблема в том, что считать типовым.
Кому-то достаточно что есть три поля и при сабмите оно падает на целевую почту.
Кому-то нужна вторая копия для отправителя, мол мы получили Ваше письмо и всё такое.
Кому-то нужны дополнительные контролы в форме. Радио баттоны и прочее там.
Кому-то нужна логика завязанная на эти контролы. Например, чтобы разные тексты отправлялись или на разные почты.
Кому-то нужна капча (а по факту всем, но люди хотят разные).
Кому-то нужно чтобы копия сохранялась в локальной БД.
Кому-то нужно чтобы при сабмите оно пушилось в CRM или лид.
Кому-то нужно чтобы при сабмите оно пушилось в саппорт систему, вроде условного ZenDesk.
Кому-то нужна многоступенчатая форма. Более того, возможно с ветвлением.
И так далее, и так далее, и так далее.
И даже это можно сделать во многом на разных типовых инструментах, иногда даже без ручной разработки и допиливания, но потом не стоит удивляться, что на сайт добавили gravityforms какой-то и ещё пять платных плагинов-дополнений к нему лол.
Наш CEO хочет no-code в проде. Я против — и готов уйти