Andrew Hunt and David Thomas『達人プログラマー』

概要

知り合いが貸してくれた。いや、先月Javaの技術書を読書したばかりだからあんまり食指は動かなかったのだが。けれどこうして偶然降ってくるままに読書することこそ雑食読書と呼べるんじゃないかと思い直してサクサク読んだ。

この本も先のJava本と同じで、どういうことを念頭においてプログラムを書くか、どういう思想でもってプロジェクトを回すか、って部分に主眼が置かれている。プログラミングのことをあんまり詳しく知ってなくてもすんなり読めたのはよかったかな。面白かったところを書いていく。

面白かったところ

割れ窓を放置しないこと

• 綺麗に掃除された廊下にはなかなか誰もゴミを捨てない。だけどゴミがひとつでも落ちていると、みんな一斉にゴミを捨てだす。廃ビルの窓が一枚でも割れていると、一斉に窓は割られる。という理論。
• プログラムのコードでも、適当な書かれ方をしていると、他の人たちも「ああこのプログラムは適当でいいんだ」とヘボな書き方をしだす。キチッと書いてそれを防ぎましょうってコト。

やめ時を知る

• プログラミングは絵と似ている。決して完璧になることはない。十分に書けているのに、ついつい「もう一筆」とやりたくなってしまうがヤメ時を知ること。俺の思想 Done is better than perfect. と共通するところがあって理解しやすい。

早起きした鳥は虫にありつけるという格言があるが、早起きした虫には何が待っていた?

• 笑った。

自分の知識ポートフォリオへ定期的な投資を行うこと

• 毎年ちがう言語を学習すること。
• 四半期ごとに技術書を読むこと。
• 四半期ごとに技術書じゃない本を読むこと。
• 講習とかユーザグループに参加すること。
• 思ったんだけれど、このみろりhpって俺のポートフォリオになってるよな。やったことほぼほぼ書いてるから。

DRY原則

• Don't Repeat Yourself. 繰り返しを避ける精神のこと。まあ、プログラミングの基本精神よな。そんな名前があったのね。
• これを実現するために関数とかfor文とかで処理をまとめるわけだ。

直交性

• 関係ないもの同士が影響しあわないこと。これもプログラミングの基本精神だよな。
• これを実現するためにプログラムをクラスとか関数に分割するんだ。
• プログラム単位であれば「ある部分を変更するために他の部分を変更する必要がどれだけないか」が直交性をはかる尺度になる。プロジェクト単位であれば「その議論をするとき必要な人間がどれだけ少ないか」が尺度になる。
• 別の言葉でいえば結合度の最小化。スパイや革命家はセルというグループに組織化されている。どこかのセルが摘発されても、他のセルの情報が漏れないという寸法だ。セルのような関数、クラス、モジュールを作ろう。

曳光弾

• これ えいこうだん って読むんだって全然知らなかった。
• ようは、プログラミングの書きミスに早めに気付くように短い間隔でテストをしようってコトみたい。

プロトタイプを作ること

• 実際にコードを書き出す前に、全体図を作るってこと。普段からやってることだし、賛成。

見積もりをすること

• 要求を洗い出し、システムをモデル化し、リスクを分析し、各パートに値を与える。というふうに見積もりを立てる。
• これはパッとできる作業ではないので、見積もりを要求されたら必ず「のちほどお持ちします」と言うこと。

ツールを揃えること

• まずは基本的な道具一式から始めて経験を積む。特殊な要求に出会ったとき、道具を追加していく。職人のように、つねに道具を増やすことを心がけよ。
• プログラミングでいえば、ひとつのエディタやひとつのIDEに依存することをヤメろってことだ。俺もSublimeだけでpython書くのヤメて、IDEとか使ってみようかな。

ひとつのエディタに習熟すること

• ひとつのエディタを知り尽くし、プレーンテキストをいじるプロになれってことみたい。
• ってアレー? 上述の「ひとつのツールに依存するな」ってのと微妙に矛盾する感じがするな。まあ、いろんなツールを知りつつも一番得意はもっておけって感じか。

知識はプレーンテキストに保存すること

• 人間が読めるデータは、データ形式や生成したアプリケーションの枠を超えて生き続ける。Wordで書いたdocファイルとかさー、WordとかOpenOfficeがなきゃ読めないじゃん。そういうのヤメろってこと。
• 俺はたびたびみろりhpにプログラミングのtipsとか書くけど、実はああいうの元は全部PCにプレーンテキストで保存しているのだよ。この習慣はバッチリってことみたいだな。
• まあ、趣味レベルでもプログラミングやっていればプレーンテキストにもっとも好感をもつようになるよ。

つねにソースコード管理システムを使うこと

• めちゃめちゃタイムリー。最近Gitに手を出したばかりだからな。確かにあれは便利だよ。

誰かに説明するのは有用な問題解決法

