ジェネリックコードまたは理解しやすいコード？

プログラミング時と同じルールを使用してテンプレートを構成する必要があります。これは本質的に、重複を避けるために共通の設計要素を別々のファイルに抽出することを意味し、したがってより再利用可能な設計を実現します。これがルール＃1（ DRY ）であり、このメソッドはプログラミング用語でリファクタリングと呼ばれます。

2番目のルールは、シンプルさと明快さ。レイアウトや、変更が必要なときにどこに行くべきかを理解しやすいはずです。

文字の最初のルールに従うと、GUIが大量に分解され、レイアウトがどのように作成されるかを理解するのが難しくなる可能性があります。あなたは物事がどこにあるかを見つけるためにたくさん探し回らなければなりません。これは2番目のルールに違反しているため、これら2つの反対のバランスを見つける必要があります。

しかし、最善のアプローチは、この問題を完全に回避する解決策を見つけることです。この場合、より単純なアプローチをまとめて検討する必要があると思います。これはHTMLであり、GUIで「単純で高度な」状態について言及していると思います。 常に すべてのフィールドを生成し、JavaScriptでGUIロジックを処理することを検討しましたか？言い換えると、どのモード（状態）にあるかに応じて、関連するフィールドをその場で表示および非表示にするクライアント側のコードを記述しますか？

これには、サーバーを使用せずにオンデマンドでモードを切り替えることができるという利点もあり、ルールを妥協する必要はありません。もう1つの優れた点は、フロントエンドの人に任せることができることです。これらの変更を行うには、通常は設計と相互作用の調整と洗練に時間を費やすことにそれほど熱心ではないバックエンドプログラマーを関与させる必要はありません。

コメント

• JSの方が単純であることに同意しません。なぜですか？私の同僚のほとんどは、JSとJavaのWebフレームワークでJS（Richfaces、GWT）を無視できるようになっていることをますます知らないのです。 ）ほとんどすべての企業がJSを気にかけていません（これまでにインタビューしたすべての企業でJSの質問が1つあったと思います）。したがって、同僚はそのコードに触れず、コードがあれば書き直します。あなたのアイデアは良いですが、現実的ではありません。さらに、ロジックの一部をJavaに、一部をJSに保持するのはなぜですか？それが、ストアドプロシージャが停止した理由だと思います（そして私はliを実行しました）それらをke）。
• @ 0101JSが何よりも単純または難しいとは言いませんでした’それはあなたのスキルに依存します。有能なhtmlコーダーがあれば、これは問題にはなりません。 GUIの問題を（それが属する）GUIレイヤーに延期することで、多くの場合、はるかに単純な解決策になってしまうと言いました。これは、GUIが非常に動的でインタラクティブであり、JSのような言語のために作られているためです。 “どの企業もJSを気にしないと思っているからといって”、’私の主張はあまり有効ではありません。
• そのようなことだと思います。問題は私の状況で何をすべきかであり、あなたの答えは”ストアドプロシージャを使用する”これは、誰も使用していないため無効であり、なぜ使用したのか理解するのが難しいでしょう。 ‘私は’自分の選択が最善であると100％確信していないので、将来的にどちらの方法が良いかを尋ねています（現在は最善の方法は、迷惑な同僚を無視することです。
• @ 0101：WebとHTMLの操作は、多かれ少なかれJavaScript（およびHTTPとCSSと画像…）を意味するため、’ JavaScriptがオプションであると仮定したことで私を責めます。 ‘私が’ Swingで書くように頼んでいるのとは違います。
• “ほとんどすべての企業がJSを気にかけていません”-あなたはそれを真剣に信じていますか？ Web上の豊富なインターフェイスは、長年にわたってクライアント側の方向に進んでいます。

コードが表示されない場合、私はしかできません。推測しますが、現時点ではコードは「エッジ」にあると思います。

