アジャイルプラクティス
アジャイルの初心
・成果をあげるのが仕事
・非難してもバグは直らない
誰かの後ろ指をさすのではなく、自分のできる解決策に注力する
・バランスが肝心
・「自分のせいじゃない」というのが正しいことはまずない。また、「全部お前のせいだ」というのも同じぐらい間違っている。
・全くミスをしていないのであれば、ｓれはおそらく一生懸命やっていない証拠。
・チームメンバーの誰かが、仕様やAPI呼び出し、前回の会議での決定事項などを誤解していたら、同じように
誤解しているメンバーがほかにいると思っていい。
・チームの足を引っ張る言動を繰り返すメンバーにはプロとしての自覚が足りない。
問題の解決に向けてチームでやって行こうという気がないのだ。
・チームの多数派の振る舞いがプロ意識に欠けていて、チームの運営に無関心な場合は、自分自身がチームを離れてよそで成功を目指すべきだ。
・応急処置は泥沼を招く
・なぜその処置が必要なのかを調査する。
・独りでコーディングしない → 継続的なコードレビュー
・ユニットテストを習慣にする
・コードがどうやって動いているかを理解する必要はあるが、このコードのエキスパートになる必要はない。
・きちんと理解するkとなく、場当たり的に修正してはならない。
・ある程度の規模のシステムは、一人で全てを理解するには複雑すぎる。
これに対処するためにはシステム全体を俯瞰して、主要な部分が互いにどのように連携しているかを把握しなければならない。
勿論、自分の担当する箇所はしっかりと理解する必要がある。
・人ではなくアイデアを批判する
・個人的立場を抑え、プロフェッショナルを貫く
・後ろ向きは斬新なアイデアの敵
・始めるためのヒント
・締め切りを設ける
・両極端で議論する
・まとめ役を決めておく
・決定を支持する
・いいアイデアの提案を常に心がけるのは勿論だが、自分のアイデアが実際には採用されなかったとしても、気を悪くしないこと。
自分の提案を生かしたいがために、すでに出ているいいアイデアに余計なものを付け加えてはいけない。
・実際の議論のゆくえは、反対意見にどれほどの現実味があるかにかかっている。
その問題がこれまでに起こったことがあるのか、どれぐらい頻繁に起こったのかを尋ねてみよう。
主張を裏付けたり、反論したりするためにプロトタイプや調査が必要であれば、そうすればいい。
・ベストな解決策を探し始める前に、その状況では何を持ってベストとするのか、メンバー全員の認識を合わせておくのもよいだろう。
開発者にとってベストなことがユーザにとってベストではないかもしれない。逆もまた然りだ。
・無条件にベストな解決策は存在しない。あるのはベターな解決策だけだ。
・「感情に流されない」というのは「提案された全てのアイデアを盲目的に受け入れる」という意味ではない。
提案されたアイデアや解決策のよさを納得できなければ、その理由をきちんと言葉を選んで説明し、自分が納得できるまで繰り返し質問しよう。
・機雷がなんだ！全速前進！
・自分では「そんなことをしたら大変だ」と思っているのに残りのメンバーに賛同してもらえない場合は
・自分の意見の正しさを十分に説明できていない
・彼らの意見が正しいのかもしれない
と考えよう。
・設計やコードに奇妙な印象を持ったら、どうしてそんなコードになっているのかをじっくりと考えよう。
その上で、「このやり方は妥当であるがわかりづらい」と思った場合にのみ、わかりやすくするためにリファクタリングすること。
・勇気を持って打ち出した見解が、状況を理解できるだけのバックグラウンドをもたない意思決定者からの抵抗にあうことがある。
そうした場合には、意思決定者に理解できる言葉で説明しよう。
（費用の節約、投資収益率の向上、訴訟の回避、顧客基盤の拡張など）
・コードの品質に妥協を迫られたら、いち開発者である自分には企業資産の価値を低下させるような権限はない、と主張すればいいだろう。
アジャイルさを育む
・変化についていく
・新しく登場したアイデアの中には、本格的な実用の域に達しないまま消えていくものも少なくない。
これは、豊富な資金を投入して話題を集めた大規模事業であっても変わらない。
だから、技術に取り組むときはペース配分を考えよう。
・あらゆる分野のエキスパートにはなれない。なろうとすべきでもない。
とはいえ、何か特定の分野でエキスパートの域に達することができたなら、
関連する分野にも詳しくなることはさほど難しくないだろう。
・その新技術の必要性を理解しよう。どんな問題を解決しようとしているんだろうか？どんな場面で使えるのだろうか？
・新しい技術やフレームワーク、言語を学びたいというだけの理由で自分のアプリケーションを移行したくなる衝動を抑えること。
新技術は、採用を決める前にそのメリットをきちんと評価しなければならない。
小さなプロトタイプの作成には、技術を評価することだけでなく、のぼせすぎた熱を冷ます効果がある。
・チームに投資する
・書籍を１章ずつ読み進める読書会はとても有益だ。ただし、良書を選ぶこと。
・トピックによっては、さしあたっては興味がなかったり、使いどころさえ思いつかないものもあるだろう。それでも関心は寄せておこう。
・チームの身の丈にあわせよう。
・定期開催を死守すること。継続的に、少しずつ進めていくのがアジャイルだ。
・夕食を一緒にとることに難色を示すチームメンバーがいる場合は「ピザをご馳走するから」という口実で誘ってみよう。
・技術系の書籍や話題に限定しないで、対象範囲を広げよう。関連する非技術系の話題（プロジェクト見積もりやコミュニケーションスキルなど）もチームにとってプラスになる。
・ブラウンバックミーティングは設計ミーティングではない。ブラウンバックミーティングでは、チームのアプリケーションに関連する
一般的な話題に限定しよう。特定の問題の解決は、普段の設計ミーティングにとっておこう。
・時が来たら習慣を捨てる
・わだちと墓穴の違いは、大きさだけだ。賞味期限を過ぎてしまった古い習慣をいつまでも引きずるのは、自分のキャリアの危機だ。
・古い習慣を完全に忘れ去る必要はない。しかし、それを活用するのは関連する適切な技術を使用するときだけにしよう。
・これまでに経験した言語で使い慣れた独特の特徴にはとりわけ注意を払い、新しい言語や新バージョンでは、互いの類似点や相違点を学ぼう。
・わかるまで質問する
「なぜ？」と問い続けること
・われを忘れてしまって、全く関係ない質問をしてしまうことがある。「なぜ？」と問うときには、問題と関連があるようにしよう。
・「なぜ？」と質問したのに、「どうしてそんなことを聞くんです？」と逆に質問されてしまうこともある。
質問のする前に、そう問う根拠を考えておくこと。事前に考えておくことは、質問と問題との関連を確実にする効果もある。
・うわべの回答に甘んじてはいけない。「これまでそうだったから…」という回答がいい回答であることはまずない。
・「さあ、私にはわかりませんねぇ」という回答は、更なる探求への絶好の出発点だ。行き止まりではない。
・リズムに乗る
・一日の終わりにチェックインされているコードはすべてテストされているように計画を立てよう。日をまたいだ積み残しをなくすようにしよう。
・イテレーション（繰り返し）のつじつまを合わせるための残業や休日出勤を常態化させてはいけない。
・チームのイテレーションは、長さを固定して、一定周期でまわすようにしよう。一旦長さを決めたら、その長さをがんばって守らなければならない。
・リズムが緊密すぎると、燃え尽きてしまう。チームの外部の相手とのやり取りがある場合、通常は相対的にゆっくりしたリズムを取り入れたほうがよい。
・一定のリズムを保つと、隠し事が難しくなる。また、勇気を出して事に挑もうというきっかけにもなる。
・ダイエットと同じで、小さな成功が大きなモチベーションにつながる。実現可能な小さい目標を立て、その達成を繰り返すことで、全員が前進し続けられる。
ユーザが求めるものを提供する
・顧客に決断してもらう
・決定した内容と、その決定を下した理由の記録を残そう。人の記憶ほどあてにならないものはない。開発メモやソリューションログ、wiki、電子メール、課題追跡ソフトウェア。
方法は何だっていいが、手間や負担にならないよう気をつけよう。
・とるになりない技術的な細かい話で多忙な偉い人たちを煩わせないように。
彼らのビジネスに影響しないことであれば、それは取るに足らない話だ。
・技術的な細かい話だからといって、ビジネスに影響しないと決め付けないように。
彼らのビジネスに影響するのかもしれないのであれば、それは取るに足りない話ではない。
・ビジネスに携わる人の答えが「わかりません」でも、全く問題ない。まだそんな際のことまで考えていないか、実際に動いている様子を
見ないと問題を評価できないのだろう。できるだけの助言をして、自分の書くコードが後から変更される可能性を念頭に置いておくこと。
・設計は指針であって、指図ではない
・CRCカードによる設計
・クラス名
・責務（そのクラスがすべき仕事）
・協調クラス（そのクラスが責務を果たすために協調する他のオブジェクト
・「大規模な事前設計をしない」というのは、設計が不要だと言ってるわけじゃない。「実際のコードでの検証を伴わずに、
設計が良き詰まってしまうことのないように」という程度の意味だ。設計のことを何も考えずにコーディングに突入したら危険なのは当たり前だ。
・最初にした設計は最終的には無駄骨に終わるかもしれない。だがしかし、それでも設計するんだ。
「設計する」という行為そのものに、何事にも変えがたい価値がある。設計することを通じて得られた知見こそが重要なのであって、設計そのものは
必ずしも重要ではない。
・ホワイトボード、スケッチブック、付箋紙は、すばらしい設計ツールだ。複雑なモデリングツールは、木月を与えてくれることよりも、
集中力をそいでしまうことのほうが多い。
・技術の採用根拠を明確にする
・プロジェクトの状況によっては、技術的な要件をきちんと評価できる段階に達しておらず、時期尚早ということもありうる。
それはそれでかまわない。決断を下せるだけの知見をまだ得られていない時点では、採用する技術の選択を焦ってはいけない。
・どんな技術にも長所と短所がある。技術の導入に伴うトレードオフを認識しておくこと。
・出来合いでダウンロードできるものがあるなら、開発してはいけない。
・いつでもリリースできるようにしておく
・大きな変更が続いており、システムをリリース可能な状態に保てるだけの時間と労力を割けないこともある。
たとえば、アプリケーションに１週間丸々かかる変更が発生したとしよう。修正作業中も使用可能な状態に保ちつつ修正を続けたら、
作業期間が１ヶ月に延びてしまう。この場合は、１週間システムをとめることを選ぶべきだ。ただし、このような事例はあくまで例外だ。
・システムを長期間にわたってリリース不可能な状態にせざるを得ないときは、ブランチを用意して（コードだけでなくスキーマも）、そこで実験的に作業すると良い。
いざというときには、ブランチをきった時点に戻せばよい。システムをリリースできない状態にしてしまうことはあっても、
それを元に戻せない状態にだけはしないこと。
・はやめに統合、こまめに統合
・「統合がうまくいっている」とは、全てのユニットテストが成功する状態を維持できていることを指す。
・自分の書いたコードは、チームメンバーのコードと一日に数回は統合したいものだ。
例えば、特に何事もない日であれば一日に５－１０回、場合によってはもっと多い、というのはひとつの目安だ。
・統合の頻度が十分ではない状態に陥ると、統合で発生した問題の対処に明け暮れてしまって、コードを全然書けなくなってしまうことがある。
統合で発生する問題が大きくなってしまうのだとしたら、それは統合頻度が低すぎる。
・プロトタイプや実験用のコードについては、分離してばらばらに作業を進めることにして、統合に無駄な労力を割かないという選択肢もある。
・その場合でも、分割したままの期間が長くなりすぎないようにすること。コードを書くことを通じて必要な知見を得たら、すぐ統合に向けた作業を始めよう。
・早いうちにデプロイを自動化する
・開発する製品によっては、前提とする動作環境を指定することもある。
動作環境によって挙動に大きな違いが発生しそうであれば、要求される依存関係を満たしているかどうかを、インストールプロセスでチェックする仕組みを用意しよう。
・インストーラが、ユーザの許可なくユーザデータを消去することはあってはならない。
・緊急のバグ修正のデプロイは簡単にできるようにしておくこと。本番環境への緊急デプロイ作業はきっと必要になる。
・ユーザがいつでもインストール内容を安全かつ完全に削除できるようにしておくこと。
・インストールスクリプトのメンテナンスが厄介になってきたとしたら、それはサポートコストがかさみ始める予兆かもしれない。
（設計がまずかったということの表れかもしれない）
・継続的インテグレーションツールと、CD/DVD作成マシンとを組み合わせれば、ソフトウェアをビルドするたびにラベルの貼られたディスクを作成することだって自動化できる。
最新のビルドが必要だったら、積んであるうちの一番上のディスクを持っていってインストールすればいい。
・頻繁なデモでフィードバックを得る
・頻繁なフィードバックを得る方法を始めて提案された顧客は「そんなにも頻繁にリリースしなければならないのか」と難色を示すかもしれない。
その場合には、こうした内部リリース（デモ）が誰よりも顧客自身のためになるということと、こうした内部リリースが必ずしもユーザ全体へ公開するリリースではないことを理解してもらうこと。
・毎日とか毎週といった頻繁な打ち合わせを嫌がる顧客もいる。2週間に一回でも嫌がられることがある。
顧客の時間を尊重しよう。仕事の都合で月に１回しか打ち合わせできないなら、その頻度でやるしかない。
・なかには、デモを行う打ち合わせに参加する専任の担当者を割り当てる顧客もいる。専任担当者がいるとなれば、フィードバックとデモを1時間おきにやりたがるかもしれない。
担当者には、打ち合わせやデモで見せるに値するだけの作業をこなせるぐらい間隔を空けてもらおう。
・デモの意図は、顧客からフィードバックを引き出すことと、プロジェクトの舵取りをしてもらいやすくすることだ。機能や安定性に欠けているものを見せてがっかりさせたり、
不安にさせたりすることは意図から外れている。昨日が安定していないのなら見せなくてもいい。機能に対する期待を、早い段階で明確にしておくこと。
つまり、顧客が今目にしているデモは開発中のものであって、最終的な完成品ではないことを顧客に理解してもらうようにしよう。
・短いイテレーションでインクリメンタルにリリースする
・イテレーションの適切な長さをどうするのかは、バランス感覚を問われる重大な問題だ。
・イテレーションでいつも時間が足りなくなってしまう場合は、タスクが多すぎるか、いてレーショ音が短すぎるかのどちらかだ。
・ユーザのニーズと、リリースした機能との間にギャップがある場合は、イテレーション周期が長すぎるのかもしれない。
・インクリメントでリリースする製品は、実際に使えるものであり、かつ顧客にとって価値のあるものでなければならない。
顧客にとって価値のあるものとは何だろうか？それを顧客に聞くんだ。
・定額契約は守れない約束
・プロジェクトの進め方について納得できる結論を出せなかったら、質問の仕方を変えられないか考えよう。
・あなたがアジャイルでない、計画を絶対視する回付をしているのであれば、そのままの開発方法論で行くか、別のやり方にするかの選択を迫られるかもしれない。
・かたくなに「最初のイテレーションが完了するまでには見積もりを出せない」と主張していると、先に見積もりを出したところに契約をとられてしまうかもしれない。
・「アジャイルである」ということは、「とにかくコーディングしてしまえば、終わったときには見積もり結果がはっきりする」ということではない。
アジャイルであったとしても、依然として概算見積もりは必要になる。見積もり時点での認識や前提に基づいた、根拠の説明と誤差範囲が求められることにも変わりはない。
・ここまでに紹介した選択肢のどれにも当てはめることができず、定額契約にせざるを得ないとしたら、見積もり技術にかなりの磨きをかけなければならない。
・契約上は各イテレーションを定額契約にしておく一方で、十汁イテレーションの回数を事前に厳密には取り決めないという作戦もある。
・アジャイルなフィードバック
・天使を味方につける
・テストで気をつけること
テストは反復可能にすること。
境界値をテストすること。
テストの失敗を放置しないこと。
・ユニットテストのメリット
素早いフィードバックを提供する
コードを堅牢にする
役に立つ設計ツールである
開発者の自信を強める
問題解決時には探査装置となる
信頼の置けるドキュメントである
学習教材である
・ユニットテストは投資だ。賢く投資しよう。アクセサや、結果が自明なメソッドのテストには、そんなに時間をかけなくてもいいだろう。
・ユニットテストをやりたくない人の言い訳は、実は設計の欠陥を示していることが多い。
・ユニットテストがどれだけ効果を発揮できるかは、テストカバレッジに左右される。現状を大まかに把握できるように、テストカバレッジツールの使用も検討すると良いだろう。
・テストを増やせば品質もひとりでに向上するとは限らない。意味のあるテストでなければ、品質にはつながらない。
テストしても何も問題を見つけられない場合は、テスト対象や、テストのやり方が適切でないのかもしれない。
・作る前から使う
・テスト駆動開発
コードを書くことが許されるのは、失敗するユニットテストを書いた後だけだ。
そして、必ずテストを先に書かなければならない。（テストファースト）
「ユニットテストの失敗」とはテスト対象となるコードがまだ存在していないか、テストをパスするために必要なロジックをまだ書いていないということ。
・「テストファースト」と「チェックイン前のテスト」は対立するようなものではない。「テストファースト」は設計を改善する技法だ。
「チェックイン前のテスト」は必ず守らなければならない掟だ。
・どんな設計にも必ず改善の余地がある。
・ユニットテストは、アイデアの実験やプロトタイプには向かないかもしれない。
・ユニットテストだけでよい設計になる保証はどこにもない。けれど、良い設計になりやすいのは確かだ。
・違いがあれば結果も変わる
・自動化で時間を節約
複数プラットフォームでテストする暇がどこになる？ →継続的インテグレーション
継続的インテグレーションツールは、バージョン管理システムからコードを定期的に取得してテストを走らせて、テストに失敗したら関係者に通知する。
・ハードウェアよりも開発者の時間のほうが貴重だ。とはいえ、サポート対象のプラットフォームや設定があまりにも多ければ、実際に社内でテストしようにも限界があるかもしれない。
・全てのプラットフォームに関わるバグが、スタックの割付やワードエンディアンといった、プラットフォームごとの違いをきっかけに見つかることもある。
・同じエラー内容の通知が、それぞれのプラットフォームから合計５つも飛んで来たら困るだろう。
これに対処するには、メインのサポート対象のプラットフォーム以外でのインテグレーションビルドの頻度を下げて、メインビルドが壊れたときには
じっくり取り組めるようにしたり、同じエラーは1つのレポートにわかりやすくまとめて通知するようにするといい。
・受け入れテストを自動化する
・全ての顧客が正しいデータを提供できるとは限らない。もう既に正しいデータを入手できるのだとしたら、新しいしシステムなんて別に必要ないのだから。
・以前のシステムに潜んでいた未知のバグが見つかるかもしれないし、これまでに発見されていなかった本質的な問題が見つかるかもしれない。
・顧客のビジネスロジックを使おう。ただし、それを整理したいからといって、ドキュメント作りの泥沼にはまらないように気をつけること。
・ありのままの進捗を計測する
・バックログを使う。
バックログとは・・・まだ完了していない作業を取りまとめた一覧
・6分単位では粒度が細かすぎる。これはアジャイルではない。
・一週間単位や一ヶ月単位では粒度が粗すぎる。これもやはりアジャイルではない。
・スケジュール上でそのころにどうなっているはずだったかではなく、実際に機能が完成しているかどうかを中心に考えること。
・費やした時間の追跡に多くの時間をかけてしまってプロジェクトの作業に十分な時間を割けていないのは、費やした時間の追跡作業に割く時間が長すぎるということだ。
・一週間の作業時間が40時間だとしても、その40時間の丸ごと全てをプロジェクトのコードを書くのに使えるわけじゃない。雑務にも結構な時間を取られていることに注意すること。
・ユーザの声に耳を傾ける
・馬鹿なユーザなんていない。いるのはバカで尊大な開発者だ。
・「それは仕様です」は答えにならない。
・コードは修正できないにしても、ドキュメントやトレーニングでなら対応できるかもしれない。
・アジャイルなコーディング
・意図を明確に表現するコードを書く
・今のあなたにとっては当たり前でも、それが他人にとっても当たり前だとは限らない。１年後のあなたにとってもそうだ。
自分の書くコードは、いつともしれぬ未来に開けられるタイムカプセルだと思うこと。
・「あとで書く」はない。今できないなら、あとになってもできるわけがない。
・コードで意図を表現することは、クラスや型をたくさん作ることとは関係ない。なので、過剰に抽象的にする言い訳にはならない。
・状況にあった結合度を選ぶこと。例えば、ハッシュテーブルを使った疎結合は、実際問題としてコンポーネント同士が緩く結合しているような状況に向いている。
コンポーネント同士が密結合な場合にハッシュテーブルを使ってはならない。単にいとがわかりづらくなるだけだ。
・コードで伝える
・クラス内の各メソッドには次のようなコメントを入れて置くといい。
目的：なぜこのメソッドが存在するのか
必要条件（事前条件）：メソッドの呼び出しに必要とされる引数はどういうものか。呼び出し時にオブジェクトはどのような状態であるべきか。
結果（事後条件）：このメソッドが正常に完了した際に、オブジェクトはどのような状態になっているか。戻り値には何を返すか。
例外：異常が起きた場合にはどのような例外が送出されるか
・コメントを短くすることに時間をかけること。
・コードだけで目的を伝えられるなら、コメントは書くまでもない。
・コメントはコードの機能を説明するためのものではない。コードの意図を説明するためのものだ。
・メソッドをオーバーライドするときには、メソッドの意図が変わらないようにすること。元のメソッドの目的や制約条件に関するコメントは残しておくこと。
・トレードオフを積極的に考慮する
・後になってから、メリットがありそうなことに労力を投入する場合は、その投資に見合った対価を本当に得られるか確認すること（ちなみに、対価が得られることは滅多にない）
・本当に高性能なシステムは、当初からそう設計されるものだ。
・早計な最適化は諸悪の根源だ。
・過去の解法や手法が現在の問題に適することもあれば、適さないこともある。いずれにせよ予断は禁物だ。実際に確認すること。
・インクリメンタルにコードを書く
・コードを書くときは編集・ビルド・テストのサイクルを短くする
・ビルドとテストのサイクルに時間が掛かり過ぎると、頻繁に実行する気がなくなる。テストを素早く実行できるようにしておくことが大切だ。
・コンパイルやテストの最中に一息ついて、コードを俯瞰して眺めると、進路を誤らない。
・休憩するときは、ちゃんと休むこと。つまりキーボードから離れるべし。
・コードをリファクタリングするのと同じ頻度で、テストもリファクタリングすること。
・シンプルにすること
・コードには必ずどこかしら改善の余地がある。とはいえ、ある程度から先は、改良を続けても現実的なメリットがない。
そうなる前に切り上げて次へ進むこと。
・ゴールを見失ってはならない。目標はシンプルで読みやすいコードだ。早すぎる段階での最適化がそうであるように、無理矢理エレガントさを求めても害にしかならない。
・当たり前のことだが、シンプルな解法であっても適切に問題を解決しなければならない。妥協の結果、シンプルになったとしても、それはただ安直になっただけだ。
・シンプルさとは素っ気なさではない。素っ気ないだけでは何も伝わらない。
・ある人にとってはシンプルでも別の人にとっては複雑かもしれない。
・凝集度の高いコードを書く
・クラスは狙いを絞り、コンポーネントは小さく保つ
・あまりに多くの部分に分割し過ぎると、逆に使い物にならなくなることがある。
・凝集度の高いコードでは、要件の変更に対応する箇所だけを変更すればいい。
１つの機能変更を実装するのに、何箇所コードを変更しなければならないのかをよく観察しよう。
・"Tell, Don't Ask" --求めるな、命じよ
・巨大なデータの容れ物にすぎないオブジェクトには要注意だ。そうしたオブジェクトが必要なこともあるだろうが、そう多くはない。
・コマンドが利便性のためにデータを返すのは問題ない（データを取り出すだけのメソッドを別途用意できるなら、それはそれでいいことだ。）
・一見すると無害そうな問い合わせがオブジェクトの状態を変えてしまうのは問題だ。
・取り決めを守ってコードを置き換える
・リスコフの置換原則（LSP）という設計原則がある。
・LSPを満たすためには、派生クラスのメソッドは、対応する基底クラスのメソッドに比べて事前条件を増やすべきでもなければ、
保証する結果を減らすべきでもない。
・継承を使うときは、派生クラスが基底クラスと置き換え可能かをよく考えること。
・「基底クラスのコードを再利用したいから」という理由ならコンポジションを使うべきなのだろう。
・新しいクラスが既存のクラスと置き換え可能で、かつ両者の関係がis-a（である）場合は、継承を使う。
・既存のクラスお新しいクラスで使いたいだけで、両者の関係がhas-a（持つ）またはuses-a（使う）の場合は、委譲を使う。
・通常は継承よりも委譲のほうが柔軟で、変化への適応力が高い。
・継承が悪だというわけではない。ただ誤用されているだけだ。
・インターフェイスに求められる事前条件や保証する機能を把握していなければ、インターフェイスの取り決めを満たす実装なんて提供できるわけがない。
・アジャイルなデバッグ
・ソリューションログをつける
・ソリューションフログに入れるべき項目
問題が起きた日時
問題の簡単な説明
解決策の詳細な説明
詳細情報や関連記事へのURL
解決の糸口や理解の助けになりそうなコード片、設定、ダイアログの画面キャプチャ
・問題のドキュメント化よりも、問題を解決することにより多くの時間を割くべきだ。ログは短くシンプルに。出版物のような品質は必要ない。
・何よりも後から解決策を探し出せる事が重要だ。必要なときにエントリを見つけられるように、キーワードをふんだんに使おう。
・Webで検索しても誰も同じ問題に遭遇していないなら、そもそもあなたの使い方がどこか間違っているのかもしれない。
・問題が発生したアプリケーションやフレームワーク、プラットフォームのバージョンも記録しておこう。同じ問題であても、
プラットフォームやバージョンが違えば、現象が異なるかもしれない。
・チームが重要な決定を下したときは、その理由を記録すること。その手の意思決定は半年後に蒸し返されても、なかなか詳細を思い出せないものだ。
