多人数プロジェクトで学んだこと

• この書き方はまずいからあとで直そう→直さない
• あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる
• コミュニケーションしなくても正しい判断ができるようにする
• 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。
• どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい?
• 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。
• 軌道を修正するコストは早ければ早いほど小さい。
• 仕組みを変えることにはコストが伴う。心理的コストも。
• 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。
• 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変えるのがいいんだと思う。
• 些細なことほど、最初からよく考えて設計することが重要。「名前が微妙」程度の理由では、みんなに広まったあとでは変えにくい。
• ワークフローの最適化が大事。実行速度に関するチューニングは後でいい。今考えているソース構成、処理順序がプロジェクトのワークフローにどんな影響を与えるのか考える。
• 既存のコードにあるパターンは伝染する。それが即席の書き捨て(書いた時はそのつもりだったんだよ!)コードであろうとも。
• 習慣は伝播する。
• 仕様は決まらないが、締め切りが近づくと決まる
• 技術力より、マネジメントのほうがプロジェクトに与える影響が大きい
• アジャイルに開発できるツールを使うと、アジャイルに仕様が変化する
• アジャイルでない仕様は誠実ではない
• アジャイルでない手法でアジャイルな仕様をハンドリングすると徹夜が発生する
• 機能一覧、「優先度」の欄に「A」と「B」しかない
• 一覧には載ってないけど実装が必須な機能がある
• 機能一覧、更新されない