レビューのアウトプットは、レビューアのレベルを超えない（2）: 柴田 芳樹 (Yoshiki Shibata)
開発組織としてメンバーのスキル向上を行うためには、経験豊富なエンジニアの知識をレビューという形式で伝えていくことが重要です。そして、たとえ初心者であっても、繰り返しきちんとしたレビューを受け続けることにより、成長させていく必要があります。コードレビューは、ソフトウェアの品質を作り込む場でもあるのですが、同時にエンジニアを教育する場でもあったりします。 しかし、開発組織がコードレビューに関して否定的だと、開発プロセスでレビューすることが規定されているというだけの理由で、初心者レベルのエンジニアだけでレビューを行わせたりします。ここで「初心者レベル」というのは、ソフトウェア開発経験年数が少ないという意味ではなく、きちんとしたコードを書くということに関して初心者レベルという意味です。 コードの品質に興味がない人がリーダとして開発チームをリーディングしている場合には、開発が遅れてくると大量に初心者
レビューのアウトプットは、レビューアのレベルを超えない: 柴田 芳樹 (Yoshiki Shibata)
拙著『プログラマ”まだまだ”現役続行』では、コードレビューに関して以下のことを述べています。 コードを複数の開発メンバーでレビューした結果のコードの質は、レビューに参加したレビューア以上のものにはなりません。つまり、いくらコードレビューが効果的だとはいっても、プログラミングの初心者どうしが集まってお互いのコードをレビューしたところで、その質には限界があります。 ペアプログラミングによって、コーディングを行いながらレビューした場合も、まったく状況は同じです。つまり、ペアプログラミングによってコードの品質が向上するかどうかは、誰とペアプログラミングしたかに依存します。 時間をかけてコードをレビューするのですから、レビュー結果として高い質を求めるためには、対象とする領域に関する技術知識を持ち、読みやすいコードを書くことに関しても知識とセンスを持つソフトウェアエンジニアがレビューアとして参加する必
アジャイル開発手法「スクラム」の工程を、1枚のイラストで分かりやすく説明する
アジャイル開発手法としてもっともよく使われている「スクラム」の工程を1枚のイラストで説明した資料が、ブログRyuzee.comのエントリ「[Agile]Scrumの流れをイラスト1枚で説明した資料」で紹介されていました。 とても分かりやすいイラストでしたので、Publickeyでも紹介させていただきます（大きな画像はこちら）。 日本語の文字が少し小さかったので、あらためて僕の方で日本語を当てはめてみました。もしも変な訳だと感じた方がいましたらアドバイスなどいただければと思います。 このイラストのオリジナルとなったのが、ブログThe Critical Path by Derek Huetherにポストされた「Free Intro To Scrum Wallpaper」です。この記事ではもう1つ、スクラムの工程を別のイラストで紹介したものがあるので、そちらも日本語化してみました（大きな画像はこ
グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
