自分のコードをレビューするにはどうすればよいですか？[閉まっている]

私はプロジェクトのソロに取り組んでおり、独自のコードを維持する必要があります。通常、コードのレビューはコードの作成者ではなく行われるため、レビュー担当者はコードを新鮮な目で見ることができますが、私にはそのような贅沢はありません。自分のコードをより効果的にレビューするためにどのようなプラクティスを採用できますか？

まず、ツールを使用してできる限りチェックします。テスト（ある程度の妥当なコードカバレッジでバックアップされます）は、コードの正確性についてある程度の自信を与えます。静的分析ツールは、多くのベストプラクティスを把握できます。しかし、決定するために人間の目が必要な問題が常にあり、あなたは他の誰かと同じように自分のことをレビューするのに良い仕事をすることはありませんが、あなたが助けるためにできることがいくつかあります

• テストが存在することを確認し、合格します（特定のケースではこれを破る必要があるかもしれませんが、おそらくターゲットテストの範囲がありますが、理由を正当化できるはずです）
• 静的解析のパスを確認します（ここにも偽陰性がありますが、なぜそれを抑制するのが良いのかを正当化できる限り問題ありません）
• レビューでチェックする追加のチェックリストを維持します（可能であれば、これを新しい静的分析ルールとして追加するのが理想的です）。もちろん、コンピューターサイエンスで知られている2つの困難な問題の1つ）
• 障害が特定された場合は、原因がシステムにあるかどうかを確認し、以前のテストまたはレビューで見つからなかった理由を調べます

これはもちろん、他のコードもレビューするときに役立ちます

見てくださいコードレビュースタックExchangeサイトを。これは、ピアレビューのために作業しているプロジェクトのコードを共有するためのものです。

Code Review Stack Exchangeは、コードのピアレビューを求めるための質疑応答サイトです。私たちは、作業中のコードを取得して改善することにより、世界中のプログラマーのスキルを向上させるために協力しています。

次の分野でプロジェクトの特定の作業コードに関するフィードバックを探している場合…

• ベストプラクティスとデザインパターンの使用
• セキュリティ上の問題
• 性能
• 予期しない場合の正確さ

コードの静的分析ツールを使用して特定の種類の問題を検出することもできますが、場合によっては誤ったアラームが生成され、設計の改善方法を提案できません。

私は頭の中で全く異なる人を何人か開発しました。そのうちの1人はプログラマーでもありません！私たちはチャットし、最新のニュースについて話し合い、お互いのコードを確認しています。

私のアプローチを強くお勧めします。

ps彼は冗談ではありません。

私は、1人のレビューは2人のレビューほど効率的ではないというjk-sの意見に同意します。ただし、最大限に活用することができます。

短期レビュー（コードが作成された直後）

gitをローカルリポジトリとして使用しています。機能を終了するかバグを修正するたびに、変更をリポジトリに転送します。

チェックインする前に、コードで変更した内容を比較して再考します。

• 変数/メソッド/クラス名はまだそれらが使用されるものを反映していますか？

長期レビュー（コードが作成されてから6か月後）

自分自身に問う：

• クラス/メソッド/変数が何をするかを1つの文章で説明できますか？
• クラスを単独で（他のクラスなしで）使用したり、ユニットテストを書いたりするのはどれくらい簡単ですか？

まず、実用的な限りコードを脇に置きます。他の何か、他のコードに取り組みます。1日たっても、あなたはあなたが見つけるものに驚くでしょう。

次に、コードを文書化します。多くのプログラマーは自分のコードを文書化することを嫌いますが、自分自身に座って、コード、コードの使用方法、および動作方法を文書化するようにさせます。コードを別の方法で見ると、間違いが見つかります。

主題の真の習得は、それを他の誰かに教える能力であると言われています。ドキュメントを使用して、他の人にコードを教えようとしています。

このデバッグ手法をコードレビュー手法に変換します：http : //en.wikipedia.org/wiki/Rubber_duck_debugging

コンセプトは、コードを新しいものであるかのように操作するための適切な考え方にあなたを向けるのに驚異的です。

