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

Я бы сказал четыре слова.

Контроль версий. Модульные тесты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тривиально: установить CheckStyle , сделайте его частью вашего процесса, скормите ему свои рекомендации по кодированию и покажите им, что вся кодовая база ОТКАЗЫВАЕТСЯ на CheckStyle .

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

1. Создайте приложение.
2. Сохраните приложение.
3. Переформатируйте код.
4. Создайте приложение.
5. Определите двоичные файлы.

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

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

Вот, пожалуй, и все.

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

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

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

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

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

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

1. контроль исходных текстов
2. правильное покрытие тестами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бизнес:

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

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

Пилотное испытание:

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

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

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

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

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