コードレビューの話新卒エンジニア向けにコードレビューを「する」話をしました。 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
コミットへのコメントサービス - クリアコード
改良版サービスのおしらせ 現在は、本サービスの改良版を「コードリーダー育成支援」として提供しています。本サービスで大事にしていることはコードリーダー育成支援サービスでも同様に大事にしていますので、本サービスにご興味がありましたらお問い合わせください。開発チームにあった進め方をご提案します。トライアルを実施して理解を深めることもできます。 クリアコードは、よいコードを書くことを当たり前にするためには、まず「みんながみんなのコードを読む」文化にすることからはじめるのがよいと考えます。 そこでクリアコードは、「みんながみんなのコードを読む」文化づくりを支援する目的で、「コミットへのコメントサービス」を提供します。 みんながみんなのコードを読む文化とは みんながみんなのコードを読むとは ここでいう「みんな」とは同じ開発チームのメンバーのことです。「みんなのコードを読む」ということはコミットされたす
WEB+DB PRESS Vol.72はコードレビュー特集 | Act as Professional
Vol.72の特集は「コードレビュー」です。会議のように日時をかっちり決めて、会議室にこもってやるようなコードレビューだけではなく、Androidの開発で使われているGerritの様なツールを利用したコードレビューについて特に詳しく書かれています。 今号は@udzuraさんが書いてるページがものすごく多いですね！Ruby連載ではRackについても書かれています。最近ではOmniAuthなどのRackミドルウェアを使う機会が多いと思うので、Rackについて改めて学び直しておく良い機会です。 特集3ではBacklogやCacooを提供している株式会社ヌーラボの開発している様子が興味深いです。特にヌーラボは多拠点で開発をしていると聞いているので、どんな感じなのかな？という様子が垣間見える内容です。 アドベントカレンダーもいいですが、Web+DB PRESSも要チェックですね！
コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リーダブルコードを読んだ後 - Kouhei Sutou - Rabbit Slide Show
Blog