他の回答で言及された便利なツールに加えて、コードのレビューを行うときにあなたの考え方を変更すると便利だと思う 馬鹿げていますが、「コードレビューの帽子をかぶっています」と自分に言います。QAでも同じことをします。

次に、その考え方に自分自身を制限することが重要です。あなたは校閲者または校閲者のどちらかであり、両方を同時にすることはできません。そのため、レビュアーとして、客観的なメモを取り、レビュー対象者と共有します。レビュー中にコードを変更することはありません。これはレビューアがすべきことではありません。

フォーマルさはときどき少しばかげているように感じますが、ソロで仕事をしていると、多くの方向に引っ張られることがよくあります。そのため、他の何かが現れる前に必ずしもレビューループを閉じるとは限りません。その形式（実際、Wikiツールで大まかなメモを話している）は、レビューを確実に完了させるのに役立ちます。同様に、QAハットを有効にして、バグを修正する前にバグのチケットを追加します。

一般的な感情は、自己レビューが効果的ではないようです。私は同意しません。徹底的に行うと、セルフレビューは多くの問題をキャッチできると思います。

ここに私の数年の経験からのヒントがあります：

• 大まかなチェックリストを用意してください。これらは、コードを読むときにフラグを立てたいものです。
• コードレビューをオフラインにします。無駄に聞こえるかもしれませんが、注釈を付けたり、前後に反転したりできる印刷物、またはiPadに同期されてオフラインになった見事に強調されたPDFのデジタル版を取ります。デスクから離れて、コードの気を散らすことなくレビューするだけです。
• 一日の終わりではなく、早朝にやってください。新鮮な目のペアが優れています。実際、コードを改めてレビューする前に1日コードから離れていた方が助けになるかもしれません。

参考までに、これらのガイドラインは、数年前に私がそこで働いていたOracleの推奨事項の一部であり、コードがテストされる前に「上流」でバグをキャッチすることを目的としていました。多くの開発者によって退屈な仕事と見なされていましたが、それは大いに役立ちました。

レビューのための個人用ソフトウェアプロセスのテクニックは有用かもしれませんが、あなたの作業と製品の品質に関する履歴データを持っていることに依存しています。

作業成果物に関する履歴データ、特に欠陥の数と種類から始めます。PSPコースのこのような欠陥を分類するさまざまな方法があります。自分で開発することもできますが、考えていることは、途中でどんな間違いを犯しているのかを伝える必要があるということです。

どのような間違いを犯しているのかがわかったら、レビュー中に使用できるチェックリストを作成できます。このチェックリストは、（他のツールを使用するのではなく）レビューで最もよくキャッチできると思われる、あなたが犯しているトップミスをカバーします。作業成果物を確認するたびに、チェックリストを使用して、それらの間違いやエラーを探し、文書化し、修正します。このチェックリストを定期的に改訂して、コード内の実際の関連する問題に焦点を合わせていることを確認してください。

理にかなっている場合は、ツールサポートを使用することもお勧めします。静的解析ツールは、いくつかの欠陥を見つけるのに役立ち、一部は一貫性と優れたコードスタイルを強制するためのスタイルチェックをサポートします。コード補完と構文強調表示を備えたIDEを使用すると、「ビルド」をクリックする前にいくつかの問題を防止または検出するのにも役立ちます。単体テストは、ロジックの問題をカバーできます。また、プロジェクトが十分に大きいか複雑な場合、継続的な統合により、これらすべてを定期的に実行されるプロセスに結合し、優れたレポートを作成できます。

単独で作業するということは、完全に見知らぬ人があなたに代わってコードをレビューすることを信頼しない限り、コードの品質を維持するためにソフトウェアの作成方法を検討する必要があることを意味します。

何よりもまず、コードが要件を満たしていることを確認する手段が必要です。次に、何か問題が発生したと判断した場合にコードを比較的簡単に変更できることを確認する必要があります。私の提案は、次の理由から行動駆動開発アプローチを適用することです。