2つまたは3つのモードで、これらのモード間の変更回数が限られている場合これでおそらく大丈夫です。ただし、もっと複雑な場合は、別のページにリファクタリングする必要があるように思われます。

個人的には、コードを理解しやすい方が好きです。他の開発者にとっても自分自身にとっても、はるかに保守しやすいです。 6か月後にもう一度取得する必要があります。

ただし、将来存在しない可能性のある問題を解決するために、コードを今リファクタリングする意味はありません。 。要件がどの程度変更されるかわからないということですが、これには変更は含まれていません。そのため、YAGNI（You Ai n “t Gonna Need It）を適用しても、今は何もしません。

コードを次のようにマークします。将来的に注意を払う必要があるので、忘れないでください。ただし、今は変更しないでください（そして壊れてしまう可能性があります）。

コメント

• + 1-疑問がある場合は、簡単に理解してください。一般的なものにする必要があるかどうかについて頭の後ろにあるナグは、’ tをすべきではないことを伝える自然な方法です。

私はほとんど同じことをしました。私を信じてください、モードごとにいくつかの異なる動作を実装した後、「メインページ」はほとんど読むことが不可能になります。その場合、制御フローブロックの束のみが表示されます（すぐにマトリックスデジタルレインが続きます）。特定のモード内の内容を明確に把握するために、いくつかのブロックを削除していることに気付きました。

したがって、「個別のページ」が最適です。ただし、これを行う場合は、「 「戦い」のコード重複の問題。これは、マージを提案することによって同僚が間違っている可能性がある場所です。残念ながら、私もそうしました。基本的には機能しますが、多くの貴重な時間を消費し、最終的にはマージが不十分なため、ページの「共通領域」が同期しなくなり、マージは実際の悪夢になります。したがって、合理的な解決策としてマージに反対するのは正しいことです。

多くの回答からわかるように、正しいアプローチは、外部エンティティ（JSPページフラグメント、JSFスニペットなど）に真に「共通の」部分を抽出することです。

コメント

• 一般的なコードがコントロールだけであるという本当の問題h：inputText + h：outputText for単一フィールド。私はそれと戦う価値がないと感じています。さらに、このページは、モードが原因で、他の開発者にとっても混乱するため（ユーザーの観点から）、実際には機能しないために死ぬ可能性があります。
• したがって、問題は実際にはいつ移行するかです。変更するたびに分割を再検討する必要があります。ページが乱雑になり始めたら、分割します。同僚のアイデアは良いと思うが、まだ実装する価値がないと考えると、同僚もより快適になると思います。

コードの複製は実際には決して良いことではありません。とは言うものの、実際には2回以下の少量の複製は許容されます。それについて宗教的であるよりも、実用的である方がよいでしょう。あなたの場合、それは大量のコードと3つの場所のように聞こえるので、それは私の個人的なしきい値をわずかに超えています。したがって、私は汎用バージョンに傾いています。とにかく、今うまくいったら、理論的な理由だけで触れる必要はありません。

OTOH将来、ページ間でさらに違いが出る可能性があると言うと、これはある時点で、別々のページに切り替える方が経済的になります（共通点を可能な限り抽出することで、ページ間の重複を最小限に抑えるように努めます）。したがって、将来の各変更の前に状況を再評価してください。

これはJSFのように見えます。各rendered = “…”は基本的に、コードにifが含まれていることを意味し、さらに複雑になります。

「同じページですが、ここにいくつかの違いがあるだけなので、同じことをしました。簡単に言えば、 であるため、長期的にはは機能しません。 / em>同じページであり、適切に機能させるには、ますます複雑なトリックを実行する必要があり、保守が不必要に困難になります。

JSPの代わりにファセットでJSFを使用する場合（可能であれば）、ページのブロックに対応するXMLフラグメントを作成し、必要に応じて含めることができます。これにより、モジュール性が購入され、ページ間でコンテンツを再利用できます。

