Как убедить руководство в том, что переформатирование всей базы Java-кода безопасно

Ответ 1

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

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

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

Ответ 2

В бизнес-среде у вас есть две проблемы.

• Технические
• Политический

С технической точки зрения, reformatters - зрелая технология. В сочетании с хешированием/контрольными суммами, если язык не является чувствительным к пробелу, вы технически безопасны для этого. Вы также хотите убедиться, что вы делаете это во время простоя, когда никакие крупные вилки не ожидают объединения. Реальные изменения невозможно отделить от переформатирования, так что делать их отдельно. Слияние может быть очень трудным для тех, кто работает на развилке. Наконец, я бы сделал это только после того, как я выполнил полный охват тестирования. Из-за причины 2...

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

Аргумент, который я сделал в 2010 году, был слишком умным, но парсеры, реформаторы, симпатичные принтеры - это просто программное обеспечение; у них могут быть ошибки, вызванные вашей кодовой базой, ESPECIALLY, если это С++. Без единичных тестов везде, с большой базой кода, вы не сможете проверить 100%, что конечный результат идентичен.

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

• Контроль источника
• Надлежащее покрытие для тестирования

тогда вы в порядке.

Однако подумайте над этим: теперь руководство знает, что вы работаете в проекте с миллионами строк с "массовым изменением". После вашего переформатирования будет обнаружена ранее неизвестная ошибка. Теперь вы являетесь главным подозреваемым в причинении этой ошибки. Является ли оно "безопасным", имеет несколько значений. Это может быть небезопасно для вас и вашей работы.

Это звучит банально, но пару лет назад я помню, что что-то случилось так. У нас был отчет об ошибке, который появился через день после ночного окна обслуживания, где я только сделал реконфигурацию и перезагрузил сервер IIS. В течение нескольких дней история заключалась в том, что я, должно быть, испортил или развернул новый код. Никто не сказал это прямо, но я получил от VP, который сказал это. Мы, наконец, отследили его до ошибки, которая уже была в коде, были отброшены ранее, но не появились, пока пользователь QA не изменил тестовый пример в последнее время, но, честно говоря, некоторые люди даже не помнят эту часть; они просто помнят, что придут на следующий день к новой ошибке.

EDIT: в ответ на редактирование jtsampson. Вопрос не в том, как это сделать; "Как убедить руководство в том, что оно безопасно". Возможно, вам следовало бы спросить: "Это безопасно? Если да, то как это сделать, безопасно". В моем заявлении указывалась ирония вашего вопроса, в которой вы предполагали, что это безопасно, не зная, как это сделать. Я ценю техническую сторону переформатирования, но я указываю, что существует риск, связанный с чем-то нетривиальным, и, если вы не наденете на него нужного человека, он может быть испорчен. Будет ли эта задача отвлекать от других задач программистов, отвлекая их на пару дней? Будет ли он конфликтовать с некоторыми другими кодерами без изменений? Исследуется ли источник вообще? Есть ли встроенный script, который является чувствительным к пробелу, например Python? Все может иметь неожиданный побочный эффект; для нашей среды было бы трудно получить временное окно, в котором не работает кто-то, работающий в филиале, и массовое переформатирование приведет к их слиянию довольно уродливым. Отсюда мое отвращение к массовому переформатированию вручную или автоматизировано.

Ответ 3

Используйте прагматичный подход:

• Создайте приложение.
• Сохраните приложение.
• Переформатировать код.
• Создайте приложение.
• Разверните двоичные файлы.

Ответ 4

Я бы использовал четыре слова.

Контроль источника. Единичные тесты.

Ответ 5

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

Ответ 6

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

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

В качестве боковой дорожки позвольте мне поделиться анекдотом. Наш архитектор решил одновременно переформатировать все файлы. Из тысяч файлов Java не найдено ни одной ошибки (и это было более полугода назад). Это заставляет меня доверять формату Eclipse для исходного кода Java. Преимуществами этого форматирования были:

• Некоторые плохо отформатированные классы теперь легче читать.
• То же форматирование везде.

Но он также имел некоторые отрицательные стороны:

• Форматирование кода не является совершенным. Иногда код, отформатированный вручную, читается лучше. Форматировщик, в частности, борется с действительно плохим кодом (слишком длинными строками, слишком много вложенных ifs и т.д.).
• У вас есть другие ветки кода, такие как старая версия, которую иногда нужно исправлять? Потому что вы можете забыть о слиянии ветвей с разными стилями кода (по крайней мере, при использовании SVN).
• Вы касаетесь всех файлов (а иногда и почти каждой строки) и одновременно разрушаете историю всех файлов. Это повреждает прослеживаемость.
• На самом деле небольшое преимущество в том, что каждый разработчик имеет собственное форматирование кода, потому что вы начинаете изучать это форматирование, и вы можете сразу определить автора фрагмента кода

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

Ответ 7

Проходят ли ваши тесты устройства после переформатирования? Если это так, то вы продали идею руководству!

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

Ответ 8

Вы хотите, чтобы "код соответствовал стандартам кодирования компании" [sic] и хотите убедить руководство?

