技術書 Archive

フラストレーションたまったときは本を読むに限ります。
ジョエル・オン・ソフトウェア。ちょっと前に流行ったソフトウェア開発本。

具体的なことが多く書かれているので、色々な人が読める本です。

仕様書のテンプレートは有害である

遊び心に溢れた仕様書を提出してみましょう。責任は取りません(´ー｀)

どのような種類の職場内競争、どのような賞罰方式、あるいは「何かを正しくやっている人々を捕まえて報いる」という昔ながらのトリックでさえ、益よりも害の方が大きい

ほんと、表彰とか冷めますよね。何が嫌って周りの人への感謝とか、コメントが決められている感じ。

テスタとして優れた資質のある人間はテスタとして働きたがらない

ですよねー。最近はテスティングがビジネスになってるから多少は改善されてるのでしょうか。人海戦術でテストしてたらダメかー。オフショアは論外ですしね。

と、最後に。

下っ端でも何かを成し遂げる方法

何かを成し遂げられるようにガンバル（ρ＿； ）

Joel on Software

人月の神話。

1人なら100ヶ月かかるものも、10人なら10ヶ月、100人なら1ヶ月で完了する、という単純明快なシステム、それが人月。

「遅れているプロジェクトに人員を投入しても、さらに遅れるだけである」というソフトウェア開発の真理が書かれているのが本書です。

そして初版から30年以上経った今も人月なのです。だから「ソフトウェア工学のバイブル」と呼ばれている、とのこと。

正直、読みやすいとは思えないですが、読んでおかないと、な一冊。
読書会向きかな。

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

優れたプログラマ向けの書籍。

達人プログラマーと言っても、誰もが思いつかないようなひらめきでプログラミングをするような人ではありません。この本が目指す達人はとても現実的でスマートなものです。そして、プログラマの仕事はコーディングをすることだけではないことを再認識することができます。

プログラマとしてとりあえずでも読んでおくべきであることは間違いありません。
難解でもないので、プログラマーとして1,2年の経験があればよりよく吸収できるのではないでしょうか。
逆にマネージャ層には不向きでしょう。

残念ながら結合度やオーダといった基本的なところを押さえていないプログラマも意外に多いのです。
情報工学を修めていない方たちを採用したときに、このようなソフトウェア工学を研修カリキュラムに組み込んでいないところがほとんどでは？
情報処理試験でも範囲になってると思うのですが、理解しなくても合格できますからね…。

愚痴る以前に、こしあん自身を見直してみると、シェルを使いこなしていない、毎年1つ新しい言語を身につけていない、というのは耳が痛いところです。。。。（（ T＿T）
猛省します。

達人プログラマー―システム開発の職人から名匠への道

Eclipseのプラグイン開発本。

竹添さんのプラグイン開発の良書が出版された今でも読む価値のある書籍です。棲み分けがされているので竹添さんの書かれた本を読んだ後に読むと良いかと思います。

この本の優れたところは、プラグイン開発の具体的な実装方法ではなく、「他のプラグインのコードを真似ろ！」のようなプラグイン開発における心構えを学ぶことができる点です。
そして終盤にはEclipseの優れた設計が解説されています。この部分はかなり読み応えありです。

中級者向けで難易度は低くありませんが本気でプラグインを作ろうと思ったら必読の一冊です。

Eclipseプラグイン開発

「アジャイルやってます」って宣言しているわけではなくても、アジャイルなプラクティスを取り入れていることもあるわけで。

評判がよく、読んでみたいと思いつつもなかなか機会がなかったこの本をようやく読んでみました。
持ち運びしやすい厚さ、2,3日もあれば読める量ですが、内容はとても濃いです。
日々の実作業でありがちな悪魔の囁き、それに対するプラクティスが紹介されています。
アジャイルって敷居が高いと思っているリーダーさんや、日々のスキルアップを目指すメンバさんにもお勧め。
さらには普段、技術書を読まない方々にも読んでもらいたいです。

紹介されているスタンドアップミーティングなどは明日からでも実践できますよね。
“アジャイル”って単語を使わなければ、それほど拒否反応も出ないでしょう。

そしてアジャイルなメンバ、チームに変わってきたら他のプラクティスも取り入れていくとよいのではないでしょうか。

お値段は高く感じますが、それだけの価値はあります。
会社に買ってもらいましょう！

それにしてもコードレビュー。これほど素晴らしいものはないと思うのですが、どうしてあまり取り入れられてないのでしょう…。指摘するのも、指摘してもらうのも、もの凄く勉強になるし、品質改善になると思うのですけど。

コードを読んだり検閲するという方法はまだ一般に知れわたってはいないかもしれないが、やってみればこの方法が、ソフトウェアの質を向上させるのに一番簡単で安価な方法だということに気付くはずである。
開発者を鍛えるコードのレビュー

嫌がる人もいることは事実ですからね。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