1. BDDは、最初にコードテストを記述することを意味します。これにより、すべてのコードがテストでカバーされます。
2. BDDは本質的にTDDですが、焦点と「言語」が少し異なります。これが意味することは、作業中のコードを継続的にリファクタリングし、テストを使用して、コードが製品仕様を満たしていることを確認するリファクタリングの努力を継続することです。
3. BDD言語では、要件を基本的に単体テストとしてエンコードするステートメントの形式でテストを作成することを推奨しています。

したがって、ここでのアイデアは、テストに合格した後でもコードのリファクタリングを継続するということです。つまり、効果的に独自のコードをレビューし、ユニットテストを「余分な目」として使用してコードを確認します。テストでエンコードされている要件から外れている。また、要件に基づいた高いテストカバレッジにより、要件を満たさずに将来コードを変更できるようになります。

あなたにとっての本当の問題は、リファクタリングの必要性を示すコードの潜在的な問題を見つけることができるかどうかです。市場には、これに役立ついくつかのプロファイリングツールと、コード品質メトリックに関係する他のいくつかのツールがあります。これらは多くの場合、コードレビューで見落としがちな多くのことを教えてくれます。また、自分でプロジェクトを開発する際には必須です。ただし、実際には経験が鍵となり、リファクタリングで無慈悲になる習慣を身に付けると、自分のコードに対してはるかに批判的になる可能性が高くなります。まだお持ちでない場合は、Martin Fowlerのリファクタリングの本を出発点として読み、使用する言語を選択した場合に役立つBDD APIを探すことをお勧めします。

自分と同じ状況にいるたびに、コードレビュー/メトリックツールを使用して、「コードに近すぎて客観的に調べることができない」という問題を解決しようとしました。言うまでもなく、ツールは経験豊富なレビュアーと同じ価値を与えることはできませんが、それらを使用してデザインの悪い領域を特定することができます。

この点でかなり便利だと思ったツールの1つにSourceMonitorがありました。これは少し単純化されていますが、クラス内のメソッドの数や各メソッドの複雑さなど、コードの中間レベルの良い意見を提供します。この種の情報は、StyleCopなどのツールを使用したコーディングスタイルの適用（重要ではありますが、最大の問題の原因ではないことが多い）ほど重要であると常に感じていました。これらのツールは通常の免責事項と共に使用してください。経験則を破るタイミングを知ってください。コードメトリックツールですべてがグリーンなものは、自動的に良質ではありません。

コードレビュー担当者に何かを説明してきた回数を話すことができず、頭の電球が点灯して「ちょっと待って」と言います。そのため、他の人が見なかったコードレビューで自分の間違いをよく見つけます。だから、あなたはそれを試すことができ、あなたが何をしたのか、そしてその理由を理解しようとしているあなたの隣に座っている人がいるかのようにコードを説明し始めてください。

コードレビューでよく見かけるもう1つのことは、開発者が実際に要件に従っていないことです。したがって、コードと実際の要件を実行するコードを比較するのは良いチェックです。

同様の構造上のニーズを持つSSISパッケージのようなことを頻繁に行います-コードレビューのために、チェックするもののチェックリストを作成しました（構成が正しいか、ログが設定されているか、メタデータデータベースを使用するか、標準の場所にあるファイルか、等。）。コードレビューでも毎回確認するのに便利なものがあるかもしれません。座って、コードレビューで確認することを確認したいもののチェックリストに何を置くかを考えてください（最初の項目、要件が満たされていることを確認し、次の項目はエラーのトラップとロギングに関係があるかもしれません）。間違いを犯して修正したら、リストに他のアイテムを追加できます（たとえば、ループ内の次のレコードに移動するか、同じ最初のアイテムを無限に繰り返しますか？それを探すことを教えてください！）。

それを3か月与えてから、戻ってコードを見てください。何かおかしな点を見つけられない場合（またはこのジャンクを書いた人に質問する場合）、あなたは私よりも優れた男です！

私は通常、すべてのコードを印刷し、静かな環境に座ってそれを読み通します。多くのタイプミス、問題、リファクタリング、クリーンアップを見つけます。誰もがすべきだと思うのは良い自己チェックだ。

