java - Java コードベース全体の再フォーマットが安全であることを経営陣に納得させる方法

Question

大規模なコードベース内のすべての .java ファイルのバッチ再フォーマット (会社のコーディング標準に準拠してコードを配置するため) が安全であり、機能に影響を与えないことを経営陣に証明するにはどうすればよいでしょうか。

答えは、非技術者と技術者の両方をなだめる必要があります。

編集: 2010-03-12技術的な説明。reformat = 空白のみの変更 - 「インポートの編成」または「メンバー変数、メソッドなどの並べ替え」はありません。

編集: 2010-03-12たくさんの回答ありがとうございます。多くの読者が mrjoltcola の回答に賛成票を投じたことに驚いています。なぜなら、mrjoltcola の回答は単に偏執的であることについての声明であり、決して私の質問に対する回答を提案するものではないからです。さらに、同じ寄稿者による質問を繰り返すコメントさえあります。WizzardOfOdds はこの見解を支持しました (ただし、すべてのコメントを読んでいない可能性があります)。-jtsampson

編集: 2010-03-12すぐに私自身の回答を投稿しますが、John Skeet の回答は MD5 の提案で正しかったです (デバッグをオフにするには -g:none に注意してください)。技術的な側面のみをカバーしましたが。-jtsampson

2010-03-15以下に独自の回答を追加しました。「安全」とは何を意味するのかという質問に対して、Java コードの機能に影響がないことを意味しました。Java コンパイラーを簡単に調べると、これが事実であることがわかります (いくつか注意点があります)。これらの警告は「空白のみ」であり、いくつかのポスターによって指摘されました。ただし、これは BizOps に説明しようとするものではありません。私の目的は、「これを行うことを正当化する方法」タイプの回答を引き出すことでした。いくつかの素晴らしい回答が得られました。

何人かの人々が、ソース管理とそれに伴う「楽しさ」について言及しました。その状況は（私のコンテキスト内で）すでによく理解されているため、特に言及しませんでした。「ガソリンスタンド」効果に注意。以下の私の答えを見てください。

score 37 · Accepted Answer

再フォーマットだけの場合、コンパイラの出力は変更されません。再フォーマットの前後にビルドのハッシュ ( MD5で十分なはずです) を取得します。すべてのファイルで同じである場合、動作が変更されていないことは明らかです。テストなどを実行する必要はありません。出力がバイトごとに同じである場合、テストがどのように失敗し始めるかを確認するのは困難です。(もちろん、それを示すためだけにテストを実行することは役立つかもしれませんが、それらは同一のバイナリが証明しないことを証明するつもりはありません.)

編集:コメントで指摘されているように、バイナリには行番号が含まれています。でコンパイルして-g:none、デバッグ情報を省略してください。行番号の変更は問題ないはずですが、名前を変更する場合は、より深刻な変更であり、実際に重大な変更になる可能性があります。

誰も気にせずに再フォーマットと再構築ができると仮定しています. Javaクラスファイルには、ビルド日などを示すものは何もないと思います。ただし、「フォーマット」によってフィールドの順序などが変更されると、大きな影響が生じる可能性があります。

score 35 · Accepted Answer

ビジネス環境では、2 つの課題があります。

テクニカル
政治的

技術的な観点から見ると、リフォーマットは成熟した技術です。ハッシュ/チェックサムと組み合わせると、言語が空白に敏感でない限り、これを行うことは技術的に安全です。また、メジャーフォークがマージされるのを待っているダウンタイム中に確実に実行する必要があります。実際の変更を再フォーマットから分離することは不可能なので、別々に行ってください。マージは、フォークに取り組んでいる人にとって非常に難しい場合があります。最後に、完全なテストケースカバレッジを実装した後にのみ実行します。理由２から…

政治的に、経営陣を説得する方法がわからない場合、それが安全であることをどうやって知ることができますか? より具体的には、それはあなたにとって安全です. ショップ内のプロセスを管理している信頼できる上級開発者にとっては簡単な仕事ですが、大規模で政治的で官僚主義的な組織で働く開発者にとっては、すべてのことを確実にカバーする必要があります。基地。

