3

私の質問は技術的ではありません。それは哲学的であり、実際には個人の好みに依存します。私はアプリケーション(Web +デスクトップ)を設計および開発していますが、これは私に起こったばかりで、皆さん(プログラマーとデザイナー)がこれまでにこれに遭遇したことがあるかどうか疑問に思っていました。

一部の設計者は、3〜5年後に実行されるアプリケーションを作成すると考えており、システムコアの変更に頼る必要なしに、アプリケーションに加えられた変更が反映されます。プログラマーとして、私はこれが決して当てはまらないという事実を知っています。小さな外​​観上の変更は発生しますが、通常は1、2年後に消滅します。時間の経過とともに、コアの変更を必要とする変更があり、最終的には新しいアプリケーションを作成します。

テクノロジーの急速な変化を考えると、5年間のアプリケーションの設計は、かなりばかげています、IMHO。設計しないという意味ですが、このアプリケーションは5年間実行されるという考えと、新しいアプリケーションを作成する必要はないという信念は、愚か者の楽園に住んでいると思います。つまり、実際には、仲間のプログラマー、実行中のフローを持つほとんどのミッションクリティカルまたは基本的な小さなアプリケーションは、通常、数年後に再作成/再構築/再編成/再コーディングされます。

だから私の質問は、なぜこの完璧なアプリケーションを10年間実行するというこの姿勢を維持するのかということです。テクノロジーは毎年変化するという事実を知っているので、それは本当にばかげています。新しいフレームワーク、新しい方法、新しいテクノロジーが出現し、クライアントはそれらを望んでいます。それで、あなたがこのフレーズの私の使用を許すならば、WTFはポイントですか?

とにかく、アプリケーションは数年以内に再設計されるとデザイナーに言い続けています。@ ssから照明を放つようにしようとしても、まったく意味がありません。完璧なアプリケーションというものはありません。

私はあなたたちが私のドリフトを取得することを願っています。皆さんも同じように感じましたか?ところで、私はソフトウェアプログラミングビジネスに約7年携わっています。本当に考えてみれば、Facebookは5年後も変わらないと思いますか。デザインは毎年かそこらで「ファンキー」なままですが、コアは2、3年ごとに変わります。私はそれを確信しています。私は妄想的ですか、それとも何ですか?私と同じ道に他のプログラマーがいることを教えてください。誰?

4

9 に答える 9

9

私のアプローチは、変化に備えて設計することです。これは、他の開発者がコードをすばやく理解できるように、できる限り保守しやすいコードを記述し、物事をゆるく結合してモジュール式に保ち、可能な限り標準的な方法で物事を実行しようとすることを意味します。

多くの場合、変更はコードの変更よりもはるかに難しい可能性があるため、私は通常、データベース設計の将来性を保証するためにもう少し努力します。

于 2010-08-09T15:00:58.547 に答える
5

私は、10 年以上前のソフトウェア製品を扱う 2 つの異なる会社で働いたことがあります。それらは多数の新機能で拡張され、多くの改良が加えられましたが、アプリケーションのコアは最初の安定版リリース以来本質的に変更されていません。これは一般的ではないかもしれませんが、アーキテクトが十分なスキルを持っていれば、システムをモジュール式に構築し、驚くほどの成長に対応できる拡張性を持たせることができます。

于 2010-08-09T15:09:22.837 に答える
4

「素晴らしい計画への最大の障害は、完璧な計画の夢です。」

私は同意します-将来起こりうるあらゆる変化に対してエレガントに回復できる完璧なシステムを設計することは無益です。成功するプロジェクトはすべてトレードオフです。必要になると確信できる場所(またはとにかく簡単に実行できる場所)で柔軟性を構築します。そして、柔軟性/変更の可能性が低いと思われる、やや迅速で汚いコードを構築します。システムをよく分析し、クライアントがニーズ/要件(常に与えられているとは限らない)をよく理解している場合、少なくともほとんどの場合、そのバランスを正しくとることができます。

