ソフトウェア,コードレビューの本、入門書、技術書、専門書の紹介,評価,安売り価格

優れたコードを書く切欠を与えてくれる本　評価：

この本は本当に「読み易く」「面白い」本だった。
本書は名前もさることながら、目的も“本書の目的は、読みやすいコードを書くことである。
”という具合に非常に「読み易い(理解し易い)」ものだ。
また、本の中に1～2週間程度で読んで欲しいと書かれていたが、届いてから4日、月曜日と水曜日は勉強会と懇親会に参加したので実質2日で最後まで読む事ができた。
というか気になってしまって読み切ってしまったというのが正しいだろう。
自分もエンジニアの端くれとして、幾つかの原則に従ってコードを書いてきた。
それは「グローバル変数は悪だ」、「短いことは良いことだ」、「コメントは分かる様に書く」等々。

内容紹介　

「美しいコードを見ると感動する。
優れたコードは見た瞬間に何をしているかが伝わってくる。
そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。
本書の目的は、君のコードを良くすることだ」(本書「はじめに」より)。
コードは理解しやすくなければならない。
本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。
名前の付け方、コメントの書き方など表面上の改善について。
コードを動かすための制御フロー、論理式、変数などループとロジックについて。
またコードを再構成するための方法。

内容（「BOOK」データベースより）　

コードは理解しやすくなければならない。
本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介する。
名前の付け方、コメントの書き方など表面上の改善について。
コードを動かすための制御フロー、論理式、変数などループとロジックについて。
またコードを再構成するための方法。
さらにテストの書き方などについて、楽しいイラストと共に説明する。
日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。

個人的には良書だと思う　評価：

初学者が次のステップを目指す為に「どういったものがこの先にあるのか」を示す俯瞰図として。
または、中級者・上級者が自分のプログラミング技能の棚卸しをする為の俯瞰図として。
この２点において、「広く浅く」という構成は非常に良いアプローチだったと考えます。

対象読者がわからない　評価：

目次を見るとユニットテストやメタプログラミングなど、興味深いものだったし、ページをぱらぱらめくってもサンプルコードもあって「これは良いのでは？」と思い購入。
期待して読み始めたが、あまりにも薄く広くで、いったい誰の役に立つのか不明だった。
またサンプルに扱っている題材などから察するに、読み手にJavaでのある程度の業務経験を想定しているようだが、そのわりに変数の種類（グローバル変数やクラス変数など）などの説明にページを割いていたり、ターゲットも不明瞭。

入門書としては完璧！　評価：

これまでは「継続的インテグレーション(CI)って、こ〜んな感じ」と何となく分かっていたつもりでしたが、この本を読んでCIの目的やすべきことが明確に見えた気がします。
著者の方々は彼ら自身の豊富な経験から得られたCI全般に関する知識を、浅すぎず深すぎず、非常にいいバランスで一冊の本にまとめてくれています。
有償無償を問わず、CIで使えるツールもたくさん載っているので、この本があればGoogleであちこち探しまくる労力をかなり減らせるはずです(ちなみに執筆当時はフリーだったと思われるツールが現在はシェアウェアになっているものをいくつか見つけました・・・)。

レビューに特化した珍しい本　評価：

業務改善のため取り組みやすく、成果の出そうなこと何かないかな と思ったのがレビューの改善でした。
レビューて簡単に言うけど、よく知らないなということで購入。
レビューの種類から方法、注意点などなどよくまとまってます。
レビュー観点なども、よく陥りがちな偏った視点などについても 書かれてあり、気づきを得ることができました。
前半はレビュー基礎知識、後半はレビュー結果の分析、データを利用した改善となっており幅広く使えそう。

仕様書を何のためにかくのかを解らずに書く人に驚き　評価：

仕様書を何のためにかくのかを解らずに書く人がいることに驚いたことがあります。
自分が作るものを明確にするために書くのであって、他人のために書くのではないという意識が持てないのなら、書かない方がいいかもしれません。
プログラミング言語で書いた仕様書を認めない人もいますが、それはその人がプログラミング言語で書いたものを、他の言語で書き直して確認したいからだとしたら、その人に書いてもらうのも手かもしれません。
仕様書の欠陥を見つけるには、何を作りたいかを明確にしていくことになるので、嬉しいと思います。
ただし、完璧な仕様書を作ってからプログラミング始めるのがいい場合と、手遅れの場合とがあることは、、、、

プログラミング技術の全てが詰まっています。　評価：

この本は、正にプログラマの聖書と読んもいい代物です。
開発言語、ジャンル等を問わずに幅広く通用し、 経験が、浅いプログラマをより高い位置へと導いてくれる本だと思います。
はじめは、自分の書くコードに対して、「本当にこの作り方で正しいのか？」と、 思いながら、何とかしたいという思いでした。
他人の書くコードもヒントにはなるかも知れません。
ただ、それは全てが全て正解ではなく、 この本には、それを解決する全てが詰まっていると思います。
上巻で約500ページにわたる本ですが、読み進める度に次々に技術の発見があり、 改めて自分が無知だということに気付かされた一冊です。

10年分のスキルアップ　評価：

名著です。
経験だけで身に付けようとすると軽く10年はかかりそうなノウハウがこの一冊に詰まっています。
この業界に入ってから2〜3年目にこの本を読みましたが、この本を読んで以来、自分の書くプログラムの品質は明らかに上がったと思いますし、他の人が書いたプログラムの良し悪しも判断できるようになりました。
また、非常に豊富な参考文献リストも素晴らしいです。
このリストを利用して自分の役に立ちそうな他の書籍を読み、またそこから他の書籍へ・・・と「書籍サーフィン」が出来るリンク集になっています。
本の値段や分厚さは関係ありません。
エンジニアならMUSTです。

検査といえば普及したと思う　評価：

検査といわれればするのに、インスペクションといわれた途端にやる気がなくなる現場がある。
なぜかはわからない。
自己査定は許容水準だった。
自分では、この点よりよくするつもりはありません。
これ以上やると無駄が増え、改善を阻害しそうだと感じるからです。
大規模組織で、大規模開発の場合と、小規模組織で、小規模開発の場合での違いがあるかどうかが課題だと考えています。
以下は自己査定の回答例です。
(1)　通常する （２）通常する （３）ときどき （４）通常する （５）ときどき （６）ときどき （７）通常する （８）ときどき （９）通常する

理論的基礎を築くには良い　評価：

インスペクションとは上流工程からの成果物(機能仕様書、テスト仕様書など）に対して一定の判定基準を元に内容を精査するプロセスのことです。
ソフトウェア開発プロセスの品質改善とプロセス自体の改善を目指したものであり、そのために本書ではデータの収集と分析を非常に重んじています。
どちらかといえば形式的なところを重んじていますが、それによる問題も同時に取り上げています。
正直な感想としては、内容に重量級のボリュームがあり、すぐに実践できるかというと、「それは無理」と感じます。
何度か実経験を踏んだ上で、さらに何をどうしたらよいか考える再に、非常に示唆に富んだ提言がかかれていると思いました。