近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥
この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
