Eric S.Raymond 「伽藍とバザール」 19の指摘（訓示）

「オープンソースプロジェクトの管理と運営」という本を読んでいたときに、 OSF(Open Source Initiative)の生みの親である Eric S.Raymond が書いたオープンソースのソフトウェア開発に関する論文 「伽藍とバザール (The Cathedral and the Bazaar)」[1999年 O'Reilly & Associates 出版]  （原文）での指摘19点がまとめられていた。
どれもとても共感できる内容なのでメモ。

1. すべての優れたソフトウェアは、開発者の必要性から始まる
2. 優秀なプログラマは何を書けばよいのかを知り、偉大なプログラマは何を書き直せば（再利用すれば）よいのかを知っている
3. 「捨てるつもりで書きなさい。どうせ捨てることになるのだから」 (Fred Brooks 「The Mythical Man-Month （人月の神話）」 第11章
4. 態度がよければ、面白い問題が寄ってくる
5. あるプログラムに興味を失ったら、それを有能な後継者に託すことが最後の義務である
6. ユーザを共同開発者として遇することが、コードのすみやかな改良と効果的なデバッグのための早道である
7. 早期に、かつ頻繁にリリースし、顧客の意見に耳を傾けよ
8. 十分な数のベータテスタと共同開発者がいれば、ほとんどの問題は、すぐに原因が明らかになり、修正方法が自明のことになる
9. 優れたデータ構造と凡庸（ぼんよう）なコードは、その逆の組み合わせよりずっとうまくいく
10. ベータテスタを最も貴重な資源として遇すれば、最も貴重な資源になって応えてもらえる
11. 優れたアイデアが浮かばないときは、ユーザの優れたアイデアをもらうことが次善の策である。ときには、後者のほうが優れていることもある
12. 最も斬新で衝撃的なソリューションは、問題のとらえ方が間違っていることに気づいたときに生まれることが少なくない
13. （設計における）完璧さとは、もう追加するものがない状態ではなく、もう取り去るものがない状態である
14. どんなツールも期待された場面で力を発揮するが、真に偉大なツールは予想もされなかった場面で力を発揮する
15. いかなる種類のゲートウェイソフトウェアを書くときも、できるだけデータストリームを乱さないように注意せよ。受信者に強制されない限り、絶対に情報を捨ててはならない
16. 言語がチューリング的完璧にほど遠いときは、構文的砂糖（糖衣構文、シンタックスシュガー）をまぶすと救われることがある
17. セキュリティシステムの堅固さは、守るべき秘密の堅固さを上回らない。擬似秘密に用心せよ。
18. 面白い問題を解決するには、面白いと思える問題を探すことから始めよ
19. 少なくともインターネット程度には優れた媒体があり、強制によらずに指導することを知っている開発調整者がいるなら、頭数は少ないより多いほうがよい

No.13, 14 あたりはとくに納得。でも実践はできていない・・・
本はまだ読みかけなので、感想などはまた後日。

ブログはじめました

エンジニアという職業柄、ほぼ毎日のようにいろいろな問題にハマってる。そんな時、先人のブログにはいつも大変お世話になっている。
少なからず自分も問題解決はしているので、まずは自分のための健忘録として、そしていつも自分がお世話になっているように、自分の情報が誰かの役に立つことでもあれば、とブログをはじめてみることにした。
技術系の内容を中心に、思いのままにその他の趣味やいろいろなつぶやきなども投稿してみよう。

とはいえ、もともと読むのも書くのもとっても遅く、かなりの筆不精な性格。投稿頻度がものすごく低くなることは目に見えているのだが、どうなることやら・・・