Chapter 8 Pragmatic Projects【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 8. Pragmatic Project を読んだ。内容は次の通り。

• 41 Pragmatic Teams
• 42 Ubiquitous Automation
• 43 Ruthless Testing
• 44 It’s All Writing
• 45 Great Expectations
• 46 Pride and Prejudice

Great Expectation

他人の期待を正しく理解することが非常に重要という話。結局、プロジェクトは誰かの期待に応えられているかどうかで判断されるわけで。

コンサルタント業界では "Expectation Management" なんて言葉もあるようだ。この本では「俺たちはそこまでしろと言ってるわけじゃない。ただ、顧客の期待を正しく理解しよう」と説いている。

Tip 69 Gently Exceed Your Users' Expectation

そして、できればその期待を少しだけ上回ろう。Gently というのはとても絶妙な表現なんじゃないかなと思った。それくらいなら、勘違いしてユーザーの期待から大きく離れてしまうこともないだろうからね。

おわりに

今年の頭くらいから読み始めて、中断して、帰りの電車でちょっとずつ読み進めてよーやく読み終わった。やはり英語の本を読むのは時間がかかる…。

全体を読んだ感想としては、こんなに頑張って読まなくてもよかったかな、という感じ。日本語版をぱらぱらと一週間くらいで読めば十分、という感覚ですね。

Chapter 7 Before the Project【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 7. Before the Project を読んだ。内容は次の通り。

• 36 The Requirements Pit
• 37 Solving Impossible Puzzles
• 38 Not Until You’re Ready
• 39 The Specification Trap
• 40 Circles and Arrows

２つほど面白い章があったので感想を書いておこう。

37. Solving Impossible Puzzles

解くことが不可能に見える問題も、正しく制約を理解すれば簡単に解けることもあるよ、っていう話。

ここでのポイントは課された制約をきちんと認識して分類すること。分類は、

• 必ず守らなければならない制約
• 必ずしも守らなくてもよい制約

という単純な二種類で充分。私たちは「必ずしも守らなくてもよい制約」を「必ず守らなければならないもの」だと誤認してしまうことが多い。この誤認に気づくと、問題が一気に解決することがある。

38. Not Until You’re Ready

闇雲に何かを始めるのではなく、始めるタイミングを見計ろう、という話。

プロの曲芸師は自分のタイミングを知り尽くしていて、すべての条件が揃うまで静かに待っている。そして、タイミングが来たと感じたら一気に勝負に出る。プログラマも何かの作業をする時はタイミングを見計らうべきだし、また、その直感を鍛えるといい。

「タイミングを見計らう」っていうのは正しく準備することにも繋がるかなぁと思った。何かに向けて準備することはとても大事だなぁ、と最近強く感じる。

いつかだったか、テレビで凄腕の心臓外科医が、手術のヤマとなる血管を切り取る場面で「ここにたどり着いた時点で、僕の勝ちは決まってるんですよ。ここにたどり着くまでが仕事なんですよね。」と言っていて、たしかになーとは思った。

CODE COMPLETE にも、

ニ回測って、一度で切る

という格言が紹介されていて、コーディングにも似た側面はあるんじゃないかなーと思った。

Chapter 6. While You Are Coding【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter6. While You Are Coding を読んだ。 内容は次の通り。

• 31 Programming by Coincidence
• 32 Algorithm Speed
• 33 Refactoring
• 34 Code That’s Easy to Test
• 35 Evil Wizards

印象に残る章がいくつかあったので書き残しておこう。

31. Programming by Coincidence

この章は、「自分が書いてるコードをちゃんと理解していますか」というような内容だった。

最近、以前よりも自分の書いたコードに自信が持てるようになったなー、と思っていて、『コンパイルする回数が減った』とか『一発でうまく動くことが増えた』とか、そういうところで開発に効いてきている。

いくつか要因はあると思うけど、大事なことの１つは「何を期待して目の前のコード片を書いているのかを常に意識する」ということだろう。プログラマは何かしらの『期待』を持っていて、それを実現するためにコードを書くわけだけど、どのコードが何の期待を満たすのか、自分の中でちゃんとマッピングさせておくのがとてもよい。コードに自信が持てるし、コードの理解につながる。

これには別の効果もあって、自分の『期待』をただしく理解しておくと、すごくデバッグが捗る。バグはたいていの場合、何らかの『期待』と異なる挙動をしているから発生する。だから、『期待』とコードのマッピングを持っておけば、必ず最後にはバグの原因にたどり着ける。まあ、たまに期待自体が間違ってたりするし、現実はそんなうまくいかないけど、バグ解決の確率はだいぶ高まる。

あとは、この『期待』と『コード』のマッピングはなるべく小さく保っておいて、それをベースにして大きなビルディングブロックを作ってくと、とてもいいコードが書けるんじゃないかなぁと感じている。

この『期待』ってのは『意図』とも言い換えられるかなーと思ったりして、そうするとこの章の言いたいこととつながるよなーと思った。

35. Evil Wizards

これは「ウィザードで生成されたコード使うならちゃんと中身読もうね」という話で、とても説得力があった。

ライブラリの場合、ライブラリ側のコード把握する必要はない。正しいインタフェースが切られていて境界がはっきりしてるからだ。

一方、ウィザードによって生成されたコードは、私たちのコードに直接入り込んでくる。「すぐにウィザードで生成されたコードをいじることになるから、理解してないとひどいことになるよ」というのはその通りだと思った。

