最近の読書

平日夜にコツコツ書かれた記事です。

最近ブログに書いていたのがディックばかりなので、小説ばっか読んでると思われそう…まあいいけど… 技術書って他人が書いた感想読んでも参考にならないことが多いし、内容を写してしまうのでは意味がないのでブログネタにしづらい。 2017年は小説、エッセイ、新書、技術書とかなんでも読んだけど、今年は小説、技術書、ハウツー本が多い。最近読んだやつのメモ。

「良いコード」とは何か

前四半期でコードの小さなミスが多いことを指摘されていたこともあって、とにかく良いコードを書く方法論を知りたくて関連するものを読んでいた。選定が微妙だった感はあるけど、読んで改めて気が付いたことも多かったし、普段の開発で使えそうな部分も多かった。

良いコードを書く技術

良いコードを書く技術　?読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus)

そもそも良いコードというものが定義できないので、色んな本がいう良いコードを見てみよう、ギヒョーさんだし読んでみようと思って買った本。実例を書きつつ、新人、中級、達人の各プログラマーのが意見を書きながらリファクタリングする流れで読みやすかった。例のコードが少し古いのでそのままだと参考にならないけど、考え方は勉強できた。

この本のいう良いコードは

• 保守性が高い
• 素早く効率的に動作する
• 正確に動作する
• 無駄な部分がない

だった。間違いではないが、これだけではまだまだ足りない気もする。また、良いコードを書く為には

• 良いコードを読む
• とにかくコードを書く
• IDEを使いこなし、自動化を進め、バージョン管理に精通し、UNIXを使う
• 原典とHow to本、リファレンス、ドキュメントをよく読む
• コードレビューを受ける、勉強会に参加する、ブログや発表でアウトプットする

といった、基本についてもサラッと書いている。そういうのを基本にやりつつも、オープンな、壊れないコードを書くことが大事だなと感じている。

達人プログラマー

新装版 達人プログラマー 職人から名匠への道

言わずと知れたプログラマーが読むべき本の一つなので、聖地巡礼として今更読んだ。

単に石を切り出す場合でも、常に心に聖堂を思い描かねばならない。

ジーン…

達人プログラマーは、眼前の問題を考えるだけでなく、常にその問題をより大きな背景な中で捉え、常により大きな問題を見つけ出そうとするのです。要するに、大きな背景を捉えることなしに、達人たり得る方法はありませんし、知的な解決、見識のある決定を行う方法もありえないのです。

こういった金言が多いのは海外の著書っぽいけど、しょっぱなから感心した。とにかくどれだけシステム全体を見渡し、イメージできるのか、抽象化できるのか、それが大切だと日々の開発で嫌という程失敗してきたからわかる。他にも大切なことがたくさん書いてあった。

完璧は求めない、どこかで筆を置く

なぜなら、完璧など不可能だから。

毎年少なくとも一つの言語を学習する

こういうのはキリがないのだけど、極めるのは難しくても、ある程度書いて読めるところまで使ってみるというのは確かに正しい。昨年から今年にかけてはKotlinだけど、それ以外にも触ったことのないものを何か増やさないといけない。今からやるならgoかPythonがいいな…でもwebアプリを書きたい…自動化の環境構築でRubyやJavaScriptなどは触っているが、アプリケーションを開発するほどではないので足りない。

何かがおかしくなったときに感じる驚きの量は、実行コードへのあなたの信頼と信念の量に比例する

首がパンパンになるまで頷いた。大抵、よくわからずに書いたコードが原因で驚かされる。つまり自分のせいなのだ。

偶発的プログラミングをしないこと

自分の書いているコードのすべての行を説明できないと、あなたは偶発的プログラミングをしている。

あなたやチームメンバーがテストをしなければ、最終的にユーザーがテストを強いられる

これはデスクに貼っておきたい。書けぬは一時の恥、書かぬは一生の恥。

何度読み返してもまだまだ達人への道は遠いなと思う一冊かもしれない。

プリンシパルオブプログラミング

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

この本はすごく便利で、前述した達人プログラマーはもちろん、リーダブルコード、コードコンプリート、人月の神話、プログラマが知るべき97のことなど数々の名著で共通しているポイントをまとめ上げたような本になっている。3年目までに身につけたい的なサブタイトルがあるが、いつでもいいからすぐに読んでおきたい内容だった。

