Зафиксировать текущее состояние продукта в части фичеобразования.
Зачастую это невозможно. Продукту нужно постоянное развитие, иначе клиенты уходят к вашим конкурентам. Только если вы монополист или плевать на всех.
Сформулировать требования и новую архитектуру.
Невозможно. Как я писал в статье — в фирме никогда и никто не знает, как работает продукт во всех деталях. Если у вас есть четкие спецификации на ВЕСЬ функционал и вы не отходите от них ни на шаг — тогда еще что-то возможно. Но в реальном мире у вас будет лишь референсная реализация — собственно, ваш работающий продукт. И при переписывании вы вынуждены будете повторить все его недостатки.
Перевести законсервированный продукт в режим «только тех.поддержка и ничего более».
Невозможно. См. первый пункт.
В какой-то момент запустить миграцию клиентов.
И просто утонуть в фидбеке о том, насколько новый продукт не соответствует ожиданиям. Пример кинопоиска, кстати.
Вывести из работы старый продукт, полностью переключится на новую платформу.
В реальности происходит миграция обратно.
Все это я видел на своем собственном опыте. Sounds good, doesn't work. Все, что можно себе позволить — медленно и кусками двигать проект из состояния «сейчас» в состояние «как бы мы хотели». Переделать UI, оставив бекенд. Переделать бекенд, оставив интерфейс API, поменять базу не меняя бекенда и так далее.
Еще раз повторюсь — у меня есть удачный и неудачный опыт. Удачный опыт всегда связан с медленными изменениями на живом проекте. Неудачный — всегда с переписыванием с 0.
Даже если и консервировать, то все равно инфраструктура под проектом будет ехать вперед. По поводу переписывания — если это что-то умещается в рамках двух спринтов, то можно переписать. Если не надо мигрировать существующих клиентов — можно переписать. Во всех остальных случаях (мое мнение) команда должна (уметь) модифицировать проект в процессе его эксплуатации, подстраиваясь под постоянно изменяющиеся требования.
Интересно, откуда у этого никудышного коллектива такой сложный продукт взялся?
По-разному бывает. Но основная причина в том, что коллектив не справляется на длинной дистанции, а не на короткой. И тут уже не особо важно, откуда взялся проект — или его этот же коллектив написал, или приняли от предыдущей команды. Важно как раз то, и на чем делался акцент, что удержание проекта в адекватном состоянии требует постоянных усилий.
Я могу только своими ощущениями поделиться тут, т.к. пробовали в лиспе их (кложура) и в эликсире, эрланге и совсем немного в скале — в лиспе макросы это легко и приятно, потому так часто ими пользуются. В других языках сразу как-то становится несколько трудно и начинает требовать дополнительных ментальных усилий. Я связываю это исключительно с синтаксисом — S-expressions идеально подходят для такого стиля, а вот остальные языки — не очень.
Тут речь у Спольски идет скорее о том, что если вы не смогли удержать ведение проекта на протяжении последнего (сравнительно продолжительного) времени, то, скорее всего, у вас не получится этого сделать и при переписывании. Рекомендую прочитать статью по ссылке.
Erlang/Elixir. Но это подход из далеких 80-х и Смолтолка вполне вытеснился «пишу тест, запускаю тест». REPL DD это архаика.
Хотрелоад.
даже в Erlang, если вы не пишете для железки, никто практически этим не пользуется. Эра кубернетеса и контейнеров делает это все ненужным. Работаю с Эрлангом последние 7 лет если что.
Макросы даже сейчас далеко не в каждом языке есть.
макросы это один из видов решения конкретной проблемы. Не единственная. Макросы за пределами Лиспа очень трудны в освоении и очень сомнительная фича.
К предыдущему комментарию только добавлю макросы в Scala и Elixir. В последнем они довольно широко используются. Только я не уверен, что за пределами языка с S-expressions макросы это хорошая идея.
Лисп и Хаскель вряд ли могут стоять рядом в таком контексте. Лисп (комон) такой же функциональный, как и современный JS, и позволяет писать вполне себе императивный код.
… автор не говорит бладаря чему этот технический долг появляется.
Говорит, но чуть ниже по тексту:
Технический долг же — это сумма накопленных, но не согласованных в рамках системы изменений, сумма не упорядоченных между собой артефактов эволюции, которая и приводит к экспоненциальному нарастанию сложности, о которой говорилось выше.
Зачем спрашивать про задачи (пункт 2), если тимлид и так должен быть в курсе этого всего, т.к. обязан присутствовать на статусных митингах? И да, превращение 1-1 в еще один статусный митинг это, мне кажется, самый распространенный антипатерн из всех.
Однако в 2018 году правила GDPR запретили рекламодателям выгружать данные пользователей, так как они взаимодействуют с сайтом паблишера, а не рекламодателя.
Это не имело отношения к адвертайзерам вне ЕС, тем не менее, доступ к user-level data отняли у всех. Как и возможность добавлять свои 3rd-party pixels и сервить маркапы у себя на YouTube, например, что фактически отняло возможность независимого трекинга/сборка статистики. И тут появился ADH. Да, свои user-level данные можно загрузить, а вот получить их от Гугла — нет. Т.е. сегмент выгрузить у вас даже за доп. деньги не выйдет, чтобы использовать его где-то вне, на условном трейдеске каком.
Как-то уж слишком кратко получилось :) Пара уточнений. PMP это еще и часть протокола OpenRTB – можно было бы уточнить, что конкретно имеется в виду. Ну и Sizmek уже больше полугода как не имеет своей DSP, а является Ad Server'ом.
В моей практике были разные «плохие проекты» и я согласен с тезисом статьи, но при одном дополнении – «если вам не предоставляют возможности его исправлять». В моей практике случались ситуации, когда команда (коллектив) получали право принятия решений, был внутренний консенсус, и в итоге проект оставляли в гораздо лучшем состоянии, чем он был до того. Но если от прав остались только обязанности, а внутреннего согласия у команды нет – ничего не будет. Крупное IT это командный вид спорта все же, одному не выплыть.
Вот как раз «байткод» может быть одинаковым, т.к. практически любой современный компилятор скорее всего развернет цикл. Но допустим, что все оптимизации мы выключили. Полученный результат будет таким же, но характеристики алгоритма стали другими — как минимум, мы увеличили расход памяти на индексную переменную. В данном конкретном случае это несущественно, и там и там константное, но в других случаях это может быть и будет совсем не так. И аналогия перестанет работать. В одних случаях мы обменяем скорость на память, в других наоборот.
Какое преобразование выражения есть в написании цикла? Вообще-то, десять раз написать принт и написать его один раз с подстановкой индекса в цикле — это не эквивалентные реализации. Я не понимаю, зачем вы упорно цепляетесь за эти преобразования, пытаясь натянуть их на алгоритмизацию задачи.
Невозможно. Как я писал в статье — в фирме никогда и никто не знает, как работает продукт во всех деталях. Если у вас есть четкие спецификации на ВЕСЬ функционал и вы не отходите от них ни на шаг — тогда еще что-то возможно. Но в реальном мире у вас будет лишь референсная реализация — собственно, ваш работающий продукт. И при переписывании вы вынуждены будете повторить все его недостатки.
Невозможно. См. первый пункт.
И просто утонуть в фидбеке о том, насколько новый продукт не соответствует ожиданиям. Пример кинопоиска, кстати.
В реальности происходит миграция обратно.
Все это я видел на своем собственном опыте. Sounds good, doesn't work. Все, что можно себе позволить — медленно и кусками двигать проект из состояния «сейчас» в состояние «как бы мы хотели». Переделать UI, оставив бекенд. Переделать бекенд, оставив интерфейс API, поменять базу не меняя бекенда и так далее.
Еще раз повторюсь — у меня есть удачный и неудачный опыт. Удачный опыт всегда связан с медленными изменениями на живом проекте. Неудачный — всегда с переписыванием с 0.
По-разному бывает. Но основная причина в том, что коллектив не справляется на длинной дистанции, а не на короткой. И тут уже не особо важно, откуда взялся проект — или его этот же коллектив написал, или приняли от предыдущей команды. Важно как раз то, и на чем делался акцент, что удержание проекта в адекватном состоянии требует постоянных усилий.
даже в Erlang, если вы не пишете для железки, никто практически этим не пользуется. Эра кубернетеса и контейнеров делает это все ненужным. Работаю с Эрлангом последние 7 лет если что.
макросы это один из видов решения конкретной проблемы. Не единственная. Макросы за пределами Лиспа очень трудны в освоении и очень сомнительная фича.
Говорит, но чуть ниже по тексту:
Это не имело отношения к адвертайзерам вне ЕС, тем не менее, доступ к user-level data отняли у всех. Как и возможность добавлять свои 3rd-party pixels и сервить маркапы у себя на YouTube, например, что фактически отняло возможность независимого трекинга/сборка статистики. И тут появился ADH. Да, свои user-level данные можно загрузить, а вот получить их от Гугла — нет. Т.е. сегмент выгрузить у вас даже за доп. деньги не выйдет, чтобы использовать его где-то вне, на условном трейдеске каком.
Значит, вы не смогли ее донести.