面白かったので土曜日の午後に一気に読み切ってしまった。今年は、ソフトウェアやシステムに関する技術書が豊作な年ですね。10年後でも十分に通用する本ばかり出版されていますね。
本書『良いコード／悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』もそんな1冊です。
仮に、この本を駆け出しエンジニアの時に買っても、その後のキャリア......シニアエンジニア、マネージャー、人事や経営と、色々な立場の時に「使える本」になります。それは、この本が技術を理解するだけでなく、「エンジニアの価値観を理解するための本」と言ってもいいからでしょう。
- 駆け出しの人は、「良いコード」と、「悪いコード」の区別の仕方、というより、そもそもそういう区別があること自体を理解するのに読むと良いです
- 駆け出しを過ぎたくらいの、目的のコードがとりあえず書けるようになった人は、自分の中の成功パターン以外にも色々なプラクティスを網羅的に学ぶのに読むと良いです
- ソフトウェア開発を指導する立場の人は、良いコードと、悪いコードの区別を教える際の語彙や概念を、オレオレ理論ではなく汎用的なプラクティスとして伝えるための教材として読むと良いです
- 人事や、組織をマネジメントする層の人は、ソフトウェアを取り巻くエンジニアが何を重要視していて、そしてそれはなぜなのか？という価値観と、その背景をを理解するために読むと良いです
- ソフトウェアの出来映えや、開発スピードがビジネスに大きく直結する組織の経営層は、コードにはさまざまな書き方が有って、それがビジネスのスピードに影響するを理解するために読むと良いです
ソフトウェアのプラクティス、全部一人でやっていれば導入するのもしないのも一人の判断でできるけど、組織で、事業としてやっている場合はそうはいかず、いくつかの階層に別れてきます。
それぞれの層がお互いにコミュニケーションを取るためには共通の理解・語彙が必要で、この本にはそのために必要なことがたくさん詰まっている、詰まり過ぎている。
とはいえ、実際のプロジェクトでは、そのレイヤーにおける責任を持つ人が適切な判断をして、意思決定をしないといけないです。で、その時に、そこに悪気が有る人は居ないし、みんなそれぞれがやるべきだと思っていることを一生懸命やっているはずなんですけど、上手く行かない時がある。
で、そこに無いのは、共通の語彙であり、立場が異なる／階層が異なる人同士のコミュニケーションだったりします。
そんな時に、真ん中にこの本が有ると、少し世界は分かり合えるのかもって思いました。
この本で触れられている実態を表していない命名、複雑すぎる条件分岐、重複するコード...どれも現実のコードに出てくるけど、誰も悪いコードを書きたいと思って書いている人は居ないはずなんです。目の前の課題を解決するために一生懸命やっているはずなんです。でも、悪いコードが誕生してしまう、放置されてしまう、それが後世の人を苦しめてしまう。
駆け出し以外の人は、「なぜそれが起きてしまうのだろう」という視点で読むと良いと思いますし、それを考えなければ結局変わらないですよね。闇雲にこの本を渡して、「さぁ、ここに書かれているのは悪いコードの例だから、そんなコードは書いてはいけません」なんていう”指示”を経営層や、マネージャーが言い出しても、何も良くならなくて、「なぜ？」をちゃんと考えていかないといけないし、そこにある別の価値観の存在を理解しないといけないんです。
で、ようやく本書の内容に触れると......とにかく第1章がめちゃめちゃ良い。
扱っているのが、「命名」、「条件分岐」、「データクラス」の三つのテーマ、順番で簡潔に悪いコードの例を示していて、まず最初が命名の問題を扱っているのが良くて、それは命名の不味さは誰に説明してもその問題が分かり易いけど、条件分岐や、データクラスは、コードの構造の問題は概念的な話なので少し考えないと納得感につながりづらいから。
命名は「実際のコードと照らし合わせて明らかにおかしい」と言いづらいので、まず命名の話が来ているのが具体的で入り易い。
で、次に複雑すぎる条件分岐の問題が出てくる...たぶん、プロダクションコードで経験する様々な「困る」のうち、この2つでかなりの割合を占めていると思われるので、その実感と合っているし、その背景としてデータクラスのような「構造の不味さ」が有ったりする。コードを読み始めて、命名のおかしさに気づき、構造のおかしさに戸惑った次に来るのは、データクラスのような「そもそもの構造、ソフトウェアアーキテクチャ設計」に起因していたりするから、この3つ、この順番で説明しているのが凄く納得感がある。そりゃほかのも大事だけど、この3つ、この順番に意味がある。
非常に内容が多岐に渡るので、個人的には読む順番としては第1章→第2章→第10章→第6章あたりをみっちり読み込むといいかなと感じました。すぐに改善できるところと、チームとして、組織としてどう変えていくのか、コンセンサスを得なければ進められないところが有ると思うので（チームで一人だけ勝手にオレオレルールを持ち込んではいけないので）、手をつけ易いかなと。
という訳で全編、学びしかない良書なので、とにかくいますぐ本屋に買いにいきましょう。
それに、なんか最近こんなに技術書がバーンと話題になることも少ないし、みんな本屋行って、積まれているところを見て、買うといいじゃないですか、お祭り感有って。
今年の技術書の豊作っぷりはすごいですね。どれも10年は内容が持つ、お買い得な本だな、という印象です。
blog.magnolia.tech
blog.magnolia.tech
blog.magnolia.tech
良い技術書は、書いてある内容をそのまま理解して実践する以上に、共通の語彙として同じ価値観／目線で会話をするために利用するものなので、1回読んで終わり、じゃないんですよね。
