почему фантастика. че тут такого. это как бы изначально понятно было. чем исходный код ИИ не рядовой источник данных. ИИ играл в шахматы сам с собой и научился. пусть играет в модификацию своего же кода и запускает обновлённые версии себя, переключается на более эффективные и стабильные и так далее.
какая забавная задачка для конструктивной математики:
на карте 100 городов поочерёдно соединены друг с другом прямыми линиями, образуя одну итоговую, проходящую через каждый город один раз. какова вероятность, что это самый короткий маршрут, по которому птица могла бы облететь все эти города?
заглянуть в будущее для понимания математических признаков самого короткого маршрута у такого количества городов, дабы предложить однозначность решения задачки и настаивать на нем не получится в данном случае, верно?
о чем вообще толкует автор. если главной причиной всему - нейросети.
отжали таки труд и удешевили. плюс корпорации из кожи вон старались по овертону изменить отношение к ремеслу, привив иной паттерн. плохо поди, когда ты подготовил общество и бизнес, а потом выдаешь токены на свое API и тарифные планы. халявные ИИ тоже еще видно будет, да и с другого имеют.
и ещё интересно, неужели CEO или какие высокоабстрактные мыслители PM'ы как-то считают, что ИИ не заменит бОльшую часть их труда? написать код (адекватный) и самое главное мэйниейнить его во времени - задача пока куда сложнее для нейронки, недели получив полное текстовое описание от бизнеса, разбить это на программные сущности и сервисы, и построить план работ.
короче передел рынка. а пргерам надо срочно осваивать нейросети в том числе. и умелое их ежедневное применения в редакторах. скоро бизнес будет требовать подобное на собесах.
материя - объект, сознание - у субъекта. неясно, отчего одна часть ученых пытаются в электронах, кварках и прочих занятных шариках и энергиях найти источник сознания. другая часть ученых, имхо, гораздо адекватнее. как ни крути, им приходится сделать вывод, что никакого субъективного опыта материя получить не может.
далее.. либо на этом нужно остановиться и сказать, что мы не знаем почему сознание имеется. либо (и часть ученых это и делают) - допустить/предположить нечто нематериального характера (душу, скажем). и констатировать, что это и есть то, что может переживать субъективный опыт. и это нематериальная субстанция, точнее ни в каких качествах и характеристиках не равна ничему из материального мира. просто параллельно с ним существует. как и прочее - тоже вопрос отдельный.
ps. есть еще фантастический вариант, что поскольку сознание (и я с этим солидарен) не может быть доступно материи - что у самой материи, равно как и у нас людей, есть свои нематериальные сущности, которые связаны с ней и могут испытывать и переживать. этого доказать будет невозможно, потому что нет возможности спросить молекулу, например. ну и в целом - это будет похоже на некий пантеизм такой, еще более сюрный.
когда вышел калькулятор - никто вроде не обезумел, рисуя себе новую веху бухгалтерии в утопичном ламерском стиле. появился инструмент и ок. вели себя сдержанно, а бухгалтера просто стали тыкать кнопки и считать быстрее.
когда, интересно, вся эта фантасмагоричная мишура вокруг ИИ пройдет, и продакты/бизнес приспокоятся от технологий. и просто оставят это программистам, а те решат, как они будут использовать новый калькулятор и когда.
я все понимаю, интересно и прочее. но в стиле обезьян с гранатой перекраивать труд специалистов, не спрашивая их прежде и не до конца понимая к чему это приведёт - это несдержанность. и непрофессиональный подход к делу.
каждый хорош в своей области. накypились будто этим ИИ и носятся теперь. первая же хапка снесла башню. приспокоились бы малень. все само со временем разрулится и придет в равновесие. нужно и полезное разработчики возьмут. при этом не пострадает сознание джуниоров, которые сейчас от всех статей сходят так же с петель разумного подхода к работе, опираясь уже на какой-то утопичный сюр. это я в целом, к слову на тему ИИ и всякие сопутствующие этому зарисовки.
мне нравится, когда реализация модуля/класса занимает условно страничку (две максимум). простое правило не раздувать решение внутри одной сущности - уже понуждает искать иные пути, которые обычно формируют правильный подход к разделению.
новые поколения регятся, а существующие еще активны и не удаляются. это кратный рост. но когда-нибудь случится насыщение - если от дедов до детей все будут зарегины. эта велична будет плюс минус держаться/колебаться. но уже никаких "в разы".
ps. параллельно с этим другой вопрос возникнет. как быть с миллионами мёртвых страниц, никнеймов и тп. всегда про это думал, как будут решать. возможно префиксами new:nick. может и иначе. отнимать прошлые ссылки и давать новым вряд ли хорошая идея.
почему-то всегда упущена одна важная причина делить на микросервисы. точнее, на разные кодовые базы.
у проекта могут быть разные уровни доступа с точки зрения бизнеса. когда нельзя чтоб каждый разраб, от джуна новичка первого дня работы до матёрого сеньора десяток лет трудящегося на благо кампании клонировали себе один и тот код.
я вот, лично, всегда дико удивляюсь, когда меня кидают на новый проект и я вдруг, как новый человек в компании, вижу какой-то код, который ну как бы, возьму его невзирая на NDA и у меня будет работающий бизнес, какой-нибудь криптообмен готовый. а я всего-то занимался фичами настройки профиля, отчетами. зачем короче это всем давать?
равно как зачем человеку, который реализовывает модуль безопасности/аутентификации иметь какой-то хлам в коде, да еще возможно как-то завязанный, который нужно использовать. видение какого-нибудь олдскульного разработчика админки на то, какая должна быть табличка users, че там индексировать и так далее.
вот это еще важные причины делить монолит.
короче, я считаю что в том, как дробить одно большое на части - удобству и доступам к репозиторию разным разработчикам нужно уделять не меньше внимания, чем выделению функциональных независимых единиц из предметной области бизнеса.
если в рамках одного языка - единое соглашение по неймспейсам во всех микросервисах достаточно, при условии общих соглашений по конфигу. а сливать разные кодовые базы в одну - не всегда хорошее решение. а в некоторых случаях бизнеса и разделения уровней доступа - просто невозможное. и разные репозитории строгая необходимость.
имхо, адекватный набор разных кодовых баз для явно специфичных доменов предметной области со своей независимой функциональностью - штука хорошая. просто нужно уметь это готовить. плохо организованные микросервисы не есть камень в огород микросервисов. это камень в огород их организации.
можно ли найти универсальный способ описания предметной области? ДА. можно ли найти универсальный способ проектирования архитектуры? ДА.
но. я к чему. если спокойно подумать, чего ради и зачем мы то или иное ищем, делаем, внедряем? что первостепенно, эта универсализация? разработка как наука, которая побуждает или толкает нас делать так или сяк? или первостепенен real world, с задачами бизнеса? или первостепенна наша нервная система и раскалённый порой до предела мозг? или личная жизнь? или перфекционизм? или первостепенны следующие поколения, кому как нам кажется мы передаем свой код, когда увольняемся? отвечать на эти вопросы важнее.
удивительно, но ответы на эти вопросы и их (как говорят психологи) проработка - достаточно влияет на то, какой код и с какими паттернами мы будем писать и как себя ощущать. тимлиды хорошо знают это. хорошо видят разных разработчиков и их заморочки по коду и архитектуре. и очень часто говорят о заморочках личности. в полной мере паттерны не бывают абстрагированные от личности разработчика.
в общем универсальная таблетка того или сего, как формализовать предметную область или как спроектировать архитектуру, паттерны и тп - важны, но могут отводить внимание от более важных вопросов с точки зрения приоритетов. мозг прогера это отдельная история, и я понимаю как он цепляется и заигрывается с новыми интересными знаниями. но порой это напоминает кошек, которым сносят крышу при виде лазерной точки от указки и они носятся за ней как угарелые. мне иногда кажется, что паттерны для нас что-то подобное.
резюме коммента: сначала главное, потом второстепенное. и поменьше прогерских инстинктов. будем более свободными, менее загруженными и более счастливыми.
"Я предложил наш обычный подход: сначала документация, детальное проектирование API и архитектуры" - это реально шляпа. не знаю как в Django, на Ruby есть DSL'ки которые по коду (не по тестам) формируют документацию API. пишешь код - и автодока готова. это тоже на любителя, но все же.
"Технический долг: Отсутствие тестов в платежной системе". ну это просто ))). какой же это технический долг? это просто безумие чистой воды. Такая разработка и есть деньги инвесторов на ветер. Непокрытие тестами (фич особо) уже неприемлемо, но когда речь о клиентском сервисе связанным с деньгами и оплатой - ну, просто слов нет. этого просто не может быть. первая же бага, когда саппорту прилетит от одного клиента финансовая проблема с его деньгами - заблокирует все. а если представить, что сервисом пользуются тысячи и прилетит 100 таких багов - да вы просто не разгребете и бизнес просто встанет. вы же не Яндекс, с неограниченными человеко-ресурсами.
PS. в данном случае и я заподозрил, что статья какой-то фейк. не мог никакой СТО даже самый упоротый и никакая компания даже самая упоротая выкатит платежную систему без 100% покрытия тестами. другие участки кода можно меньше покрывать, но не этот.
не пойму, почему автор дезинформирует нас о причинах почему , PHP дурно пахнет и в сообществе разработчиков его не жалуют. это совсем не "«Он слишком простой», «Подходит только для новичков» и «Нет серьезных проектов»". просто сам язык Г. как по синтаксису, так и по типу исполнения в ос. и самое главное - его макаронный подход испортил мозги многим, отбросив на много лет переход на нормальные паттерны.
это с некоторых пор пхп комьюнити одумалось и успела впрыгнуть в последний вагон поезда. MVC и подобные фреймворки и некоторые моменты системные слизанные под копирку с других языков - единственное что оставило его на плаву.
ну и конечно - это наследие. пых реально стал очень популярным и захватил в свое время почти все серваки. сколько понаделали сайтов и проектов на нем. и CMS и тп. так что имея такой прицеп-тележку разумеется как откажешься и всех переучишь. потому сидят на том что было, обновляются в подходах и возможностях вслед за нормальными языками.
когда новые молодые лиды берут с нуля писать серьёзный и не серьёзный проект на нем - это конечно вызывает вопросы. но тоже вкусовщина. да и это наследие пыха еще остаётся в кадрах. найти пышника пока еще проще.
автор не в курсе, что история циклична, а мода изменчива. плюс нужно уметь сдерживать эмоции и текущие "вау" от происходящего, рисуя картины будущего с претензией на правдивость. аппроксимация от несдержанного ума всегда слегка параноидальна и чрезмерна.
касательно регулярного роста уровня абстракции, на которых разработчик реализовывает идеи - что есть, то есть. история программирования всегда открывала и предоставляла новые и более высокие уровни, которые все ближе приближаются к чистой бизнес логике. но, причем тут ИИ? этого можно достигать выпуская новые фреймворки, придумывая новые подходы, генераторы и прочее. ИИ может в этом помочь просто как еще один инструмент (бездушный). но не более.
момент, когда желания изложенное текстом или условным конфигом может превратиться в готовый протестированный программный продукт - не завязан на ИИ. этот процесс и так идет. и лично я предпочел бы, чтоб это был не черный ящик нейросети, агрегирующий коды и выдающий никому непонятный рабочий результат - а чтоб это был плод человеческого ума, где прослеживалась бы персонализированная идея автора, которую можно почитать, внести правки и все прочее, что мы любим. но даже в том утопическом бездушном будущем, обрисованным автором статьи, мода на человеческий код, как и возврат к музыкальным инструментам, когда после появления синтезаторов тоже много пророчествовали про уход на покой живой музыки - так же может появиться. и опять актуально то, что сейчас мнится угасающим. все циклично. о чем я уже упомянул. и это мы еще не берем и просто неизвестный нам на данный момент сценарий развития событий. технологии тоже не стоят, кто знает вообще что будет. может, ИИ покажется детским садом.
обязательные регулярные дейли-созвоны в одно и то же время (по утрам как правило) - это по факту основная и самая прoтивнaя особенность скрама.. абсолютно бессмысленное действо, сколько бы ни рисуй табличек и не описывай пользы.
все созвоны командой - должны быть или по необходимости, или по точкам необходимой синхронизации. и один день - ну очевидно, абсолютно никак не может рассинхронизовать людей, делающих свое дело. это полный бpeд. интервал общей синхронизации должен быть соизмерим с некорректным путем работ, который в самом неверном раскладе самого непонимающего участника команды может случайно образоваться. и это точно не один рабочий день, когда у всех есть мозги.
а необходимость в этом только у проджект-менеджеров, чтоб ощущать свою ежедневную "работу". и для суетливых тимлидов.
не человек для методологии, но методология для человека. если бы эти дейлики были бы просто по желанию кофе-брейк да по общаться и возможно что-то сообщить при желании (хотя чаты для этого есть всегда) - вопросов бы не было.
PS. про то что, некоторым нужно утром подольше поспать, чтоб быть продуктивными и что такая "гибкая" методология не дает нормально это сделать - молчу.
если компания держит такого архитектора который не пишет код, а лишь раздаёт указания по его реализации - значит, явно обходятся одними мидлами и джуниорами.
сеньорам, конечно, тут ловить нечего... чтоб кто-то решал на таком уровне как че внедрять и просто давал тебе на реализацию методы, классы и подобное - это как студентам на практике решать задачки препода. несерьезно и неинтересно. точнее, это норм на определённом этапе опыта. но когда ты уже сам начинаешь рубить архитектурную фишку и способен от а до я эффективно реализовать бизнес-задачу потому что уже прокачался - ты сам себе архитектор. и это правильно. никто лучше не сделает. техлид только должен дирижировать всем процессом и командами, задавая или проверяя паттерны и технологии, чтоб увязать это все в единый продукт. и более никто не нужен. ну и тимлиды понятно. имхо.
почему фантастика. че тут такого. это как бы изначально понятно было. чем исходный код ИИ не рядовой источник данных. ИИ играл в шахматы сам с собой и научился. пусть играет в модификацию своего же кода и запускает обновлённые версии себя, переключается на более эффективные и стабильные и так далее.
какая забавная задачка для конструктивной математики:
на карте 100 городов поочерёдно соединены друг с другом прямыми линиями, образуя одну итоговую, проходящую через каждый город один раз. какова вероятность, что это самый короткий маршрут, по которому птица могла бы облететь все эти города?
заглянуть в будущее для понимания математических признаков самого короткого маршрута у такого количества городов, дабы предложить однозначность решения задачки и настаивать на нем не получится в данном случае, верно?
о чем вообще толкует автор. если главной причиной всему - нейросети.
отжали таки труд и удешевили. плюс корпорации из кожи вон старались по овертону изменить отношение к ремеслу, привив иной паттерн. плохо поди, когда ты подготовил общество и бизнес, а потом выдаешь токены на свое API и тарифные планы. халявные ИИ тоже еще видно будет, да и с другого имеют.
и ещё интересно, неужели CEO или какие высокоабстрактные мыслители PM'ы как-то считают, что ИИ не заменит бОльшую часть их труда? написать код (адекватный) и самое главное мэйниейнить его во времени - задача пока куда сложнее для нейронки, недели получив полное текстовое описание от бизнеса, разбить это на программные сущности и сервисы, и построить план работ.
короче передел рынка. а пргерам надо срочно осваивать нейросети в том числе. и умелое их ежедневное применения в редакторах. скоро бизнес будет требовать подобное на собесах.
статья должна состоять из одного слова:
НЕТ
материя - объект, сознание - у субъекта. неясно, отчего одна часть ученых пытаются в электронах, кварках и прочих занятных шариках и энергиях найти источник сознания. другая часть ученых, имхо, гораздо адекватнее. как ни крути, им приходится сделать вывод, что никакого субъективного опыта материя получить не может.
далее.. либо на этом нужно остановиться и сказать, что мы не знаем почему сознание имеется. либо (и часть ученых это и делают) - допустить/предположить нечто нематериального характера (душу, скажем). и констатировать, что это и есть то, что может переживать субъективный опыт. и это нематериальная субстанция, точнее ни в каких качествах и характеристиках не равна ничему из материального мира. просто параллельно с ним существует. как и прочее - тоже вопрос отдельный.
ps. есть еще фантастический вариант, что поскольку сознание (и я с этим солидарен) не может быть доступно материи - что у самой материи, равно как и у нас людей, есть свои нематериальные сущности, которые связаны с ней и могут испытывать и переживать. этого доказать будет невозможно, потому что нет возможности спросить молекулу, например. ну и в целом - это будет похоже на некий пантеизм такой, еще более сюрный.
когда вышел калькулятор - никто вроде не обезумел, рисуя себе новую веху бухгалтерии в утопичном ламерском стиле. появился инструмент и ок. вели себя сдержанно, а бухгалтера просто стали тыкать кнопки и считать быстрее.
когда, интересно, вся эта фантасмагоричная мишура вокруг ИИ пройдет, и продакты/бизнес приспокоятся от технологий. и просто оставят это программистам, а те решат, как они будут использовать новый калькулятор и когда.
я все понимаю, интересно и прочее. но в стиле обезьян с гранатой перекраивать труд специалистов, не спрашивая их прежде и не до конца понимая к чему это приведёт - это несдержанность. и непрофессиональный подход к делу.
каждый хорош в своей области. накypились будто этим ИИ и носятся теперь. первая же хапка снесла башню. приспокоились бы малень. все само со временем разрулится и придет в равновесие. нужно и полезное разработчики возьмут. при этом не пострадает сознание джуниоров, которые сейчас от всех статей сходят так же с петель разумного подхода к работе, опираясь уже на какой-то утопичный сюр. это я в целом, к слову на тему ИИ и всякие сопутствующие этому зарисовки.
стек гут! лишний только PHP) ну эт шутка.
интересно всегда еще глянуть что поменяется при переезде репы, скажем, на gitlab. сравнить. ci дот файлы или что-то еще.
мне нравится, когда реализация модуля/класса занимает условно страничку (две максимум). простое правило не раздувать решение внутри одной сущности - уже понуждает искать иные пути, которые обычно формируют правильный подход к разделению.
новые поколения регятся, а существующие еще активны и не удаляются. это кратный рост. но когда-нибудь случится насыщение - если от дедов до детей все будут зарегины. эта велична будет плюс минус держаться/колебаться. но уже никаких "в разы".
ps. параллельно с этим другой вопрос возникнет. как быть с миллионами мёртвых страниц, никнеймов и тп. всегда про это думал, как будут решать. возможно префиксами new:nick. может и иначе. отнимать прошлые ссылки и давать новым вряд ли хорошая идея.
почему-то всегда упущена одна важная причина делить на микросервисы. точнее, на разные кодовые базы.
у проекта могут быть разные уровни доступа с точки зрения бизнеса. когда нельзя чтоб каждый разраб, от джуна новичка первого дня работы до матёрого сеньора десяток лет трудящегося на благо кампании клонировали себе один и тот код.
я вот, лично, всегда дико удивляюсь, когда меня кидают на новый проект и я вдруг, как новый человек в компании, вижу какой-то код, который ну как бы, возьму его невзирая на NDA и у меня будет работающий бизнес, какой-нибудь криптообмен готовый. а я всего-то занимался фичами настройки профиля, отчетами. зачем короче это всем давать?
равно как зачем человеку, который реализовывает модуль безопасности/аутентификации иметь какой-то хлам в коде, да еще возможно как-то завязанный, который нужно использовать. видение какого-нибудь олдскульного разработчика админки на то, какая должна быть табличка users, че там индексировать и так далее.
вот это еще важные причины делить монолит.
короче, я считаю что в том, как дробить одно большое на части - удобству и доступам к репозиторию разным разработчикам нужно уделять не меньше внимания, чем выделению функциональных независимых единиц из предметной области бизнеса.
если в рамках одного языка - единое соглашение по неймспейсам во всех микросервисах достаточно, при условии общих соглашений по конфигу. а сливать разные кодовые базы в одну - не всегда хорошее решение. а в некоторых случаях бизнеса и разделения уровней доступа - просто невозможное. и разные репозитории строгая необходимость.
имхо, адекватный набор разных кодовых баз для явно специфичных доменов предметной области со своей независимой функциональностью - штука хорошая. просто нужно уметь это готовить. плохо организованные микросервисы не есть камень в огород микросервисов. это камень в огород их организации.
можно ли найти универсальный способ описания предметной области? ДА. можно ли найти универсальный способ проектирования архитектуры? ДА.
но. я к чему. если спокойно подумать, чего ради и зачем мы то или иное ищем, делаем, внедряем? что первостепенно, эта универсализация? разработка как наука, которая побуждает или толкает нас делать так или сяк? или первостепенен real world, с задачами бизнеса? или первостепенна наша нервная система и раскалённый порой до предела мозг? или личная жизнь? или перфекционизм? или первостепенны следующие поколения, кому как нам кажется мы передаем свой код, когда увольняемся? отвечать на эти вопросы важнее.
удивительно, но ответы на эти вопросы и их (как говорят психологи) проработка - достаточно влияет на то, какой код и с какими паттернами мы будем писать и как себя ощущать. тимлиды хорошо знают это. хорошо видят разных разработчиков и их заморочки по коду и архитектуре. и очень часто говорят о заморочках личности. в полной мере паттерны не бывают абстрагированные от личности разработчика.
в общем универсальная таблетка того или сего, как формализовать предметную область или как спроектировать архитектуру, паттерны и тп - важны, но могут отводить внимание от более важных вопросов с точки зрения приоритетов. мозг прогера это отдельная история, и я понимаю как он цепляется и заигрывается с новыми интересными знаниями. но порой это напоминает кошек, которым сносят крышу при виде лазерной точки от указки и они носятся за ней как угарелые. мне иногда кажется, что паттерны для нас что-то подобное.
резюме коммента: сначала главное, потом второстепенное. и поменьше прогерских инстинктов. будем более свободными, менее загруженными и более счастливыми.
"Я предложил наш обычный подход: сначала документация, детальное проектирование API и архитектуры" - это реально шляпа. не знаю как в Django, на Ruby есть DSL'ки которые по коду (не по тестам) формируют документацию API. пишешь код - и автодока готова. это тоже на любителя, но все же.
"Технический долг: Отсутствие тестов в платежной системе". ну это просто ))). какой же это технический долг? это просто безумие чистой воды. Такая разработка и есть деньги инвесторов на ветер. Непокрытие тестами (фич особо) уже неприемлемо, но когда речь о клиентском сервисе связанным с деньгами и оплатой - ну, просто слов нет. этого просто не может быть. первая же бага, когда саппорту прилетит от одного клиента финансовая проблема с его деньгами - заблокирует все. а если представить, что сервисом пользуются тысячи и прилетит 100 таких багов - да вы просто не разгребете и бизнес просто встанет. вы же не Яндекс, с неограниченными человеко-ресурсами.
PS. в данном случае и я заподозрил, что статья какой-то фейк. не мог никакой СТО даже самый упоротый и никакая компания даже самая упоротая выкатит платежную систему без 100% покрытия тестами. другие участки кода можно меньше покрывать, но не этот.
не пойму, почему автор дезинформирует нас о причинах почему , PHP дурно пахнет и в сообществе разработчиков его не жалуют. это совсем не "«Он слишком простой», «Подходит только для новичков» и «Нет серьезных проектов»". просто сам язык Г. как по синтаксису, так и по типу исполнения в ос. и самое главное - его макаронный подход испортил мозги многим, отбросив на много лет переход на нормальные паттерны.
это с некоторых пор пхп комьюнити одумалось и успела впрыгнуть в последний вагон поезда. MVC и подобные фреймворки и некоторые моменты системные слизанные под копирку с других языков - единственное что оставило его на плаву.
ну и конечно - это наследие. пых реально стал очень популярным и захватил в свое время почти все серваки. сколько понаделали сайтов и проектов на нем. и CMS и тп. так что имея такой прицеп-тележку разумеется как откажешься и всех переучишь. потому сидят на том что было, обновляются в подходах и возможностях вслед за нормальными языками.
когда новые молодые лиды берут с нуля писать серьёзный и не серьёзный проект на нем - это конечно вызывает вопросы. но тоже вкусовщина. да и это наследие пыха еще остаётся в кадрах. найти пышника пока еще проще.
автор не в курсе, что история циклична, а мода изменчива. плюс нужно уметь сдерживать эмоции и текущие "вау" от происходящего, рисуя картины будущего с претензией на правдивость. аппроксимация от несдержанного ума всегда слегка параноидальна и чрезмерна.
касательно регулярного роста уровня абстракции, на которых разработчик реализовывает идеи - что есть, то есть. история программирования всегда открывала и предоставляла новые и более высокие уровни, которые все ближе приближаются к чистой бизнес логике. но, причем тут ИИ? этого можно достигать выпуская новые фреймворки, придумывая новые подходы, генераторы и прочее. ИИ может в этом помочь просто как еще один инструмент (бездушный). но не более.
момент, когда желания изложенное текстом или условным конфигом может превратиться в готовый протестированный программный продукт - не завязан на ИИ. этот процесс и так идет. и лично я предпочел бы, чтоб это был не черный ящик нейросети, агрегирующий коды и выдающий никому непонятный рабочий результат - а чтоб это был плод человеческого ума, где прослеживалась бы персонализированная идея автора, которую можно почитать, внести правки и все прочее, что мы любим. но даже в том утопическом бездушном будущем, обрисованным автором статьи, мода на человеческий код, как и возврат к музыкальным инструментам, когда после появления синтезаторов тоже много пророчествовали про уход на покой живой музыки - так же может появиться. и опять актуально то, что сейчас мнится угасающим. все циклично. о чем я уже упомянул. и это мы еще не берем и просто неизвестный нам на данный момент сценарий развития событий. технологии тоже не стоят, кто знает вообще что будет. может, ИИ покажется детским садом.
короче, работаем. там будет видно.
обязательные регулярные дейли-созвоны в одно и то же время (по утрам как правило) - это по факту основная и самая прoтивнaя особенность скрама.. абсолютно бессмысленное действо, сколько бы ни рисуй табличек и не описывай пользы.
все созвоны командой - должны быть или по необходимости, или по точкам необходимой синхронизации. и один день - ну очевидно, абсолютно никак не может рассинхронизовать людей, делающих свое дело. это полный бpeд. интервал общей синхронизации должен быть соизмерим с некорректным путем работ, который в самом неверном раскладе самого непонимающего участника команды может случайно образоваться. и это точно не один рабочий день, когда у всех есть мозги.
а необходимость в этом только у проджект-менеджеров, чтоб ощущать свою ежедневную "работу". и для суетливых тимлидов.
не человек для методологии, но методология для человека. если бы эти дейлики были бы просто по желанию кофе-брейк да по общаться и возможно что-то сообщить при желании (хотя чаты для этого есть всегда) - вопросов бы не было.
PS. про то что, некоторым нужно утром подольше поспать, чтоб быть продуктивными и что такая "гибкая" методология не дает нормально это сделать - молчу.
если компания держит такого архитектора который не пишет код, а лишь раздаёт указания по его реализации - значит, явно обходятся одними мидлами и джуниорами.
сеньорам, конечно, тут ловить нечего... чтоб кто-то решал на таком уровне как че внедрять и просто давал тебе на реализацию методы, классы и подобное - это как студентам на практике решать задачки препода. несерьезно и неинтересно. точнее, это норм на определённом этапе опыта. но когда ты уже сам начинаешь рубить архитектурную фишку и способен от а до я эффективно реализовать бизнес-задачу потому что уже прокачался - ты сам себе архитектор. и это правильно. никто лучше не сделает. техлид только должен дирижировать всем процессом и командами, задавая или проверяя паттерны и технологии, чтоб увязать это все в единый продукт. и более никто не нужен. ну и тимлиды понятно. имхо.
без всякого извечного холивара, но для рубистов "читабельность", "удобство" и тп у питона - это, конечно, как бревном в глаз.