これまで読んだソフトウェア関連で良かった本

実装系

Effective C++

www.maruzen-publishing.co.jp

Effective XXXの元祖?。 コードスタイルの観点だけでなく、ありがちなミスの予防、パフォーマンス、設計観点のプラクティスが多いのが良い。

Effective Java

www.maruzen-publishing.co.jp

Effective C++Java版。 こちらもコードスタイル以外の観点でプラクティスを挙げてくれているのが良い。

Java言語で学ぶデザインパターン入門

www.hyuki.com

最初にデザパタを学んだ本。他のデザパタの本よりとっつきやすい。今もしばしば見る。

プログラミングGauche

www.oreilly.co.jp

Gauche関数型言語Schemeの処理系の一種。関数型言語に初めてにして唯一学んだもの。 Schemeに限らず、関数型言語を1つは体験しておくのは、おすすめできる。

数列の漸化式を立てるような感覚で、コーディングできるのは新鮮な体験だった。 マージソートC言語などで書くよりも簡潔に分かりやすく実装できる。 可変オブジェクトよりも不変オブジェクトを使った方が堅牢なつくりにできるというのもSchemeで学んだ。

この本読んでしばらくは、再帰関数で実装しないと気が済まない病ににかかっていたこと。 (関数型言語再帰処理に向けた最適化が行われているが、そうでない言語ではそうでないし、StackOverflowの問題がある)

CODE COMPLETE

shop.nikkeibp.co.jp

古典。いろいろなプラクティスを学んだ。 この本で紹介されていた、実装前に擬似コードを書くテクニックは今も使っている。

Pthreadsプログラミング

www.oreilly.co.jp

C言語のスレッドを扱うライブラリpTthreadsの本・ ライブラリ自体よりも並列処理の基礎的な考えやパターンを学べたのが良かった。

アルゴリズムクイックリファレンス

www.oreilly.co.jp

難易度が丁度良かった。「アルゴリズム入門」系の本よりは、種類も多いし、理屈の説明もしっかりしている気がする。 ダイクストラ法などの基礎的なグラフアルゴリズムは、この本で学んだ。

モダンC言語プログラミング

www.kadokawa.co.jp

「C言語でもオブジェクト指向できるから!」という本。 ボイラーコードを書くのが面倒なものの、確かにC言語でも普通にオブジェクト指向プログラミングできる。 「C++使えるけど、他の人達がC++覚えられないのでC使え!」という開発案件では世話になった。 (今になってみると、Cしか使えない人たち向けのソースなのに、オブジェクト指向使うのは嫌がらせ感あるw)

レガシーコード改善ガイド

www.shoeisha.co.jp

「テストがないコード = レガシーコード」という考えの本。 テスト可能な設計になっていない既存コードに、少しつづテスト追加 + リファクタリングをしていく手法が満載。 レガシーコードを題材にしたテスト駆動開発といった印象。 既存コードがテスト可能な設計になっていないので、「自動テスト書けません」、「いきなり理想形に作り直します」的な人に読んで欲しい本。

レガシーコードのメンテナンスばかりで鬱屈している人を励ます言葉が書かれており、そこには少し感動した。

レガシーコードからの脱却

www.oreilly.co.jp

「レガシーコードが生まれる仕組みが分かっていないのに、ソフトを作り直しても別のレガシーコードが生まれるだけだ」という主張には同意。 すぐに作り直す病がある人達に読んで欲しい本。

上の本はコード寄りだが、こちらは開発プロセス寄りの本。

集合知プログラミング

www.oreilly.co.jp

ベイズフィルタによる迷惑メールフィルタ、Webクローラーなどを実装していく本。 もう賞味期限切れだと思うが、発売当時は、機械学習がブームになる前でかなり面白かった。

設計系

ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本

www.shoeisha.co.jp

ドメイン駆動の話は読んだり聞いていて眠くなることが多いが、この本はそうではなく最後まで読めた。 これまで自分の仕事ではドメイン駆動関係なかったが、それでもレイヤーごとの責務の割り当て方はとても参考になった。 業務ルールをソースコードに反映させる部分の話がないので、この本のことだけ実践してもドメイン駆動設計にならないと思うが。

ユースケース駆動開発実践ガイド

www.shoeisha.co.jp

要求から実装に落とし込むまでのプロセスが生前としていると思った。 一番参考になったのは、要求からユースーケースを記述する方法。簡素で分かりやすいと思った。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

www.kadokawa.co.jp

いろいろな人が語っているので語ることのない本。

「1970年代だか1980年代のコンピュータエンジニアが現代にタイムスリップしても、すぐに適応できるだろう」という旨の部分はそうだと思った。 移り変わり早いように見えて、インターネットの普及、マシンリソースがリッチになったこと以外は、このころと根本は変わっていない気がする。

