バザーで失われた世代

「品質は、誰かが個人的に責任を負う場合にのみもたらされます。 」

-フレデリック・F・ブルックス







こんにちは、Habr！



Paul-Henning Kampのエッセイ「 Bazaarで失われた世代 」の無料翻訳に注目してください。これは、ドットコムブームの間に育ったIT専門家の世代の悲しい運命と、ソフトウェアの品質と移植性に直接影響するUNIXの根本的な問題を教えてくれます。 まず最初に。

大聖堂とバザール

彼のメモでは、著者はエリック・レイモンドのエッセイ「 The Cathedral and the Bazaar 」で説明されている大聖堂とバザールの比phorを使用していますが、エッセーの承認された翻訳のテキストからの抜粋を引用するのが適切であると思います：



---引用の始まり---



Linuxは素晴らしいシステムです。 数千人の開発者が世界中に散らばっていて、インターネットを通じてのみ協力することで、世界クラスのオペレーティングシステムを作成できると誰が考えたでしょう。 いずれにせよ、私はそうは思わなかった。 1993年初頭にLinuxが注目される頃には、約10年間UNIXとオープンソースソフトウェアの開発に携わってきました。



Linuxは、私が知っていることについて気が変わりました。 UNIX用の小さなツールを開発する際の主なものは、長年にわたる急速な設計と進化するプログラミングだと思いました。 同時に、開発の複雑さが増すにつれて、より集中化されたアプローチが必要になると考えました。 最も洗練されたソフトウェア（オペレーティングシステムやEmacsのようなすばらしいツールなど）を開発することは、大聖堂を建てるようなものであると信じていました。 このようなプログラムは、個別のマスターまたは厳密な隔離で動作するウィザードの小さなグループによって作成され、時期尚早なベータバージョンを防止する必要があります。



Linus Torvaldsの開発スタイル-リリースの頻繁なリリース、すべてのソーステキストの利用可能性、異種プログラムに対する耐性に非常に驚きました。 これは、大聖堂の測定された構造とはまったく異なります。Linuxコミュニティは、ノイズの多いバザールに似ており、さまざまなアプローチと方向を持っています。 このバザーで一貫した安定したオペレーティングシステムが生まれたという事実は、奇跡の奇跡のように思えます。

このバザースタイルがうまく機能し、うまく機能することにショックを受けました。 私は個々のプロジェクトの開発に参加しただけでなく、Linuxの世界で無秩序がないだけでなく、大聖堂の建築者がonly望するほどのスピードで前進している理由を理解しようとしました。



1996年半ばまでに、私は理解し始めたように思えました。 運命は私に私の理論をテストする絶好の機会を与えてくれました。 それは私が意図的にバザー形式で行ったオープンソースのソフトウェア開発プロジェクトでした。 このプロジェクトの成功はすべての期待を上回りました。



---引用終了---

---翻訳の開始---

はじめに

13年前に出版されたエリックレイモンドの本「大聖堂とバザール」は 、新しい用語で語彙を増やしました。 さらに、彼女は、フリーソフトウェアの普及運動のおかげで、 ソフトウェア開発のカスケードモデルの終了と大規模なソフトウェア企業の時代の衰退を予測しました。



本を読んだ後、私は何か考えることがありましたが、彼女は私を納得させませんでした。 一方、私はオープンソースソフトウェアの世界と直接関係しているため、何も手伝うことはできませんが、著者が正しければ素晴らしいことです。



この夏、海岸の私の家にあることが判明した別の本も、考えを刺激します。 それは明らかにレイモンドの本よりも深く（ところで、積極的にそれを指します）、これはフレデリック・P・ブルックスの「デザインのデザイン」です。 そして、私が何回も同意してうなずき、ブルックスの執筆スタイルと資料を提示する彼の能力を楽しんだ。

ドットコム時代

13年前、90年代のドットコム時代のクライマックスに到達したのは、すべての学校の学生がWebプログラマーであったか、すべての大学のドロップアウトがすでに自分のWebスタートアップを所有していたときでした。 自動展開スクリプト、バージョン管理システムなどの作成-これらのsalagsの基本的なプロフェッショナルスキルを教えようとしたとき、私は本当に喜びを得ました。 もちろん、懐かしさはあまり面白くありませんでした。

ドットコム時代全体がIT / CS業界全体、特にUNIXにとって真の災害だったことを否定することはできません。 ソフトウェア製品の品質が攻撃を受けました。



ドットコムの期間にIT業界がどれだけ成長したかについての正確な情報はありません。 私の個人的な評価では、表面化した職業の数を数えると、ニッチは2桁、つまり10,000％以上成長したということです。



