無駄な複雑さを制御するために、開発環境に正式な役割（内部または外部）を割り当てる必要がありますか？

Question

数年前、私は、社内フレームワークの開発に携わった小さな会社で働いていたため、彼らは最上級の開発者とアーキテクトをカスタムMVCフレームワークとORMのゼロからの開発に専念させました。これら2つのことは、コア製品と直交していました。残念ながら、このフレームワーク主導のアプローチのサポートはトップからのものであり、収益を生み出すソフトウェアの提供を遅らせました。また、作成されたフレームワークは、遅延を悪化させた既製の代替品よりも著しく劣っていました。会社はすぐに現金を使い果たし、最終的には全員が解雇されました。

後の雇用主も同様の過ちを犯しました-彼らは高度に技術的に熟練した開発者を手に入れました-完璧主義者であり、企業の設計パターンに強い基盤を持ち、クライアントの1人のためのコンサルティングソリューションを大幅にオーバーエンジニアリングし、故意に損失を被ることを期待してこのソリューションは、他の顧客向けに適合および拡張できます。プロジェクトは大幅にオーバーランしました。しかし、他の潜在的な顧客は噛みつきません。少額の費用がかかる金メッキの戦略的失敗。

どちらの場合も、かなりの程度の過剰設計がありました。どちらの場合も、会社とプロジェクトの管理者は、プログラミングのバックグラウンドではなく、ドメインまたは分析のバックグラウンドを持つ人々でした。どちらの場合も、ソフトウェアアーキテクトは、技術的でない管理からの共謀を伴いながら、かゆみを掻き取り、履歴書を強化するために過度に複雑なソリューションを構築しました。どちらの場合も、アーキテクトはコストを抑えることに関与していませんでした（会社が倒産した場合に職を失うリスクは別として、エンプロイアビリティが高いことを考えると、それほどリスクはありませんでした）。

私の経験では、開発ショップが陥るのは珍しいことではないことを示唆しています。

ソフトウェアプロジェクトには、正式な内部または外部の技術的敵対的役割である「積算士」が、建物のアナロジーを使用して、無駄な過剰設計を呼びかけたり、防止したりする場所がありますか？この役割を果たすのに最も適しているのは誰ですか？

Aaronaught · Accepted Answer

「複雑さの制御」は次の仕事です。

システムとエンタープライズアーキテクチャを確保することが仕事であるアーキテクト現在のプロジェクト/製品に適している;
correctだけでなくmaintainableである設計とコードを作成し、他の開発者のコードをレビューして理解できるようにすることを仕事とする開発者それ;そして
ビジネス/システムアナリストまたは製品の所有者。その仕事は、ビジネスが何であるかを理解することです現在実際に必要なもの、後で終了できるもの、またはまったく実現しない可能性のあるもの。

「複雑さ」はとにかく抽象的な概念であり、「複雑さを減らす」ことはそもそもソフトウェアの目的そのものであると主張することができるので、それに専念する役割を提案することは意味がありません-それが全体ですチームはすでにやっているはずです！

ROIとTCOをざっと見てみると、ソリューションが実際にそして本当に過剰に設計されていることが示されていると仮定すると、申し訳ありませんが、それに取り組んでいたアーキテクト、開発者、およびアナリストは単にそうではありませんでした。彼らの仕事はとても上手です。そして、thatアスペクトの責任者は、彼らを雇ったマネージャーまたはエグゼクティブです。 おそらく彼らは過剰設計の文化を育んでいて、部分的に過失があるか、あるいは実装チームから悪いアドバイスを受けているだけかもしれません。

私は（おそらく）あなたの会社で働いていなかったので、どれを推測するつもりはありませんが、1対1の会話をするだけで、かなり簡単に自分でそれを理解できると確信しています。上記のマネージャーの数人。

ちなみに、社内フレームワークの開発ではない常に悪いことです。これらのフレームワークは、通常、現在のプロセスの観察と改良に基づいている必要があります。既存のコードをリファクタリングすることによって実現されるフレームワークまたはライブラリは、長持ちする傾向があります。一方、人々がただ飛び込んで開始する場合フレームワークの開発コンテキストがまったくない場合、通常、それは責任になり、すぐに発生します。

人々はconventionsの違いを認識できる必要があります（組織内のほとんどのプロジェクトは、一定量の定型コードを使用して同じテクノロジースタックを使用しますが、それがすべてをまとめて詰め込むことを意味するわけではありません「フレームワーク」は良い考えです）vs。重複（人々は文字通り同じビジネスまたは技術的な問題を何度も何度も解決しており、矛盾は複雑な設計と深刻な欠陥につながります）。ソフトウェアビジネスcanおよびshould後者のシナリオを認識し、複雑さを軽減するための措置を積極的に講じます。フレームワークdo 内部プラットフォーム効果に屈しない限り、複雑さを軽減します。

BЈовић · Answer

ソフトウェアプロジェクトには、正式な内部または外部の技術的敵対的役割である「積算士」が、建物のアナロジーを使用して、無駄な過剰設計を呼びかけたり、防止したりする場所がありますか？この役割を果たすのに最も適しているのは誰ですか？

いいえ、通常そのような立場はありません。

秘訣は、その仕事にふさわしい人を雇うことです。オーバーエンジニアリングを行わず、必要なことだけを行う人。

これは、アジャイルアプローチを使用して行うことができます（反復で要件を実装する、TDDまたはBDDを使用するなど）。しかし、繰り返しになりますが、アーキテクチャが過剰に設計されている場合、それは役に立ちません。