Как я могу сделать рефакторинг приоритетом для моей команды?

Кодовая база, с которой я работаю ежедневно, не имеет автоматических тестов, непоследовательных имен и множества комментариев, таких как «Почему это здесь?», «Не уверен, нужно ли это» или «Этот метод не назван правильно», и код изобилует «Журналы изменений», несмотря на то, что мы используем систему контроля версий. Достаточно сказать, что наша кодовая база может использовать рефакторинг.

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

Как я могу продемонстрировать ценность рефакторинга, чтобы он был добавлен в наши списки задач? Стоит ли просто рефакторинг по ходу дела, прося прощения, а не разрешения?

«Лучше просить прощения, чем разрешения» - это правда.

Зачем беспокоиться об этом? Просто рефакторинг самых ужасных частей.

Вы уже знаете, какие ошибки самые дорогие , верно?

Если вы этого не сделаете, то шаг 1 состоит в том, чтобы точно и недвусмысленно определить наиболее дорогой, сложный, подверженный ошибкам код ошибки.

Определите количество заявок на устранение неисправностей, часы отладки и другие очень конкретные, очень измеримые затраты .

Затем исправьте что-то в этом списке проблем с высокой стоимостью .

Когда вам нужно попросить прощения, вы можете указать на снижение затрат.

Если вы не знаете, рефакторинг требует модульных тестов, чтобы доказать, что поведение до и после совпадает. В идеале это должен быть автоматический кодовый тест, например, модульный тест.

Это значит выбрать одну вещь. Напишите юнит-тест. Исправить это одно. Вы сделали два улучшения. (1) написал тест и (2) исправил код.

Итерация.

Следуйте правилу бойскаутов: оставьте лагерь (код) немного лучше, чем вы его нашли. Я ни разу не слышал, чтобы кто-то был написан за небольшие улучшения кода, «пока они были там».

Я возьму, возможно, чрезмерно циничную точку зрения.

Рефакторинг - такая жесткая таблетка, которую можно проглотить. Вы берете на себя ответственность и вину, и плоды вашего труда часто идут кому-то еще, кто опирается на вашу чистую базу кода.

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

Подумайте о том, чтобы присоединиться к другой компании, где они более серьезно относятся к инженерной практике.

Я замечаю, что многие из постеров здесь, похоже, убеждены, что проблема в управлении - пока этот вопрос не упоминает об этом.

Я бы пошел дальше: по моему мнению, паршивая кодовая база почти никогда не является прямой ошибкой менеджмента. Руководство не написало этот код, разработчики сделали (есть некоторые исключения в моей компании, где некоторые из наших нынешних менеджеров фактически написали исходную базу кода). Поэтому проблема культуры лежит на разработчиках - если они хотят, чтобы культура изменилась, им самим придется измениться.

Я пытаюсь донести эту реализацию и изменение отношения и до «моих» разработчиков. Всякий раз, когда меня спрашивают «когда у нас будет время на рефакторинг?», Я удивляюсь и отвечаю: «Вы уже должны проводить рефакторинг все время!». Единственный способ, которым, как я полагаю, вы можете поддерживать работоспособность кодовой базы - это три варианта

1. Только когда-нибудь добавить здоровый код.
2. Всегда исправляйте не очень здоровый код, как только вы его увидите.
3. Если по причинам крайнего срока вы не можете выполнить 1 или 2, всегда имейте список проблем с «исправлением сразу после крайнего срока» и не принимайте никаких оправданий для того, чтобы не работать через этот список после крайнего срока.

Следующее замечание разработчиков неизменно гласит: «Но как нам получить время для этого - у нас сейчас нет времени?». Единственный правильный ответ (опять же ИМХО): «У вас нет времени НЕ делать этого». Если вы не будете поддерживать исправность кодовой базы, вы обнаружите, что время выполнения заказа будет увеличиваться и увеличиваться, графики становятся все более непредсказуемыми, ошибки становятся более неприятными, а ценность снижается.

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

Наконец, история предупреждения. Если нажать, я буду отрицать, что это когда-либо случалось. В компании, в которой я работал, существовало давнее приложение с большой устаревшей кодовой базой, созданное более 10 лет назад. Многие разработчики, в том числе и я, полагали, что эта устаревшая кодовая база была плохой или, по крайней мере, устаревшей, а не самой современной. Поэтому мы успешно лоббировали крупный проект по рефакторингу и начали проект по переписыванию, после чего мы верили, что все будет лучше.
Мы долго и упорно реализует почти все в новом и современном стиле, с использованием новых библиотек, новые возможности языка. Ближе к концу мы приложили огромные усилия, чтобы собрать все воедино, чтобы сделать возможным выпуск новой версии долгосрочного приложения с новой и улучшенной базой кода.
Как и ожидалось, в новом выпуске были некоторые проблемы с прорезыванием зубов из-за новых библиотек, с которыми мы еще не были знакомы, и некоторых взаимодействий в нашем коде, которые мы не предвидели. Тем не менее, нам, наконец, удалось получить релиз в соответствии с тем же стандартом, что и наши предыдущие выпуски. Мы вздохнули с облегчением от нашего «успеха». Затем подгруппа разработчиков вернулась к руководству с просьбой о новом проекте по рефакторингу, потому что наш новый код оказался не совсем серебряной пулей, как они ожидали, и они увидели некоторые возможности полностью переписать некоторые вещи ...

