В блоге Sequoia Capital (крупный венчурный фонд) интересная статья с прогнозами по развитию AI сферы. По сути уже года два как формируется новый пласт продуктов сделанных поверх AI. Т.е. кодовая часть для сопровождения этого AI все равно нужна, архитектура тоже) В статье есть также небольшой экскурс в историю. Вообщем краней полезно почитать чтобы понимать куда развивается область Software Services. Картинка говорит сама за себя.

https://www.sequoiacap.com/article/generative-ais-act-o1/

Какой интересный код оказывается есть.

451 Unavailable For Legal Reasons
HTTP-код ответа 451 Unavailable For Legal Reasons указывает, что пользователь запросил ресурс, который недоступен по юридическим причинам, например веб-страница, заблокированная из-за судебных исков.

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/451

Бывают такие статьи который читаешь и прямо перед глазами пробегают ситуации из прошлых проектов. Сегодня статья о 8 ошибках при переписывании проектов/систем. Автор собрал замечательный список. Чаще всего здесь идет речь о переписывании системы в которых вы не принимали участия при проектировании/написании. Выбрал несколько которые особо понравились и откликнулись, остальные читайте в оригинале.

- Планировать миграцию только когда новая система будет "почти готова" - при позднем планировании миграции могут реализоваться риски по несовпадению форматов, стандартов, объема данных. Что-то чего вы не сможете учесть или увидеть при планировании. Что тогда? Возможно откат на пару шагов назад. Что делать? Помнить что есть например паттерны Strangler Fig, Parallel Run они помогут спланировать миграцию с меньшими рисками.

- Недооценивать усилия. Чаще свойственно middle или начинающим senior разработчикам, они уже могут брать на себя много ответственности но еще не попадали в капканы легаси ?. Это когда одна хитрая строчка может стоить пары дней нервных клеток. Что делать? Оценивайте функциональность и объем системы, планируйте по этапам. По поводу планирования связаны две следующие ошибки

- Не спрашивать о функциональности системы, пытаться копировать ее 1:1 и Пытаться заменить всю систему целиком. Спланируйте что вы меняете и почему, возможно у системы есть стабильное ядро и его можно не трогать, или возможно нарекания вызывает только системы которую вполне можно изолировать?

- Оверинжиниринг. Наша любимая программисткая ошибка. Иногда старая система так задалбывает своей отсталостью, что хочется вложить в новую версию все самое свежее и новое. Будьте очень осторожны. История разработки программного обеспечения уже знает такие истории. Легендарный Фредерик Брукс сформулировал Second-System Effect. На смену небольшим и компактным системам приходят неповортливые и раздутые монстры.

Что еще почитать на эту тему?
Patterns of Legacy Displacement (Effective modernization of legacy software systems)

Оригинальная статья "The 8 biggest mistakes when rewriting software systems (that I have seen so far)"

Telegram

Бесконечное ИТ

Всем известен подход для переписывания legacy приложений. Вы скрываете за прокси старое приложение и часть функций постепенно делаете на новом, перегоняя туда трафик. Итерация за итерацией, новая часть становится все больше и настает момент когда старое приложение…