久しぶりに物理本を読んだけど、やっぱ物理はええな・・かさばるとこ以外。
せっかくなので読書感想文と、特に印象に残った部分を、章ごとに書いておく。
第1章: 達人の哲学
この本を読んでいくにあたって、そもそも達人とはなんぞやという話がメイン。
プログラマーというより、いわゆる社会人としてこうあれみたいなテーマで書かれてて、なんかみんな読んだらいいのではと思いました。
物事をうまく進捗させるために、
- まず何を言いたくて
- その結果どうしたいのかまで考えて
- 相手の状況やタイミングを見計らって
コミュニケーションを実行する・されると、あれこれスムーズにいきますよっていう。
このテクは中々に便利で、日常生活でもそれこそ夫婦間とかのコミュニケーションでも使える話かなーと思ってて。
ただ自分の場合はこれをやりすぎて、質問してるはずが誘導尋問みたいになっちゃうときがたまにある・・。
第2章: 達人のアプローチ
ETC: Easier To Change
何をするにも簡単に変えられるようにしとけってやつ。
個人的にも、「とにかくシンプルに作る」ってことをここ数年ずっと思ってて、達人的にはETCって言うんですね〜ってなった。
何を作るにしても、不必要に複雑さを持ち込みがちな昨今、さらにその気持ちは強まってるところがある・・。
プログラムを書いてなくても、この決断は後で取り返しが効くやつか？って考えて判断基準にできたりもするし。
曳光弾（えいこうだん）
（漢字が読めんかった・・・！）
銃の弾倉の何発かに1発入ってて、光を発して射線を描いてくれるやつらしい。
要件がでかすぎる案件とか、何も決まってない案件で使えるテク。
とりあえず簡単に動くものを作ってみて、そこから、肉付けするなり方向性を調整したりすることをいうらしい。（プロトタイピングは作ったあとで捨てるけど、こっちは捨てずに生き続けるところが違うとのこと）
今やってる！これやってる！ってなった。
昔はこれをやるにしても、1発目をどこに定めて撃つかが難しくてな〜さっさと仕様決めてくれ〜みたいに思ってた。
けど、往々にして仕様は待ってても決まらんので、よしなにできるよう（試されてるということで）取り計らって、さっさと決められるよう材料を提供してあげるってのが、急がば回れで結局いいなと思ってる今日このごろ。
第3章: 基本的なツール
プレーンテキスト信者たれとか、GUIよりCLIですよねとか、やはり自分は達人だったのか〜ってまたなった。
いわゆるデバッグに取り組むときの心構えとか小技とかも、それやるやる〜って感じだった。
第4章: 妄想の達人
章タイトルの意味はよくわからなかった・・！
先のことなんか見えるもんではないので、あまり予言したり想像したりせず、着実とやれることをやっていけという話。
そういう心意気をコードに表すときの注意点としては、
- さっさとクラッシュさせる
- catchでログはいてthrowするな
- リソースは責任もって解放までしろ
- できる限り影響を局所的にせよ
- etc...
これも割と普段から意識してることなので（以下略
第5章: 柳に雪折れ無し
雪折れしない柳のように、柔軟なコードを書くために気をつけるべきことは？というテーマ。
- 分離できるところは分けろ
- シングルトンやめろ
- FSMはいいぞ
- リアクティブにPub/Subしよう
- 状態を溜め込むな
- 継承やめろ
といった、現世のベストプラクティスみたいなものについての章。
これも（ｒｙ
FSM、ものを考えるやり方としてはわかりやすいけど、実装になると冗長さがどうしても気になってしまって、そこまで厳密にやる必要ある？ってなるな〜と思ってたけど、本書でもそのまま導入するのは難しいかもねって書いてあって安心した。
第6章: 並行性
この章はそのまんま並行処理の話。
ただいわゆる、独立した非同期処理は並行でっていうのではなく、さらに大きなスコープの話。
セマフォー、トランザクションを経て、人類はアクターモデルにたどり着いたのじゃよ・・という流れについて書かれてた。
ただアクターモデルも気持ちはわかるけど、FSMと一緒でコードにすると中々に厳しいな〜って思っちゃう。
なのでこれは、実際に自分のいる領域ではそこまでの並行性を必要としていないからなんやろうなと思った。
Rustみたいな言語がスコープごとに所有権を区切ってるのは、言語レベルから並行性を重視してるからなのだなあ〜と実感した。
第7章: コーディング段階
個人的にイチオシだったのがこの章。
この本的にはここからが実際にコードを書くにあたっての話らしい。
爬虫類脳からの声に耳を傾ける
つまり？ってなるけど、読むと納得。
PRのレビューとかで、なんかすごい嫌な感じがする・・（言葉で説明しようとすればもちろんできる、ただ自分の中で当たり前過ぎて、言語化するのにエネルギーを消費する・・）みたいなことが、誰しもあるはず。
この本能的な直感みたいなものを育てていけという話。
この感覚を洗練させていけば、コードを書く前の段階でも、要件を聞いただけでも危険予知ができていいぞ！と。
偶発的なコード
なんでそうしたのか説明できないコードを書くなという話。
身近な例だと、Reactでなんでもかんでもメモ化しちゃうのとか。
コピペで持ってきたコードをそのまんま何も考えずに使うとか、そういうのをやめなさいという話。
他には、とあるライブラリを採用してるのに、使いこなせてなかったりするケース。使いこなせてないならまだしも、APIが存在することすら知らない場合とか。
アルゴリズムのスピード
ループのネストとかをカジュアルに書きがちな皆さんへのセクション。
エンジニアたるもの、競プロは当然やってますよね〜とは言わんけど、ある程度の知識は持ってるべきよなあと、最近は思ってる・・。（勉強します・・）
リファクタリング
息を吸うように、すきあらばコードを改善していけという話。
何を隠そう、めちゃめちゃリファクタする勢としては（ry
悪いところ、欠陥があったから直すだけではなく、少しでも洗練する余地があればやるってことをやらないと、コードはどんどん陳腐化していく。現状維持は衰退のはじまり。
一日の仕事をはじめる前に、机の上を掃除するのと同じくらいカジュアルにリファクタしていきたい。
第8章: プロジェクトを始める前に
前の章もよかったけど、この章もなかなかによかった。
特に前半の、コーディングするべき仕様を明らかにするまでのフェーズについての部分。
要求の落とし穴
エンジニアやってると言いがちな「仕様を決めてくれ」っていうやつ、これはないものねだりなのでやめろという話。
依頼者も実は何もわかってなくて、ただぼんやりと「あれやりたい」って言ってるだけ。むしろエンジニアリングの仮定でセラピーとして、プログラマー側から仕様を引き出していくしかない、と。
認めたくなかった現実がココにあった・・・！って感じ。
もちろん案件にも依るけど、実装するフェーズのことも考えた上でやりたいことを出してくれる人って、ほんとに貴重な存在やったんやな〜。
というわけで、淡い期待は捨て自分でなんとかしろ、そこでどれだけ情報を引き出せるかが腕の見せどころっていう話。
コードを書くことだけを生業としてる・したい人にとっては、中々に耳が痛い内容なんじゃないかなーと思った。
自分がこういう視点とか可能性とかに気づけるのは、SIerで上流工程ばっかやってたからこそな気もしてて、自分のキャリアをちょっと見直すなどした。
第9章: 達人のプロジェクト
プロジェクトを遂行するチームそのものについての章。
これも中々痛快な章だったと思う。チームは編成して終わりじゃないし、人が多すぎれば"群れ"ができただけで終わる。
ココナツでは解決できない
どこぞの成功例をそっくりそのまま持ち込んでも、ワークしませんよっていう話。
カーゴカルトって単語ははじめて知ったけど、すごいしっくりきた。
コードを書く行為だけでなく、日々の営みにも当てはまるので気をつけないといけない。
感想
個人的には割と好きなジャンルの本だった。
ただこれにすごく共感できたり、自分の中で重要度を上げて反芻できるのは、30も過ぎた今だからこそかなーと思ったりもした。
タイトルはプログラマーって付いてるけど、エンジニアリングという職域を担ってる人は、一通り読んでおいて損はないのではと思う。
ただ内容を実践できるようになるためには、それなりの時間が必要なので、まぁじっくりコトコト。
また忘れた頃に読み物として読み直そっと。