大学に戻って、私はライティングの家庭教師でした。多くの開発者が考えもしなかったと思うコーディングに関するいくつかの視点を確かに与えてくれました。最も重要なことの1つは、コードを声に出して読むことです。大したことではないように聞こえますが、誰もが関係できると思う完璧な例を挙げます。

メールや論文を書き、何度も読み直して正しいことを確認してから送信しましたが、つらいスペルミス、タイプミス、文法ミスがあることがわかりましたか？昨日、クライアントにシフトキーの代わりにたわごとキーを押すように依頼したときにこれを行いました。頭の中で読むと、見たいものが見えます。

これは、「1日、1週間、1か月待つだけ」という他の人の提案のショートカットです。声を出して読むと、同じことがわかります。なぜそんなに効果的かはわかりませんが、何百人もの生徒と一緒に座って声を出して読んだ後は、うまくいくというだけです。

ほとんどの人は、自分のコードを自分の赤ちゃんと見なし、現実よりもエゴを与える傾向があります。他のコードレビューと同じように、他の人のコードが表示されているときにレビューします。何かを書いたことを完全に忘れてください。コードの各行を確認します。チェックリストは、独自のコードのレビューに関する審美性を高めるのに役立ちます。コードレビュー用の自動化ツールは、ある程度の拡張に役立ちます。私はklocwork（商用ソフトウェア）のようないくつかのツールを使用しました。これは、大規模なプロジェクトで作業していて、複数の開発者が作業しているときに非常に便利です。修正よりも常に欠陥検出に焦点を合わせます。

しかし、ベストプラクティスは、自分自身をレビューし、後から少なくとも2人の他の人を関与させて、顕著な役割でレビューすることです。

自分でFaganの検査を行うことを検討してください。自分で作業しているため、プロセスを調整する必要がありますが、そこからかなりの価値を引き出すことができるはずです。トリックは、ソロ開発者としてコードを評価するための適切な「ルールセット」を見つけ、そのたびに批判的、分析的、容赦ない心の中でそれらの質問をする規律を持つことです。最初から4〜5個の重要な質問をブレーンストーミングし、時間の経過とともに進化させたいと思うかもしれません。一部の人々は、非常に時間がかかるように見えるため、正式な検査に反対しています...高価すぎると判断する前に、検査を適切に行うと実際にプロジェクト時間が短縮されるというすべての統計的証拠に留意してください。以下のウィキペディアリンクを使用して、さらに調査を開始できます。

http://en.wikipedia.org/wiki/Software_inspection

シュトラウスとエベナウによる「ソフトウェア検査プロセス」のためのグーグルなど、いくつかの本もありました。

別のオプションは、誰かに重要なプロジェクトを検査するためにお金を払うことです-あるいは、すべてのコードの検査をするために時々彼らにお金を払うことです。この男はかなりいいです。新しい開発者を訓練するために何度も彼を空輸しました。

http://www.javaspecialists.eu/

コードレビューに関するすべての推奨事項とは別に、PMDやfindBugなどのツールを使用して、コードの第1レベルの健全性を実現できます。

これは実際にはまだ回答に含まれていません（ただし、既存の回答へのコメントとして追加されています）

おやすみなさいの睡眠の後、コードをレビューします。例えば、前日書いたコードをレビューすることで一日を始めます。

もちろん、これはチームの集合的な経験を与えるものではありませんが、新しい視点からコードをレビューできるようにします。

たとえば、コードの一部を厄介なハックのままにした場合、すぐにコードをレビューすれば、修正する気にはならないかもしれません。結局のところ、コードのレビューを開始すると、このハッキングの存在をすでに知っており、受け入れています。しかし、あなたが良い睡眠をとったならば、あなたはおそらくより良い解決策を見つけるためにもっとや​​る気があります。

私たちが眠るとき、脳は実際に私たちが抱えている問題に取り組むことを止めないので、あなたは実際に解決策を思いつくかもしれませんが、それらの解決策は時々奇妙な形で現れるかもしれません。