Мораль этой истории: часто вещи не так сильно сломаны, как кажутся, и «начинать сначала» обычно означает, что вы будете торговать известным набором проблем с, по крайней мере, волосатым неизвестным набором проблем. Рефакторинг по одной части за раз!

Кто-то однажды сказал мне, что когда я иду на собеседование, я не должен забывать, что я также беру интервью у компании. Это место, где я хочу работать? Они делают обзоры кода? Есть ли у них автоматизированные интеграционные тесты? Модульные тесты? Что они думают о парном программировании? Лично я найду другую работу, и на этот раз тоже не забуду задать несколько вопросов.

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

Если вы чувствуете, что у вас все еще есть драка и вы еще не провалились, сделайте последний удар. Постарайтесь получить как можно больше поддержки от единомышленников, рассказать о своем изнеможении начальству, которое заботится о вашем благополучии, откровенном обходе и дистанцироваться от всех, кто может противостоять вашим убеждениям, и стараться потратить некоторые обязательные часы рефакторинга на планирование новых проекты / особенности.

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

Если бы мне пришлось ввести одну практику, чтобы сделать вещи лучше в таком контексте, это были бы обзоры кода. Кодовые отзывы

• обычно интуитивно воспринимается разработчиками как фактор улучшения кода, уменьшения количества ошибок и т. д.
• совместный и демократичный
• не слишком много времени, если вы правильно их распределяете
• хорошее место, чтобы сделать рефакторинг, если у вас нет времени сделать это во время "нормальной" разработки
• довольно эффективный троянский конь для постепенного внедрения всевозможных лучших практик в области разработки кода, модульного тестирования ...

Вам не нужно систематически проверять код, только когда вы сначала делаете большие / сложные части кода.

Конечно, если вы чувствуете, что нуждаетесь в официальном одобрении, прежде чем вводить обзоры кода, вам, возможно, придется сначала убедить своего босса, что база кода, вероятно, рухнет, если все оставить как есть.

Вот что я делаю в таких ситуациях (за 15 лет моей карьеры разработчика я сталкивался с таким кодом почти каждый день)

1. Подавать пример - я проверяю код, к которому прикасаюсь. Я безжалостно удаляю старый закомментированный код и большие абзацы комментариев.
2. Каждый раз меня просят пересмотреть изменение кода, без чего я не одобряю проверку кода.
3. Люди постепенно видят изменения, когда код становится более компактным, более читабельным и, следовательно, менее глючным. Это требует времени, но постепенно вся команда ценит и принимает практику.

Руководство никогда не выделяет время для повторного факторинга кода (у них никогда не хватает ресурсов!), Поэтому делать это медленно и стабильно - правильный подход.

Попросите руководство провести исследование по «техническому долгу». Также отнесите их к «Теории разбитого окна», оба эти эффекта напрямую влияют на эффективность, качество и мораль.

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

Если с ситуацией не разобраться, в конечном итоге вы пересечете точку невозврата, где это становится экономически невыполнимым, если вы будете действовать постепенно, до того, как это произойдет, выгоды восстановятся, что даст вам больше топлива для решения проблемы по мере продвижения.

Похоже, ваши проблемы носят более общий характер.
Проблема рефакторинга является как симптомом, так и потенциальным избавлением от части проблемы.

Программный лидер и команда выделяют время команды

Исходя из моего опыта, я думаю, что вы можете столкнуться с проблемой, которую я называю «каждый менеджер программного обеспечения». Менеджеры продуктов, менеджеры проектов, а иногда системные инженеры и тестировщики могут быть печально известны тем, что пытаются микроуправлять разработчиками, у которых, вероятно, уже есть опытный менеджер программного обеспечения. В вашей команде может быть даже несколько человек, которые считают, что их роль - управлять.

Если вы являетесь менеджером программного обеспечения, сделайте назначения для рефакторинга, который вы хотите, или, что еще лучше, попросите вашу команду сделать рефакторинг для вашего одобрения. Чтобы не заниматься микроменеджментом, у вас могут быть рекомендации по возрасту / автору / размеру / контексту кода, подлежащего рефакторингу, которые можно свободно реорганизовать против необходимости одобрения. Если член вашей команды хочет провести массовый рефакторинг четырех больших классов сложного старого кода, которые он не написал, и которые не являются частью его функции, его двухнедельная утечка - ваша проблема, поэтому вам нужен шанс сказать «нет».

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