『サピエンス全史』を読んで

ちょっと前、と言っても数ヶ月は経ったけど『サピエンス全史』を読んだ。

サピエンス全史(上)文明の構造と人類の幸福

サピエンス全史(下)文明の構造と人類の幸福

DEEP WORK を書いた人のブログに紹介されてて、ふーん、って思って、ぐぐったらどうやら邦訳が出てるらしい。 たまにはこういう読み物系も悪くないか、と思って読んでみた。

人類という種としての歴史、すなわちホモ・サピエンスという種の歴史が書かれている。

著者によるとホモ・サピエンスの歴史には3つの転換点があったようだ。

• 認知革命
• 農業革命
• 科学革命

これらの3つの革命をベースにさまざまな話題がちりばめられた本だ。

感想

最初の認知革命から農業革命あたりの話が楽しく読めた。単にその時代あたりの歴史（数万年前）をあまりに知らなかったから新鮮だっただけかも。

狩猟時代の人類はとても生活レベルが高かったというのは面白い。まだ人口も少なく、食料や衛生面で困ったら移住するという手段があり、1日のうち少し狩りをしたらあとは自由に過ごしていたようだ。一方、農業が栄えてからは、人口も増え、農作物が不作になるリスクを抱え、定住による衛生面の悪化で苦労し、年中作物の面倒を見なければならなくなり、挙げ句の果てに、階層の高い一部の個体のために育てた農作物を献上しなければ生きていけなくなった。ここから「人類は本当に幸せになったのだろうか」という問いにつなげるあたりはなかなか。

一方、科学革命からの資本主義がどうとかってところは思ったほど面白くなくて、別に考え方・とらえ方は間違ってるとは思わないんだけど「ふーん」という感じ。資本主義についてから最後にかけての展開がこの本を際立たせてる要因だと思うのだけど、自分にはあまり響かなかったな。そこらへんで仕入れた知識を列挙してるだけ？と思ってしまった。

最後に、

ひょっとすると 、私たちが直面している真の疑問は 、 「私たちは何になりたいのか ？ 」ではなく 、 「私たちは何を望みたいのか ？ 」かもしれない 。この疑問に思わず頭を抱えない人は 、おそらくまだ 、それについて十分考えていないのだろう 。

って投げかけてきて、「あっ、はい」ってなったところで本は終わった。

Amazon の 2017 年のビジネス書大賞にも選ばれてたりして、これビジネス書？って思ったりしたけど、話題の作品なのは間違いないようですね。

https://www.amazon.co.jp/b?node=5026826051

Chapter 5. Bend, or Break【The Pragmatic Programmer】

The Pragmatic Programmer の Chapter 5. Bend, or Break を読んだ。

内容は次の通り。

• 26 Decoupling and the Law of Demeter
• 27 Metaprogramming
• 28 Temporal Coupling
• 29 It’s Just a View
• 30 Blackboards

一通り読んだけど、あまり印象に残る話題がなかった。たぶん、どこかで一度は目にしたような話が多かったからだろう。30 の Blackboards は、「確かに、そうだね」って感じだったけど、イマイチ具体的な話が伝わってこず、消化しきれない感じ。

---

6割くらい読んできた感じとしては、技術的な話のところは大して面白くなく、精神論みたいな話の方が楽しい。

ただ、精神論を読みながら、「うんうん、ほんとそうだよねー」って自己完結しても大して身にならないので、気をつけないとね。

Chapter 4. Pragmatic Paranoia【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 4. Pragmatic Paranoia を読んだ。

内容は次の通り。

• 21 Design by Contract
• 22 Dead Programs Tell No Lies
• 23 Assertive Programming
• 24 When to Use Exceptions
• 25 How to Balance Resources

契約によるプログラミングとか、Assertion 使いましょうとか、全体的に時代を感じる章だった。まずはクラッシュさせよう！とか聞くと、うーん…、って感じになる。確かに理解はできるが…。

そういえば、最近はあまり assert とか使ってないなぁと思った。昔は結構単体テストとか assert とか書きたがるタイプだったけど。

単に今の仕事ではそこらへんをきちんとすることへの優先度が低いと感じているだけかな。自分には時間も能力も限られたものしかなくて、何が一番効果的かと考えた時、assert や単体テストを拡充することが今の業務にとって有効だと感じていない。

やりたいこと/やった方がいいことがあったとしたら、きっと、そのうち 80% のことは諦めなきゃいけなくて、決意を持ってそのうちの 20% を選ぶことが仕事なんだと思う。そして、うまく選べればその20%で80%くらいの結果は出せるはず。

最近は人生もそんな感じかな、と思うようになった。

話が完全に本と関係なくなってしまったな。。。

Chapter3. The Basic Tools【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 3. The Basic Tools を読んだ。

内容は次の通り。

• 14 The Power of Plain Text
• 15 Shell Games
• 16 Power Editing
• 17 Source Code Control
• 18 Debugging
• 19 Text Manipulation
• 20 Code Generators

この章はツールの紹介とかが多くて、やや話が古い印象を受けた。現代においてソースコード管理システムを使わない開発はありえないだろう。

一方、デバッグの心構えみたいなのは古くなってないと感じた。

Tip 27 Don't Assume It - Prove It

という話はまさにその通り。

他にもデバッグの心構えはいくつか書かれていたけど、本当にこの一言に集約されると思いました。

おわり。