コード検査システムは、商業開発プロセスに完全に適さないとscられることもあります。 これは批評家に関するものではありません。 評論家は、大企業の大規模プロジェクトで商用ソフトウェア開発のプロセスでテストされ、優れていることが証明されました。 この素晴らしいツールを試すことを強くお勧めします。
批評家のソースコードは、 github.com / jensl / criticからダウンロードできます。
評論家はスウェーデンの開発者OperaによってJensLindströmという名前で書かれました。 彼は既存のコード検査システムに満足していなかったため、独自のコード検査システムを作成することにしました。 ところで、イェンスはこれだけで有名ではありません。 興味がある人は、インターネットでCarakan Opera JSエンジンに関する彼の投稿を検索できます。
批評家は、オペラの特定のニーズとタスクのために書かれました。 このツールの作成者もそのユーザーでした。 彼はこのツールを自分自身や他の開発者にとって実用的で有用なものにしようとしました。 彼を見て批評家のユーザーが成長し、便利な機能で成長するにつれて、ジェンスは成功したと思います。 評論家は、ユーザーの時間を節約する便利で効果的なツールであることが判明しました。
CriticはWebアプリケーションであり、Pythonで記述されています。 CriticはGitと密接に統合されています。 コミットは、Criticが監視しているGitリポジトリにプッシュするとすぐにレビューに追加されます。
検査サイクルは次のとおりです。
- レビュー作成者は、Criticが監督するGitリポジトリにコードをコミットします。
- コミット方法に応じて、git pushを使用して自動的にレビューを作成するか、Critic Webインターフェイスを使用して手動でレビューを作成できます。
- レビューが作成されるとすぐに、変更を受けたコードのインスペクターとオブザーバーに電子メールで通知されます。
- インスペクターとオブザーバーは、問題メモとコードメモを追加できます。 変更されたコードを検査済みとしてマークできるのは、インスペクターのみです。 検査されたコードは承認されたという意味ではありません。 これは、検査官がそれをチェックし、発見したすべての問題の記録を作成したことを意味します。
- レビューの作成者は、問題とメモの議論に参加し、見つかった問題を修正する新しいコミットをレビューにプッシュします。 新しいコミットは未検査としてマークされます。 項目4〜5は何度も繰り返すことができます。
- すべてのコミットが検査され、問題のオープンレコードが1つもない場合、レビューは承認されたと見なされます。
- 承認されたレビューは、たとえばBTSのバグと同様に再発見できます。 クローズされた問題レコードも再発見される場合があります。 そしてもちろん、検査済みのコードに新しい問題を追加することができます。 哲学はBTSのようなものです。 特定のワークフローがあり、通常はそれに従いますが、必要に応じて、このワークフローの前のフェーズに戻ることができます。
いくつかのメモ：
- 問題レコードは、レビュー全体、コミット、または特定のコード行を参照できます。 これらのコード行は、コミットの一部ではない可能性があります。 たとえば、コミットによって変更されていないコードの動作が変更された場合など、「変更されていない」コードの一部になります。 問題レコードが特定のコード行を参照し、これらの行が次のコミットで修正される場合、問題はこのコミットによって「対処済み」としてマークされます。 ただし、新しいコミットは未検査としてマークされるため、すべてのレビューが自動的に承認されることはありません。 これは、システムで作業するときに時間を節約する機能の1つです。
- 評論家は「歴史の書き換え」をサポートしています。 怖いように聞こえますが、特にgit rebase -iを使用して並列Gitブランチで「書き換え」が行われる場合に便利です。 たとえば、レビューが50件のコミットに成長し、これらのコミットの多く（マイナーバグ修正、コンパイル修正、変数名の変更、コメントの編集、その他の「クリーンアップ」など）がVCSの履歴を破棄します。 そのような場合、メインプロジェクトコードへの統合のためにブランチを提供する前に、これらのすべての中間修正を、修正したコミットに「固定」すると便利です。 したがって、プロジェクトのメインブランチには、混乱ではなく、常に美しいストーリーがあります。 まあ、またはほぼ常に。 そのため、このような操作を実行し、同じ内容で50の「悪い」コミットを5つの「良い」コミットに変更した場合、評論家はこのコードをもう一度検査するように求めません。 すべてがうまくいくためには、50の「悪い」コミットの差分の合計が5つの「良い」コミットの差分の合計と100％一致する必要があります。 書き直されたストーリーはレビューで公開されます。
- 評論家は、ブランチのレビューポイントの変更もサポートしています。 プロジェクトのメインブランチの上部からレビューブランチをブランチするとします。 検査中、プロジェクトのメインブランチは前進しました。 また、メインブランチの新しい現実に合わせて、ブランチでコードを変更する必要があります。 何をすべきか、新しいレビューを作成し、このレビューですでに行ったすべての作業を失いますか？ どんなに。 評論家はここであなたを助けます。 同じgit rebaseを使用して、すべてのコミットを新しいブランチポイントにコピーし、正確にブランチポイントを移動した場所をCriticに伝えることができます。 そして彼はすべてを理解するでしょう！ また、同じコードをもう一度検査することを求めません。 そして、彼はあなたにメインブランチから大量のコードを検査するように頼みません。 しかし、彼はあなたがマージの衝突を解決したことに気付き、あなたがそれを正しく行ったかどうかを検査するよう検査官に尋ねます。 まあ、それは素晴らしいことではありませんか？
- Criticは拡張機能をサポートしています。 「今はファッショナブルです。」拡張機能は明らかにCriticの機能を拡張し、さらに時間を節約できます。 拡張機能は、すべてのユーザーが必要としないさまざまな特定の機能を実装できます。 したがって、各ユーザーは、必要な拡張機能を自分でインストールします。 プロジェクトXで作業しているとします。バグを修正します。 レビューでは、最初はバグ修正に対して1つのコミットがありましたが、インスペクターは非常に厳しく、それらを満足させるために修正にさらに5つの修正をコミットする必要がありました。 最終的にレビューが承認されました。 そして、あなたは少しシンプルですが、コミットをコミットするための退屈な正式な仕事をしています。 プロジェクトの誰かがチームメイトの生活を楽にすることを決め、プロジェクトの拡張機能を開発しました。 拡張機能は、「バグ修正をプロジェクトXに統合する」ボタンをWebインターフェースに追加します。 これで、この魔法のボタンを押すことができ、Criticが多くの便利なことをしてくれます。
- 6つのコミットを1に収集します。
- 最初のコミットからコメントを提供します。
- コメントの編集を提案します。
- 進行中のプロジェクトのメインブランチ、またはバグ修正のためのブランチとのマージの競合があるかどうかを確認します。
- バグ修正のためにブランチに修正をコミットします。
- Criticのレビューを閉じます。
- BTSで何か良いことを書きます。
- BTSのバグを閉じます。
- Criticは、Gerritなどのメインプロジェクトリポジトリのラッパーではありません。 したがって、Criticは、組織の都合に応じて、コミット前レビューとコミット後レビューの両方に使用できます。 ただし、評論家は、メインリポジトリからコードを取得することも、1つのリポジトリを共有することもできます。 また、前の段落で示したように、拡張機能を使用してそこにコードをプッシュします。
評論家もあなたの役に立つことを願っています。 開発に頑張ってください！