2010 年に私が行った議論は少し巧妙すぎるかもしれませんが、パーサー、リフォーマッター、きれいなプリンターは単なるソフトウェアです。コードベースが原因でバグが発生する可能性があります。これが C++ の場合は特にそうです。大規模なコードベースでは、ユニットテストがどこにでもなければ、最終結果が同一であることを 100% 検証できない場合があります。

開発者として、私は偏執狂的であり、その考えは私を不安にさせますが、あなたが以下を使用している限り:

ソース管理
適切なテスト範囲

それなら大丈夫です。

ただし、これについて考えてみてください。経営陣は、あなたが「大量の変更」を伴う数百万行のプロジェクトをいじっていることを認識しています。再フォーマット後に、以前は発見されていなかったバグが報告されます。あなたは今、このバグを引き起こした主な容疑者です。「安全」かどうかには複数の意味があります。あなたとあなたの仕事にとって安全ではないかもしれません。

陳腐に聞こえるかもしれませんが、数年前にこのようなことがあったことを覚えています。IISサーバーの再構成と再起動のみを行った夜間のメンテナンスウィンドウの翌日に、バグレポートが届きました。数日間、私が失敗したか、新しいコードをデプロイしたに違いないという話がありました。誰も直接言わなかったが、私はそう言った副社長から見た. 最終的には、コード内にすでに存在し、以前にプッシュされたバグにまで突き止めましたが、QA 担当者が最近テストケースを変更するまで表示されませんでしたが、正直なところ、その部分を覚えていない人もいます。次の日に新しいバグが発生したことを覚えているだけです。

編集: jtsampson の編集に応じて。あなたの質問は、それを行う方法に関するものではありませんでした。それは「経営陣に安全だと納得させる方法」でした。代わりに、「それは安全ですか? もしそうなら、安全に行うにはどうすればよいですか?」と尋ねる必要があったかもしれません。私の発言は、あなたの質問の皮肉を指摘するものでした。あなたは、方法を知らずに安全だと思っていたのです。再フォーマットの技術的な側面には感謝していますが、些細なことにはリスクが伴い、適切な人を配置しない限り、めちゃくちゃになる可能性があることを指摘しています。このタスクは、プログラマーの他のタスクの妨げになり、数日間脇道にそれますか? 他のコーダーのコミットされていないリビジョンと競合しますか? ソースはまったく改訂中ですか？空白に敏感な埋め込みスクリプトはありますか?? 何にでも予期せぬ副作用が生じる可能性があります。私たちの環境では、ブランチで作業している人がいない時間枠を確保するのは難しく、大量の再フォーマットによりマージがかなり醜くなります。したがって、手動または自動による大量の再フォーマットに対する私の嫌悪感。

score 13 · Accepted Answer

実用的なアプローチを使用します。

アプリケーションをビルドします。
アプリケーションを保存します。
コードを再フォーマットします。
アプリケーションをビルドします。
バイナリを差分します。

score 8 · Accepted Answer

8

4つの単語を使用します。

ソース管理。単体テスト。

于 2010-03-10T20:08:53.873 に答える

score 5 · Accepted Answer

まあ、それはまったく安全ではなく、彼らを納得させることはまずありません. 多くの開発を管理してきた者として言えば、収益が依存する商用コードベースでそれを考慮したことはありません。好きなようにフォーマットされたコードに利点がないと言っているわけではありませんが、フォーマットにコードの変更が含まれない可能性はゼロです。つまり、わずかな利益でも大きなリスクがあるということです。やらなければならない場合は、コードをバグ修正するときに少しずつ行い、大ヒットで行わないでください。プログラマーとしてのあなたにとっては良い決断かもしれませんが、管理者にとってはひどい決断になるでしょう。

score 4 · Accepted Answer

ここで話している管理は何ですか？彼らは、コードのフォーマットとは何か、Java が空白をどのように扱うかを理解するのに十分なほど技術に精通していますか? そうでない場合、そのような技術的な決定を下す資格はないと思います (つまり、そのような質問は、コードの責任者に委任する必要があります)。

しかし、彼らがそうである、またはあなたがあなたの「アーキテクト」または同様の誰かを説得しようとしているのであれば、それはサードパーティのツールを信頼することです. フォーマッタをコーディングしていないため、できることはあまりないことを除けば、評判の良いフォーマッタを提案してください。

