最近のある日、私は友人と開発プロセスがあるという事実について話をしました。プログラマは仕事をしていますか、それともバグをつぶしますか？ 誰でも開発者になれますか？ ソフトウェア開発プロセスの複雑さは何ですか？ 私たちの対話が、プログラミングに関与していない人たちの問題を理解するのに役立つか、自分の好きな娯楽を振り返りたいと思っています。
そして、それはすべてかなり一般的な質問から始まりました。
-なぜプロジェクト開発予算が頻繁に超過するのですか？
-これは難しい質問です。 私は、状況を説明するのに役立つ比basisを基礎とすることを提案します。 もちろん、これは私が受けた経験に基づく私の意見です。
そのため、開発者は新しい世界の創造者です。 仮想世界。
-あなたは映画「マトリックス」について私に言ったでしょう！
-実際にはそこからの隠phor。 だからここに。 入力要件は、顧客がどのような世界を必要としているのかを示します（顧客は社内にいることもできます）。
ほとんどの場合、要件は広範で曖昧です。
-ちょっと待って。 すぐにぼやけるのはなぜですか？ たとえば、実行したいプロジェクトがあります。 私はそれがどのように機能するかを明確に理解しています。 また、私はTKを持っています!!!
-はい。 はい。ただし、顧客はこの新しい世界の多くの側面を考えず、考えるべきではありません。これは開発者の仕事だからです。 ソースコードを整理する方法は？ 従うべき変数の命名規則は何ですか？ 使用するライブラリ どの分岐戦略を使用する必要がありますか？ パフォーマンスを確保する方法は？
概して、開発者のタスクは、この新しい世界にこのような法律を敷き、この世界が元の問題を解決することです。 ビジネス要件または機能要件を新世界の法律の要件に関連付けます。 さらに、この世界は新しい要件と情報の影響下で絶えず変化しなければなりません。
-でも、これは予算とスケジュールと何の関係があるのでしょうか？
-プロジェクトに新しい機能を作成するために必要な時間、したがって予算に影響を与えるものについて考えてみましょう。
まあ、特定の機能があります。 それを行う方法を理解する時間があります。 実装してテストします。 そして、開発者はそれを行う方法に関するすべての情報を持っているとしましょう-彼は、必要な技術、プログラミング言語、アプローチを完全に知っています。 彼は要件を理解しています-最終的にどのように機能するかを知っています。
タスクの実装時間はコードを書く時間と同じですか？ もちろん違います。 これに加えて、開発者は既存の世界に新しい機能を組み込む必要があります。 既存の法律に埋め込みます。 古い機能と新しい機能の両方が機能するように、新しい法律を追加するか、既存の法律を変更します。
これらの問題の複雑さは、多くの場合、機能自体の実装の複雑さよりも何倍も高いため、これはまさに最も困難です。
-これは家を建てる方法ですか？ たとえば、部屋に別のウィンドウを追加する場合、十分な暖房があるかどうかを考慮する必要がありますか？ 熱伝達の法則を破りますか？
-まさに。 ここで、熱伝達が一側面にすぎないことを想像してください。 複雑なソフトウェアシステムでは、数千ではないにしても数百のそのような側面があります。 それぞれの小さな新機能を実装するとき、すべての側面に注意を払う必要があると想像してください。 そして今になってようやく、私は主要なアイデアを説明することができます。 このような世界（プロジェクト）の作成と開発として、内部の法律と規則の数は常に増加しています。 この世界のいくつかの法律は時代遅れであり、それを取り除く必要があることを追跡することはそれほど簡単ではありません。
世界は不必要なルールに覆われています。 開発チームのメンバーはより複雑な世界に住み始め、人件費は増加しています。
-そして、何が行われ、単純化されたかを徐々に修正し、不要なものを削除することが不可能なのはなぜですか？
-それで可能です。 継続的なリファクタリングなど、特定のプラクティスもあります。 ただし、チームレベル、特に技術レベルでの自己反省はめったにありません。 はい、すべての問題を見つけるのは困難です。プロジェクトの規模はますます大きくなっています。 特定のタスクの実装中にアーキテクチャが悪化しないようにのみ監視できます。
その結果、開発者はタスクを解決するのが難しいという理解を持って生活します。結局のところ、多くの接続を彼のこのファンタジーの世界で再構築する必要があります。 グレードが高すぎます。 タスクは、実際よりも時間がかかります。
それは重りで走るようなものです-同じ距離をカバーするためにより多くのエネルギーが費やされます。
-別のシナリオ-開発者は、複雑さの増加を見ていませんが、誇張しすぎていません。 彼らの世界にはすでに法律があります、彼らは単にそれらを知りません。 そして実生活のように-法律の無知は責任を免除されません。 これは、技術的負債の蓄積のいずれかにつながります-問題がありますが、それらは後で発生します。 または、新しい機能の実装はシステムの他の部分の崩壊につながりますが、これはすぐに気付かないかもしれません-あなたは常にすべての作業を再確認するわけではなく、何かが後でポップアップします（本質的に特定の機能のコストが増加します）。 そうそう、あなたは自動テストを言う-しかし、それらを開発するのは安いですか？ 彼らは100％のパフォーマンスをテストしていますか？
-さあ、それはあなたがポンピングしているようです-しかし、モジュール性はどうですか？ 私はプログラマーではありませんが、複雑さに対処する方法を理解しています。 パーツに分割します。 責任範囲を分離します。
「あなたは正しい。」 それが、最新のプログラミング手法のほとんどが目指していることです。 たとえば、マイクロサービスアーキテクチャについて聞いたことがあるかもしれません。 開発者は、責任の量を制限することでシステムの複雑さを軽減しようとしています。
しかし、問題は同じままで、それらの一部だけが別の面、つまり統合に移動します。 同じモジュールまたはサービス間のリンクを確立します。
私はあなたに以前の論文の別の例を与えたかった-既存の法律を改正することの難しさ。
私はこのトピックについて哲学するのが好きです。 変更の必要性を理解することが難しいのはなぜですか？
法律を知っているだけでなく、あなたが世界を創造したとき、それらはあなたによって生まれたものであり、物事を異なって認識することは困難です。 自分のロジックを自分の強い批判にさらすために、これが統合失調症に到達する方法です。 そして、これらの法律を改正することは非常に困難です。 特定の開発者またはチーム全体の頭の中でこの世界のあるパラダイムを変更する必要があるため、常に長いとは限りませんが、困難です。 重力の法則の理解が変わる場合、現実世界のすべてを再考する必要があると想像してください。 または、たとえば、突然、地球がまだ平らであることがわかりましたか？ これらは非常に基本的な概念であり、私たちの生活に織り込まれているため、再考のプロセスには一生かかる可能性があります。 そして実際、あなたがこの世界を認識していることを除いて、実際には何も変わりません。 したがって、開発者はパラダイムを変更することを好みません。 いずれにせよ、大多数。 古いパラダイムでより多くのコードを記述する方が、パラダイムを変更して特定性を簡素化するよりも便利です。
-理解し始めているようです。 もちろん、すぐに自分自身で試して、あなたと話すだけでこのすべての複雑さを理解するのは難しいですが、少なくとも私は作品の詳細を理解し始めました。 おそらく今日、私は思考のための十分な食べ物を持っていますが、次の会議で私たちの対話を喜んで続けます...