今日は、私たち（人）を取り巻く複雑さと、それを扱う私たちの能力について推測したいと思います。 「すべてが複雑である」などのソーシャル ネットワークの結婚状況について彼らが書いている複雑性についてではなく、組織的および技術的システムの複雑性について (ちなみに、私の意見では、それは大学の専門）。私は独創的であるふりをしませんし、さらに、真実であるふりをしません (特に、少なくとも半分は、私がここで下品にしたり、いたずらしたり、ふざけたりするからです)。この推論の一部は、コメントのどこかですでに行っていますが、私にとってこの質問はクローズされていません。したがって、人生は常に、さらに考えさせられるさまざまな実例を私に投げかけます。金曜日にもかかわらず、それは面白い読書をすることを意図したものではありませんでした.一文だけ読みたい場合は、残りの楽しい金曜日の記事を読みに行きます。「実行できる場合は複雑さを単純化し、単純化できない場合は複雑さに対処し、経験を積み、最初のケースと 2 番目のケースを区別する能力を身に付けます」。
偉大な人からのいくつかの引用：
理解することは単純化することです.
単純化することは理解することではありません。
シンプルさにはデザインとセンスが必要です。
できるだけシンプルにしてください。
複雑さは私たちの周りのどこにでもあります。私たちは洗練された技術装置を使用し、複雑な刑法を尊重し、私たちの内部では複雑な免疫システムがコロナウイルスと戦い、最も単純な単細胞生物は驚くほど複雑な細胞小器官を運び、ニュートンの最も単純な法則ははるかに複雑な法則を単純化したものであることが判明しました非相対論的な速度で、そして標準モデルとあらゆる種類の異なる量子力学の複雑さについては、私は通常沈黙を守っています。
複雑性は常に一定の順序、相互作用する要素の特定のシステムであり、この基本概念の定義に完全に従って、要素の数が増え、これらの要素間の接続の数と種類が増えると、複雑さが増します。おそらく、複雑さは秩序と同義であり、カオスのアンチテーゼでしょうか?
一般に、人生は、まともな散逸システムのように、外部の複雑さが減少するため、私たちの内部の複雑さが自発的に増加します。エネルギーは、複雑さを増すために一部を費やす必要があるような方法で再分配されますが、結果として生じる組織、結果として生じる秩序は、大量のエネルギーへの「アクセス」を与えます。これが、生命の複雑性が「自発的に」増加する進化の理由だと私は思います。
私たちの周りの複雑なシステム、分散したい物質とエネルギーの組織の複雑さは、消費者の複雑さの増加につながり、さらにその連鎖に沿って進みます。長い幹の助けを借りてのみ蜜に到達できる花は、そのようなデザインソリューションを決定した蝶の幹の
私たちはプログラマーであり、その蝶のトランクのように、人生の複雑で複雑なプロセスと同様のソリューションを自動化するのに注意が必要なソフトウェア システムを作成します。
私たちはプログラマーであり、複雑なものを作成します 彼らが何と言おうと、私たちはこの複雑さを作り出すのが好きですが、他の複雑な技術システムの作成者と私たちを区別するニュアンスが 1 つあります。
複雑な素材と技術装置の作成者は、強度、摩擦、その他の素材によって制限され、想像力の飛行をわずかに妨げます。プログラマーの摩擦力は (彼が世界最高の水圧破砕シミュレーターの開発者でない限り)、デバイスの強度と重量も気にしたり制限したりしません 。私の意見では、ここから主な問題が発生します。
そしてそれは、私たちプログラマーが複雑さを作り出すのは簡単すぎるという事実にあります。私たちには簡単すぎる。 Ctrl + C および Ctrl + V、新しい関数、新しいモジュール、新しいライブラリ、新しい抽象化レイヤー、マクロ - シュマクロス、プリプロセッサ - ポストプロセッサ、アダプター、コンバーター、およびファサード - これはすべて機能します。追加する必要があります周波数と RAM が増え、フリクション リデューサーは必要ありません。創造された物理世界では、すべてがそれほど単純ではありません。遺伝的プログラミングだけでなく、少なくとも単純な Lisp マクロの類似物が工業生産のどこにあるのでしょうか?
再び。複雑さを加えるにはプログラミングが簡単すぎますが、複雑さを減らすにはプログラミングが難しすぎます。さらに、リファクタリング中に常にすべてを壊すため、プログラミングの複雑さを軽減する人は誰も好きではありません。
複雑なコードが悪いと言っているのではありません。コードは実際の作業を自動化し、データ モデルに反映します。コードは実物よりも単純ではありません。コードの複雑さは問題の複雑さとともに大きくなりますが、読み書きのできない開発者は、問題の複雑さよりもはるかに多くの複雑さをコードに加えます。
有能な開発者は、コードに複雑さを持ち込まないようにします。デバッグはコードを書くよりも難しいので、使用できる複雑さの限界で書いたコードをデバッグすることはできない、と偉人が言ったのも当然です。しかし、有能な開発者は、複雑さに対処する能力の 84% よりも難しいソリューションを作成しないとも言います。
人生の要件における将来の予測不可能な変化を設計できないということは、コードを書き直して作り直す必要があるという事実につながります。こんにちは、私はあなたのキャップです。しかし、複雑なソフトウェア システムが気に入らないという理由だけで、複雑なソフトウェア システムをゼロから書き直すことはできません。
複雑さと混乱は別物です。私がいつも言っているように、他の人の研究室を持ってきて、彼らがそれを理解していると確信している学生たちに (最近、2 つのフレームは、自分自身のコードを書くのではなく、他の人のコードを説明することを学ぶべきだとさえ言った. !)、わからなければわからないということはありえない。帰納的閾値のこちら側では、「わかったと思う」という状況と「本当にわかった」という状況を区別することはできません。
誰かがあなたのところに来て、「ここでは難しいので、最初から書きます」と言った場合、その人に書くことを許可してはいけません。最初に、彼が古いシステムをリファクタリングできることを証明する必要があります。段階的なリファクタリングの方法で既に抱えている複雑さに対処できない場合、自分で書き始めたときに複雑さをさらに悪化させ、最終的に問題を解決することはできません。なぜ？定義上、自分が理解していないことや過小評価していることを正確に理解することは不可能だからです。
誇張: 適切な自転車を発明しても、最初はうまくいきません。最初の自転車は、女の子のデザイナーの古典的な写真のように、3 つの歯車がペアで接続された、湾曲して斜めになっています。しかし、それはあなたがそれを構築する際に必要な難易度にあなたを連れて行ってくれるでしょう.そして2台目のバイクはすでに賢明なものになっています.彼らは、構文を学ぶためではなく、生命を与える複雑さの一部を得るために、独自のクラスの文字列を作成します。
同じソリューションの 1 つのコードの複雑さは、システム内にすでに存在するコードの複雑さに大きく依存し、システムの複雑さはサブシステムの複雑さの合計ではありません。そして、これは、顧客や他の外部の観察者と一緒に仕事をするときの問題の一部です。 「これは簡単です。ただ {action X} {inside system Y} です。すでに {inside system Z} が存在します!」.これは、システムの複雑さを過小評価した結果であり、何かを他のすべてと切り離して簡単に実行できる場合、既成の大規模システム内で実行するのは簡単であると人が信じている場合です。プログラムが A、B、C、D、E、F を実装する必要があり、それらがすべてほぼ同じ複雑さである場合、それらが同時に構築されると考えるのはかなり過小評価されます。
経験豊富なプログラマーにとって重要なことは、複雑さを管理する能力です。通常、私たちは複雑さを追加するだけです (単純にリファクタリングすることはできません) が、リファクタリングに慣れていない人にとっては悲惨です (実際、単純化!)。次に、物事を整理して単純化する代わりに、松葉杖の方が書きやすいため、そのような開発者は松葉杖を松葉杖に巻き付けて止めることができません。時間が経つにつれて、松葉杖を書くことはますます難しくなりますが、コツは、毎回、別の松葉杖を書くことはますます難しくなるということですが、 stable stable stable舎を片付けて物事を整理するよりも、常に簡単です。そして、締め切りがあるため、松葉杖を書くことが最適な解決策であるという錯覚が常にあります。残念ながら、これは現時点では最適なソリューションですが、長期的には非常に最適とは言えません。貪欲プログラミング。
複雑さに対処し、結果を予測し、問題の対象外の関係を理解する能力は、それ自体が大きな専門的価値であり、これがプログラマーがマネージャーや上司に参加する方法です。ある意味で、複雑なシステムの動作を予測し、新たに出現するシステム接続の結果を予測すること、「精神的なデバッグ」と「極端なケースのテスト」、「これが何につながるか」は、プログラマーの専門的なスキルとして、抽象化、誘導、推論の一般的なスキルとともに、マネージャーへの成長。それどころか、プログラマーの他の多くの専門的スキルと同様に、内向性と内向性、内向性は、この成長を制限します。
複雑性に対処する方法をどのように学びますか?このスキルに何が効き、何が逆に効くのかを知るためのアドバイス以外にレシピはありません。しかし、いずれにしても、すべては最も基本的な教育から始まると思います。研究。繰り返しは学びの母です。私は教師です。プロのデフォルメがあります。同じことを 2 回繰り返すことです。私は教師です。プロのデフォルメがあります。同じことを 2 回繰り返すことです。私
教育全般、特に学校や大学での教育について、特に関係のないことが教えられ、脳が不必要な知識やスキルでいっぱいになっているという事実について、多くの不満があります。私の娘は、さまざまな形状の穴のある中空の立方体を持っていて、対応する形状の小さな数字だけが中に入りました。望ましい幾何学的形状のキーを選択することを教えられた子供が、大人になってからバグベアのスキルが必要になると考える人はいますか?
最初の学位論文の防御に至るまで、教育の非常に重要な部分は、複雑さに対処するために脳を訓練することだと思います。学校の子供が紙の列に 3 桁の数字を掛けることを学んだとき、正しい心の中で、このスキルが人生で役立つとは誰も思わないでしょう。列の 2 つの 3 桁の数字を正しく掛け算することは、脳に負担をかけ、いくつかの数字を覚え、一定期間集中力を失わないようにするためのエクササイズです。最初に列を追加し、次に乗算してから除算します。複雑さを増すことによって。緊張する能力、働く能力。
これは適切な品質ですか？それはあなたが作成したい人によって異なります！ 「有資格者」であれば不要です。 「クリエーターマン」なら必要だと思います。人生では、列で乗算する機能は役に立ちません。人生では、正確な答えが必要な場合に、電話で同じ番号を乗算できると便利です。また、それぞれから有効数字を 1 桁だけ残すことができます。電話を使わずに頭の中で数を見積もり、おおよその値を取得します。ところで、これは、複雑なデータをすばやく決定し、入力データを単純化し、大まかな見積もりを使用して、複雑さを処理する能力に他なりません。しかし、もし誰かが自分の仕事に集中する必要はなく、間違いなく同様の日常的な作業をいくつか実行すると信じているなら、おそらく彼はこの世で頭を使って仕事をすることはないでしょう.
もちろん、これは、考えがまとまりのないものであると結論付けて、最初の段落で行ったアピールをもう一度繰り返したいと思います。実行可能な場合は複雑さを単純化することを学び、単純化できない場合は複雑さに対処することを学び、前者と後者を区別する経験と能力を開発します。