プログラミングの6大10項目リスト

Jeff Atwood / 青木靖 訳
2007年3月22日

以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。
[ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。]

ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣

1. 自分が誤りを犯すということを理解し、受け入れること 。
2. 自分と自分のコードは別物である。
3. どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。
4. 相談せずにコードの書き直 しをしない。
5. 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。
6. 世界で唯一変わらないのは変わるということだけ。
7. 唯一本当の権威は、地位ではなく知識より生ずる。
8. 自分で正しいと思うことのために戦うこと。しかし負けは潔く認めること。
9. ｢部屋に籠りきりのやつ｣にはなるな 。
10. 人ではなくコードを批判すること——コーダーには優しく、コードには厳しく。

デア・オバサンジョの｢ソフトウェアプロジェクト失敗の10の兆候｣

1. 最初のバージョンであまりに多くのことをやろうとする。
2. 確立されていないテクノロジーに大きく依存している。
3. 稼ぎ頭だったり強力な後ろ盾を持っていたりする別な社内プロジェクトと競合している。
4. チームが人員不足。
5. ｢複雑な問題には複雑な解法が必要｣
   [ 複雑さ自体がプロジェクトのゴールになる。]
6. スケジュールチキン
   [ 悪いニュースを伝えることを恐れる。]
7. スコープクリープ
   [ スケジュールは変わらずに要件が膨らんでいく。]
8. 第2のシステムシンドローム
   [ 比較的小さい成功したシステムの後継システムが、機能満載の肥大化したシステムになる傾向があること。]
9. 参入戦略がない。
10. 解き方を知らない問題に取り組んでいる。

オマル・シャヒーンの｢Microsoftで(あるいはその他のどこであれ)働くための10のヒント｣

1. プロセスは思考の代用にはならない。
2. オフィスにばかりいないこと。
3. 自分の製品を使うこと(あなたの顧客が使うように)。
4. 何かが壊れていたら不平を垂れるのではなく、直すこと。行動は不平よりも雄弁だ。
5. 難しい問題を簡単に見えるようにすること。簡単な問題を難しく見えるようにしないこと。
6. 仕事や相手に応じて適切なコミュニケーション手段を使うこと。
7. 誤りから学ぶこと。
8. ものごとをシンプルに保つこと。
9. 常に価値を付け加えること。
10. 他の人の製品も使ってみること。

マイケル・マクドナーの｢デザイン学校では決して教えてくれない10のこと｣

1. 才能が成功に占めるのは1/3でしかない。
2. どんなクリエイティブな仕事でも95%はクソみたいな作業だ。
3. すべてが同じように重要であるというのは、すごく重要なものがないということだ。
4. 1つの問題について考えすぎないこと。
   [デザイナというのは偏執的だ。十分なものになったところで先に進むこと。]
5. わかることから始めて、わからない部分を潰していくこと。
6. 目標を見失わないこと。
7. 幅をきかせすぎると、バランスを失う。
   [ 自信を持ちすぎるのは自信がないのと同様に有害である。問題には謙虚に対すること。]
8. 地獄への道は善意で舗装されている。あるいは、偉業を罰せられずに進めることはできない。
   [  世界は平均的で予測可能なものでできており、すばらしいアイデアは挑戦を受けることになる。]
9. アウトプットがすべて。
10. 世界の残りの部分が重要。
    [ 自分の仕事が意味を持つのも他の人たちあってのこと。]

アンドレス・テイラーの｢10年のソフトウェア開発が教えてくれた10のこと｣

1. オブジェクト指向は思っているより難しい。
2. ソフトウェア開発で難しい部分はコミュニケーションである。
3. NOと言えるようになろう。
4. すべてが同じように重要なら、重要なものはないということだ。
5. 1つの問題を考えすぎないこと。
   [ 悪魔は細部に宿るが、悪魔払いの方法は理論ではなく、実装することだ。]
6. 何かに本当に深く潜り込むこと。ただし時間を取られすぎないこと。
   [ 深遠で興味深い事であっても、実際使う場がないことも多い。]
7. ソフトウェア開発組織の別な部分について学ぶこと。
8. 同僚は最良の教師だ。
   [ 同僚を競争相手としてではなく、資産として見ること。]
9. 動くソフトウェアがすべて。
10. どうしようもないやつらもいる。

スティーブ・イエギの｢偉大なる10冊｣

1. The Pragmatic Programmer: From Journeyman to Master
   [ 達人プログラマー―システム開発の職人から名匠への道  ]
2. Refactoring: Improving the Design of Existing Code
   [ リファクタリング―プログラムの体質改善テクニック ]
3. Design Patterns
   [ オブジェクト指向における再利用のためのデザインパターン ]
4. Concurrent Programming in Java: Design Principles and Pattern (2nd Edition)
   [ Javaスレッドプログラミング―並列オブジェクト指向プログラミングの設計原理 ]
5. Mastering Regular Expressions, 2nd Edition
   [ 詳説 正規表現 第2版 ]
6. The Algorithm Design Manual
7. The C Programming Language, Second Edition
   [ プログラミング言語C ]
8. The Little Schemer
   [ Scheme手習い―直感で学ぶLisp ]
9. Compilers
   [ コンパイラ―原理・技法・ツール <1> <2> ]
10. WikiWikiWeb

明らかにプログラマではなくデザイナである人物の10項目リストを含めていることを妙に思っている人もいるかもしれない。私は次のジョーイ・デビラの考えと同意見だ。

ソフトウェア開発はエンジニアリングの近い親戚であり(エンジニアリングの原則自体はそうでないにしても)、数学や科学にクリエイティビティをブレンドしたものだ。それがクリエイティブな人たちのアドバイスの多くがソフトウェア開発にも適用できる理由なのだ。

それから私の推薦図書リストとスティーブ・イエギのリストを比較してみるのも面白いかもしれない。私のリストに｢リファクタリング｣と｢デザインパターン｣が入っていないのには理由がある。そしてスティーブのリストに｢コードコンプリート｣が入っていないのにもきっと理由があるのだろうと思う。