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

Question

Как можно доказать руководству, что пакетное переформатирование всех файлов .java в большой кодовой базе (для размещения кода в соответствии со стандартами кодирования компании) безопасно и не повлияет на функциональность.

Ответы должны были бы удовлетворить как нетехнических, так и технических.

Редактировать: 2010-03-12 Разъяснение технического среди вас; reformat = изменения только для пробелов - нет «организации импорта» или «переупорядочения переменных-членов, методов и т. д.»

Редактировать: 2010-03-12 Спасибо за многочисленные ответы. Я удивлен, что так много читателей проголосовали за ответ mrjoltcola, поскольку это просто утверждение о том, что он параноик, и ни в коем случае не предлагает ответ на мой вопрос. Более того, есть даже комментарий того же автора, повторяющий вопрос. WizzardOfOdds поддержал эту точку зрения (но вы, возможно, не читали все комментарии, чтобы увидеть ее). -jtsampson

Редактировать: 2010-03-12 Я скоро опубликую свой собственный ответ, хотя ответ Джона Скита был прав на деньги с предложением MD5 (примечание -g: ни один, чтобы отключить отладку). Хотя это только технические аспекты. -jtsampson

2010-03-15 Я добавил свой ответ ниже. В ответ на то, что означает «безопасный», я имел в виду, что функциональность кода Java не пострадает. Простое исследование компилятора Java показывает, что это так (с несколькими оговорками). Предостережения Thos были «только пустым пространством» и были отмечены несколькими плакатами. Однако это не то, что вы хотите попытаться объяснить BizOps. Моя цель состояла в том, чтобы найти ответы типа «как оправдать это», и я получил несколько отличных ответов.

Несколько человек упомянули контроль над источниками и «веселье», которое сопровождает его. Я специально не упомянул это, поскольку эта ситуация уже хорошо понята (в моем контексте). Остерегайтесь эффекта «АЗС». Смотрите мой ответ ниже.

Answer 1

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

РЕДАКТИРОВАТЬ: Как указано в комментариях, двоичные файлы содержат номера строк. Убедитесь, что вы скомпилировали с -g:none, чтобы пропустить отладочную информацию. Это должно быть в порядке с изменениями нумерации строк, но если вы меняете имен , это более серьезное изменение, которое действительно может быть критическим.

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

Answer 2

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

1. Технические
2. Политическая

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

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

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

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

1. Контроль источника
2. Правильное тестовое покрытие

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

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

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

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

Answer 3

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

1. Сборка приложения.
2. Сохраните приложение.
3. Переформатировать код.
4. Сборка приложения.
5. Различаются двоичные файлы.

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

Но у этого также были некоторые отрицательные стороны:

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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

Это насчет покрова.