はてなブックマーク

コナーセンスとは コナーセンスはソフトウェアの品質メトリクスであり、結合度の分類方法です このサイトではさまざまな種類のコナーセンスをコードの改善に役立つ実例付きで紹介しています。 変更の可能性 あらゆるコードに変更の可能性があります。現実世界が変化するのに合わせて、私たちのコードも必ず変更されます。コナーセンスは、長期的な観点から柔軟性のあるコードを書くにはどうすればよいかについて洞察を提供してくれます。コードベースの柔軟性を維持することは開発速度を長期的に維持するために不可欠です。 柔軟なメトリクス コナーセンスはメトリクスであり、他のメトリクスと同様に不完全な測定値です。しかし、コナーセンスはより包括的なアプローチを取っています。コードベースのコナーセンスは以下の３つの独立した軸で判断する必要があります。 強度。コナーセンスが強いと発見が難しい、またはリファクタリングが難しくなります

コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか？ コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か？ 機能性: コードは作成者の意図通りに動作するか？ユーザーにとってコードの挙動は適切か？ 複雑さ:

コードレビューの仕方 このセクションでは、長年の経験に基づいて、コードレビューをする最良の方法に関するいろいろな推奨事項を説明しています。 各ページをひとまとめにすると一つの完全なドキュメントになりますが、便宜上、多くのセクションに分割しています。 全部を読む必要はありませんが、多数の感想によれば、ドキュメントを通読するのが個人としてもチームとしても非常に有益です。 コードレビューの基準 コードレビューの観点 レビューで CL を閲覧する コードレビューのスピード コードレビューコメントの書き方 コードレビュー中の取り下げに対応する CL 作成者のガイドも参考にしてください。こちらは CL をコードレビューしてもらう側の開発者のための詳細なガイドです。

小さな CL どうして小さな CL を書くのか？ 小さくシンプルな CL には以下のような利点があります。 速くレビューできる。レビュアーにとって、小さな CL をレビューするための 5 分間を数回確保するほうが、一度の大きな CL をレビューするための 30 分をまとめて確保するよりも容易です。 隅々までレビューできる。変更が大規模だとあっちこっちに詳細なコメントを大量に書かねばならず、レビュアーと作成者がストレスを感じやすくなります。ときには重要な点を見落としたり省略したりしてしまうこともあります。 バグが混入する可能性が減る。変更箇所が少なければ、開発者もレビュアーも CL の影響範囲が予測しやすく、バグが混入したかどうかを見分けやすくなります。 CL が却下されても無駄になる作業が少ない。巨大な CL を書いてからレビュアーに全体的な方向性が間違っていると言われると、多くの作業が無

コードレビューの観点 （注）以下のポイントを検討する際にはつねにコードレビューの基準を忘れないでください。 設計 レビューで確認すべき最も大切なことは、CL の全体的な設計です。 CL のコードの各部分は相互にきちんと連携するでしょうか？この変更はコードベースに属するものでしょうか、それともあるライブラリに属するものでしょうか？システムの他の部分とうまく統合するでしょうか？この機能を追加するタイミングは今がふさわしいでしょうか？ 機能性 この CL は開発者の意図通りに動作しますか？開発者の意図はこのコードのユーザーにとって適切でしょうか？「ユーザー」とは普通、エンドユーザー（その変更によって影響を受ける場合）と開発者（将来このコードを「使う」必要のある人）の両方を指します。 通常、CL がコードレビューに至るまでには、コードが正しく動作することを開発者が十分にテストしていると期待できます

コードレビューの基準 コードレビューの主な目的は、Google のコードベースにあるコードの全体的な健康状態を時間をかけて改善することです。 コードレビューのすべてのツールとプロセスは、その目的のために設計されています。 これを実現するには、さまざまなトレードオフのバランスを取る必要があります。 まず第一に、開発者は自分のタスクを進めることができなければなりません。 コードベースに改善を提出できなければ、コードベースは改善しません。 また、どんな変更に対してもレビュアーがいちいち難色を示して変更を取り入れずにいると、早晩、開発者は改善を行う意欲を失います。 一方、CL の品質を確認するのはレビュアーの義務です。CL を取り入れてコードベースのコードの全体的な健康状態 (code health) がだんだんと悪化するのは問題ですから、きちんと確認しなければなりません。 これは骨の折れるやっか

Google Engineering Practices Documentation (日本語訳) Google には、全言語および全プロジェクトをカバーする広範なエンジニアリングの慣行があります。 ここにあるドキュメントは私達が長年の経験からさまざまなベストプラクティスを蓄積してきたことを表しています。 この知識がオープンソースプロジェクトや他の組織の利益になることを願って、私達は可能ならそれを誰にでも利用できるように公開します。 現在、以下のドキュメントがあります。 Google コードレビューガイドライン。これは 2 つのドキュメントからなります。 コードレビュアーのガイド 変更作成者のガイド 用語 ここにあるドキュメントには、Google 内部で使われる用語があります。外部の読者のために意味を掲載しておきます。 CL: 「changelist」の略。一つの独立した変更を意味していて