チームの市場性を維持しながら、フレームワークの複雑さの懸念を回避するにはどうすればよいですか？

Question

同僚とソフトウェアプロジェクトを設計する方法を決定するとき、ほとんどの提案は、「求人市場で人気があるため」または「それが採用担当者に電話をかけるフレームワークであるため」、特定のフレームワークを使用することである傾向があります。これは、「システムが将来の変更に適応し、開発者の生活が楽になるため、プロジェクトに最適だからです」と探しています。

ドメイン駆動設計について読み始めるまで、私はこのようにプロジェクトを見始めませんでした。実際のドメインは、使用されているフレームワークの奥深くに隠されており、ソフトウェア製品によって実装されているビジネスプロセスを学ぶのは難しいことがわかりました。

複雑さを回避しながら、開発チームとしての露出を得るという2つの競合する目標を組み合わせる方法はありますか？妥協するフレームワークはありますか、それとも他の解決策がありますか？

pdr · Accepted Answer

フレームワークが過剰設計の原因であるとは思いません。多くの場合、フレームワークは定型コードを削除し、維持する必要のあるコードベースを簡素化します。

また、すべてにAPIを期待するのは悪い考えであるというThorbjornのコメントにも同意します。ランタイム環境がほとんどすべてのアプリケーションに現れるものに焦点を合わせ、他の一般的な問題が解決される場所にフレームワークを追加できるように十分な柔軟性を持たせる方がはるかに優れています。

しかし、フレームワークを使用するためにフレームワークが使用されるインスタンス（Java world）の外）を見たことがあります。これが悪いと思う理由がわかります。製品が複雑になりすぎると、ただし、開発者にCVを改善する余地が与えられた場合、開発者は固執してさらに多くを学ぶ理由が増えることを覚えておく必要があります。

フレームワークが役に立たないことに気付いた場合、開発者が後退する可能性が高い限り、開発者を手放すのには十分な理由があります。

しかし、あなたの話を読んでいると、もっと大きな問題があります。ビジネスドメインを理解していないのです。あまりにも多くの製品が実際のビジネス上の問題に関係なく書かれており、開発者が役立つと思うものを作成しようとしているだけです。これはフレームワークのせいではなく、開発者のせいですが、なんとかして修正する必要があります。

それをどのように行うかは、チームの構造に大きく依存します。しかし、「人々の生活をより良くするソフトウェアを書いていると思ったら、仕事にもっと満足できると思いませんか？」というコメントをたくさんしてください。

または、開発者がソフトウェアを使用する人々と一緒に座って、彼らが毎日直面する問題を確認し、解決策を提供するように手配します。

または、それに関しては、キャリアの角度でプレーしてください。誰が次のインタビューに行き、「ええ、最善を尽くしましたが、顧客が望んでいた製品ではありませんでした」と言いたいのです。そこで、私はビジネスに出てモデルを調査し、DDD技術を使用してそれをソフトウェアモデルに変えて」？

S.Lott · Answer

フレームワークは、過剰に設計されたプロジェクトの多くの触媒です

番号。

それとももっと単純なものですか？

はい。

ソフトウェアプロジェクトでこれらの問題に遭遇した場合、どのように対処しましたか？

それを無視します。

プロジェクトが過剰に設計されているときに注意すべき重要な指標はありますか？

はい。

いくつかの提案がありますか？

それとも、質問は単に修辞的なものでしたか？

オーバーエンジニアリングの主要な指標の1つは、オーバーエンジニアリングについて不平を言う人々です。真剣に。 その他不平を言う人。

オーバーエンジニアリングとは、次のことを意味します。

要件のない追加機能が投入されます。

ユーザー（または製品所有者）は機能要件のみを気にするため、柔軟性、スケーラビリティ、可用性、およびその他すべての非機能要件がプロジェクトに投入されることがよくあります。

一部の人々は、非機能要件について非常に深く議論することを本当に望んでいます。いろいろなものを追加します。

一部の人々は、非機能要件を非推奨にすることを好みます。ソフトウェアを「軽量」または「透明性」などにするために重要な機能を削除します。

ある人の本質は別の人の任意です。

誰もが間違っているので、誰もが正しいです。どこかに妥協点があります。

重要なのは、フレームワークが基本的にゼロコストで非機能要件の標準スイートを提供することです。明らかに、それは楽しいことではありません。誰がユーザーの紛らわしい要件に焦点を合わせたいですか？

フレームワークを回避するということは、非機能要件のすべての標準スイートを最初から構築する必要があることを意味します。明らかに、それはもっと楽しいです。ユーザーの実際の要件を回避して非機能要件に焦点を合わせるのは、実際のプログラミングに似ています。

tp1 · Answer

フレームワークを選択するときは、次のことを考慮してください。

フレームワークにはいくつの依存関係がありますか。他に必要なライブラリ、プログラム、環境、コンピューター、またはシステム。 all依存関係を維持するのにどれくらいの労力がかかりますか？労力は少ない方が良いです。
フレームワークの元の開発者が消えると、どうなりますか？フレームワークを維持することは不可能であり、困難であり、1000人のチームが必要です
より良いフレームワークが（すでに）利用可能であると全世界が考えている間、それが退屈で迷惑な作業であっても、フレームワークを気にし、それを維持するために時間とお金をボランティアで提供する人々が常にいるほど人気がありますか？
フレームワークが消滅し、廃止されたと見なされるまでの時間
使用するインターフェースのサイズはどれくらいですか。小さい方が良いです。
フレームワークの規則は、コードを22の異なる形状の部分に分割しようとしていますか？コードに規則を適用しますか？実装する必要のあるコールバックに注意してください。 yourコード全体に広がる命名/メモリ管理/ API規則にも注意してください。
フレームワークは、開発作業の煩わしい部分や煩わしい部分をあなたの責任に移しましたか、それともそれを処理して単純化しようとしましたか？
フレームワーク全体の機能を使用できますか、それともフレームワークのごく一部のみを使用して計画しているものですか。小さなパーツのみを使用している場合、フレームワークは負担が大きすぎて維持できない可能性があります。
フレームワークが依存しているプログラミング言語または環境はどれですか？その環境は将来利用可能になる予定ですか？環境を提供しているいくつかのベンダー？
フレームワークを変更可能なボックスに分離する簡単な方法はありますか？
フレームワークを使用するために必要なソースファイルはいくつありますか？数値は小さいほど良いです。
フレームワークを使用することを決定したときに、どれだけの労力を節約できますか？それが解決する問題は何ですか？それを使用し、永久に維持するためにあなたがする必要があるどれだけの余分な努力。