LEFログ:学習記録ノート

leflog: 学習の記録をどんどんアップしていきます

【感想】『アジャイルプラクティス』を読みました!

開発者の習慣:グッドプラクティスとバッドプラクティス

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 | コンピュータ・一般書,プログラミング・開発,開発技法 | Ohmsha

アジャイルラクティスを読みました!

とても簡単に内容をまとめると、

  • プロダクトは少しずつ作っていこう!
  • こまめに情報共有しよう

という2つのアイデアに集約されるのかも。いや、これだけを書くとそんなの当たり前でしょ、と思われるかもしれませんが、本書ではこの2つについてとても詳しく書かれています。

自分はフィヨルドブートキャンプでアジャイル開発の手法でチーム開発をおこなっていたため、ここに書いてあることは普段から(たぶん)できていていることだったのですが、その背景にどのような根拠・理論があるのか?ということを詳しく学ぶことができました。

また、話が変わるのですが、大学の頃、ゼミの教授の一人がこんなことを言っていました。

人生に良い変革をもたらすためには、良いハビトゥスが必要である

ハビトゥスとは態度,外観,装い,様子,性質,習慣などを意味するラテン語であり、トマス・アクィナス倫理学の重要な概念で、アリストテレスのヘクシスに由来しています。

ハビトゥス(はびとぅす)とは? 意味や使い方 - コトバンク

人間は善への志向をもつが,その構成契機のうち情念 passioとともに道徳的選択に影響を与えるものが habitusで,行為によって獲得された習慣である。

倫理学においては善を実践するための動機づけとして、義務論と功利主義と徳倫理学の3つが主要なものとして扱われるわけですが、その徳倫理学に直結するのがこのハビトゥスです。

ニンゲンが普遍的な善について実行するためには、普段からの習慣(ハビトゥス)が大切になっている、というようなことをアリストテレスが言っていて、そこから徳倫理学が始まったのですが、それと同じように「良い開発をするためには良い習慣が必要である」というのは、同様にもっともな話だと思います。

それから、もう一つ連想したのは、自分が勝手に名称をつけた理論――「わんこそば理論」にも通じるところがあるような気がしました。

わんこそば理論とは、つまり「大きなどんぶりにたくさんの蕎麦をぶちこんでそれを食べていくよりも、わんこそばの形式でちょっとずつ食べていくほうが、結果的に多くの蕎麦を食べることができる」という理論です。

普段、なぜかTwitterは無限に見ることができるのに、読書にはなかなか集中できないのは、この「わんこそば理論」を心理学的にTwitterの開発者(ジャック・ドーシー)が理解していたからでしょう。

話を戻しますが、開発においても、いきなり大きな機能を実装するのではなくて、小さな機能をちょっとずつちょっとずつ実装していくほうが、長期的に見て偉大なプロダクトを生み出すことができますし、開発者にとっても顧客にとっても進捗が分かりやすく方針も変えやすくてWin-Winな状態になれることが再確認できました。

読んでいてちょっとだけ分からなかったところがあって、それは「継承よりも委譲を使おう」というところです。

これに関しては、次の記事を読んで図としてイメージすることができて良かったです。

「継承」と「委譲」|ヒロト

継承:仮に役割が別のものが継承したとします。例えばアリクラスを作って、歩く処理を実装したいのでAnimalクラスを継承すると歩く処理に加えて鳴く処理も実装されます。このように不要なメソッドが実装されてしまうと、このクラスを使用するクライアントとなるクラスから意図しない使われ方をしてしまう可能性があるのです。

委譲:インスタンス作成の処理やメソッド呼び出し処理の記述が必要にはなるが、意図しない処理が実装されることはない。

継承と委譲の図

また、個人的にpp.54-55、「12. 技術の採用根拠を明確にする」の節は個人的に思い当たるところがあって、ウッ……(ヽ´ω`)となる場面がありました。

というのも、最近特にフロントエンド関係の新しいフレームワークをあれこれと調べていて、結局手を動かすことがあまりできず、不変的で基礎的な知識の吸収を疎かにしていたからです。

特に、自作サービスだと、どんな技術やフレームワークを選んでもOKなので、新しい技術に目移りしがちです。しかし、実際のところ、DBを使うアプリのほとんどはRailsやLaravelやDjangoなどで充分だったりします(最近Discord Botを使うアプリを作ろうとして、そのことを実感しました←サーバーを動かす必要があるため)。

そのためチーム開発だけでなく、やはり個人開発であっても目的ファーストで技術選択をしなくはいけないな~と感じました。

また、クラスやモジュールの責務を分けて、「凝集度の高いコードを書く」ことも意識しようと思いました。図6.2の変形ピアノのイラストは分かりやすかったです(ピアノと化粧ダンスをくっつけるのはナンセンス)。

最近、自分が尊敬するとある方から「プロジェクトを進める上では、やっぱり段取りが一番大切ですね。段取りがうまくいっていれば、あとは作業をするだけ(意訳)」ということを伺って、本当にその通りだな~と自分も感じたのですが、その段取りをうまく活かすためには、良い習慣が必要であることをこの本から学べたと思います。