コードレビューいろいろ - steps to phantasien
コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque
ホッピングの話のつづき - steps to phantasien
つづき。 Should の話は 前回 済ませた。 今日は was のはなし。私の時はこんな風だった、こんな会社があったという話をしてみたい。 読みやすさや角をたてないためなどの都合で一般化した書き方をするけれど、 ごく限られたインスタンスが相手である点はご了承ください。 グリッドと地層 最初のホッピングが終わって気づいたのは、新卒という立場の特別さだった。 新卒は給料が安く世間知らずとホッピング界ではバカにされがち。 けれど実際は良いこともある。 いまの私から見て一番うらやましい新卒特典は、 バッチ採用された同期入社の同僚たち。たくさん、しかも部門をまたいであちこちにいる。 中途採用で勤め始めると、知り合いは周りの人たちだけだ。 社交的で知り合いを増やすのが得意な人にしてみれば、 これは小さなことかもしれない。 でも人見知りな身からするとシステムとして顔見知りができる バッチ採用は大きな助
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
