メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
IPA ISEC セキュア・プログラミング講座：C/C++言語編 第2章 脆弱性回避策とソフトウェア開発工程：ソースコードレビュー
ソースコードレビューは、開発者担当者が書いたソースコードを閲読してセキュリティ脆弱性あるいはそのきざしを読み取る作業である。 ソースコードレビューで見いだされた脆弱性の情報を開発作業にフィードバックし、ソースコード修正を行う。 (1) ソースコードレビューを行う理由 プログラマが書き下ろしたソースコードは、そのままでは多くのバグといくつかのセキュリティ脆弱性を内に秘めているおそれがある。 ソースコードの正しさを検証するためにテストを行うのであるが、その前にソースコードをレビューしてブラシュアップすることにより、問題の何割かを事前に除去しておくことができる。 (2) 誰が行うか ソースコードレビューを行う人物には次が考えられる。 開発者本人 開発チームの別の担当者 開発チームとは独立したセキュリティ脆弱性対策チームのメンバ 開発者本人がソースコードを見直すことと、別の人物の眼によるチェックを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