補足として、逸話を共有させてください。私たちのアーキテクトは、一度にすべてのファイルを再フォーマットすることを決定しました。何千もの Java ファイルのうち、エラーは 1 つも見つかりませんでした (これは半年以上前のことです)。これにより、Java ソースコード用の Eclipse のフォーマッターを信頼するようになりました。このフォーマットの利点は次のとおりです。

一部の不適切な形式のクラスが読みやすくなりました。
どこでも同じフォーマット。

しかし、それにはいくつかのマイナス面もありました。

コードフォーマッタは完璧ではありません。手動でフォーマットされたコードの方が読みやすい場合があります。特にフォーマッタは、非常に悪いコード (行が長すぎる、ネストされた if が多すぎるなど) と格闘します。
時々パッチを適用する必要がある古いバージョンなど、コードの他のブランチはありますか? コードスタイルが異なるブランチ間のマージを忘れることができるからです (少なくとも SVN を使用している場合)。
すべてのファイル (場合によってはほぼすべての行) に触れ、すべてのファイルの履歴を一度に台無しにします。トレーサビリティが損なわれます。
各開発者が独自のコード形式を持っているという点で、実際には小さな利点があります。その形式を学習し始めると、すぐにコードの作成者を特定できるからです。

個人的には、マイナス面がプラス面を上回っていると思います。素晴らしいアイデアのように聞こえますが、実際には、思ったほど多くは得られません。ひどくフォーマットされたコードに出くわしたら、そのクラスまたはメソッドだけを再フォーマットし、それを大きな目標への小さな一歩と見なしてください。

score 2 · Accepted Answer

再フォーマット後に単体テストに合格しますか? もしそうなら、あなたはそのアイデアを経営陣に売りました！

テストされていないコードをいじっている場合は、より困難なケースになります。

score 2 · Accepted Answer

「会社のコーディング標準に準拠したコード」 [原文ママ] が必要で、経営陣を説得したいですか?

些細なこと: CheckStyleをインストールし、それをプロセスの一部にし、コーディングガイドラインにフィードし、コードベース全体が CheckStyle で惨めに失敗することを彼らに示します。

score 2 · Accepted Answer

これは、技術とビジネスのミスマッチの良い例です。

技術者は、コードが読みにくくなる可能性があるため、そうしたいと考えていますが、それがよほど悪い場合を除き、本当の理由は、平均的なプログラマーの典型的な繊細な感性と美学を損なうからです。

ビジネスマンはリスクを管理したいと考えています。なんらかの利益があり、ビジネス上の利益がない場合は、リスクを冒すことができます。ただし、再フォーマットされたソースコードを使用して将来の開発を行う方が安く、速く、リスクが少ないと主張しない限り、これは正直言って難しい売りです。

ほとんどの定義では、変更にはリスクが伴います。ここでのリスクはわずかですが、（経営陣の観点から）存在しないわけではなく、利点はほとんどありません.

考慮すべき別の問題もあります。この種の変更は、ソース管理に大混乱をもたらす可能性があります。誰が何を変更したかを追跡するのは難しくなります。これは、行の最新の変更が再フォーマットになるため、リビジョンを比較する必要があるためです。これは、単純な「非難」または「注釈」コマンドよりもやや面倒です。

また、複数のアクティブなブランチがある場合、コードの再フォーマットはマージに大混乱を引き起こします。

score 1 · Accepted Answer

Eclipseを開発プラットフォームとして使用している場合は、すべてのコードをワークスペースにローカルにロードできます。[問題] タブを表示して、経営陣に問題がないことを示します。

次に、右クリックして各プロジェクトを 1 つずつフォーマットします。これも、問題が発生していないことを示しています。

リポジトリにまったく害を与えることなく、ローカルワークステーションでこれを行うことができます。

正直なところ、管理者がソースコードの書式設定を恐れるほど非技術的である場合は、書式設定後に [問題] タブに問題が表示されないことを実証するだけで、コードがまだ正常であることを示すのに十分なはずです。

言うまでもなく、おそらくソース管理でタグ付けされた古いバージョンがありますよね?

score 1 · Accepted Answer

純粋な書式設定の変更はコンパイルされたものに違いをもたらさないため、実行時のコードの動作に違いがないという意味で安全です。

