Трёхпроходный алгоритм рефакторинга Front End

[teology]

У уборщиц не как у программистов: пока они работают, английский язык не тренируют. По-русски надо общаться, господа, по-русски! )

[mikita_du]

Пояснительную бригаду, пожалуйста

[teology]

Быть культурным и объясняться на русском — это круто. Тем более на английском ты все равно нуб и до их культуры тебе как до лампочки. Так какую бригаду выслать?

[mikita_du]

Ураа, у меня появился хейтер))

[enkryptor]

Всё круто и правильно, и вроде бы придираться к орфографии это дурной тон, но когда я вижу "типо" где-либо вне неофициальной переписки — как полосатый слон "теряю волю" 8(

[mikita_du]

Учту, спасибо.
Обнаружил, что у меня это слово — паразит. По этому в данной статье всё же оставлю, т.к хочется оставить в свободной/разговорной форме статью (честнее что ли...)
А вот для будущих пересмотрю, спасибо)

[enkryptor]

Тут беда не в том, что это слово-паразит, а в том что это родительный падеж слова «тип». То есть должно быть «типа», а не «типо». Какого типа компонент? — Компонент типа кнопки.

[ilya_kochetov]

Вы изобрели lazy refactoring

[baxxter]

Есть ряд вопросов к автору:
1. Лезем в воду, не зная броду. На чужой код, который вы планировали рефакторить были написаны тесты? Вы не задумывались почему каждый новый разработчик создавал, свой новый компонент, а не переиспользовал старые? Может на то были причины, чтобы например изолировать свой код, который понятно на что влияет и в который можно предсказуемо вносить изменения, от чужого?
2. В статье описан процесс организации, но не описаны причины и результаты. Например что стало с проектом, через 3 месяца такого рефакторинга? Что стало лучше, что стало хуже, много ли было работы, не выгорели ли под гнётом миллиона ту-ду?
3. Заказчику как правило фиолетово на ваши технические задачи, ему важны только сроки по его бизнес-задачам, которые влияют на функциональность. Как в вашем случае заказчик оценивает эту работу? Нужен ли ему рефакторинг и не кажется ли ему, что вы создаете имитацию бурной деятельности? Может заказчику и не нужно знать об техдолге, а часы на него проще прятать в бизнес-задачи?

[mikita_du]

1. Не знаю в какой вы там брод лезете. Нет, тесты на styled-component никто не писал. Думаю это несколько бредовое занятие. Какой каждый новый разработчик? Там была определённая команда и они выбрали такой код стайл — создавать новый styled-component в стилях рядом с каждым контейнером.
2. Мне очень приятно, что вы отметили соответствие текста статьи её названию.
   Через 3 месяца стал более понятный сторибук. Не выгорели. Ничего не стало хуже. Работы было много, но с некоторыми видео пояснениями и блок схемами монотонную работу отдали джунам. Затем я за ними доделал работу. Под гнетом миллиона туду не выгорели, Т.к его на было
3. Я с заказчиком играю против правил. По этому объяснив плюсы и пообещав больший контроль за проектом приступил к работе. Рефакторинг ему оказался нужен. Может и не нужен, тут уж я не спрашивал. По итогу ему очень понравилась новая версия проекта.

[baxxter]

1. Если это простые компоненты по 15 строчек, то весь этот ритуал с какими то скриптами и туду зачем? Поправил сразу на месте и забыл. ИБД? Опять же не очень вообще понял в чем «рефакторинг» состоял? Обертки для тупых компонентов подправить во всем проекте?
2. У вас в статье написано, что вы были один на проекте. Откуда джуны взялись?
3. Ну то есть вы подтвердили мою мысль — заказчику знать об технических задачах не стоит, если он явно об этом не просит (например если ему не понятен почему выставлен такой большой естимейт по задаче и нужно детально расписать). Вы же не докладываете заказчику сколько компонентов за неделю создали или строчек css написали? Это чисто технические нюансы. Если для выполнения бизнес-задач требуется рефакторинг, то он должен быть заложен в эстимейты этих бизнес задач. Это утверждение конечно с оговоркой, оно не относится к большим проектам — когда появляются прослойки между заказчиком и разработчиками в виде ПМов, тимлидов, аналитиков, но даже в таком случае все технические задачи декомпозируются из бизнес-задач, просто для бизнеса они не существенны, а для ПМ\тимлида могут быть важны.

[mikita_du]

1. Что можно сделать скриптом — сделал скриптом. Логика в том, чтобы ускорить.
2. Shadow mode)
3. Диоген объяснил, что нужна только бочка. По этому да, по сути подтвердил. Да и проект ему не нужен, по этой же логике
   А если серьёзно, то обычно работаю с заказчиками людьми, с ними можно разговаривать.им какие-то вещи нравятся, какие-то нет. Не вижу причин решать за них, что им нужно, а что нет. За спрос ещё ни разу не били, только спасибо говорили.

[mikita_du]

Блин, с телефона дублировался комментарий, а удалить не могу. Извиняюсь за мусор...