この考えをよりよく示すために、私はダーウィンの本から段落を取り、生物学的用語を開発世界からの用語に置き換えました。提案自体はオリジナルのままでした。言語は少し具体的ですが、一般的には理解できると思います。
第V章変化の法則。短いレビュー
変化の法則に対する私たちの無知は深いです。 100のケースのいずれにおいても、この機能またはその機能が変更された理由を特定することはできません。しかし、比較の手段があるすべての場合において、同じコンポーネントの品種間の小さな違いの形成は、同じライブラリのコンポーネント間の大きな違いと同じ法則の作用によって引き起こされることがわかります。条件の変化は通常、変動する変動のみを生み出しますが、直接かつ明確な結果につながることもあります。これを裏付ける十分な証拠はまだありませんが、これらの結果は時間の経過とともにより顕著になる可能性があります。多くの場合、その劣化と減少における習慣-憲法上の特徴の形成、使用-機能の改善と不使用-は、その行動において強力であるように思われます。
同種の部分は同じように変化する傾向があり、互いに結合する傾向があります。フロントエンドの一部を変更すると、内部構造の一部に影響します。ある特定の部分が強力に開発されると、隣接する部分から開発リソースが流用される可能性があり、損傷することなく削除できるアプリケーション構造の部分が削除されます。幼い頃の構造変化は、後で発達する部分に影響を与える可能性があります。間違いなく、相関的な変動の多くのケースがあり、その性質は理解できません。反復するパーツは、数と構造の両方で可変であり、これはおそらく、特定の機能に対するそのようなパーツの厳密な特殊化の欠如に起因するため、自然な選択がそれらの変更を妨げませんでした。同じ理由の結果は、おそらく、ソフトウェア製品の成熟度の低い段階にあるソフトウェア製品は、アプリケーション構造全体がより専門化されている高レベルの製品よりも変更可能であるという事実です。機能は初歩的で役に立たず、自然な選択の対象ではないため、変更可能です。コンポーネント属性、つまりあるライブラリのコンポーネントが共通の祖先から分岐したときとは異なり始めた特性は、ライブラリの特性、つまり、長い間継承され、指定された期間中に違いが生じなかった特性よりも変動します。これらの発言では、特別な機能や部品を扱ってきましたが、最近では変化しているため、変化しているため、変更可能です。しかし第II章で私達は見ました同じ原則がプロジェクト全体に適用されること。
特定のライブラリの多くのコンポーネントを含む領域、つまり、大幅な変更と差別化が最近行われた領域、または新しい形式のコンポーネントの作成が活発に進んでいる領域では、そのような領域とそのようなコンポーネントで、平均して最大数がまだ見つかっていることを確認しました。品種。関数の署名は非常に不安定です。それらは同じグループのコンポーネント間で大きく異なります。アプリケーション構造の同じ部分の可変性は、通常、同じコンポーネントの2つの通信プロトコル間で関数シグネチャを生成する場合と、同じライブラリのコンポーネント間でコンポーネントの違いを形成する場合の両方に役立ちました。関連するコンポーネントの同じ部品または機能と比較して、過度にまたは排他的に開発された部品または機能、このライブラリの開始以来、異常な比率に変更が加えられている必要があります。このことから、変動は遅くて長続きするプロセスであり、そのような場合の自然な選択には、さらなる変動と逆転の傾向を習得するのに十分な時間がまだないため、他の部分よりもはるかに大きく変更可能である理由がわかります。変更の少ない状態に。しかし、異常に発達した機能を持つコンポーネントが多数の変更された子孫の祖先になったとき、それは私の意見では、非常に遅いプロセスであり、膨大な時間を必要とします。そのような場合、そのような場合、自然な選択は、異常な発達にもかかわらず、すでにこの機能に一定の機能を与えることができました。コンポーネント、共通の祖先からほぼ同じ体質を継承し、同様の条件にさらされた人々は、当然、同様の変化を与えるか、時には遠い祖先の特徴のいくつかに戻る傾向があります。逆転や同様のバリエーションのために、新しく重要な変更を加えることはできませんが、そのような変更は美しく調和のとれた多様な開発に追加されます。
理由が何であれ、おそらく、ライブラリバージョン間の微妙な違いごとに（そしてそれぞれに理由があるはずですが）、好ましい違いの着実な蓄積が、各コンポーネントのライフサイクルのためにすべての最も重要な構造変更を引き起こしたと信じる理由があります。
元の段落で置き換えた用語
- 属->ライブラリ
- ビュー->コンポーネント
- 器官->機能
- 個人->プロジェクト
- 子孫とその親->ライブラリバージョン
- 栄養素->開発リソース
- 有機的な存在->ソフトウェア製品
- 有機ラダー->ソフトウェア製品の成熟度
- 二次性特性->機能シグネチャ
- 性別->通信プロトコル
- 強化、弱化->改善、劣化
- ソリッドおよび外部->外部インターフェイス
- ソフトで内部->内部構造
- 自然->開発
また、このコンテキストで奇妙に見える用語を置き換えました。
- 使用法->使用法（単語が少し古くなっているように見えるため）
- 組織->アプリケーション構造（意味が正しいように）
- ライフスタイル->ライフサイクル
また、元の段落をよく理解しておくことをお勧めします。スポイラーの下に隠しました。
本から元の段落を読む
. 100 , . , , , , . , : , . – , – – . , . . - , , , , , , . , ; , , . , , , , , , - , . , , , , , , , . , , . , . . , , , , , . . , . , , ; II , . , , , . . , . ; . , . , , ; , , , , . , , , , , , . , , , . , - , , .
, , – , – , .
少し説明
完全に交換した後、私はテキストを読むのが非常に難しいことに気づきました（誰が考えたでしょうか？）。これには多くの理由があります。最も重要なものの1つは、選択された段落です。事実、この段落には、この章自体で説明されているすべての短い説明が含まれているため、テキストは非常に簡潔で簡潔です。残念ながら、用語をそのような最小限のジェスチャーに置き換えることができる別の適切な段落を見つけることができませんでした。
テキストが完全に狂ったように見えないように、いくつかの文をもう少し詳しく説明します。
例1
元の：
いずれかの部分が強く発達するとき、それは隣接する部分から栄養素をそらす可能性があり、損傷なしに排除できる組織のあらゆる部分が排除されます。
第V章でのこの考えの説明：
, , ; , , , , , . , , , , , . , , – , .
ある特定の部分が強力に開発されると、開発リソースが隣接する部分から逸れる可能性があり、損傷することなく削除できるアプリケーション構造の部分が削除されます。
人生の例：Habrプロファイルのアイコンは、境界線のある歌姫のように見え、かつては美しいアイコンでした。明らかに、これらのアイコンをサポートおよび開発するためのリソースは割り当てられていません。ただし、コメントを読んだりナビゲートしたりすることは、以前よりもはるかに便利になりました。どうやら、コメントの開発はアイコンの開発からいくつかのリソースを奪います。
例2
元の
種の特性、つまり、同じ属の種が共通の祖先から分岐したときとは異なり始めた特性は、一般的な特性、つまり、長期間継承され、指定された期間中に継承されなかった特性よりも変動します。違いが生じました。
第V章でのこの考えの説明：
これを簡単な例で説明しましょう。より大きな属の植物で、ある種が青い花を持ち、他の種が赤い場合、色は特定の特徴にすぎず、青い種の1つが赤に変わっても、またはその逆でも、誰も驚かないでしょう。 ; しかし、すべての種が青い花を持っていれば、色は一般的な兆候であり、その変化はより異常な現象のように見えます。
用語を置き換えた後：
コンポーネント属性、つまり あるライブラリのコンポーネントが共通の祖先から分岐したときとは異なり始めた特性は、ライブラリの特性、つまり、長い間継承され、指定された期間中に違いが生じなかった特性よりも変動します。
実際の例たとえば
、プロジェクトでBootstrap CSSフレームワークのボタンを使用する場合、.btnまたは.btn-primaryクラスのコンテンツは、これらのクラスの名前を.g -buttonやgなどに変更するよりも頻繁に変更されることは明らかです。-ボタンファースト
結論
記事はそう、半真面目であることが判明しましたが、いずれにせよ、私たちは自然な進化の過程から多くを取り、それを開発に移すことができると思います。
PS：私の友人や同僚に感謝します。彼らは、なぜ用語が私に言っているのか分かりませんでした。