バザール方式の教訓

ウィキペディア小見出し辞書

バザール方式の教訓

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/02/10 01:06 UTC 版)

「伽藍とバザール」の記事における「バザール方式の教訓」の解説

さまざまなソフトウェア開発の取り組みから学んだバザール方式の19の教訓を挙げ、それぞれがオープンソースソフトウェア開発における優れた開発手法に関する題目を述べている。 全ての良いソフトウェアは開発者の個人的な希望から始まる。 良いプログラマは何を書けば良いか知っている。凄いプログラマは何を書き直せば・何を再利用すれば良いか知っている。 破棄する計画を立てる。いずれにせよ、そうすることになる。 適切な取り組みをしていれば、おかしな問題は自発的に主張してくる。 ソフトウェアに興味がなくなった時には、ソフトウェアを手放して優秀な後継者に引き継ぎする。 利用者を共同開発者として扱うことは迅速な実装改善と効率的なデバッグの最短ルートである。 素早く頻繁なリリース（英語版）を実施し、顧客の話を聞く。 十分なベータテスターと共同開発者の基盤があれば、大半の問題はすぐに特定されて誰かが直す。 賢いデータ構造と愚かなソースコードは、その逆であるよりずっと良い成果を出す。 あなたがベータテスターを最も有益な資産として扱うなら、彼らは最も有益な資産となり応えてくれる。 次の最適案は利用者による良いアイディアに気付かされる。後から出たアイディアの方が良いこともある。 大半の衝撃的で革新的な解決策は自身の問題の捉え方が間違っていることに気付くことから始まる。 完璧な設計はそれ以上の追加することがなくなった時ではなく、それ以上の削減することがなくなった時である。 全てのツールは想像通りに便利であるべきであるが、本当に凄いツールは作者の想像を越えた便利さを与える。 どんなゲートウェイソフトウェアを実装する場合でも、データストリームへの影響は可能な限り最小限に抑え、受け手が強制しない限りはデータを決して破棄しない。 自分の書き方がチューリング完全から外れているなら、シンタックス・シュガーは手助けになる。 セキュリティシステムのセキュリティはそれが秘密である時だけ意味を成す。見掛けのセキュリティには注意すること。 おかしな問題を解決することは、おかしな問題を探すことから始まる。 開発コーディネーターが少なくともインターネットと同等に良質な交流手段を持って圧力をかけない先導手法を知っているなら、必然的に頭数は多い方が良い。