Ранний выбор проекта создает порочный цикл для рефакторинга

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

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Зачастую разработчики программного обеспечения вынуждены производить в соответствии с подходом управления Theory-X, который гласит, что рабочие в основном ленивы и не будут работать, если их не заставят подчиниться. Бём резюмирует и противопоставляет предложенную модель следующим образом:

«Вместо того чтобы характеризовать менеджера как автократа (Теория X), тренера (Теория Y) или фасилитатора (Теория Z), Теория W характеризует основную роль менеджера как посредника между его различными группами интересов и упаковщиком проектных решений. с условиями выигрыша для всех сторон. Помимо этого, менеджер также является целеустремленником, монитором прогресса в достижении целей и активистом в поиске повседневных конфликтных ситуаций между проектами типа «победа-поражение-поражение», противостояние им, и превращая их в беспроигрышные ситуации ".

Быстро и грязно часто просто грязно

Далее Бем указывает на причину, по которой разработчики из команды поддержки так несчастны.

«Создание быстрого и неаккуратного продукта может быть недорогой краткосрочной« победой »для разработчика и заказчика программного обеспечения, но это будет« неудачей »для пользователя и сопровождающего». Обратите внимание, что в модели Бёма клиент скорее является администратором контракта, а не конечным пользователем. В большинстве компаний считают менеджера по продукту суррогатом клиента или, возможно, человеком, который покупает продукт для его списка функций.

Мое решение состояло бы в том, чтобы не выпускать оригинальную команду разработчиков (или, по крайней мере, оригинального лидера), пока код не подвергнется рефакторингу, чтобы, по крайней мере, соответствовать стандартам кодирования.

Для клиента я думаю, что разумно считать менеджера по продукту суррогатом клиента, и группа людей, вознагражденных за то, что они доставили что-то быстрое и грязное, безусловно, может быть расширена, так что есть большая группа людей, которые делают неправильные вещи.

Рефакторинг не подлежит обсуждению

Пожалуйста, не отступайте от своей роли менеджера программного обеспечения. У вас должны быть полномочия и свобода действий, чтобы использовать время вашей команды в процессе и улучшения продукта. В этой роли вам может потребоваться согласовать ваш выбор, чтобы сделать вашу команду более профессиональной. Однако, что касается процесса, не ведите переговоры с маркетингом, потому что, по моему опыту, это проигрышная игра. Договориться с инженерным управлением. Это показывает, что у тебя есть видение. Создание профессиональной команды разработчиков программного обеспечения является продолжением их роли и, скорее всего, будет восприниматься как беспроигрышный вариант.

Вы всегда можете просто подождать. В конце концов, команда пропустит достаточное количество сроков и выпустит программное обеспечение с недостаточным количеством ошибок, которое руководство поднимет и скажет, что, по словам Бога, что-то изменилось лучше!

Хорошо, это рискованное предложение. Но это на самом деле то, что произошло в нашем магазине несколько лет назад (часть трудностей заключалась в том, чтобы общаться с руководством о сроках, но это уже другая история), и во многом по этой причине у нас сейчас десятки тысяч автоматизированных тестов, владение общим кодом, свобода рефакторинга, готовность удалять мертвый код и самые качественные релизы, которые мы когда-либо имели.

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

Я думаю, что ответ на вопрос, как найти время, зависит от того, почему вы хотите провести рефакторинг кода.

Если это работает, нет необходимости в специальном рефакторинге, и вы можете сделать это, касаясь этой части кода. Поэтому вам не нужно особое время для этого.

Если это замедляет развитие вашей команды, вам нужно поговорить об этом с руководителем группы и создать специальное задание для рефакторинга, и у вас будет время.

То же самое касается скорости выполнения и других случаев, если рефакторинг может что-то улучшить, а не только «хорошо выглядеть код» или ваше мнение о том, как должен выглядеть код, и обеспечить реальную выгоду, создать задачу или поговорить с кем-то, кто за это отвечает.

Я немного посмеялся над тем, как вы описали вещи, так как это звучит довольно похоже на кодовую базу, над которой я работаю, поэтому я думаю, что наши ситуации очень похожи. К счастью, в моей ситуации у меня есть дальновидный менеджер, который решил, что лучший способ улучшить кодовую базу - это модульность с использованием современной среды веб-разработки, а не просто рефакторинг всей кодовой базы. Таким образом, проблемные места основного приложения могут быть переписаны в виде отдельных модулей, а затем интегрированы в основное приложение (но все же по существу независимы). Это может быть подход, который вы хотите использовать, так как он не потребует рефакторинга всей (предположительно большой?) Кодовой базы, с которой вы работаете.

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

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

