Как убедить руководство в том, что переформатирование всей базы кода 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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Последовательность - это хорошо, но «глупая последовательность - это хобгоблин маленьких умов».

Answer 6

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

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

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

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

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

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

Бизнес

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

Answer 9

Школа мысли могла бы сделать это, не спрашивая, а затем уметь «Видеть!»

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

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

Answer 10

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