BEST SOFTWARE WRITING

この記事は約 8 分で読めます。

BEST SOFTWARE WRITING (2008/02/21) 不明商品詳細を見る

編集は、Joel・Spolsky氏です。
この方、世界的に認知されているソフトウェア開発プロセスのエキスパートです。
彼のWebサイト「Joel on Software」は、世界中のソフトウェア開発者に人気があり、30以上の言語に翻訳されているとのこと。
すみません。何となく、名前は聞いたことがありますが、よく知りませんでした。

本書は、16人の開発者によるエッセイが掲載されています。
著者のブログに掲載された記事や、セミナー等で発表された内容だったりとJoel氏お薦めのエッセイが集められています。
気軽に読める感じの本です。
面白いなと思ったエッセイをいくつかご紹介します。

「スタイルは内容である」 ケン・アーノルド
プログラミング言語のコーディングスタイルについてに書かれています。
著者は、ANSI Cでコーディングスタイルを言語文法として定義してしまえといいます。
コーディングスタイルに沿っていなければ、コンパイルでエラーにしてしまえということです。
これによって得られる恩恵は大きいと言います。
コーディングスタイルについてはずっと議論されていますが、確かに言語文法として定義してしまえばすべてのコードのスタイルが統一されるし、読むのも書くのも余計なこと考えなくて楽チン出し、良いこと尽くめだと思います。
だけど、今度は言語文法としてのコーディングスタイルをどれにするかっていう議論が発生しますよねー。
結局、ちょっと前に進んだ様に見えて結局進んでないってことになりますよね。
難しいですねぇ。
アイデアは良いと思いますけどね。
まあ、こんなこと考えている人いっぱい居そうですが。

「プログラマのアウトソーシングの落とし穴」 マイケル・ビーン
プログラミングをアウトソーシング（外注）に出すことによる弊害のお話です。
内容は、激しく同感です。
実際、私の部署は開発を基本アウトソーシングしていません。
社内では異質な部署になっていますね。
特にうちの部署でしょってるパッケージのコアの部分は絶対に外に出さないですね。
まあ、それを売りにしているところもあってそうなっています。
だから、ココに書かれているメリットは、実際に体験しています。

「強い型付け vs. 強いテスト」 ブルース・エッケル
ココに書かれていることは、仕事としては経験してたけど、こういう風には考えていなかったと感心しました。
内容は、変数の型定義について、言語によって強い型定義する必要があるもの（たとえばC言語とか）とバリアント型で済んじゃうもの（たとえばPythonとか）がありますよね。
賛否両論ですが、その型定義について強い方が良いと主張する人がいるが、強い型定義にはメリットはないと著者は言います。
なぜかというと、強い型定義で変数の型によるバグをコンパイルエラーで見つけたところで、そのコードの品質は上がらない。
品質を確保するには、結局、テストするしかないからだと言います。
それも強いテストを行うしかないからだと言います。
だから、コーディング時に余計な型定義によってコーディング時間を無駄にするなら、強い型定義はない方が良いと言います。
品質を確保するには強いテストをするしかないというのは同感です。
しかし、強い型定義までは考えが及びませんでしたねぇ。
素晴らしい洞察です。

「すごいハッカーとは」 ポール・グレアム
タイトルの通り、すごいハッカーとはこういう人ということが書かれています。
コレを読んで、ちょっぴり悲しいですが、私はすごいハッカーでは無いなと断定しました。
自分的に満たせなかった条件は以下の通りです。

何かで優れている人というのは、自分が優れていると思うよりは、他の連中がどうしてそんなに無能なのか不思議に思っているものだ。

 う～ん、私はあまりそう言う風に思ってないですねぇ。
他の連中よりも、努力したから優れているんだと思ってますね。

「チームへの報奨」 メアリー・ポッペンディーク
すごい良い結果を出したチームに対しての報奨について書かれています。
どういう話かというと、能力給のために人々をランク付けするのは間違いだというお話。
すごい良い結果を出したチームの中でメンバのランク付けをすることは間違っている。
メンバのチームワークによって得られた成果なのにメンバごとの甲乙は付けられない。
すべてのメンバに成果に対する対価を支払うべきだということです。
確かに同感。
うちの会社も学校と一緒でクラス全員の成績を平均すると3にならないといけないので、クラス全員が学年の上位成績者で構成されていても、5が付く人がいると1か2が付けられる人を必ず作らないといけないという理不尽な査定方法が取られています。
確かに、部署ごとの予算が決まっているのだから、その中に収まるように給料を支払わなければいけないのだから多い人がいれば少ない人がいるのはわかりますが、その分儲かったんなら、一時的にでも予算枠を拡大してその対価を支払えと思いますね。
なかなか難しいとは思いますが。
でも、メンバのモチベーションに関わるのだから頑張ってほしいものです。

最後に目次をお知らせ。

---

スタイルは内容である
最もおバカなユーザインタフェース賞:Windows検索
プログラマのアウトソーシングの落とし穴
データベースとしてのExcel
ICSOC04講演
自閉的ソーシャルソフトウェア
なぜ、アンドキュメンテッドな振る舞いに依存するアプリケーションを単に締め出さないのか?
ラマを蹴っ飛ばす
カナダのインターネットをWIPOから救え
EA:人間の物語
強い型付け vs. 強いテスト
Processingのプロセシング
すごいハッカーとは
ロケーションフィールドは
新しいコマンドラインである
スターバックスは2フェーズコミットを使わない
情熱
C++ － 忘れられたトロイの木馬
電球を変えるのにMicrosoft社員は何人必要か？
ハマったときにどうするか
ラリーのソフトウェアエンジニアリングの法則第2番：テストメトリクスでテスタを測定することはできない
チームへの報奨
MAC WORD 6.0
グループにとっての最悪の敵は自分自身である
ユーザとしてのグループ：フレーミングとソーシャルソフトウェアのデザイン
ギャップを埋める パート1
ギャップを埋める パート2
採用の危険
PowerPointリミックス
（マンガのキツネと学ぶ）短時間の（そして願わくは辛くない）Rubyコース

---

評価：★★★★☆

•