職場でクリーンなコーディングを促進するにはどうすればよいですか？

私は社内のアプリケーションで多くのレガシーJavaおよびRPGコードを使用しています。ご想像のとおり、コードの多くはさまざまなスタイルで記述されており、名前が不十分な変数、一貫性のない形式、および矛盾するコメント（存在する場合）のために、多くの場合読みにくくなっています。

また、十分な量のコードは堅牢ではありません。多くの場合、コードは熟練したプログラマーによって迅速に本番環境にプッシュされますが、新しいプログラマーによるコードは、IMOが不十分であるという「コードレビュー」によって妨げられます。（それらは通常、コードの深刻な批評よりも「うまくいく、大丈夫だ」という形をとります。）私たちはかなりの量の生産上の問題を抱えています。私は、元のデザインとテスト。

私はこの会社で約4か月働いており、私のコーディングスタイルについては2、3回褒められています。私のマネージャーはまた、標準よりもクリーンなコーディングのファンです。より良いスタイルとより防御的なコーディングを推進しようとするのは私の場所ですか、それとも私ができる限り最善の方法でコーディングすべきでしょうか？デバッグと変更時間を短縮できますか？

この件に関する専門知識のレベルについては触れませんでした。でもあなたが上級プログラマーでないなら、あなたができる最善のことはあなた自身の仕事をうまくやることだと思います。あなたのマネージャーはクリーンな仕事が好きだとも言っていました-それは素晴らしいです。それについて（たぶんセミプロの環境で）彼と話すことができるなら、あなたは彼と問題についてのあなたの懸念を共有するべきです。彼はワークフローを変更する立場にあります。

クリーンなコードはあなたにとって何を意味しますか？

あなたの定義は素晴らしいと思いますが、職場の他の人たちはおそらく独自の定義を持っています。彼らは間違っていない、あなたと違うだけだ。

職場の全員が同意できるコーディングガイドラインを作成し、他のプログラマーと一緒に作成する必要があります。これを人々に強要しようとしないでください。そうすると、逆効果になります。

チームをまとめて、「クリーンなコード」の一般的な定義に取り掛かりましょう！これには厳しいルールはありません。あなたはいくつかの心を一つにまとめようとしていて、それが対立の原因となる可能性があるので、すべての人が敬意を払い、心を開いておくべきであるという肯定的な注意をもって段階を設定することができます（コードの記述は個人的なものです...）。

クリーンコードブックは便利になることがあります。その本の例を使用して、そこに共通の根拠があるかどうかを話し、確認することができますか？

コード品質の一貫性と高い水準を確保するために驚異的なことができる2つのことがあります。

コードレビューを行う

チーム内の別の人がレビューするたびに、チェックインするたびに努力する必要があります。例外なく。これは最初は邪魔になるようです。特に、経験の浅い人にコードをレビューしてもらえないのではないかと思う上級開発者にとっては特にそうです。ただし、定期的なコードレビューは、チームのすべての開発者に計り知れない影響を与えます。

標準を定義し、それに固執する

Google では、C ++、Java、Pythonなど、使用するすべての言語用のコーディングスタイルガイドを用意しています。エンジニアはスタイルガイドに自由に同意できますが、オプションではありません。（そして、コードレビューでは厳格に実施されています。）その結果、コードベース全体（数十万行のコード）は非常に一貫しています。

クリーンなコードに情熱を傾けているなら、これは同僚にすり減ることになると思います。熱心な方法で優れたデザインとクリーンなコードを提唱する人々が変えることができる「うまくいく、大丈夫だ」という考え方。

しばらくの間、いくつかの有用な回答がここに投稿されていますが、もう1つ余地があると思います。私の提案は、他の人が言ったように、コードレビューを行うことです。しかし、「コードレビュー」という用語はあいまいなので、もう一度言及する価値があります...「クリーンなコード」と同じくらいあいまいです:-)。私はそのとらえどころのない目標に向けて取り組むことに多くの時間と努力を費やしてきました。特に過去2年間、私の情熱を共有してくれた同僚に支えられて、著名な開発者からの重要なアイデアを取り入れた概念を、Zen of Code Reviewsというシリーズにまとめました。

私の記事は、私の知る限り、その中で私がカバーし、ユニークで両方の通路の両側に：として、コードレビューをしている著者としてコードレビューをして審査。関連していますが、それぞれのスキルは多少異なります。そして、両方をよく行うことができることはします、より良いコードの品質につながります。コードをレビューすることは、コードを書くことと同じくらい重要です。本当に。それは知識の伝達を促進し、チームの一貫性とコミュニケーションを促進し、あなたの技術を改善するのに役立ちます、そして最後に、重要なことに、それはバグのあるソフトウェアを非常にコスト効率よく、可能な限り最初から減らします。

