冬で「アジャイルとテスト」というお話をしてきました。wacate.jpspeakerdeck.com資料を作ったんですが結局セッション時間内では話切れなくて、本番では泣く泣くスライドは大量に非表示に。セッション的には、アジャイルの概要が掴めれば成功かな、と思っています。個人的に一番言いたかったことはp35のプロセスモデルによらず、アジャイルの考え方は適応できるよということ。このセッションをきっかけにアジャイルや関連する概念を勉強して、プロジェクトを改善していけるような人が一人でも居たら良いなぁと思っています。達人に学ぶソフトウェアの構造と設計という本を読みました。前(発売日)くらいに買っていて、ずっと読もう読もうと思って積んでいてたので、いい加減読みたいなぁと思って読みました。読み始めたときに、なんでもっと早く読まなかったんだろうと少し後悔しました。プログラム言語のパライダムの歴史や、SOLIDの原則を説明していて、その後具体的にじゃあどうすれば良いのか、ということを示してくれている本でした。Blog一枚の絵でクリーンアーキテクチャをまとめている画像がこれです。外側がDBやフレームワークやIFを担当していて、外部ー>内部は依存するが、内部ー>外部は依存しないというものです。個人的に今まで作成してきたソフトウェアもなんとなく階層化をしていたけれども、4段階と明確には分けてなかったし、なるべく疎結合にするようにはするものの、明確に依存性の方向までは意識出来ていなかったので個人的には衝撃的でした。これからは、この図を意識してプログラミングしていきたいと思います。28章にはテスト境界という章があります。この章では、テストはなるべく壊れないように設計しなければいけないよねということが書いてありました。具体的な例が書いていないのでなんとなくしか理解できていないですが、理想はUIに依存しないようにするだけではなく、DBなどにも依存しないようにビジネスルールを検証できるAPIを用意しようということなんだろうと思います。確かにこの設計は最初からやらないと難しいと思うけれど、実際どうやる想定なのかがちょっとわからなかったです。時間があったら調べたいと思いました。29章には組み込みに関しての記述があります。書いてあることにはほとんど同意できる内容でそうだよなぁと思いながら読みました。ファームウェアやOS、ソフトウェアの境界はしっかりインターフェイスを設けようということが書かれています。実感としてLinux向けのソフトウェアじゃないもののテストを自動で走らせるのはなかなか出来ないので、RTOSなどのOS依存のコードをレイヤーで分けておかないといけないということは前から思っていたことなのですが、そういった疎結合にする方法の内容がずばり書いてありました。ファーム、OS依存を分けられると、ハードやOSが変わったときに大変な思いもしなくて済むんだろうなぁと思います。訳者あとがきにはフレームワークの選定後回しにすることがあるのだろうか?と書いてありますが、実際には結構あると思います。いうフレームワークを使うか、どういうDBを使うか、どういうプロトコルを使うかということは後から変わることがあって、やっぱりあっちが良いとなることもあります。そのために切り離すことが重要なんだろうなぁというのが個人的な実感です。久々に長い感想を書いてしまいましたが、すべてのプログラマーの人に読んでほしいと思える本でした。2019XP祭り2019でセッションやります。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。