脳に収まるコードの書き方~複雑さを避け持続可能にするための経験則とテクニック~ー FL#56に参加してきた

forkwell.connpass.com

少し時間は経ってしまいましたが、こちらのイベントに参加していたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第56回目では『脳に収まるコードの書き方―複雑さを避け持続可能にするための経験則とテクニック』を取り上げます。 ソフトウェアは複雑さを増すばかりですが、人間の脳は限られた複雑さしか扱えません。ソフトウェアが思い通りに動くようにするには、脳に収まり、人間が理解できるコードを書く必要があります。

本書は、拡張を続けても行き詰ることなくコードを書き、複雑さを回避するための実践的な方法を解説します。 今回は訳者の原田 騎郎 氏に本書のポイントについてお話していただきます。

会の様子

脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

翻訳をはじめたときの小話

アンクルボブは本書の著者とは意見が合わないという話をしているそうで、まえがきにもそう書いているそうですが、これはアンクルボブが面白い人に対して送る言葉でもあるそうで、この本は翻訳したら楽しそうだという期待感があったということでした。

本書の概要

本書では、コードの書き方というよりもどんなコードが頭に入りやすいかという話をしているそうで、(雑な表現ではあるものの)必ずしもうまくいくやり方ではないけれど役に立つ認知バイアスを経験則をもとに紹介しているイメージを持っておくとよいといいという話がありました。

そのため、これは同意できないという部分が出てきそうなところも非常によいだろうということで、経験則を自分たちのものに昇華できると本書の目的は達成できるだろうということでした。

一番使われているアーキテクチャ

世の中ではMSAをはじめいろいろなアーキテクチャが出回っていますが、いまだに使われているのは大きな泥団子だという話がありました。

なかなか大きな泥団子以外が普及しない背景の一つとして、(面白いし良い本ではあるものの)Refactoring to Patternsなどがデザインパターンによって不要な複雑性を入れ込むきっかけになったことが挙げられるということでした。

本書の構成

レストランの予約管理アプリ*1を作りながら、脳におさまらない部分を深堀りするようになっているという話がありました。

1章〜アートかサイエンスか〜

建築や庭といったメタファーはソフトウェアと異なるもので、メタファーとして適していなかったよねという話が書かれているそうです。

ソフトウェアは根本的にはアートであり、アートでないような部分は自動化されていくので人が扱う部分はずっとアートであり続けているという主張されているそうです。

ただし、そういったアートができるようにエンジニアリング教育を受けていなくても、ソフトウェアエンジニアはソフトウェアを発展させてきたということで、そこは誇っても良いところだという話がありました。

2章〜チェックリスト〜

人はやらないといけないことがたくさんある状態だと、めちゃくちゃ初歩的なところでミスをするという話がB-17の試作機の話を踏まえてありました。

そのため、非常に複雑なソフトウェア開発でも、覚えずにチェックリスト化するのは重要だという話がありました。(意味があるリストにしておくことが重要)

3章〜複雑さに対処する〜

リチャードはWorse Is Betterで、雑にでもいいから使えるものを作れという話をしていたという話がありました。一方で、役に立つかどうかばかり考えてしまっても雑すぎるものができてしまうので、そのあたりのバランスを取るのが非常に重要だということでした。

人間は、Fast&Slowでも書かれているように、結論に飛びつきたい生き物であるため、2週間後のことを考えてコードを書くのが重要だということです。

4章〜バーティカルスライス〜

チームが動くソフトウェアを作れるか？という話や、本当に価値があるアプリケーションなのか？という話を、より早く検証するために、バーティカルスライスをしていくことが重要だということでした。

そこで、ハイレベルなテストはアサーションをゆるくして、アウトサイドインテスト駆動開発が有効だというお話がありました。

5章〜カプセル化〜

契約による設計を守りながら、オブジェクトが決して無効にならないことを保証するべきだということがカプセル化であるという話がありました。