コードの一括再フォーマットは、後でソース管理を扱うときに「楽しい」ことにつながる可能性があることを覚えておく価値があります。複数の同僚がコードをチェックアウトし、1 人のチームメンバーがやって来てコードを再フォーマットした場合、それらのコピーはすべて古くなっています。さらに悪いことに、作業コピーを更新すると、あらゆる種類の競合が発生します。これらのフォーマットの変更はコードの大部分に影響を与え、それを解決することは悪夢になる可能性があるためです。

score 1 · Accepted Answer

コードの再フォーマットは、Word で文書を再フォーマットするのと同じです。レイアウトと読みやすさを変更しますが、内容は変更しません。

すべてのファイルを同じ形式にすると、コードが読みやすくなり、メンテナンスが少し簡単になり、コストが削減されます。また、コードレビューをより迅速かつ効果的に行うことができます。

さらに、適切な書式設定スタイルがあれば、バグを隠すことができないため、バグをより簡単に見つけることができます。中かっこのない if ステートメントと、それらの想像上の中かっこ内の 2 つのステートメントを考えてみてください。

コードを再フォーマットする前に、賢くチェックインしてタグを付けてください。そうすれば、他に変更を加えずに、元の状態に戻って (そしてそれがどれほど簡単かを人々に伝えて)、再フォーマットしてチェックインし、再度タグを付けることができます。

score 1 · Accepted Answer

経営陣のためにこれらの質問に答えれば、それが安全な変更であることを彼らに納得させるのに長い道のりを歩んだことになりますか?

適切な書式設定が重要なのはなぜですか?
どのような変更が行われますか? (これに答えられない場合は、再フォーマットが安全かどうかを十分に理解していないということです)
単体テストスイートは、変更が悪影響を及ぼさないことを証明しますか? (答えは「はい」である必要があります)
既存のコードはソースリポジトリでタグ付けされるので、迅速なロールバックオプションがありますか? （答えはイエスの方が良いと思います）

それはそれについてカバーします。

score 1 · Accepted Answer

実際、私はおそらく彼らの側にいるでしょう。実稼働に戻る前に完全にテストされる場合は、修正または拡張のためにユニットを開くときにユニットを再フォーマットします。最初は正しくフォーマットされているはずですが、本番環境では、スタイルのためだけに再フォーマットするのは不必要で無謀に思えます。

一貫性は良いですが、「愚かな一貫性は小さな心のホブゴブリンです」.

score 1 · Accepted Answer

マネージャーの帽子をかぶっています...

一つの壮大なプロジェクトとしてやるとしたら、いくらなんでもやらせはしない。ただし、これらのフォーマットの変更を含めるために既存のファイルを変更しているため、変更に関するより長い見積もりにはオープンです。ただし、フォーマットの変更を独自のチェックインにする必要があります。

score 1 · Accepted Answer

ご回答ありがとうございます。

経営陣を説得するための私の最後の議論。すべての回答の一部が含まれています。助けてくれてありがとう。

テクニカル：

再フォーマットは空白の変更で構成されます (インポートの並べ替えなし、メンバー/メソッドなし)
再フォーマットは [ツールとプロセスを指定] を使用します
[マージの影響を最小限に抑えるため、コーディングサイクル内の時間を指定してください] に再フォーマットが行われます

再フォーマットの前後の両方:

すべての単体テストに合格します
すべての統合テストに合格します
すべての機能テストに合格します
すべての SOAP-UI テストに合格します
バイトコードは同じです (javac (-g:none) に続く .class ファイルの MD5)

仕事：

目的: 当社のソースファイルが当社のコードの論理構造を正確に表していることを規定する会社の基準に準拠すること。

再フォーマットの変更とコードの変更 (上記の Word ドキュメントの例)
再フォーマットは【一般的なプロセス】を使用します
改革は [影響を最小限に抑えるためにビジネスサイクル内の時間を指定してください] に行われます

パイロットテスト：

「Format Batch」は、「Format as you Code」よりもマージの競合が少ないことを確認しました。.
実行コード (4k+ .class ファイル) が同じであることを確認しました。(MD5 テスト)
確認済みの機能は影響を受けません (自動テスト/スモークテスト)
確認済みのフォーマッタ設定には、空白の変更のみが含まれています。

注:私の場合、パイロットテストは、自動化されたツールを使用して開発者のサブセットによって 6 か月にわたって実行されました (上記の回答の一部で規定されているように)。再フォーマットによってマージの競合が増えると考える人もいましたが、実際にはそうではありませんでした。