引用だけで100冊以上の大量の本のエッセンスが詰まっているので、実際にそれらを読んで重複した部分を自分で整理しながら読むよりは効率がいい。もちろん時間があればすべての本に目を通したいが、日進月歩の技術の世界で時間は非常に大切だ。

開発手法を始め、読書の仕方、設計論、プログラマとしての心がまえやチームビルディングについてまで書いてあり、幅広い概念を知れる。

良いコードというか、性質上読むことに大半の時間を使うコードはこうあるべきだというスタンスで書かれている。例えば

優れた文章を書く肝は、「内容を書くこと」と「内容をわかりやすく伝えるための構成を考えること」を、別の作業にすることです。この作業の分断が、コードを書く場合にも当てはまります。

最近、技術書典に向けて執筆してることもあり納得した。俺はコードは小説だとは思わないが、人が読むものとしては同じであると思っているので、優れた文章を書くことは優れたコードを書くことにつながると信じている。しかし、この意識が自分の中にないと、文章が上手いのにコードはグチャグチャということが起きる。なので良いコードを書くことはそれ自身も技術であると考えている。

文章を書いたあとに校正するのと同じく、コードもリファクタリングするのが大切で、その際全体としての抽象度を統一しようねということだ。こういった小さな気付きが無数に言語化されていてよかった。

アスペクト指向プログラミングについてのフワッとしたイメージは、

• 処理を差し替えられる
• アノテーション
• コード生成の応用

みたいな感じだったが、オブジェクト指向のオブジェクトやドメイン駆動設計のドメインモデルのような、現実世界の事物をプログラミングの世界へ抽象化したものには含まれない、システムで横断した関心ごとを分離するのが目的だとわかった。ロギング、セキュリティコントロール、データベース処理などがそれに近い。それらを自動で後から変更できることで、ある時点で書くコードが文脈を考慮せずに済むというのが優れている。こうした理解をしてからコードを書くことが偶発的プログラミングを避ける。

• わかりにくいコードは3回保守してはいけない、2回目で手を打つ
• 仕様は待たずにできるだけ早く作り始める
• 一見似ているが微妙に違うコードを無くす

などの普段わかっているが見過ごしがちなことも実践したい。

達人プログラマーもおすすめだが、先にこれを読んでから、気になった部分を原典で深掘りするのがいいと思う。

人との接し方や人をやる気にさせたい、自分をコントロールしたい

自分のやる気を出すのなんて簡単だし、すべて自分で解決できればいいのだけど、世の中そうもいかないので人の心を動かすには何が必要なのかといつも考えている。

大事なのは自分をコントロールし、他人の心を動かすことだ。心理学の本やコンビニにあるような本は他人を操作するかのような言い回しで嫌いだ。策や罠にはめて人を動かしたところで意味はない。自分の意志でそうしたいと願って行動してもらうことが大事なのだ。

人を動かす

人を動かす　新装版

ベタベタな名著に手を出すのが今年なのかもしれない。聖地巡礼は続く。

• 人はどんなに悪くても自分が間違っているとは考えない
• 批判、非難、苦言はかならず自分に返ってくる
• 皆、顔をつぶされたくない

という人間の弱さをかなりしつこく書かれている。同じことが何度も別なエピソードで書かれるスタイルなので、小説的な反復が苦手な人は、読みにくいかもしれない。こういうのは自分事と思えるエピソードに出会うのを狙ってたくさん書かれていると思う。

人は責められるのが嫌いだ。とても親しくてなんでも打ち明けられる人でない限り、自分の弱みを指摘されていいことはない。そういう基本から、

• 人は自分の重要感が欲しい
• 誰もが誰かに認められたい
• 関心を持たれると好意が芽生える
• できるだけ議論を避ける

という人の特性をきちんと捉えて、それがわかった上で相手の長所や成功を心から賞賛することが大切だと書かれている。うわべではなく褒めるのだ。うわべかどうかわかるのは、相手にどれだけ関心を持ち話しているかだ。好きだったエピソードがあった。

