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

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

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

おわり。

Chapter2. A Pragmatic Approach【The Pragmatic Programmer】

Pragmatic Programmer の Chapter 2. A Pragmatic Approach を読んだ。

内容は次の通り。

• 7 The Evils of Duplication
• 8 Orthogonality
• 9 Reversibility
• 10 Tracer Bullets
• 11 Prototypes and Post-it Notes
• 12 Domain Languages
• 13 Estimating

曳光弾開発とプロトタイプ開発の違いについての話は興味深かった。

Tracer Bullets と Prototypes

モジュールごとではなく、システムを貫通するように機能を中心に作ることを曳光弾開発という。この言葉は前から知っていた。プロトタイプ開発と曳光弾開発と何が違うのか？

プロトタイプ開発はあくまでプロトタイプ。製品リリースに向けてコード自体を１から書き直す前提。プロトタイプのコードをベースにして開発を進めてはいけない。

一方、曳光弾開発は製品レベルのコードで一部の機能を実装する。実装したコードは作り直すことがなくほぼそのまま製品として利用できる。この点が大きな違い。

プログラムとプログラム製品

『人月の神話』に『プログラム』と『プログラム製品』の違い、という話がある。

『プログラム』を作るのにはそれほどコストはかからない。それは単一の環境で、簡単なデータの組み合わせに関して動作すれば良いものだから。エースプログラマが徹夜して数日で『プログラム』を作り上げた、なんて話はよく聞くだろう。

でも、多様な環境で動作して、様々なデータに対応した『プログラム製品』にするには『プログラム』を作る3倍のコストがかかる。というのが『人月の神話』に書かれた話。加えて『プログラム』を、コンポーネントに分離された拡張可能な『プログラムシステム』（フレームワークとか OS に該当）にするには 3 倍のコストがかかり、もし『プログラム』を『プログラムシステム製品』にするなら 9 倍のコストがかかる。

プロトタイプの危険性

プロトタイプを作るということは『プログラム』を作ることであって、決して『プログラム製品』を作っているわけではない。プロトタイプができてもリリースまでにはさらに数倍のコストがかかる。

プロトタイプをマネージャーや経営陣に見せる時は注意が必要だ、と Pragmatic Programmer には書かれている。

動くものがあると、リリースはすぐそこだと勘違いしてしまいやすい。『プログラム』を『プログラム製品』にするには3倍のコストがかかるという事実を忘れてしまう。

それを防ぐため、正しい情報を伝えるのもエンジニアの役目なのだろう。

第 218 回 TOEIC の結果

そういえばもう一ヶ月くらい前になるけど、第 218 回 TOEIC の結果が返ってきた。

Listening	Reading	Total
430	415	845

結果として前回から100点くらい伸びた。Listening も Reading も前回の TOEIC よりはきちんと理解して解けたところが多かった。理解できてない問題はきちんと分かるようになった。

「ああ、これは間違いなくこの答えだな」と「うわ、今の会話は全然聞き取れなかった…」が、ちゃんと分かるようになった。 まだまだ前者の割合が低く、後者の割合が高い。前回に引き続いて予想以上の結果がでてるなぁと思った。

やったこと

去年の TOEIC から何をやっていたかというと、ひたすらこの本をやってた。毎日30分くらいこれをやり続けた。

どんどん話すための瞬間英作文トレーニング (CD BOOK)

結果を出すためには日々の継続が大事なんだなぁと改めて感じた。特に語学はね。

先週くらいから、これに加えて iknow を始めて少し英語に費やす時間を増やすことができている。なかなか時間の取れない中で、習慣として少しでも英語に費やす時間が増やせたのはだいぶよい。あとは英会話を始めたいけど、どうやって時間を捻出するか…やはり休日の朝か…。