同僚の話を聞いてください。彼は正しいです。

コメント

• 私の編集をご覧ください
• @ 0101、私は疑いました。まさにこれです。’しないでください、それは狂気への道です-おそらくあなたにとって-
• 本当の問題は、私のやり方が最善の方法であるということです。もし私が3ページをやったとしたら、誰かが1ページだけを変更し、他のページについては考えないでしょう。私のバージョンを将来のメンテナとして欲しいです。
• 私のコードは、将来のメンテナに他のケースについて考えさせていると思います。プロジェクトの新しいプログラマーであり、デバッガーでbaseFormBasic.xhtmlのコードを変更する必要があることがわかった場合、baseFormAdvとbaseFormSpecでもコードを変更しますか？
• @ 0101、なぜ最適なものを尋ねるのですか？先入観を確認したいだけの場合は？

ページを生成する機会はありますかコードを使用していますか？この場合、次のようになります。

page1 = { showField1 = true; showField2 = false; showField3 = true; } page2 = { showField1 = true; showField2 = false; showField3 = false; } 

ページレンダリングコード

if page.showField1 then .... if page.showField2 then .... 

またはOOPスタイルの場合：

class Page1 { renderField1() { ...} renderField2() {} renderField2() { ...} } class Page2 { renderField1() { ...} renderField2() {} renderField2() {} } 

コメント

• いいえ、変更はありません。やったら十字架につけられます。さらに、まったく同じ問題が発生します。 if ==レンダリングされます。
• ページロジックを抽出するため、正確な問題ではありません。 2つではなく1つのタスクのみを実行します。
• たぶん、同じように感じます。私の理由は、フィールドの表示が異なるのは1つだけであり、配置も異なり、場合によってはラベルも異なるためです。それに加えて、そのWebプログラミングなので、’このようにすることはできません。

モーダルコードは悪化するだけです。開始時に一度分類して決定し、モードのないクリーンな実装に分岐します。

コメント

• isn ‘ tコードの重複は最悪ですか？すべてのコードは常に相互に同期する必要があります（単純に変更する場合は、advanceを変更することを忘れないでください。忘れた場合はどうなりますか？）
• サブルーチン、関数、ヘルパー/基本クラスなどで共通コードを分離します。 ; OOPでは、モーダルコードはクラスが欠落していることを示します…

この質問の本質いくつかの小さな違いがある3つの非常に類似したWebページがある場合、それらの3つのページを複製して必要に応じてそれぞれを変更するか、単一のページにロジックを組み込んで、どの「モード」に従ってページを動的にレンダリングするかをお勧めします。 “が表示されています。

記録のために、私はJSFの人で、それが好きで、条件付きレンダリングを利用しています。

3ページを選択した場合、変更が発生すると、メンテナが3ページすべてに正しく適用できない可能性があります。

条件付きレンダリングの使用を選択した場合、その問題は解決しますが、ビジネスロジックをページに移動したため、検討が必要になる場合があります。

個人的には条件付きレンダリングの使用に問題はありませんが、モードロジックがバッキングBeanに移動されることを本当に望んでいます。例：代わりに：

<h:output rendered="mode=2" value="Name: " />

好きなもの：

<h:output rendered="#{myBean.advancedMode}" value="Name: " />

Beanが処理する場所ロジックであり、trueまたはfalseを返し、要素のレンダリングを制御します。

理由は、表示されているモードがこの1ページ以上を制御する必要がある場合、ユーザーの単一セッションを超えて永続化する必要がある場合、またはモードを完全に変更する必要がある場合があるためです。道路。

または、どちらのアプローチにも潜在的なマイナス面があることを認めることができます。すべてのマイナス面は、将来の痛みを和らげることに関するもののようであり、それらの「将来」のいずれかが発生した場合は、さらに心配することに同意します。 実際に出てきて、要件がどのように変化するかについて実際に多くのことがわかったので、より良い決定を下します。