Комментарии 6
А могли бы выкинуть PHP под шумок и заменить на язык программирования а не это вот всё
Точнее на что-то компилируемое со статической типизацией.
Например, rust/c#/java/go
Rust чуть сложнее пишется, но гораздо удобней сопровождается
Никому этот рефакторинг не нужен судя по моему опыту и по опросу в моей статье
https://habr.com/ru/articles/855822/
Рефакторинг нужен был чтобы это можно было както потдерживать. Когда у тебя каждый день по 2 инцидента это не очень прикольно.
И основное было то что это рабочий бизнес который приносит деньги и его не можно остановить или заморозить.
По поводу интеграции новых языков или переход на них - имеет место быть в виде отдельных компонентов (сервисов). Сам проект никто не будет переписывать в этом нет смысла.
Скажите, кто был владельцем ресурсов и насколько сложно было согласовать выделение ресурсов на задачи не связанные напрямую с новыми фичами или инцидентами?
У меня на памяти было 4 рефакторинга подробно масштаба. Половина успешных)
Один успешный когда мы не могли выпустить релиз с большими изменениями без обновления основного кода.
Второй успешный когда система использовалась условно раз в квартал, но уж если падал то все на уши становилось. Тогда было время чтобы проактивно всё изучить и так ничего и не поняли из-за путаной реализации. В результате просто модуль переписали с нуля и с тех пор всё работает как часы, в итоге нас перевели на другой продукт.
Рефакторинг по моей статье куда дал ссылку трудно назвать полностью успешным из-за постоянного отвлечения на другие задачи и короткого жизненного цикла продукта.
И по ещё одному я подробностей не помню. Я выдвигал умные мысли а все крутили пальцем у виска: туши пожар, как потушишь начинай тушить следующий, как закончишь все - переведем на другой продукт. Круглое кати , квадратное тащи. Всё.
Грузчик. Грузчик.
Бери побольше, неси подальше.
Круглое тащим, квадратное катим.
Три нормы в день при низкой зарплате.
Трудно ли это? Сам поразмысли!
Грязные руки. Но чистые мысли.
Чугунные мышцы, суровые лица.
Пусть и в пыли, но нам есть, чем гордиться.
Тонна угля, две тонны цемента
Грузим с обеда до финишной ленты.
Греческий профиль, осанка и стать -
Этого мало, чтоб грузчиком стать.
Мало работать, мало учиться.
Грузчик – судьба. Им надо родиться
Скажите, кто был владельцем ресурсов и насколько сложно было согласовать выделение ресурсов на задачи не связанные напрямую с новыми фичами или инцидентами?
Владельцем ресурса был PO. Первый год выделения ресурсов и времени на тех задачи было легко, потому что все понимали что у нас есть проблемы которые по другому уже не решаются. Дальше все становилось сложнее это делать и приходилось или завышать оценку для задачи и делать вместе с бизнес фичей или заниматься мне как TechLead самостоятельно этим без привлечения ресурсов команды.
И по ещё одному я подробностей не помню. Я выдвигал умные мысли а все крутили пальцем у виска: туши пожар, как потушишь начинай тушить следующий, как закончишь все - переведем на другой продукт. Круглое кати , квадратное тащи. Всё.
Тут все индивидуально и зависит от многих факторов:
компания - это IT которая нацеленная на качественный продукт или на компанию которая нацелена только на деньги; Мне больше нравиться работать в IT компаниях
команда - готова к изменениям или просто сидит за з/п с 9-18
бизнес - понимания руководства и продвижения идеи к тех изменениям выше
Для единого стиля был написан вебхук
Похоже на просто "хук", без "веб", если речь про файл в .git/hooks, как можно предположить по содержимому
Из легаси в конфетку: история трансформации