開発
- 小さく始めてから拡張する: 新しいシステムを作るときや既存システムに機能を追加するときは、必要最小限の機能しかない非常にシンプルな版から始め、徐々に拡張する
- 変更は一度に一つずつ行う: 開発中にテストが失敗したり機能が動かなかったりするとき、一度に一つの変更だけを行っていれば、問題を見つけるのがはるかに容易になる
- ロギングとエラー処理は早い段階で追加する: 新しいシステムを開発するとき、ロギングとエラー処理を初期から入れておくことは有用
- 新しいコード行は最低一度は実行されるべき: 機能が完成する前にテストすべき
- 全体をテストする前に部分をテストする: 十分にテストされた部分は時間の節約になる
- あらゆる作業は思ったより時間がかかる: とくにプログラミングでは予想以上に長くかかる
- まず既存コードを理解する: 新機能を追加する前に現在の解決策を理解しなければならない。コードを読むことは、コードを書くことと同じくらい必要な技能だということ
- 読んで実行する: コードを理解するには、コードを読むこととコードを実行することという二つの補完的な方法がある
問題解決
- バグは常に存在する: 「最初から正しくやる」というアプローチは良くない
- 問題報告に対応する: 開発者は顧客からの問題報告を処理し、バグ修正に時間を割くべき。そうすることで、顧客が何をしようとしているのか、システムがどう使われているのか、問題解決がどれほど簡単または難しいのか、システムがどれほど適切に設計されているのかをはるかによく理解できる
- 問題を再現する: バグ修正の第一歩は問題を再現すること。そのうえで修正を加えたあとに問題が解消したかを確認する
- 既知のエラーを修正したあと、残っているものを確認する: 問題が複数あるときは、既知の問題をすべて修正してから、残っている症状を確認する
- 偶然の一致だと決めつけない: テストや問題解決では偶然を信じず、調査すべき。「タイマー値を変えたらシステムがより頻繁に再起動するようになった。これは偶然ではない。新機能を追加したら無関係な機能が遅くなった。これも偶然ではない。さらに調べること」
- タイムスタンプで相関を取る: 問題解決の際はイベントのタイムスタンプを活用する
協力
- 対面が最も高い帯域幅を持つ: 問題の解決方法を議論するとき、対面は他のすべての方法（ビデオ、電話、チャット、メール）より優れている
- ラバーダック・デバッグ: 問題に行き詰まったとき、同僚に問題を説明すると解決策に気づけることがある。同僚が何も言わなくても、話しているうちに問題が何か分かることが多い。魔法のように聞こえるが、驚くほどよく効く
- 尋ねる: コードを把握するときは、読むことと実行することが有効な場合が多い。しかし、それについて知っている人（おそらく元の作者）に尋ねられるなら、その方法も併用すべき
- 功績を分かち合う: 功績はあるべきところにきちんと認める。「私たちは…を試しました」ではなく、「Marcusが試すべきアイデアを思いつきました」と言う（実際にそうなら）。助けてくれた人や貢献した人が誰かを積極的に示すこと
その他
- 試してみる: ある言語機能がどう動くのか確信が持てないときは、小さなプログラムを書いてテストする
- 眠る: 難しい問題に直面したときは、判断する前に一晩寝るのがよい
- 変化: ときどき役割や仕事を変えることを恐れないこと。別の人たちと、別の製品や別の会社で働くことは刺激になる
- 学び続ける: ソフトウェア開発の最大の利点の一つは、常にさらに学び、知る余地があること。さまざまなプログラミング言語やツールを試し、ソフトウェア開発に関する本を読み、MOOCの講座を受講するとよい。小さな改善の積み重ねが、あなたの知識と能力に実質的な変化をもたらす
7件のコメント
対面が最も高い帯域幅を持つ――見事な表現です。
+1.
ラバーダック・デバッグ。本当にプログラミングを知らない人に話しているだけでも、何が問題なのかに気づける
+1.
金科玉条ですね。
+1
わあ、どれも本当にいい言葉ですね。対面が最も高い帯域幅を持つというのは少し残念ですね。技術がもっと発展してほしいです。