Учитывая все обстоятельства, насколько другие люди говорят, что вы должны бросить и т. Д., Я думаю, это зависит от того, как руководство видит вещи, если они понимают ситуацию и понимают, почему некоторые вещи могут занять больше времени, чем они должны оптимально, тогда все может быть хорошо, как Что касается рабочей среды, но если они постоянно сталкиваются с проблемой невыполненной работы, это может со временем стать вредным. Мне повезло иметь руководство, которое в основном понимает, что приложение - кусок дерьма, но оно имеет много клиентов и приносит деньги, так что оно по-прежнему ценно и стоит исправлять ошибки, даже если только на короткий срок ,

Ваша главная проблема в том, что коды не видны достаточно.

Я предлагаю использовать инструмент непрерывной интеграции, такой как Jenkins , и интегрированный в него инструмент статического анализа кода, который измеряет цикломатическую сложность, стандарты именования, длину кода и т. Д.

Когда программист фиксирует изменение, Дженкинс запускает модульные тесты, запускает на нем инструмент анализа статического кода и генерирует веб-отчет, который все могут видеть, со статусом цвета светофора.

Когда качество кода видимо всем (особенно руководителю группы и боссу), а контроль версий и юнит-тесты необходимы, чтобы вы были спиной ... люди чувствуют побуждение к рефакторингу.

Код медленно продвигался по множеству мелких изменений. Это тоже нужно будет исправить.

Вы можете сделать это по мере продвижения вперед, в первую очередь - увеличить все оценки на 10%, чтобы обеспечить улучшение кода и долгосрочное обслуживание. Если кто-то жалуется, спросите его, лучше ли проверять масло в двигателе автомобиля каждую неделю или подождать, пока двигатель полностью не зафиксируется.

Проведите собрание и определите постоянные стандарты кодирования.

Введите основные правила, которые будут использоваться по мере продвижения:

Всякий раз, когда новый код вводится в класс, должны быть написаны автоматические тесты, чтобы доказать, что класс работает (а не только новый код).

Всякий раз, когда ошибка исправлена, должны быть написаны автоматические тесты, чтобы доказать, что класс работает (а не только исправленный код).

Всякий раз, когда программист изменяет файл, он должен исправить все предупреждения компилятора в этом файле и обновить код, чтобы он соответствовал новым стандартам кодирования.

Через некоторое время наиболее используемый код будет обновлен и будет покрыт автоматическими тестами. Старый код будет обновляться при его изменении, если он никогда не изменяется, вам не нужно беспокоиться об этом.

Важно встроить эти привычки в стандартные задачи кодирования, чтобы ни одна из них не отнимала огромное количество времени от «реальной» работы, но все они приносили реальную выгоду. Не пытайтесь сделать проект из рефакторинга старого кода, это ужасная, скучная, мучительная боль, которая будет выглядеть как трата времени на техников!

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

Итак, первый шаг - выяснить, какую боль чувствует ваш начальник. Определите, какие у него самые большие проблемы. Затем выясните, как то, что вы хотите сделать, согласуется с решением его проблем, и представьте серьезное экономическое обоснование для этого. Используйте свои системы отслеживания дефектов и планирования проекта (перерасход времени), чтобы предоставить доказательства того, где находятся проблемы. Вам нужны факты, а не чувства. Без метрик (количество ошибок / модуль, стоимость исправления) рефакторинг - это просто программист, играющий за чей-то счет. Ваш начальник предоставит вам необходимые ресурсы только в том случае, если вы сможете продемонстрировать серьезное экономическое обоснование для этого.

Код дерьма чаще всего исправляется. Без автоматизированных регрессионных тестов стоимость тестирования рефакторированного кода чрезвычайно высока.

В большинстве случаев я видел плохой код, который действительно нуждался в рефакторинге, было большое количество недокументированных функций и сложностей в требованиях, которые невозможно понять с самого начала. Это не малое дело, и мой опыт на порядок сложнее оценить стоимость работы по рефакторингу, чем добавить новую функцию.

Я бы воздержался от того, чтобы идти вперед и делать это позади вас, боссы назад (если он не был сломан, и вы его сломали, как это выглядит) - исправьте код, который все равно нужно изменить, но если он не сломан, не делайте это исправить.

Странно никто не упоминает это:

Чтобы сделать вещи приоритетными, сделайте их простыми: получите хороший инструмент рефакторинга.

Есть отличные инструменты рефакторинга (по крайней мере, для .NET afaik). О, и не забудьте заранее написать модульные тесты (как уже отмечали другие).

Удачи!