コンピューターに夢中になるのは簡単です。ほとんどの人がボードを別のボードに釘付けできるのと同じように、ほとんどの人が作業プログラムで作業できます。 問題は、家庭用家具市場を考えた場合、そのような専門家に釘付けされていないボードの相互の割合が非常に小さいことです。 また、2つのボードから見栄えの良い椅子のセットまたは組み込みのワードローブに移動するには、才能、練習、教育が必要です。 同じもの（10,000％-100％）=追加のパーセントの9,900％は 、IT業界に参入したときに経験も教育も受けていません。 そして、彼らがそれを手に入れる機会を得る前に、パーティーは終わりました、そして、ほとんどは全く仕事なしで残されました。



私は慈悲を示し、その地位に固執した人々が間違いなく最も才能があり、最も熟練していることに注意しますが、この場合でも、人生経験の不足のためにITプロフェッショナルとして成功しなかったことは否定できません。



E.レイモンドが提唱したバザールスタイルは、ドットコム以前の優れた設計の大聖堂とは対照的に、「 ちょうど洗い流された 」、ドットコムの崩壊後も消えませんでした。残念ながら、今日でもUNIXは自重で沈んでいます。

Unix

ラップトップを更新しました。 過去18年間、FreeBSDの開発版を実行しており、ソースから最小限の作業環境を構築するのに1日かかります。これは、バザーとしてE.レイモンドと呼ばれるアナキストのゴミからロジックとアーキテクチャを構築しようとしているためです。



遠くから見ると、FreeBSD Ports Collectionは、FreeBSDユーザーが何かを見つけやすくするためのちょっとしたバザールカードのようです。 実際には、この「マップ」は現在、 22,198個のファイルで構成されており、バザー内の各テントの簡単な説明が記載されています。 また、テント内で見つかった各ソフトウェアをどうするかを指示する23,214個のmakefileがあります。 これらのメイクファイルは、考えられるシナリオ、さまざまなオプションオプション、およびそれらのデフォルト値を通知しようとします。 カードには、提案された手工芸品の湾曲を滑らかにする24,400パッチファイルが付属しています。 実際、これらのパッチのほとんどはソフトウェアの移植性の問題を修正するために使用されています。



最後に、このマップは、 www / firefoxをインストールする場合、まずdevel / nspr 、 security / nss 、 databases / sqlite3などをダウンロードする必要があることを教えてくれます 。 マップを使用してそれらを見つけ、依存関係を探し、依存関係の依存関係のリストを再帰的に取得すると、 www / firefoxを取得する前に間違いなく必要な122個のパッケージの購入リストを取得します。







私たちは皆、ソフトウェア開発に対するコンポーネント指向のアプローチが大好きです。 しかし、最も些細な場合でも、コードの再利用方法論はバザールとはまったく無関係です。FreeBSDポートコレクションのプログラムには、少なくとも1,342個のコピー/ペースト暗号化アルゴリズムが含まれています。



再利用方法論のそのような怠慢が自給自足の独立したソフトウェアパッケージのメカニズムの形で具体化された場合、コードの複製とパッケージ管理の容易さの間で妥協があります。 しかし、これは明らかに私たちの場合ではありません-パッケージは体系化されていない依存関係の絡み合ったウェブを形成し、コードのさらなる重複とリソースの浪費につながります。



皮肉な例です：Sam Lifferのgraphics / libtiffライブラリは、共通の依存関係チェーンにある122個のパッケージの1つであるwww / firefoxに向かっています。 ターゲットプログラム-Firefox Webブラウザ-はTIFF画像を表示できません 。 122個のパッケージのうち10個がPerlを必要とし、 7個がPythonを必要とする理由を見つけようとしませんでした。 そのうちの1つであるdevel / glib20には両方の言語が必要ですが、その理由は想像できません。



リストのさらに下の方には、ここにピーターの原則があります。これは、「階層システムでは、あらゆる従業員が無能のレベルまで上昇する」ように聞こえ、グローバルに次のように定式化することができます。災害を引き起こすでしょう。」 特別なケースがソフトウェアエンジニアリングで使用されます-「死にかけているプロジェクト。徐々に複雑になりすぎて、自社の開発者が理解できないようになっています」 ご覧のとおり、3つの異なるバージョンのmake、マクロプロセッサ（m4）、アセンブラ、およびその他の興味深いパッケージが必要です。 フードチェーンの最後には、いわば、 libtoolツールがあります。これは、UNIXには動的ライブラリ（ 共有ライブラリ ）を作成するための標準化された方法がないという事実を隠すように設計されています 。



すべてのnyxesに対してこのメ​​ソッドを標準化する代わりに（たとえば、 ld（1）コマンドの単一フラグとして実装する） 、Peter Principleの参加により、これは別のlibtoolコンピテンシーをもたらしました。 そしてこの場合、この原則は顕著にうまく適用されています-devel / libtoolのソースコードには414,740行が含まれています。 このコードの半分はテストであり、一般的に称賛に値しますが、実際にはピーター原則の結果にすぎません。テストは複雑なシステムの機能を巧みに調査し、発生してはならない問題を特定します。



