自分のコードを確認するにはどうすればよいですか？
私はプロジェクトソロで作業しており、自分のコードを維持する必要があります。通常、コードのレビューはコードの作成者が行うのではないため、レビュー担当者は新鮮な目でコードを見ることができますが、私にはそのような贅沢はありません。自分のコードをより効果的に確認するには、どのような方法を採用できますか？
まず、できる限りチェックするためのツールを使用します。テスト（妥当なコードカバレッジでバックアップされている）は、コードの正確さにある程度の自信を与えます。静的分析ツールは、多くのベストプラクティスを捉えることができます。しかし、人間の目で判断する必要がある問題が常にあり、自分のものを他の人よりもよく見直すことは決してできません。しかし、あなたが助けるためにできることがいくつかあります。
- チェックテストが存在し、合格する（場合によっては、ターゲットテストカバレッジがあるが、特定のケースではこれを解除する必要があるが、理由を正当化できるはずである）
- 静的分析パスをチェックします（ここにも偽陰性がありますが、理由を正当化できるのであれば、それを抑制して罰金を科すことができれば問題ありません）
- レビューで確認する追加事項のチェックリストを維持します（可能であれば、これを新しい静的分析ルールとして追加するのが理想的です）SAはチェックできない、たとえばコメントはまだ有効であるなど） 、適切に命名されたものです（命名はもちろん、コンピュータサイエンスで知られている2つの難しい問題の1つです）
- 障害が特定された場合は、原因が系統的であるかどうかを確認し、以前のテストまたはレビューで見つからなかった理由を確認します
もちろん、これは他のコードもレビューするときに役立ちます
Code Review Stack Exchangeサイトをご覧ください。これは、作業中のプロジェクトのコードを共有するためのものです ピアレビュー ：
Code Review Stack Exchangeは、コードのピアレビューを求めるための質問と回答のサイトです。私たちは協力して、実用的なコードを取り、それを改善することにより、世界中のプログラマーのスキルを向上させています。
次の分野でプロジェクトの特定の機能するコードに関するフィードバックを探している場合…
- ベストプラクティスと設計パターンの使用
- セキュリティ上の問題
- パフォーマンス
- 予期しないケースの正当性
コードの静的分析ツールを使用して特定の種類の問題を検出することもできますが、場合によっては誤警報が発生し、設計の改善方法を提案できません。
私は頭の中で全く違う人を何人か育ててきました。それらの1つはプログラマーでもありません！私たちはチャットし、最新のニュースについて話し合い、お互いのコードをレビューしています。
私のアプローチを強くお勧めします。
ps彼は冗談ではありません。
1人でのレビューは2人でのレビューほど効率的ではないというjkの見解に同意します。ただし、それを最大限に活用することができます。
短期レビュー（コードが作成された直後）
ローカルリポジトリとしてgitを使用しています。機能を終了したり、バグを修正したりするたびに、変更をリポジトリに転送します。
チェックインする前に、コードで変更したものを比較して再考します。
- 変数/メソッド/クラス名はまだそれらが何に使用されているかを反映していますか？
長期レビュー（コードが作成されてから6か月後）
自分自身に問う：
- クラス/メソッド/変数の機能を1つの文で記述できますか？
- クラスを単独で（他のクラスは除外して）使用したり、単体テストを記述したりするのはどれほど簡単ですか。
まず、できるだけ長くコードを脇に置きます。何か他のコードに取り組んでください。 1日たっても、見つけたものに驚くことでしょう。
次に、コードを文書化します。多くのプログラマーはコードを文書化するのが嫌いですが、座って、コードの使用方法としくみを説明します。コードを別の方法で見ると、間違いが見つかります。
主題の真の習得は、それを他の誰かに教える能力であると言われています。ドキュメンテーションを使用して、誰かにコードを教えようとしています。
このデバッグ手法をコードレビュー手法に変換します。 http://en.wikipedia.org/wiki/Rubber_duck_debugging
コンセプトは、あたかもコードが新しいものであるかのようにコードを処理するための適切な考え方にあなたを置くことに驚異をもたらします。
他の回答で言及されている便利なツールに加えて、コードレビューを行うときに、考え方を変更すると便利だと思います。それはばかげていますが、私は「コードレビューの帽子をかぶっています」と独り言を言います。 QAについても同じです。
次に、-limitを自分の考え方に合わせることが重要です。あなたはレビュアーまたはレビュアーのいずれかです。同時に両方になることはできません。したがって、レビュアーとして、客観的なメモを取り、レビュアーと共有します。レビュー中はコードを変更しません。レビュー担当者が行うべきことではありません。
形式は時々少しばかげた感じがしますが、ソロで作業しているとき、私は多くの方向に引っ張られることがよくあります。そのため、何かが出る前にレビューループを閉じる必要はないかもしれません。その形式（実際には、wikiツールで大まかなメモを話している）は、レビューが完了したことを確認するのに役立ちます。同様に、QAハットを付けたまま、バグを修正する前にバグのチケットを追加します。
よくある感想として、セルフレビューは効果がないようです。私はそうは思いません、そして、徹底的に行われればセルフレビューは多くの問題をとらえることができると思います。
ここに私の数年の経験からのヒントがあります：
- 大まかなチェックリストを用意してください。これらは、コードの読み取り中にフラグを付けたいものです。
- コードレビューをオフラインにします。無駄に聞こえるかもしれませんが、注釈を付けたり、前後にめくったりできる印刷物、またはiPadに同期されたハイライトされたPDFのデジタル版を使用して、オフラインにすることができます。机から離れて、コードの邪魔にならないようにコードを確認するだけです。
- 営業日の終わりではなく、朝早くにそれを行います。新鮮な目が良いです。実際、コードを再検討する前に、コードから1日離れていた方がよい場合もあります。
参考までに-これらのガイドラインは、私がそこで働いていた数年前のOracleの推奨事項の一部であり、コードがテストに入る前に「上流」でバグをキャッチすることを目的としていました。それは多くの開発者によって退屈な仕事と考えられていましたが、それは多くを助けました。
レビューのためのパーソナルソフトウェアプロセステクニックは、仕事や製品の品質に関する履歴データに依存しますが、役立つ場合があります。
まず、作業成果物、特に欠陥の数と種類に関する履歴データから始めます。このように、欠陥を分類するさまざまな方法があります PSPコースからの1つ 。自分で開発することもできますが、その過程でどのような間違いを犯しているかを知る必要があるという考え方です。
自分が犯している間違いがわかったら、レビュー時に使用できるチェックリストを作成できます。このチェックリストは、（他のツールを使用するのではなく）レビューで捉えるのが最善だと考えている、あなたが犯しているトップミスをカバーします。作業成果物をレビューするたびに、チェックリストを使用して、それらの間違いやエラーを探し、文書化して修正します。このチェックリストを定期的に改訂して、コード内の実際の関連する問題に集中していることを確認してください。
それが理にかなっている場合は、ツールサポートの使用もお勧めします。静的分析ツールは、いくつかの欠陥を見つけるのに役立ち、いくつかはスタイルチェックをサポートして、一貫性と優れたコードスタイルを実施します。 IDEをコード補完と構文の強調表示で使用すると、「ビルド」をクリックする前に問題を防止または検出するのに役立ちます。ユニットテストはロジックの問題をカバーできます。また、プロジェクトが十分に大きいか複雑な場合、継続的な統合により、これらすべてを定期的に実行されるプロセスに組み合わせて、Niceレポートを生成できます。
一人で作業するということは、完全な見知らぬ人があなたに代わってコードをレビューすることを信頼しない限り、コードの品質を維持するためにソフトウェアの記述方法を検討する必要があるということです。
何よりもまず、コードが要件に一致していることを確認する手段が必要です。次に、何か問題が発生したと判断した場合にコードを比較的簡単に変更できるようにする必要があります。私の提案は、以下の理由で Behaviour Driven Development アプローチを適用することです。
- BDDは、最初にコードテストを記述することを意味します。これにより、すべてのコードがテストの対象になります。
- BDDは本質的にTDDですが、焦点と「言語」が少し異なります。これが意味することは、コードに取り組んでいる間、コードを継続的にリファクタリングし、テストを使用して、コードが製品仕様を確実に満たすようにリファクタリングの取り組みを継続することです。
- BDD言語では、テストを本質的に要件をユニットテストとしてエンコードするステートメントの形式で記述することを推奨しています。
つまり、ここでの考え方は、テストに合格した後でもコードを継続的にリファクタリングするということは、自分のコードを効果的に確認し、ユニットテストを「特別な目」として使用して、コードが確実に実行されるということです。テストでエンコードされている要件から外れます。また、要件に基づいた高いテストカバレッジにより、要件に違反することなく、将来コードを変更できるようになります。
実際の問題は、リファクタリングの必要性を示すコード内の潜在的な問題を見つけることができるかどうかです。市場には、これを支援するいくつかのプロファイリングツールと、コード品質メトリックに関連する他のいくつかのツールがあります。これらは、多くの場合、コードレビューで見逃す可能性のある多くのことを伝える可能性があり、自分でプロジェクトを開発する場合には必須です。ただし、実際には経験が鍵であり、リファクタリングで容赦のない習慣を身につけると、自分のコードに対してはるかに批判的になる可能性があります。まだ行っていない場合は、Martin Fowlerの Refactoring 本を出発点として読んで、動作するように選択した言語で動作すると思われる優れたBDD APIを探すことをお勧めします。と。
私があなたと同じ状況にいるときはいつでも、コードレビュー/メトリックツールを使用して、「コードに近すぎて客観的に調査できない」という問題を解決しようとしました。言うまでもなく、ツールは経験豊富なレビュアーと同じ価値を与えることはできませんが、それを使用して、設計の悪い領域を特定することはできます。
この点で私がかなり便利だと思ったツールの1つは SourceMonitor でした。これは少し単純化していますが、クラス内のメソッドの数や各メソッドの複雑さなど、コードについて中程度の見解を示しています。このタイプの情報は、StyleCopなどのツールを介したコーディングスタイルの実施と同じくらい重要であると感じていました（これは重要ですが、多くの場合、最大の問題の原因ではありません）。これらのツールを通常の免責事項とともに使用します。経験則を破るタイミングを知ってください。コードメトリックツールですべてグリーンになっているものは、自動的に品質が良くなるわけではありません。
私がコードレビューアに説明している回数と、頭の電球が点灯して「ちょっと待って」と言う回数はわかりません。そのため、他の人には見られなかったコードレビューで自分の間違いをよく見つけます。だからあなたはそれを試すことができます、あなたの隣に座ってあなたが何をしたのか、なぜそれを理解しようとしている人がいるかのように、コードの説明を始めてください。
私がコードレビューで頻繁に見つけるもう1つのことは、開発者が実際に要件に従っていないことです。したがって、コードと実際の要件を比較して、適切なチェックを行う必要があります。
私たちは、SSISパッケージのような構造上のニーズがあることを頻繁に行っています-コードレビューのために、チェックする項目のチェックリストを作成しました（構成は正しいか、ログが設定されているか、メタデータデータベースを使用しているか、標準の場所にあるファイルか、等。）。コードレビューでも毎回確認するのに便利なものがあるかもしれません。コードレビューで必ず確認したいことのチェックリストに何を載せるかについて考えてください（最初の項目、要件が満たされていることを確認してください。次の項目は、トラップエラーとログ記録エラーに関係している可能性があります）。間違いを犯して修正したら、他のアイテムをリストに追加できます（たとえば、ループ内の次のレコードに移動するのか、それとも同じ最初のアイテムを無限に繰り返すのですか？それを探すように教えてください！）これは主に、やるべきことを忘れるのを防ぐためです。
私は通常、すべてのコードを出力して静かな環境に座って読み、多くのタイプミス、問題、リファクタリング、クリーンアップを行います。誰もがすべきだと思うのは良いセルフチェックです.
3か月後、コードに戻ります。あなたがそれで何か悪いことを見つけられないなら（またはこのジャンクを書いた人に質問を！）あなたは私よりも良い人だと約束します！
大学に戻って、私は執筆の家庭教師でした。確かに、多くの開発者が考えたことのないようなコーディングの見方を私に与えてくれました。最も重要なことの1つは、コードを読み上げることです。あまり聞こえませんが、誰もが共感できると思います。
メールや論文を書き、何度も読み直して正しいことを確認してから送信しましたが、目立ったスペルミス、タイプミス、文法エラーがあることを発見しただけですか？昨日、クライアントにシフトキーの代わりにシットキーを押すように頼んだとき、私はちょうどこれをやった。あなたが頭の中で読んだとき-あなたはあなたが見たいものを見ます。
これは、他の人が行った「1日、1週間、または1か月だけ待つ」という提案のショートカットです。声を出して読むと、同じことがわかります。なぜそれがそんなに効果的かはわかりませんが、何百人もの生徒と一緒に座って声を出して読んだ後、私が言えることはそれがうまくいくということだけです。
ほとんどの人は自分のコードを自分の赤ちゃんと見なし、現実よりもむしろエゴを与える傾向があります。他のコードレビューと同じように、他の人のコードが表示されているときにレビューします。あなたが何かを書いたことを完全に忘れてください。コードの各行を確認します。チェックリストは、自分のコードをレビューすることの美学に役立つでしょう。コードレビュー用の自動化ツールは、ある程度の拡張に役立ちます。私は klocwork （商用ソフトウェア）のようないくつかのツールを使用しました。これは、大規模なプロジェクトで作業していて、何人かの開発者が作業しているときに非常に役立ちます。修正ではなく、常に欠陥検出に焦点を当てます。
しかし、ベストプラクティスは、自分自身を確認し、後で他の少なくとも2人の人を巻き込んで、明確な役割を持つ確認を行うことです。
Faganインスペクションを自分で行うことを検討してください。自分で行うのでプロセスを適応させる必要がありますが、そこからかなりの価値を引き出すことができるはずです。秘訣は、コードを単独の開発者として評価するための適切な「ルールセット」を見つけ、そのたびに、批判的で分析的で容赦のない心の中でそれらの質問をする規律を持つことです。まず、独自の4〜5の重要な質問をブレインストーミングして、それを時間とともに進化させたいと思うかもしれません。時間がかかるように思われるため、一部の人々は正式な検査に反対しています...検査が高すぎると判断する前に、検査を適切に行うと実際にプロジェクト時間が短縮されるというすべての統計的証拠に留意してください。ここにあなたがさらなる研究を始めることができるウィキペディアのリンクがあります：
http://en.wikipedia.org/wiki/Software_inspection
いくつかの本もありました。シュトラウスとエベナウによる「ソフトウェア検査プロセス」のGoogle。
別のオプションは、重要なプロジェクトを検査するために誰かにお金を払うことです-またはおそらくすべてのコードの検査を行うために彼らに時々支払うことです。この人はかなりいいです、私達は私達の新しい開発者を訓練するために彼を何度も空輸しました：
コードレビューに関するすべての推奨事項とは別に、PMDやfindBugなどのツールを使用して、コードの第1レベルの健全性を実現できます。
これは実際にはまだ回答に配置されていません（ただし、コメントとして既存の回答に追加されています）。
安眠した後、コードを確認してください。前日に作成したコードを確認して、1日を始めます。
もちろん、これはチームの集合的な経験を与えるものではありませんが、新しい視点からコードを確認することができます。
たとえば、コードの一部に厄介なハックを残した場合、直後にコードを確認すれば、修正する傾向があまりないかもしれません。結局のところ、コードのレビューを開始すると、このハッキングの存在をすでに知っており、受け入れています。しかし、良い睡眠をとっていれば、より良い解決策を見つける意欲が高まるでしょう。
私たちが眠るとき、脳は実際に私たちが抱えている問題への取り組みを停止しません。そのため、実際にそこに解決策を思い付くかもしれませんが、それらの解決策は 時々奇妙な方法で現れることがあります 。