最初の2つは、コードレビューを準備するためのヒントとテクニックを提供します。手短に：

• 作成者は、変更された各行がコードレビューに含まれている理由をよく理解しています。多くは教育を受けたレビュアーには明らかですが、多くはそうではありません。レビュー担当者に送信する前に、コードレビューに注釈を付けることでそれらのポイントを伝えます。
• その前でも、コードレビューの構成要素を慎重に検討してください。1つの問題に関連するすべての変更を含め、複数の問題を含めないようにしてください。
• 送信する前に、必ずソース管理チェックアウト（コードをmainと再同期するため）を行ってください。
• コードを送信する前に、コードを1行ずつ確認してください。

パート1：事前レビューコメント：コードレビューに関するフィードバックを改善するために同僚に力を与える

パート2：ベストプラクティス：コードレビューを準備するためのガイドライン

そして、他の2つの記事は、より良いレビュアーになる方法についての実用的なアドバイスを提供します。

• 最初にJira / issue / ticket / requirement（あなたがそれを何と呼ぶにせよ）を読んでください。
• 単体テストが要件をカバーしていることを確認します。
• 同等性クラスと境界値の完全性についてユニットテストを確認します。
• 各単体テストが十分に機能することを確認します。複数のテストは行いません。
• SOLID原則の順守についてコードを確認します。
• 車輪の再発明、過度に複雑なコード、そして単に複雑なコードに注意してください。
• Eschewマジック（マジックストリング、マジック整数、そしてもちろん、マジックブール）。
• 蝶の効果をキャッチします。見落とされた波紋があります（たとえば、名前の不一致）。

パート3：レビューアの物語：コードレビューを実行するためのガイドライン

パート4：コードを所有しているかのように確認する

模範を示す。コードを確認してもらいます。

私の経験では、ほとんどの「RPG + Java」アプリケーションは、Java側ではなくRPG側から来るプログラマーによって書かれており、2つの世界の考え方は非常に異なり、これが基本設計の理由の1つだと思います問題。

公式のIBMツールはEclipseベースであるため、これを使用すると、Eclipseで利用できるヒントとコツのほとんどを使用できます。基本的にはこれらを表示する必要があるため、少ない労力で多くの見返りが得られるものを見つける必要があります。それを実行する価値があるという人々。

これについて私が見つけた最も効率的なものの1つは、Javaエディターの保存アクションです。ファイルを保存するたびにソースを再フォーマットするように要求できます。これにより、コーディングレイアウトがより均一になり、読みやすくなります。 私の調査結果をここに書いた。

最初にあなたが有用な提案をするかもしれないという考えを植え付けたら、人々は聞く可能性がはるかに高くなります...

「誰もが悪いコードを書いている」。それを消化し、それを認めます。これにより、チーム全体が1つの平面に配置され、階層が崩れ、すべてが平等である全員に浸透します。上級プログラマーがこれらの振る舞いと態度を実証することは非常に重要です。これらを前提として、ペアプログラミングを練習し、その間に話し合い、討論（タイムボックス）し、何かが間違っている可能性がある理由を話し合った後、何が正しいかについての決定に集中します。ペアプログラミングは1人が他より優れていますが、どちらも謙虚でオープンなプログラマです。優れたコーディング方法を促進するためのより良い方法は何ですか！:)

これまでの回答で言及されたことのない1つの方法は、教育です。最寄りのJavaZoneやRubyConf、またはあなたに適した便利な会議に行きたい人のために、あなたの会社にスポンサーエントリを依頼してください。関連するコースを見つけて、選ばれた開発者を出席させる。会社が十分に大きい場合は、ベストプラクティス、母国語のマスタークラスなどのテーマに関する社内セミナーやコースを手配することも可能です。このテーマについて優れた講師を取得し、会社の状況に合わせたコースを準備します。

私の会社はこれを非常に多く行っており、頑固に関心を拒否する人はまだいますが、このような問題に対する全体的な認識は高まり、コードベースの一般的な状態は改善しています。私たちが数回行った「ベーシックC」コースでさえ、Cを10〜15年も書いてきた開発者に啓発的であることが証明されました。彼らが悪いプログラマーであるからではなく、習慣に陥り、なぜそれを忘れがちであるのか、そして言語とそれを使用する方法についての集合的な経験もゆっくりと変化しているからです。