アップロードサービスを設計する。 OOP

Question

でヘルパー/ユーティリティクラスは、私は最近、大学を卒業しました

は、確立されたソフトウェア会社に入社し、アップロードがレポートを生成したコードを書くために、私は仕事を課された18

のチームの大きさに取り付けた（レポートA） SharePointなどのファイルダンプ領域に移動します。私たちのアプリは現在、多くのレポートを生成しています（レポートA〜Z）。しかし、私はただ今、レポートAのためだけに任されていました。

私は、レポート（B to Z）が将来私のサービスを簡単に利用することを可能にするアップロードサービスを設計しなければならないことは間違いありませんでした。

チームのベテランから、ファイルをアップロードするヘルパー/ユーティリティの1つのクラスを実行するように指示されました。

しかし、私が考案したデザインは、Uploader抽象クラスを継承し、UploadServiceファイルを呼び出すReport A Uploaderを返すファクトリデザインパターンを含んでいます。 将来、Report B to Zは単にUploader抽象クラスを継承し、アップロードする宛先を決定するメソッドを実装するだけです。

私は混乱していますので、私は本当にこの問題を熟考しましたか？私のデザインは間違っていたのですか？

Answer 1

正しいかどうかの基準をすべて理解していなくても、デザインが「間違っている」か「正しい」かどうかは、実際には分かりません。一般的にチームリードは、その基準に関する後輩以上のものを知っているべきです（常にそうとは限りません）。また、「正しい」と「最適な」との間には違いがあることを忘れないでください。

商業環境の経験豊富な開発者は、「クイック」ソリューションに対して「良い」デザインをトレードオフすることが多く、このトレードオフはしばしば暗黙のうちに行われます。彼らはまた、複雑さを不信にすることを学びます。多くの場合、チームリーダーは「do X」と言うときにこれを実行します。

最善のチームリードは、トレードオフの仕組みを理解してより良い開発者にするために、経験の浅いメンバーに彼らの思考プロセスを説明します。

デザインが複雑すぎると思われる場合は、リードを確認することをお勧めします。 「どうすればいいのか」というより、「私は私たちがすべきだと思うから...」と言います。優れたマネージャーは、チームメンバーがイニシアチブを示し、知っていることを分かち合う意欲がさらに高まると、それを気に入っています。