Trivial: установите CheckStyle, сделайте его частью своего процесса, сообщите ему свои рекомендации по кодированию и покажите им, что вся кодовая база с ужасом FAILS на CheckStyle.

Ответ 9

Это хороший пример несоответствия технического бизнеса.

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

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

Почти по определению любое изменение связано с риском. Риск здесь пуст, но он также не является несуществующим (с точки зрения управления), практически без роста.

Есть и еще одна проблема: этот вид изменений может привести к хаосу с контролем источника. Сложнее отслеживать, кто изменил то, потому что последнее изменение в любой строке будет переформатированием, поэтому вам нужно будет сравнивать ревизии, что несколько утомительно, чем простая команда "винить" или "аннотировать".

Кроме того, если у вас несколько активных ветвей, переформатирование вашего кода приведет к хаосу с вашими слияниями.

Ответ 10

Если вы используете Eclipse в качестве платформы разработки, вы можете загрузить весь код в рабочую область локально. Продемонстрировать руководству нет проблем, показывая им вкладку "Проблемы".

Затем щелкните правой кнопкой мыши и отформатируйте каждый из проектов один за другим - снова продемонстрируйте отсутствие проблем.

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

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

Не говоря уже о том, что вы, вероятно, имеете прежнюю версию с тегами в исходном элементе управления?

Ответ 11

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

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

Ответ 12

Код переформатирования совпадает с переформатированием документа в Word; он изменяет макет и, следовательно, читаемость, но не содержимое.

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

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

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

Ответ 13

Отвечайте на эти вопросы для управления, и вам удастся убедить их в безопасном изменении?

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

Что касается его обложки.

Ответ 14

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

Консистенция хороша, но "глупая консистенция - это хобгоблин маленьких умов".

Ответ 15

Я надеваю свою шляпу менеджера...

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

Ответ 16

Спасибо за все ваши ответы.

Мой последний аргумент, чтобы убедить руководство; Биты всех ваших ответов включены. Спасибо за помощь.

Технические:

• Реформат состоит из изменений в пробеле (без переупорядочения импорта, без элемента/метода)
• Reformat будет использовать [указать инструмент и процесс]
• Реформат будет появляться в [указать время в цикле кодирования, чтобы минимизировать влияние слияния]

Как до, так и после форматирования:

• Все тесты модуля пройдут
• Все тесты интеграции пройдут
• Все функциональные тесты пройдут
• Все тесты SOAP-UI пройдут
• Байт-код тот же (MD5 файлов .class после javac (-g: нет))

Бизнес:

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

• Изменение реформата и изменение кода (пример документа Word, как указано выше)
• Reformat будет использовать [общий процесс]
• Реформат будет происходить в [указать время в течение рабочего цикла, чтобы свести к минимуму воздействие)

Пилотный тест:

• Подтвержденный "Формат партии" привел к уменьшению конфликтов слияния, а затем "Форматировать как код"..
• Подтверждено, что исполняемый код (файлы 4k +.class) остается неизменным. (Тест MD5)
• Подтвержденные функциональные возможности не будут затронуты (автоматические тесты/тесты дыма)
• Подтвержденные настройки форматирования содержат только изменения пробела.

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

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

В последнее время я надеялся, что кто-то предоставит хорошую ссылку на исследование, показывающее прирост производительности, связанный с общим кодом, поскольку трудно показать ROI для бизнеса. Хотя в моем случае, поскольку это был стандарт компании, у меня было "соответствие" на моей стороне. Я только должен был показать, что для "Отформатировать как код" больше "Время от времени", чем "Пакетный формат"

Ответ 17

Школа мысли могла бы сделать это, не спрашивая, а затем быть в состоянии пойти "Смотрите!"

Конечно, если вы повредите все это, вас уволят. Вы делаете свой выбор...

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

Ответ 18

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

Ответ 19

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

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

Заключительное примечание: если вам нужно убедить ваше управление в этом, может быть, вам стоит искать способ работать с умными людьми?

Ответ 20

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

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

Ответ 21

Мы используем Jalopy здесь на моей текущей работе. Это довольно солидный продукт, и он производит очень аккуратный выход. Самый старший разработчик здесь переформатировал всю базу кода, когда он перенес его из CVS в SVN, и ему пришлось выполнить некоторые тесты, чтобы убедиться, что все это будет работать от начала до конца, и теперь у нас есть крючки, в коде правильно отформатирован.

Говоря, я не думаю, что вы можете убедить кого-либо в том, что любой инструмент является дураком (или ошибкой), потому что такого инструмента нет. Если вы считаете, что выигрыш стоит времени и (очень малого) риска, попробуйте убедить ваше руководство в наибольшей выгоде, которое вы видите при этом. Для меня наибольшее преимущество придет, если:

• Все разработчики имеют одинаковые настройки форматирования;
• Форматирование исходного кода проверяется при регистрации крюком в вашем SCM.

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

Ответ 22

Если у вас есть хороший охват unit test, результатов теста до и после будет достаточно.

Ответ 23

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

Ответ 24

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