この認識は、改革の時間的な偶然に基づいていました。たとえば、車について何も知らない人を考えてみましょう。ある日、ブレーキが効かなくなります。彼らはその原因を何に帰するのでしょうか? もちろんガス。それは彼らが車に入れる最後のものでした（「ガソリンスタンド」効果？）。ただし、明らかに、ブレーキと燃料システムは、フォーマットとコードの変更と同様に異なるシステムです。ビルドプロセスのコンテキスト内での不適切なチェックインに問題があることがわかりました。

最後に、ビジネスに ROI を示すのは難しいため、一般的なコードに関連する生産性の向上を示す調査への適切なリンクを誰かが提供してくれることを願っていました。私の場合は社内基準なので、「コンプライアンス」は自分の味方でした。「コードとしてフォーマット」と「バッチフォーマット」のほうが時間がかかることを示すだけでした。

score 0 · Accepted Answer

考えの学校は、尋ねずにそれを行い、「見る」ことができるようにすることです。

もちろん、全部ぶち壊せば解雇されます。あなたはあなたの選択をします...

または、ソース管理 (または単純なバックアップ) を使用すると、いつでもロールバックできます。

score 0 · Accepted Answer

現在の仕事では Jalopy を使用しています。それはかなり堅実な製品であり、本当にきれいな出力を生成します. ここで最も上級の開発者は、CVS から SVN に移行するときにすべてのコードベースを再フォーマットし、最初から最後まで機能することを確認するためにいくつかのテストを実行する必要がありました。コード内は適切にフォーマットされています。

そうは言っても、そのようなツールは存在しないため、どのツールもばか (または過失) 証明であると誰かに納得させることはできないと思います。時間と (非常に小さな) リスクに見合うだけの価値があると考える場合は、これを実行することで得られる最大の利点を経営陣に納得させるようにしてください。私にとって、最大の利点は次の場合です。

すべての開発者が同じフォーマット設定を持っています。
ソースコードのフォーマットは、SCM のフックによってチェックイン時にチェックされます。

上記を実行すると、コードが既にフォーマットされている場合、SCM でリビジョンを比較すると、フォーマットの変更だけでなく、プログラムのロジックの実際の変更が表示されるためです。

score 0 · Accepted Answer

以前の回答はすべて問題ないことはわかっていますが、別の可能性のある回答を次に示します。再フォーマットの前後にコンパイル済みバージョンでCRCを実行します。コンパイルはスペース、タブ、改行などを無視するため、コンパイルされたバージョンは元のバージョンと同一である必要があり、それは半技術的なマネージャーにすべてがうまくいっていることを証明します.

score 0 · Accepted Answer

技術的には、コンパイルの最初の段階で、レクサーはソースからすべてのコメントと空白を取り除きます。これは、コードのセマンティクスがコンパイラによって認識されるずっと前のことです。したがって、空白やコメントは、プログラムロジック内の何も変更できません。それどころか、その言語はどのような用途に使用され、スペースや改行をいくつか追加するとセマンティクスが変わるとしたら、誰がそれを使用したいと思いますか?

ビジネス面では、そのために専用のツールを使用することになるでしょう。私は彼らが彼らのウェブサイトで彼らがうまく機能することを宣伝していると確信しています.

最後のメモ: 経営陣にそのことを納得させる必要がある場合は、より賢い人々と協力する方法を見つける必要があるのではないでしょうか?

score 0 · Accepted Answer

コードのコードカバレッジがほぼ 100% に近い場合、リスクを少し下げることができると思います。

ただし、経営陣がコードベースが安全であることに同意したとしても、開発に長い間導入された（おそらく）標準に準拠するためだけに、コードの再フォーマットに何時間も費やすために従業員に支払うことを正当化する必要があることに彼らは目を向けていると思いますライフサイクル。

score 0 · Accepted Answer

私は経営陣に、コードが機能すると信じる現在の根拠は何なのかを尋ねます。次に、同じツール (テスト、ドキュメント、小さな声...) が再フォーマットされたコードに対しても正確に機能することを示します。私は彼らの答えを「テスト」にしたいと思います...

java - Java コードベース全体の再フォーマットが安全であることを経営陣に納得させる方法

24 に答える 24

Related

Reference