こんにちは、土居です。先日、待望の長男が誕生しました！現在産まれてから１ヶ月半ですが、どんどん成長していて見る度に感動しています。

最近、メンバーとの雑談の中で技術書には大きく２種類

• 特定の言語や技術について書かれた本
• プログラミング全般、または普遍的な内容の本

があるけど、バランスよく読むべきだという話をしていて、自分は必要に応じて前者は読んでいたが後者のタイプはあまり読んでなかったなぁと感じました。

特定の言語や技術について書かれた本

よくあるのは「入門！{言語/フレームワーク名}」といったタイトルの本ですね。初めて触れる言語についてざっと学んだり、実際にやりたいことの実装方法を調べたりなど、即効生があって便利です。
フロントエンドだと変化が大きくて作りにくいのか、JavaScriptのオライリー本があまり出なくなっていたり、（来年実に8年ぶり？にThe Definitive Guideの新版が出るようですが）最近ですと人気のVue.jsやReactの入門本がたくさん書店に並んでいます。私は技術書といえばもっぱらこちらのタイプでした。

特定の技術によらない本

プログラム全般でコード書き方であったり、テストの実施方法、リファクタリングなど、普遍的な内容について書かれたタイプ。
今回メンバーにおすすめされた本では

達人プログラマー

Code Complete

あたりですね。
名著と呼ばれる本はこちらのタイプの方が多い気がします。

達人プログラマー

そういうわけで、早速こちらから手に取ってみました。ソフトウェア開発における様々なトピックに触れられており、折に触れて何度か読み直したいですね。印象に残ったものをいくつか紹介したいと思います。

直交性

異なる要素が互いに与え合う影響がもっとも少ない状態を「直交」していると呼び、その状態に近ければ近いほど、ソフトウェアの開発/テストが短期間で済むことになる。
最近、KPT振り返りの中で見積もり精度の向上について議題が上ったときに、既存とほぼ同様+α程度な機能を、その既存機能にかかった時間を参考にして少なめに見積もってしまったという経験談を上げました。
ソフトウェアに直交していない部分があればあるほど、時間が経つにつれて影響する範囲が広がり、単純な追加であっても以前以上に時間が取られてしまうことがあります。完全に直交な状態を保つのは難しいと思いますが、序盤から意識しておくことで後々に影響を与える傾斜を少しでも緩められればと思います。

容赦ないテスト

単体・結合テストから、パフォーマンステスト・回帰テストと様々なテストの注意すべき点、何のためにするテストかについて述べられています。これも最近KPT振り返りで話題に上ったのですが、自分はテストケースを対象のプロジェクト/機能の実装ごとに都度用意して検証していましたが、観点を漏れなくチェックするためにテストケースのテンプレート的なものを用意しておいた方がいいなと感じました。

ユーザーの期待を少しだけ上回る

「少しだけ」というのがミソなのだと思いますが、やりすぎると蛇足になってしまいますので難しいなと感じました。本では具体的に+αの機能（ヘルプ機能、ショートカット機能など）を加えてユーザーを喜ばせるともあります。便利な機能をおまけするということ以外でも、例えば設計段階から適切なコミュニケーションを繰り返すことで、期待された機能そのままでない、より良い形の提案ができたりすると良さそうです。

まとめ

普遍的な内容の本は出てくるコードやツールが古めだったりすることもありますが、考え方そのものは時代に関わらず有用なために数年ごとに改訂されるなど長く名著として愛されているのだと思います。達人プログラマーは喩えやジョークが面白く、読み物としても楽しめました。これからはもうちょっとこちらのタイプも読んでいこうと思いました。

どいけん