類似した機能に異なるパターンを使用する


10

私はプロジェクトの唯一の開発者です。これは、他のソフトウェアプロジェクトと同様に、将来誰かに奪われる可能性があります。

機能Aを実装するためにパターンXを使用したとしましょう。機能を開発して完成させた後、今学んだパターンYを使用して同じ機能を実装できることに気付きました。しかし、機能Aはうまく機能しており、XからYへのリファクタリングは時間がかかり、ほとんどメリットがありません。

次に、機能Bを実装します。これはAに似ていますが、今回はこの機会にパターンYで遊んでみたいと思います。機能Aを実行するときよりも、最終結果に満足しています。ただし、コードでは2つ使用していますXとYの異なるパターン。

ただし、機能AIを構築するときに機能Bと同じパターンを使用するのに十分なスキルがなかったという事実を除いて、異なるパターンを使用する実際の理由はありません。

この質問は、特定の問題に適切なパターンを選択することに関するものではないことに注意してください。同様の問題を解決するためにコードベースに共存する約2つのパターンは、リファクタリングするのに十分な時間を与えると1つに減らすことができます。

  • そのコードは臭いですか?
  • このようにソースコードを保持することの欠点は何ですか?
  • 1つのパターンのみを使用する必要がありますか?つまり、Bを記述するときに、AをリファクタリングしてYを使用するか、Xを使用し続けるか。
  • ソースで、類似した機能に2つの異なるパターンがある理由は本質的に理由がないことをどのように伝えることができますか?
  • 次の開発者が私のコードをどう思うかについてあまり心配していませんか?

回答:


7

パターンXとYが同じ問題を解決し、どちらも客観的に優れている場合は、どちらかを決定してそれに固執する必要があります。それが可能な限り、同じ問題を同じ方法で一貫して解決するよう努力する必要があります。

あなたはあまり心配していませんが、それは間違いなく処理してクリーンアップする必要がある深刻なコードのにおいです。

コードベースの同じ問題に対して異なる解決策があることの欠点:

  • コードを理解するには2倍の時間がかかります
  • パターンを含む動作の一部を変更すると、コードの変更に2倍の時間がかかります
  • バグは2倍になります
  • 現在および将来の同僚はあなたを嫌います

2

JacquesBの回答に同意します。合計して、他の質問に対処します。現時点で2つのパターンが共存していて、アプリケーションをリファクタリングして最良のパターンを使用する時間がない場合は、これは、「問題のある」クラス(リファクタリングされるクラス)のコメントにあります。このようにして、将来の開発者(あなたや他の誰か)には、まだいくらかの借金が残っていることは明らかです。

最後に、このようなコードベースを維持することの主な欠点は、追加されますが不必要な複雑さです。あなたは絶対に不要な複雑さを避けたいと思います!


私はむしろこれをある種のToDoリストで、または少なくともコード内のメモに加えて見たいと思います。
JeffO 2016

@JeffO同意する。todoリストのみに依存することには追加の問題がないわけではありませんが、ほとんどの場合、これらは個人的な(共有されない)ものであり、共有コードベース内のコメントとは反対です。しかし、繰り返しますが、両方に同意することをお勧めします(そもそも最初から避けられない場合)。
carlossierra 2017年

それは良い点です。共有、コラボレーション、コミュニケーション、その他すべての楽しいものを含めるには、それは単純なTodoリスト以上のものでなければなりません。
JeffO 2017年

1

コードベースでプレイしないでください。プロトタイプを作成すると、1つのパターン/デザインが他のパターンよりも優れている点と不利な点を見つけることができます。

直感的に感じるものを減らすことができ、実際には2つの異なるパターンを持つよりも複雑であることがわかる場合があります。

プロトタイプ用に開発されたコードの大部分をスローすることを期待してください。


1

これがコードのにおいであるかどうかは、問題Aと問題Bがどれだけ類似しているかによって異なります。JacquesBの答えは、それらが非常に類似していると想定しているようで、問題Aを変更する場合(たとえば、バグを修正する場合)は、同時に問題Bも変更する必要があります。JaqueBは正しいかもしれませんが、AとBはそれほど類似していないため、独立して変化する場合もあります。そのような状況では、マイナス面が説明される可能性はほとんどありません。

あなたの説明によると、コードの匂い(複製)のように聞こえますが、匂いがどれほど臭いかを判断するのは困難です。たとえば、Aがテンプレート方式を使用し、Bが戦略を使用する場合、使用されているミラーリングパターンにもかかわらず、2つの問題は非常に異なる可能性があります。私は待って、アプローチを見てみました。問題Cが発生し、それがAとBのようなものである場合、AをリファクタリングしてBと一致させ、Cを作成するのは非常に簡単です。Aにバグがある場合、Bと一致するようにリファクタリングしたい場合は、バグを修正します。何も変わらない場合は....それは問題ではありませんか?

コードベースで同様の問題を解決する複数の方法があることは現実です。あなたが唯一の開発者である場合でも、新しいことを学び、新しい洞察を得ようとするので、ソリューションは変化します。あなたは正しく認識しているので、価値を提供しながらこれらの欠陥を修正する必要があります。二度と変更されないコードの再設計(パターンを変更するときに実際に行っていること)は、価値を提供しません。それが変更されることを知る唯一の実際の方法は、実際に変更を行わなければならないことです。そのため、問題Cを待ちます。


1

いいえ、1つのコードベースで複数のパターンを使用できます。

ただし、コンポーネントを実装していて、パターンに従ってそれを使用する方法を公開している場合は、おそらくコンポーネントに固執するのが最善です。たとえば、RESTクエリクライアントにビルダーパターンを使用しているが、リソースの1つを別の方法で実装するとします。それは人々を混乱させるでしょう。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.