クソコードの測り方
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