さらに厄介なのは、これらのコード行のうち31,085行-configureと呼ばれる読みにくい不格好なシェルスクリプトです。 この設定スクリプトは、ユーザーがlibtoolを使用して手動で逆アセンブリする必要がないように、約200の自動テストを実行するという考え方です。 これは、ばかげた考えです。最初に登場した80年代に徹底的に批判されました。 これは、ソースコードが移植可能であると主張し、実際には高品質の移植性を提供する代わりに、ファサードとしてconfigureスクリプトの背後に隠れることを可能にするためです。

configureのアイデアが生き残ったのは馬鹿げています。



1980年には、24ビットポインターをサポートするCray-1 、 Amdahl UTS （IBMメインフレームのUNIX）、 ミニコンピューターメーカーの多能なSysV + BSD実装、 Data Generalのような企業のUNIXクラフトなど、いくつかのUNIX実装が見られました。 、本格的なUNIXクローンでさえあります-Mark Williamsの Coherentです。



当時のスクリプトは手作業で作成され、発見などのタスクを実行しました-これはBSDまたはSysVに似たUNIXであり、適切なMakefileと場合によっては.hを適切な場所にコピーします。 後にconfigureスクリプトがより野心的になりましたが、これはすでに遠くからPeter Principleの前例として認識できます。 しかし、UNIXを標準化してこれらのスクリプトの必要性を排除する代わりに、ある人はconfigureスクリプトを自動生成するautoconfプログラムを書きました。



IBM z / OSメインフレームのバージョンを考慮しても、今日のUNIX / Posixライクなシステムは、1980年のオブザーバーの観点からはほぼ同一です。 libtoolスクリプトの構成コードは、 <sys / stat.h>および<stdlib.h>を確認するために、 31,085行あります。それらが欠けていたニックにはlibtoolを実行するための十分なメモリがありませんでした。 ; または、 16 MBのlibtoolソースコードに適合するディスク容量。

これはどのように起こりましたか？

さて、誰も気にしない理由で、autoconfプログラムは前のマクロ言語m4で書かれていたので、テストが登場しました：







言うまでもなく、適切なプログラマーは、たとえスキルがあったとしても、これを自発的に掘り下げたくないので、これらのautoconfスクリプトは、コピーと貼り付けを使用して作成され、多くの場合、「標準テスト」上記の。

はい、 20年にわたって誰も経験したことのない互換性の問題をチェックするまさにそのテストです。



これはまた、libtoolがシステムに存在しない少なくとも26の異なるFortranコンパイラ名をチェックし、 26の存在しないコンパイラが-gフラグをサポートするかを調べるためにさらに26のテストを費やす理由を説明します。



これは、彼の本でレイモンドが賞賛したバザーの悲しい現実です。 「ITプロフェッショナル」と呼ばれる無知の世代によって際限なく沸き上がった、ハッキングによる腐った古い束。 あなたは彼らの耳で「ITアーキテクチャ！」と叫ぶことができますが、彼らはまだ聞きません。



今日は信じがたいですが、動きを妨げるこのゴミの下に、美しいUNIX大聖堂の廃thereがあります。それは、設計のシンプルさ、機能の適切さ、エレガントな実行で当然のことで有名です。



ブルックスの素晴らしいことわざの1つは、「品質は、誰かが個人的に責任を負う場合にのみもたらされる」というものです。 私は、ブルックスがUNIXをこの声明の例として引用していないことに驚いています。なぜなら、UNIXが断片化し始めた瞬間をほぼ外科的に正確に判断できるからです-90年代初期にAT＆T はUNIXを割り当て 、その権利をNovellに売却しましたその建築家のシステム。 （デニス・リッチーは、この取引をパン一forの魂の販売と比較しました-約翻訳者 ）。



最近、ブルックスと同じ結論に達した人もいます。 バザールの秩序と構造を回復することを望んで、ある種の正気を強要したり、技術基準の形で法を正式に定式化することさえ試みました。 バザールで失われたドットワンダーキンドの世代は大聖堂を見たことがないため、これらの大聖堂が必要な理由と理由を想像することさえできないため、すべての試みは見事に失敗しました。



もちろん、これは悲しい皮肉です。 BrooksのDesign of Designの専門家は、それが完全に理解不能であることを理解するでしょう。 まあ、少なくとも一度はm4マクロを使用してautoconfを構成し、Webブラウザーを構築するために26個のFortranコンパイラーをチェックするシェルスクリプトを生成することは、ややこしいことだと考えていた仲間にとって、ブルックスすべてを修正する機会があることを願っています。



---翻訳の終わり---

修正するチャンス

• 「Ubuntuは、サードパーティアプリケーションをインストールするための独自のパッケージ形式を開発しています」 。
• 記事「Qt Build System：Build Lifebuoy 」 -これを読むことをお勧めします。批判をするための多くの参考文献があります。QBSとの連携の良い例です。

UPD：翻訳を改善し、テキストの誤りを訂正するために、すべてのチャンネルでアドバイスを受けます。これを行うために時間を割いたすべての人々に感謝を表明します。 ありがとう

〜Xlab