本章は、コードを書きながらぜひ読んでほしいということです。

6章〜三角測量〜

ソフトウェアは、はじめから目的地が決まっているということはないため、短期記憶で状態を測りながら全体として良いコードを探すというのが重要だという話がありました。

7章〜分解〜

脳の短期記憶のサイズにマジックセブンを適応したという話が出ていました。

また、変化の速度に応じてコードを分けることや、特性の横恋慕が生じていないことを考えるのが重要だということです。

8章〜API設計〜

使う側があんまり考えないようにすることがAPI設計に応じて重要だという話がありました。

9章〜チームワーク〜

チームの脳に収まるコードの一例として、コミットメッセージでWhyが書いてあるといいという話があり、実際に本書のgit messageを見てほしいということでした。

また、モブプロ・ペアプロをやってみるのもおすすめだということです。

おすすめの読み方

本書は、ざっと見て合意できるところ/合意できないところを洗い出して、その後は他言語などでコードをチームで書いてみて、合意できるかどうかを考えてみるのがおすすめだということでした。

おわりに

コードに複雑さを入れ込んでしまうと、問題解決の複雑さに立ち向かえないという話で発表が締められました。

Q&A

Q&Aの内容を、一問一答形式かつ常体で記載していきます。

Kiroさんが同意できないところは？

自動生成で作ったコードはテストしなくていいとかは、あまり同意できなかった。また、もう少し薄いフレームワークから徐々に大きくすることをやってほしい。

将来の開発者が幸せになれるベストプラクティスは？

いらなくなった機能を消してほしい。

タスク管理や手法も関連しそうな気がしたのでそのあたりも教えてほしい

開発生産性は敵。如何に小さく、なるべく書かずに済ませられるのか？が大事。

循環敵複雑度を7以下にするためにどう実践しているのか？

テストが7ケース以上あるのはおかしい、という風に考えている。

スパゲティコードのほぐし方

いらないコードを消していく。また、ストラングラーフィグパターンも活用する。また、なんとかなる内から対処する。

ウォーキングスケルトンとMVPはどう違うのか？

リンスタにおけるMVPはプロダクトにニーズがある証明ができることであり、ユーザーストーリーマッピングにおけるMVPはユーザーにとって価値がある一番薄いものであり、ウォーキングスケルトンは作るのに必要なやつが一本通れ！という意味である。*2

他のコード本との違いは？

熟練のコード書きはこういうハマり方をしているんだよ、というのを記載している本。

テスト環境のない現場ではどうしたらいいのか？

自分のコードをよりよく書くためにできることを始めればいい。

脳に収まるコードと脳に収まらないコードの対比を見てみたい

本書の付録をよく見てほしい。現場ではよく書けたコードはほとんどない。

生成AIのコードを脳に収めるためには？

コードリーディングの助けにはなると思うし、良いプロンプトを考えるという話もあるのかもしれないが、現状だと機械が読めるコードを書く印象。

コードレビュー時に、個人の好みと読みやすさの境界で迷うときの指針は？

自分が読めるかではない。チームで一番経験が浅い人やジュニアな人が読み間違えないコードがいいコードだと思う。

読みやすいコメントよりもコードをというのはQAよりなアプローチがおすすめということか？

QAよりのアプローチというのがよくわからないが、通訳の説明が減るコードというのは重要だと思う。

読みやすいコードをなかなか書くことができない現場なのだがどうするとよいか？

自分がみやすいコードを書いてみるのが重要だと思う。

会全体を通した感想

「(自分の)脳に収まるコード」というテーマで話すと議論も多そうで、それぞれの考えている微妙な違いを生み出すという意味では非常に良い本なんだろうなあと思いました。

Kiroさん節がQ&Aでよく出ていたのも満足できるポイントでした。

*1:UIはなくJSONによるデータ投入から

*2:ピザの予約注文であれば、マルゲリーダだけ頼めればいい