現実で、この玉葱の図の通りにレイヤーを分ける = クリーンアーキテクチャと言われると、疑問を感じることがある。

モノリスからマイクロサービスへ

www.oreilly.co.jp

既存サービスに劇的な影響を与えないで、逐次的にサービスを分解していく方法が書かれている本。 ただただ、感心した。根本的な考えは、既存ソースコードを捨てないでリファクタリングしていくのに似ている。 過去に「コード書くのが上手い人は、アーキテクトの資質がある」という主張を聞いたことがあるが、そのとおりだと思った。

開発プロセス

ソフトウェア見積り 人月の暗黙知を解き明かす

www.amazon.co.jp

いろいろな見積もり技法が載っている本。複数人見積もり、最悪・普通・最良の3点見積もりなど。

3点見積もりは手軽でおすすめできる。 なぜ、これが良いかというと、1点見積もりをすると、最良ケースで見積もりする傾向が多いから。

過去実績工数を使った単純な技法が、COCOMOのような数式を使った見積もり技法より劣るわけでないことを知れたのもよかった。 過去実績工数を使った見積もりは組織の文化やプロセスも暗黙のうちに考慮されるが、数式を使うタイプの技法はそうでないから。

他にも、完全にあてずっぽう見積もりよりも、何か仮定を起き、それが正しいとして定量的な見積もりを行う方が良いという話も良かった。

アジャイルサムライ

shop.ohmsha.co.jp

いろいろな人が語っているので語ることのない本。語り口が面白い。

カイゼン・ジャーニー

www.shoeisha.co.jp

SIerにいた頃に読んで、プロセス改善の行動を起こすことに勇気をくれた本。 基本は、スクラムの紹介が多い。カンバン、ドラッカー風エクササイズあたりはとても参考になった。

カンバン仕事術

www.oreilly.co.jp

カンバンの本。タスクボード ≠ カンバン。大まかには以下の流れ。スクラムよりもゆるくて良い。五月雨式に開発項目が降ってくる環境にも向いている。

  1. ボードと付箋を使って仕事を見えるか
  2. WIP(仕掛り作業の数の制限)を設定したり、ルールの調整
  3. 開発プロセスボトルネックを見つける
  4. 改善策を考える&実施
  5. サイクルタイム、リードタイムなどを見て効果があったか考える
  6. 1に戻る

SIerの頃、この本の影響で物理ボードを使っていたが、電子ボードよりすぐに見れるのがとても良かった(コロナのおかげで物理ボード使う機会は当面なさそうだが)。

教養

Unix/Linuxプログラミング理論と実践

asciimw.jp

雰囲気で使っていたUnix/Linuxのことが一段と深く理解できた。特にパイプやソケット。

C言語ポインタ完全制覇

gihyo.jp

ポインタについて、とても詳しいです(^q^)。C言語使っているなら、入門書の次に読むのおすすめ。 自分が読んだのは2006年度版だが、2017年に新しい版が出ている。

コンピュータの構成と設計

www.nikkeibp.co.jp

CPU + アセンブラ目線でのコンピュータの仕組みが分かる本。 これを読んでおくと、いろいろなことの理屈が想像できるようになる。 (具体的には、関数呼び出しが重いこと、プリミティブ型は参照ではなく値渡しの方が早いこと、割り算は遅い、バッファローオーバーフローの仕組みなど)

マスタリングTCP/IP 入門編

www.ohmsha.co.jp

TCP/IPプロトコルの解説本。 今どきスタンドアローンプログラムはなく、ほぼ通信する。であれば、どういう仕組みで通信が行われているのかは理解しておいて損はない。

リファクタリング・ウェットウェア

www.oreilly.co.jp

マインドマップの使い方、集中の仕方が参考になった。特にマインドマップを使う読書術。

オブジェクト指向UIデザイン──使いやすいソフトウェアの原理

gihyo.jp

書いてあることは目新しくないが、「オブジェクト指向デザイン」「タスク志向デザイン」という言葉を作ってくれたのが良かった。

  • オブジェクト志向デザイン
    • 操作対象を選ぶ -> 何か操作するという流れのUI
    • 概ねのソフトのUIはこれ
  • タスク志向デザイン
    • 操作する -> 操作する -> 操作するというUI
    • 最後になるまで実行結果が想像しづらいので、あまり良くない
    • 典型はインストールウィザード
    • あえてこれにする必要はない

ライト、ついてますか―問題発見の人間学

honto.jp

あるビルのエレベータが遅くて渋滞ができてしまう問題の解決方法がすごく良い。 エレベーターの基数を増やすわけでもなく、スピードを上げる訳でもない別の方法。 技術以外の解決方法を考えることも重要ということを実感。

ビジョナリー・カンパニー2 飛躍の法則

shop.nikkeibp.co.jp

劇的な飛躍を求めるのではなく改善のサイクルをこつこつ回していくことの重要さを教えてくれた。