Рефакторинг программного обеспечения. Лекция 1

[@hardlandingtac]

Вот, кстати, вспомнил, есть у меня на канале пример рефакторинга (помимо основной темы ролика) называется "Принцип единой ответственности (SRP) - что с ним не так?". Там в оригинале приводится пример программирования игры в боулинг. Причем делается явно не понимая, что такое ООП. Так вот там четко видно, что если исходить из логики авторов, то никаким рефакторингом невозможно дойти до нормального решения. И продолжать делать рефакторинги, это только добавит каши. Поэтому нужно сразу делать крупный рефакторинг, но его нужно перетестировать, ибо сразу новая логика может не получится. Но оставлять как есть, тоже такое ... это пример, как раз того, что вся ваша теория не соответствует практике.

[@hardlandingtac]

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

[@LidiyaHITS]

Благодарю за ваше мнение. Не стоит забывать, что компании бывают разные, у всех свои процессы. Как минимум странно будет на дэйлике менеджеру на вопрос "какую задачу делаешь" ответить "не скажу". Тимлиды есть не везде, иногда менеджер выполняет все роли сразу.

[@hardlandingtac]

@@LidiyaHITS Сейчас заметил, что у вас на слайде когда делать рефакторинг, не очень точно передается правило 3 ударов, там нужно слово "делаете" заменить на "натолкнулись". Так вот тогда, я говорю о том, что нужно взять это правило + встроить в процесс (по смыслу близко, что у вас как мнение 4). Ну и далее, у вас правильный список "Когда рефакторинг не делать". И вот тогда - объяснять кому то, что я делаю рефакторинг не нужно. Просто делайте, не выделяя в отдельную задачу. А вместо не скажу, говорить, что делаю все тоже, что и делал на прошлой неделе. Ну, или же нет у руководства понимания, отказывайтесь делать задачу, или говорите о нереалистичных сроках. Не делать нужный рефакторинг - такой опции нет, это все равно что врач будет спрашивать резать или не резать. Ну и чтобы не вставать два раза - слайд поиск места для рефакторинга - плохой. Тут нужно говорить о ревью проекта в целом, и находить самое уязвимое место. Ну и говорить про "дурные запахи по Фаулеру". А то ,что на слайде - это не практично, так экзотика. Ну а вообще все ок, мне нравится стиль ведения лекции ) ах, да - на вопрос "на дэйлике менеджеру " - еще лучше говорить, что он тратит мое время, хочет узнать пусть делает ревью коммитов. Это значит, что в правильно организованных процессах - менеджер - это сеньор, который делает ревью и на дейликах именно он говорит, что кому исправить, а не наоборот.

[@TV-xj5ke]

Не соглашусь. У заказчика есть потребность в определенной ценности, которая решает его проблему. Если каждый раз проект будет сдвигаться вправо, то просто найдут ему замену. Всему своё место, в том числе и рефакторингу. Если потребность в рефакторинге реально есть (не выдумана), то любой менеджер это поймет и не надо будет ничего скрывать.

[@hardlandingtac]

@@TV-xj5ke Вообще, каждый отдельный рефакторинг занимает небольшое время, в идеале час-два. Есть рефакторинги, которые просто нельзя не делать, чтобы добавить функциональность. Например, устранение дублирования при добавлении аргумента в метод. Вообще я ищу конкретные примеры, чтобы продемонстрировать. Так можно говорить конкретнее. Но есть рефакторинги которые тянут изменения на пару недель. Такие я часто вижу, когда прихожу на новый проект, который делали джуниоры. Вот тогда и начинаются психи со всех сторон, так вот прежде чем ворошить эту кучу говна, нужно хорошо подумать ... можно остаться виноватым, что все перестанет работать :) Менеджерам нужно понимать, что после рефакторинга это нужно будет перетестировать, на что они не готовы.