前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
発表 ↑ です。ヒカリエ相変わらず奇麗で良いですね。なんか来週も行くかと思いきや会場変更ですが(急でスミマセン……)……。 会場で割と、「githubのほうが〜〜という点で有利ではないか」みたいな意見をもらった気もしますが、言われたことはぼくもほぼ大筋同意しています。 基本、githubにすでに慣れていて、レビューの勘所もつかんでいるのならgithubを便利に使えば良いと思います。 ぼくはまあ、みんながギッハブギッハブ言っていてもつまんないよな〜と思ったので、gerritを使っていて一定以上の程度でちゃんと回せているというのを伝えたかったのと、あと前の会社での経験がありまして、前の会社でもgithubにリポジトリをクローンしていたんですが、あんまり有効に使えていなかったよな〜と言う思い出があります（ぼくのいたチーム、まあ途中で空中分解したんですが、は少なくとも誰も有効な使い方を分かっていな
タイトル適当。 まともに書いてブロッグにアップしたかっｔ 必要なもの gitに対する愛 開発プロセスに対する愛（わぁいレビュー あかりレビュー大好き） 前提状況 申し訳ないけど「gerrit の機能が一通り使える」ことが前提のフロー。githubは読み替えて。gerrit 自体の使い方も、正直よい日本語の記事が無いので時間があれば書くかもしれない。 で、以下のような機能を作る 1) Foo 機能の処理モジュール(Service) 2) Foo 機能のHTTPサーバ側エンドポイント(Controller) 3) Foo 機能のブラウザ側の表示(View) 4) Foo 機能のブラウザ側からのサーバ側への連携(Client-side Cooperation) 2 は 1 に、 4 は 1-2 と 3 に依存している。とりあえず上から作っていく。この時点では 2 までできたよ、とする。後、トピッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
