コピー2019.12.305章は技術的なプラクティスに関して。技術的なプラクティスはアジャイル開発の本質部分であり、最も重要だと強調されている。Development(TDD)に関してはかなりページ量を割いて書かれており、TDDの重要さを説くために会計のアナロジーが採用されている。会計では大量の記号や数字を文書として扱うが、それらの正しさを担保するために複式簿記が発明された。あらゆる取引は二回記入され、バランスしなければエラーを検知できる。あまりに重要なので、複式簿記は法によって遵守が求められる。同じように大量の記号や数字を文書(ソースコード)として扱うソフトウェアでは、TDDが複式簿記に相当する。要求される振舞いは必ず二回入力されるべき。次にプロダクトコードとして。TDDでは以下の3つのルールを守らなければならない。失敗するテストを書かずにプロダクトコードを書いてはならない。失敗するのに十分なだけのテストを書くこと。失敗するテストを通すのに十分なだけのプロダクトコードを書くこと。テストを先に書けば、テストしにくいコードを書くことはできない。それがTDDが設計テクニックである所以だとも述べられている。リファクタリングについては余り紙面は取られておらず、ファウラーの素晴らしい本があるよ、ってことと、リファクタリングは計画して行うような(大きな)活動ではなく、日々の作業の中で常にやるべきものだよと言っている。シンプルなデザインでは、設計はトレードオフなので、どれだけ行うかはバランスを取って判断するべきだと述べられている(可能な限り、シンプルに)。ペアプログラミングについては、どれくらいペアプロするかは好きにしていいよ、30%のプロジェクトもあれば80%の場合もあるだろうね、とのこと。リサーチによるとペアプロのオーバーヘッドは約15%らしく、半分をペアプロに充てた場合は全体で約7-8%のオーバーヘッドがあるだろうと。レビューの効果やクロストレーニングの効果もあるのでトータルで見れば十二分にペイするよねと書かれている。3章や4章と比べて、5章は熱量が高いように感じる。その中でもTDDについてはかなり熱く語られていて、やっぱりTDDって重要なプラクティスだよねと考えさせられた。TDDの3つのルールに従ってソフトウェアを開発するのって簡単ではないけれど、個人として、チームとして少しずつできるようにしたいところ。サンプルアプリのフロントをReactで作りたいと思い、積ん読になっていた本を引っ張りだして読んだ。発行日が2016年12月1日なので内容は古いだろうが、まずは入門ということで。アジャイルになるとはどういうことか。『チーム・ジャーニー』の第02話「一人ひとりに向き合う」を読んだ感想。やってグループをチームに変えてジャーニーを開始するのか。Agile』の読書記録。Agile」は何故アジャイルでやるのか?が述べられている。Reactの勉強のために2冊目に読んだ本。ヤフーなどでフロントエンジニアとして働く著者グループによる書籍なので、実践的なSPAのアプリケーションを開発するために必要な内容がカバーされている。『チーム・ジャーニー』第04話は「チームのファーストを変える」。「皇帝」がいなくなった太秦のチームは合宿を行ってチームとして再出発をしたのだが、パフォーマンスは一向に上がらずPOの砂子から叱咤される始末。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。コメントアーカイブ2020年2月2020年1月2019年12月2019年10月タイトルとURLをコピーしました。