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

https://stackoverflow.com/questions/2420174

19-09-2019
|

Вопрос

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

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

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

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

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

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

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

Решение

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

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

Я предполагаю тебя Можно Переформация и восстановление без заботы - только проверка переформатированного кода обратно в контроль источника должна дать любой случай для беспокойства. Я не считать Файлы классов Java имеют что -нибудь, что дает дату сборки и т. Д. Однако, если ваше «форматирование» меняет порядок полей и т. Д., Что Можно иметь значительный эффект.

Другие советы

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

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

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

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

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

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

Управления источником
Правильный тестовый охват

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

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

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

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

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

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

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

Управления источником. Модульные тесты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это о покрытии.

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

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

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

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

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

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

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

Переформатировать состоит из смены в белом пространстве (без повторного заказа импорта, без члена/метода)
Recaramat будет использовать [указать инструмент и процесс
Переформатировать будет происходить [указать время в цикле кодирования, чтобы свести к минимуму воздействие слияния

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

Все модульные тесты пройдут
Все интеграционные тесты пройдут
Все функциональные тесты пройдут
Все тесты мыла пройдут
Код байта одинаково (MD5 файлов .class после Javac (-g: none))

Бизнес:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow