面白かったので土曜日の午後に一気に読み切ってしまった。今年は、ソフトウェアやシステムに関する技術書が豊作な年ですね。10年後でも十分に通用する本ばかり出版されていますね。
本書『良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』もそんな1冊です。
仮に、この本を駆け出しエンジニアの時に買っても、その後のキャリア......シニアエンジニア、マネージャー、人事や経営と、色々な立場の時に「使える本」になります。それは、この本が技術を理解するだけでなく、「エンジニアの価値観を理解するための本」と言ってもいいからでしょう。
- 駆け出しの人は、「良いコード」と、「悪いコード」の区別の仕方、というより、そもそもそういう区別があること自体を理解するのに読むと良いです
- 駆け出しを過ぎたくらいの、目的のコードがとりあえず書けるようになった人は、自分の中の成功パターン以外にも色々なプラクティスを網羅的に学ぶのに読むと良いです
- ソフトウェア開発を指導する立場の人は、良いコードと、悪いコードの区別を教える際の語彙や概念を、オレオレ理論ではなく汎用的なプラクティスとして伝えるための教材として読むと良いです
- 人事や、組織をマネジメントする層の人は、ソフトウェアを取り巻くエンジニアが何を重要視していて、そしてそれはなぜなのか？という価値観と、その背景をを理解するために読むと良いです
- ソフトウェアの出来映えや、開発スピードがビジネスに大きく直結する組織の経営層は、コードにはさまざまな書き方が有って、それがビジネスのスピードに影響するを理解するために読むと良いです
ソフトウェアのプラクティス、全部一人でやっていれば導入するのもしないのも一人の判断でできるけど、組織で、事業としてやっている場合はそうはいかず、いくつかの階層に別れてきます。
「素朴に、愚直に、素直に書いたら、そうなってしまうので、止めよう」
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
「先を考えるとたいてい大変な思いをすることになるので、止めよう」
「別の価値観でみると最適だったことが逆に足枷になったので、止めよう」
3番目はもう組織文化の話になってくる
1番目を言うべきは直接指導をする先輩とかメンター
— magnoliak🍧 (@magnolia_k_) 2022年5月1日
2番目を言うべきはマネジメント層
3番目を言うべきは経営層（もしくはプロジェクトにおける相当する裁量を与えられている人） https://t.co/T52fmPElkZ
それぞれの層がお互いにコミュニケーションを取るためには共通の理解・語彙が必要で、この本にはそのために必要なことがたくさん詰まっている、詰まり過ぎている。
『良いコード/悪いコードで学ぶ設計入門』、著者の良心と言える点は、その悪魔を「誰が」召喚しているかには敢えて触れていない点が良い
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
悪魔は粛々と退治するか、封印するか、地獄へ送り返すしかないのだ
とはいえ、実際のプロジェクトでは、そのレイヤーにおける責任を持つ人が適切な判断をして、意思決定をしないといけないです。で、その時に、そこに悪気が有る人は居ないし、みんなそれぞれがやるべきだと思っていることを一生懸命やっているはずなんですけど、上手く行かない時がある。
で、そこに無いのは、共通の語彙であり、立場が異なる／階層が異なる人同士のコミュニケーションだったりします。
アンチパターンに出てくるようなコード、書きたくて書いているというより「ビジネス要求を素直に、必要な順番で愚直に実装してみたら」出てくることが有り、コードがビジネス要求の単なる写像ではならないという話になるのだけど、これを理解するまでに平均的な人類には約10万年の歳月がかかると言われ
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
だってバグがなければ、どんなにアンチパターンであってもそのコードは動き、お金を稼いでしまう訳で、それでもダメと言う以上、納得できる理由を提示していかないといけないし、その時に「個人のスキルの高低の話ではない」と持っていかないといけない
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
そんな時に、真ん中にこの本が有ると、少し世界は分かり合えるのかもって思いました。
この本で触れられている実態を表していない命名、複雑すぎる条件分岐、重複するコード...どれも現実のコードに出てくるけど、誰も悪いコードを書きたいと思って書いている人は居ないはずなんです。目の前の課題を解決するために一生懸命やっているはずなんです。でも、悪いコードが誕生してしまう、放置されてしまう、それが後世の人を苦しめてしまう。
例えば「変数の再代入はよくない」と言われ、なぜよくないかは言われれば分かるけど、じゃあ「なぜ書いてしまうのか」という所に踏み込んでいかないといけない
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
駆け出し以外の人は、「なぜそれが起きてしまうのだろう」という視点で読むと良いと思いますし、それを考えなければ結局変わらないですよね。闇雲にこの本を渡して、「さぁ、ここに書かれているのは悪いコードの例だから、そんなコードは書いてはいけません」なんていう”指示”を経営層や、マネージャーが言い出しても、何も良くならなくて、「なぜ？」をちゃんと考えていかないといけないし、そこにある別の価値観の存在を理解しないといけないんです。
アンチパターン、それ自体はダメって言いやすいけど、実際に解消しようとすると「なぜそれが生まれ、維持され易いのか」という所と向かい合うことになり、そこで行き着くのは案外「誰かの気持ち」だったりするので、余計に辛い戦いになる
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
「俺は困っていないよ」vs「いや私は困っている」という対立軸になってはいけなくて、みんなで幸せになろう
— magnoliak🍧 (@magnolia_k_) 2022年4月30日
で、ようやく本書の内容に触れると......とにかく第1章がめちゃめちゃ良い。
扱っているのが、「命名」、「条件分岐」、「データクラス」の三つのテーマ、順番で簡潔に悪いコードの例を示していて、まず最初が命名の問題を扱っているのが良くて、それは命名の不味さは誰に説明してもその問題が分かり易いけど、条件分岐や、データクラスは、コードの構造の問題は概念的な話なので少し考えないと納得感につながりづらいから。
命名は「実際のコードと照らし合わせて明らかにおかしい」と言いづらいので、まず命名の話が来ているのが具体的で入り易い。
で、次に複雑すぎる条件分岐の問題が出てくる...たぶん、プロダクションコードで経験する様々な「困る」のうち、この2つでかなりの割合を占めていると思われるので、その実感と合っているし、その背景としてデータクラスのような「構造の不味さ」が有ったりする。コードを読み始めて、命名のおかしさに気づき、構造のおかしさに戸惑った次に来るのは、データクラスのような「そもそもの構造、ソフトウェアアーキテクチャ設計」に起因していたりするから、この3つ、この順番で説明しているのが凄く納得感がある。そりゃほかのも大事だけど、この3つ、この順番に意味がある。
非常に内容が多岐に渡るので、個人的には読む順番としては第1章→第2章→第10章→第6章あたりをみっちり読み込むといいかなと感じました。すぐに改善できるところと、チームとして、組織としてどう変えていくのか、コンセンサスを得なければ進められないところが有ると思うので（チームで一人だけ勝手にオレオレルールを持ち込んではいけないので）、手をつけ易いかなと。
という訳で全編、学びしかない良書なので、とにかくいますぐ本屋に買いにいきましょう。
それに、なんか最近こんなに技術書がバーンと話題になることも少ないし、みんな本屋行って、積まれているところを見て、買うといいじゃないですか、お祭り感有って。
4/29お知らせ: 技術評論社『良いコード/悪いコードで学ぶ設計入門 保守しやすい成長し続けるコードの書き方』の著者、仙塲大也さんから直筆POPをいただきました。 pic.twitter.com/47s7K8pJm0
— ジュンク堂書店池袋本店 PC書担当 (@junkudo_ike_pc) 2022年4月29日
今年の技術書の豊作っぷりはすごいですね。どれも10年は内容が持つ、お買い得な本だな、という印象です。
良い技術書は、書いてある内容をそのまま理解して実践する以上に、共通の語彙として同じ価値観／目線で会話をするために利用するものなので、1回読んで終わり、じゃないんですよね。