• 「あのさー、ちょっと質問があるんだけど、これこれこういうことしてたらこんな問題が起きてさー、あれこれ試したんだけどうまくいか……ってアレ? あ、そっか。ゴメン自己解決したわ。」
  • ってあるあるネタのこと。この場合の誰かはただ頷いてるだけでいい。Gregというスゲー開発者はそのためにいつもお風呂に浮かべる黄色いアヒルを持ち歩いていたらしい。そのアヒルに対して問題を説明していたってわけ。

コードジェネレータを使うこと

• コードを生成するコードのことみたい。よくわかんない。えーとアレか? 以下のようなコードはいつもいつも書くんだから、そういうものは自動化しろってことかな?

class Foo:
    def __init__(self):

• ただしGUIのウィザードが記述するコードを使うなら、その内容を理解していなければならない。

Design by Contract

• 契約による設計。このプログラムは何を受け取り、何を返すのかしっかり決める(契約)ってこと。
• ようは、引数と返り値のことをDocに書けってことだよな? 引数とかは事前条件(require)と呼ばれ、返り値とかは事後条件(ensure)っていうらしい。

トラッシュ(めちゃくちゃ)にさせるんじゃなくクラッシュ(停止)させること

• プログラム内でエラーが起きたら即座に例外飛ばして停止させること。エラーが起きたにもかかわらず最後まで処理が走ったら、結果はオカシイけどどこでおかしくなったのかわからんってことになる。

メタプログラミング

• 設定項目はコード内に書かないこと。コードには抽象概念を書くこと。
• これは普通に理解できるな。以前つくったDialogFrameで自然にやったことだ。ソースコードには処理だけが書いてあって、どんな情報でその処理を回すか、っていうの(メタデータというらしい)は設定ファイルに書いた。

O()記法

• オーダー記法と読む。「実行時間が O(n**2) である」と言うとき、データが二倍になったら時間は四倍になる。

リファクタリング

• スクリプトを見直して、繰り返しのあるところを関数化したりクラス化したり、ともかく構造をブラッシュアップすること。
• 上述の「割れ窓を放置しない」というのは要はリファクタリングをバッチリやりましょうってこと。
• ただしリファクタリングと機能追加は同時に行わないこと。そしてリファクタリングする部分のユニットテストを用意し、リファクタリングによって何かが壊れたときそれをすぐに察知できるようにすること。

ユーザの視点に立つには、ユーザと共に働くこと

• 開発者側の視点とユーザの視点はズレるってこと。以前ゲーム作ったときそれは経験してる。俺が思いもしなかった操作をプレイヤーが行ったために、せっかく作ったイベントがスキップされちゃったんだよ。

枠にとらわれず考えるというのは、枠を無視するってことじゃなく、もっと広い枠を見つけるということ

• そうだな。

早めにテスト、何度もテスト、自動でテスト

• なんかね、ユニットテストってものが大事なことはすごくよく伝わってくるんだけどそれが何かよくわからん。次にpythonでやる遊びは、ユニットテストにしようかな。

達人はドキュメントを重んずる

• 書くべきなのは、なぜそれをするか、という意図。
• 書くべきでないのは、コードの内容をただ言い換えるもの。あと改訂履歴。改訂履歴はコード管理システムにやらせるべき。
• そして作者の名前を書くべきである。それは作者に誇りと責任感を与える。

まとめ

プログラミングの本に共通していることがあるように思う。

• 「繰り返し同じことを書くな」
• 「プログラミングは絵と似ている」
• 「例外処理はうまく使え」
• 冗談が多い

5年後の感想

(2022-03-24)

いやあ、この本は良いな。この読書感想文を書いてから5年経ったけれども、いまだに振り返りにきてしまう。5年後の今、当時のサマリに対して、いくつかコメントしておく。

直交性
これを実現するためにプログラムをクラスとか関数に分割するんだ。

そのとおり。これを快く思うきみは、 Vue.js の "SFC" なんつー思想を経験したら気持ちいいと思うぜ。 Single File Component の世界観では、ひとつのファイルの中で変数が完結する。

ツールを揃えること
俺もSublimeだけでpython書くのヤメて、IDEとか使ってみようかな。

よい傾向だ。 Sublime ちゃんもよいエディタだけど、プログラムを書きたいなら、 VSCode とかのほうが良い。単純に実力が Sublime ちゃんよりも高い。

ひとつのエディタに習熟すること
ってアレー? 上述の「ひとつのツールに依存するな」ってのと微妙に矛盾する感じがするな。

矛盾はしない。 "ツール" はプログラミング全般についてのツールのこと。こっちで言われている "エディタ" はプレーンテキストを編集する道具のこと。エディタについては依存していい。依存してもよいので、 "プレーンテキストをうまくいじれない" なんつー状況をなくせ、ということだ。検索、置換、整理、これらはちゃんと出来るようになっとけってことだ。