デトロイトの学校の先生が、スティーヴィー少年に頼んで逃げ出した実験用のネズミを探してもらったらしい。彼が目が不自由にもかかわらず。それを頼んだ理由は代わりに耳がすごく鋭敏だったからだそうだ。少年は生まれて初めて自分の才能を誰かが認めてくれたことに感激し、スティーヴィー・ワンダーという偉大な歌手に成長していった。

褒める力は人生を変える。

我々は、このわかりきった方法を、なぜ人間に応用しないのだろう？なぜ、鞭の代わりに肉を、批判の代わりに賞賛を用いないのだ？たとえ少しでも相手が進歩を示せば、心から褒めようではないか。それに力をえて、相手はますます進歩向上するだろう。

センスというスキルを身につける

センスは知識からはじまる

センスは知識からはじまる

前に現実世界を見る解像度を上げるには知識が必要という記事を書いたときにmorishitterから勧められた本。実はこういう実感は昔からあった。友達がDTP受託をしていたときに、「〜（その友達）の作ったデザインいいよね！わたしもできそう！」という人をよく見かけた。本とは逆の例えなのだけど、よくわかってない人ほどなんとなく自分でもできそうと感じるのだ。実際にやってみると細部に宿るこだわりを見抜けずにゴミが出来上がる。わかっている/気づける人は何が優れているのかを賞賛する。もちろん、全てわかっていてできるという人もいるとは思うけど、軽い気持ちで言っているなら作者を傷つける前に、自分の無知をさらけ出す前に深く考えてみたい。

本を読んでいてわかったのは正解のないものは文脈やプロセスが大事になり、知識がない人にはそれがまるでセンスだと錯覚させることができるということだ。そして知識のある人にはそれがよくデザインされているものだと伝わる。その手順についても書いてあり、

• 王道を知る
• 最新を知る
• 共通点を探す

をすることで知識を増やす＝センスを磨くことができるとなる。服装などもセンスがない人がいるわけではなく、自分に似合うものを知らない人がいるだけなのだ。そう思うとセンスがないなぁと諦めていたものすべてが、頑張ればできるものへと変わっていく。この意識の切替は本当に大切だと思う。自分を例にするとやはり対外発表がまだまだ磨き足りない部分だと感じている。

お金に強い思考が欲しい

読んで字のごとくである。

マネタイズ戦略

マネタイズ戦略――顧客価値提案にイノベーションを起こす新しい発想

Twitterランドでみつけた引用が面白かったので、つい買ってしまった。何でもかんでも完璧に学べないが、こういうエッセンスを得られる本は好きだ。

かっけーよなコレは pic.twitter.com/i8oosl4LxN

— アチク (@_achiku) July 22, 2018

技術者が「ビジネスモデル」と聞くとｳｯとなることが多いと思うが、売れない最高のソフトウェアを作っても自分しか幸せにならない。どうせなら少しでも売れて、自分の家族が困らない程度には役立って欲しい。会社ではエンジニア目線なのか知らないが、こういう話をエンジニアとしないように気をつけろみたいな雰囲気が一部にはある気がする。そうではなく、もっとお互いの領域に踏み入って、重なる部分を見つけてコミットしていくことが大切だ。

マネタイズは「誰から儲けて誰からは儲けない、どこで儲けてどこでは儲けない、今儲けなかったらいつ儲ける」といった、これまであまり考えたことのない疑問をあなたに投げかける。

冒頭のこの文章が気に入った。

全体を通すとそれをマネタイズと呼ぶの？みたいな部分もあるが、メディアは広告でしか儲けられないのか...？と諦めかけていた俺には目新しい視点が多く、勉強になった。Netflixが最初はビデオレンタル屋だったということも知らなかったし。儲けることが好きじゃない人はアカデミックな世界の方が合うかもしれない。俺は社会人として会社に所属する限り、儲ける仕組みについて知らないと恥ずかしいとさえ思っている。金に目がないと言われるかもしれないが、呼吸をしてるだけで金がかかるこの世の中で、金のことを考えない人の方がどうかしてるような気もする。

---

ただ、ZOZOの前澤社長がいっている「世界平和のためにはお金をなくすことだ」という主張はめちゃくちゃ共感できる。お金もなくなって、仕事もしなくていい世界で、好きなことだけをして生きていけたらこれほど幸せなことはないだろう。