「リファクタリング」を読んだ

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

PofEAAと同じMartin Fowlerの本。PofEAAとは打って変わってすらすら読める内容。
リファクタリングの趣旨等と、リファクタリング手法のカタログから成る。
理屈として難しい本ではなく、カタログの内容は目新しいものではないが、再認識することが重要な気がする。
多少古い本だが内容もほぼ錆びておらず読む意味のある本だと思う。

「人月の神話」を読んだ

人月の神話【新装版】

人月の神話【新装版】

最近古典に目を通そうと思って手をつけた本の1つ。非常に有名な本の内容について、伝聞でしか知らず真意を誤解している事というのが結構ある。
この本だと「セカンドシステム症候群」がそうで、単純に二度目の実装に時間をかけすぎる事というのが伝聞での理解だったが、むしろプロトタイピングは推奨されていて、製品として世に出た物の中で開発者にとって二回目の物がセカンドシステムの定義である。また、セカンドシステム症候群の製品は失敗した製品群という訳ではなく、例えばWindows NTなどもセカンドシステムに入るらしい。
主としてソフトウェア開発におけるマネジメントがテーマの本だが、ソフトウェアエンジニアとして働き始めて1年経ったので、自分に当てはめて考える事もできて、これは大学時代などに読むより良かったと思う。

「暗号技術入門」を読んだ

暗号技術入門 第3版

暗号技術入門 第3版

より本格的な本に手を付ける足がかりとして読もうと思った本。難しい本ではないが、結構知らない話も多かった。

「テスト駆動開発」を読んだ

テスト駆動開発

テスト駆動開発

これも明らかにもっと早く読めばよかった本。と思ったが新訳は2017年刊なのでそれは当てはまらないか。
テスト駆動開発は概念としてはポピュラーなので聞き伝えの知識でまあまあ知っているつもりだったが、しっかりと原典を当たるべきだという事がよく分かった。
PofEAAより読んでいて遥かに楽しかった。

「エンタープライズ アプリケーションアーキテクチャパターン」を読んだ

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

PofEAAという略称で知られる結構有名な本だと思う。例えばRailsのActive Recordなどはこの本がおそらく元ネタ。

原著は2002年の本で、歴史的には意義のある本なのだろうけど、正直読むのが結構苦痛だった。EJBとか知らんし…

苦痛だった理由としては、現代ではフレームワークがよりきれいな形で解いていて、わざわざ自力で解く必要のない事柄についての議論が多かったり、さらには現代ではバッドプラクティスだとみなされている内容が推奨されていたりなどが挙げられると思う。

全体的な問題点としてはデザインパターンと言う割には紹介されるパターンが特定の問題や下手するとフレームワークにくっつきすぎている点があると思う。

影響力のあった本なのは確かなので昔の話が好きな人は読んで見るといいかもしれないが、あまり人に勧めたい感じではない。以前は昔話は結構好きだったので自分も心の余裕がなくなってきているのかもしれないが…

作者のホームページに2006年から書きかけで放置されいている続編の原稿がありむしろこちらのほうが現代でもよく聞く項目・デザインパターン名が多い気がする。MVCの項目などは特に有用かもしれない。ただ一向に続編が出版されない理由の一因は前編が錆びてしまったからという可能性はある…

「アジャイルサムライ」を読んだ

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

ふとこの手の本全然読んできてなかったけど、大昔はこういうの読むの好きだったよなと思って買って読んだ。今読むとなんとなく仕事との関連もあってもっと面白いが、同時にこの本すごいSIer臭いなという事に気がついた(米系とは言え自分の居る所とは極めて空気が違いそうな雰囲気)。なんとなくアジャイル≒Web系みたいなイメージを持っていたけど(半分はRailsの某書籍のタイトルのせいだと思うが)、ThoughtWorks自体も言うなればSIerだし、「日本のSIerガラパゴス」自体言い過ぎなんだなあみたいな、気がついたらアジャイルとあんまり関係ないことについて考える結果となった。軽い読み物だと思う。

同時にこの人のQuoraの回答も面白かった。要約すると、アジャイルがそのままの形で適用しやすいのは、わかりやすい機能がたくさん存在して、明確な外部の発注者が居るプロジェクトで、逆に、シンプルなインターフェイスで内部が複雑なタイプのソフトウェアプロジェクトにはそのまま当てはめづらいとのこと。