Comments 13
У уборщиц не как у программистов: пока они работают, английский язык не тренируют. По-русски надо общаться, господа, по-русски! )
Всё круто и правильно, и вроде бы придираться к орфографии это дурной тон, но когда я вижу "типо" где-либо вне неофициальной переписки — как полосатый слон "теряю волю" 8(
Вы изобрели lazy refactoring
Есть ряд вопросов к автору:
1. Лезем в воду, не зная броду. На чужой код, который вы планировали рефакторить были написаны тесты? Вы не задумывались почему каждый новый разработчик создавал, свой новый компонент, а не переиспользовал старые? Может на то были причины, чтобы например изолировать свой код, который понятно на что влияет и в который можно предсказуемо вносить изменения, от чужого?
2. В статье описан процесс организации, но не описаны причины и результаты. Например что стало с проектом, через 3 месяца такого рефакторинга? Что стало лучше, что стало хуже, много ли было работы, не выгорели ли под гнётом миллиона ту-ду?
3. Заказчику как правило фиолетово на ваши технические задачи, ему важны только сроки по его бизнес-задачам, которые влияют на функциональность. Как в вашем случае заказчик оценивает эту работу? Нужен ли ему рефакторинг и не кажется ли ему, что вы создаете имитацию бурной деятельности? Может заказчику и не нужно знать об техдолге, а часы на него проще прятать в бизнес-задачи?
1. Лезем в воду, не зная броду. На чужой код, который вы планировали рефакторить были написаны тесты? Вы не задумывались почему каждый новый разработчик создавал, свой новый компонент, а не переиспользовал старые? Может на то были причины, чтобы например изолировать свой код, который понятно на что влияет и в который можно предсказуемо вносить изменения, от чужого?
2. В статье описан процесс организации, но не описаны причины и результаты. Например что стало с проектом, через 3 месяца такого рефакторинга? Что стало лучше, что стало хуже, много ли было работы, не выгорели ли под гнётом миллиона ту-ду?
3. Заказчику как правило фиолетово на ваши технические задачи, ему важны только сроки по его бизнес-задачам, которые влияют на функциональность. Как в вашем случае заказчик оценивает эту работу? Нужен ли ему рефакторинг и не кажется ли ему, что вы создаете имитацию бурной деятельности? Может заказчику и не нужно знать об техдолге, а часы на него проще прятать в бизнес-задачи?
- Не знаю в какой вы там брод лезете. Нет, тесты на styled-component никто не писал. Думаю это несколько бредовое занятие. Какой каждый новый разработчик? Там была определённая команда и они выбрали такой код стайл — создавать новый styled-component в стилях рядом с каждым контейнером.
- Мне очень приятно, что вы отметили соответствие текста статьи её названию.
Через 3 месяца стал более понятный сторибук. Не выгорели. Ничего не стало хуже. Работы было много, но с некоторыми видео пояснениями и блок схемами монотонную работу отдали джунам. Затем я за ними доделал работу. Под гнетом миллиона туду не выгорели, Т.к его на было - Я с заказчиком играю против правил. По этому объяснив плюсы и пообещав больший контроль за проектом приступил к работе. Рефакторинг ему оказался нужен. Может и не нужен, тут уж я не спрашивал. По итогу ему очень понравилась новая версия проекта.
1. Если это простые компоненты по 15 строчек, то весь этот ритуал с какими то скриптами и туду зачем? Поправил сразу на месте и забыл. ИБД? Опять же не очень вообще понял в чем «рефакторинг» состоял? Обертки для тупых компонентов подправить во всем проекте?
2. У вас в статье написано, что вы были один на проекте. Откуда джуны взялись?
3. Ну то есть вы подтвердили мою мысль — заказчику знать об технических задачах не стоит, если он явно об этом не просит (например если ему не понятен почему выставлен такой большой естимейт по задаче и нужно детально расписать). Вы же не докладываете заказчику сколько компонентов за неделю создали или строчек css написали? Это чисто технические нюансы. Если для выполнения бизнес-задач требуется рефакторинг, то он должен быть заложен в эстимейты этих бизнес задач. Это утверждение конечно с оговоркой, оно не относится к большим проектам — когда появляются прослойки между заказчиком и разработчиками в виде ПМов, тимлидов, аналитиков, но даже в таком случае все технические задачи декомпозируются из бизнес-задач, просто для бизнеса они не существенны, а для ПМ\тимлида могут быть важны.
2. У вас в статье написано, что вы были один на проекте. Откуда джуны взялись?
3. Ну то есть вы подтвердили мою мысль — заказчику знать об технических задачах не стоит, если он явно об этом не просит (например если ему не понятен почему выставлен такой большой естимейт по задаче и нужно детально расписать). Вы же не докладываете заказчику сколько компонентов за неделю создали или строчек css написали? Это чисто технические нюансы. Если для выполнения бизнес-задач требуется рефакторинг, то он должен быть заложен в эстимейты этих бизнес задач. Это утверждение конечно с оговоркой, оно не относится к большим проектам — когда появляются прослойки между заказчиком и разработчиками в виде ПМов, тимлидов, аналитиков, но даже в таком случае все технические задачи декомпозируются из бизнес-задач, просто для бизнеса они не существенны, а для ПМ\тимлида могут быть важны.
- Что можно сделать скриптом — сделал скриптом. Логика в том, чтобы ускорить.
- Shadow mode)
- Диоген объяснил, что нужна только бочка. По этому да, по сути подтвердил. Да и проект ему не нужен, по этой же логике
А если серьёзно, то обычно работаю с заказчиками людьми, с ними можно разговаривать.им какие-то вещи нравятся, какие-то нет. Не вижу причин решать за них, что им нужно, а что нет. За спрос ещё ни разу не били, только спасибо говорили.
Блин, с телефона дублировался комментарий, а удалить не могу. Извиняюсь за мусор...
Sign up to leave a comment.
Трёхпроходный алгоритм рефакторинга Front End