ただし、システム全体が3〜5年ごとに新しいテクノロジーに置き換えられるという考えも誤りです。最新の、最新の、最もセクシーなシステムを必要とするすべてのクライアントのために、従来のCOM / VB / MS-Access /スパゲッティロジックのモラスであるシステムを手放すことを恐れている(または置き換える余裕がない)5つのクライアントがあります保守性、柔軟性、または拡張性に関係なく、無計画に構築されます。そのシステムを構築するのはあなたではありません。もしそうなら、あなたはあなたのクライアント/雇用者に不利益を与えています。

于 2010-08-09T17:38:20.537 に答える
4

個人的には、数年以内に置き換えられると仮定して、いかなる種類のアプリの設計も開始しません。完全に新しいアプリケーションを待ちたくない顧客が望む迅速な修正のために、これらの「更新」と「書き換え」が延期されることがよくあります。要件が変わるのは確かで、機能が必要ですが、多くの場合、現在のイテレーションで必要になります。

つまり、同じことを考え、現在でも使用されているアプリ、言語、デザイン パターンがたくさんあります。私の頭に浮かぶのは、y2k バグです。70 年代のプログラマーは、自分たちのコードが 30 年続くとは思っていませんでした。世紀が変わる前に、誰かがこれらの年の値を 4 つの数字に拡張することは確実でした。私たちは皆、その考えがどうなったかを覚えています...

于 2010-08-09T15:05:06.153 に答える
3

データとデータ構造は (多くの場合) 何十年も続くように合法的に設計する必要があります。アルゴリズム、UI、その他すべてが急速に進化することが期待されています。

データが法的文書や財務記録を表している場合、何十年も保持しなければならない可能性があります。

これも、極端に取ることができます。データベースに保存されていた可能性のあるメモリ パフォーマンス カウンターのように、おそらく 50 年後には誰も気にしないであろうデータのサブセットがあります。

于 2010-08-09T15:21:04.083 に答える
3

システムのコアが何年にもわたってあまり変わっていない原則に基づいて構築されている場合、システムは基本的にあまり変更されず、ほとんどの変更は主に審美的なものになると私は信じています.

データベースの正規化、コードのモジュール化など、試行錯誤されて今日まで有効な原則がいくつかあります。

したがって、何をコアとして定義するかによって異なります。私にとって、コアとはシステムの設計を意味し、それが適切に行われていれば、おそらく今後も大きく変わることはないでしょう。

于 2010-08-09T15:03:23.270 に答える
3

それは本当に環境に依存します。私たちの社内アプリケーションは、ローンチから 18 か月以内に完全に見直されます (多くの場合廃止されます)。それは誰のせいでもありません。ビジネスの優先順位が変わり、要件が変わり、新しいシステムが稼働します。同時に、他のシステムが非常に長時間実行されます。

確かに、すぐに廃止されることを期待してアプリケーションを開発することはありませんが、すぐに解決策を必要とするビジネス ニーズがあり、アプリケーションをオンラインにしてできるだけ早くエンド ユーザーの手に渡した方がよい場合もあります。次善の策を更新し、繰り返し、決定します。

于 2010-08-09T15:11:23.210 に答える
3

.Net Rocks のポッドキャストの 1 つで、私たちの業界を次のように説明した James Kovac の言葉を覚えています。

唯一の定数が変化するもの

そのため、変更が発生した場合 (ほとんどの場合は必然的にそうなるでしょう*)、アプリケーションの適応/更新の作業がより簡単になるように、柔軟性を考慮して設計する必要があります。確固たる根拠に基づいてアプリケーションを構築しようとするべきではないと言っているわけではありませんが、最初から完璧なソリューションよりも、簡単に変更できる柔軟なソリューションを用意することが重要です。

*私は、多くの銀行で人々がまだ古いアプリケーションを使用していることを知っています。なぜなら、それらを変更するのはリスクが高すぎて、変更する専門知識がもはやないからです..

于 2010-08-09T15:25:21.667 に答える
2

理想的なデザインは完全に直交していると思いますが、思い描いたようにうまくいくことはめったにないことを受け入れる必要があります. The Pragmatic Programmer を読んだことがない場合は、コードの将来性を保証することについて多くのことが書かれています。

于 2010-08-09T15:04:05.640 に答える