多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え
