問題タブ [code-maintainability]

あなたのコードを維持することになる人があなたがどこに住んでいるかを知っている暴力的な精神病質者であるかのように常にコーディングしてください。

これは誰かのブログで見つけました、そしてそれはリック・オズボーンのものとして紹介します。しかし、私はこれをグーグルで検索し、他の人はこう言います：マーティン・ゴールディング、ジョン・ウッズ、ダミアン・コンウェイ...はい、ダミアン・コンウェイは「Perl Best Practices」（2005）でこの引用を使用しましたが、ダミアンは誰が書いたかについては言及していません。

この格言の本当の作者が誰であるかを誰かが知っていますか？

エラーコード、エラー文字列、ログ以外に、コードの実行時にデバッグ/トレース情報を取得するためにコードに組み込むことができ、実行時に問題をデバッグする（または何が起こっているのかを知らせる）のに役立つ機能はありますか？

単体テストで最大限のコード カバレッジを実行するのは良いことだということを常に学びました。また、Microsoft などの大企業の開発者は、実行コード自体よりも多くの行のテスト コードを記述すると言っているのも耳にします。

さて、それは本当に素晴らしいですか？メンテナンスをより困難にするだけの影響を与える完全な時間の損失のように思われることはありませんか?

たとえばDisplayBooks()、データベースから本のリストを生成するメソッドがあるとします。製品の要件では、ストアに 100 冊以上の本がある場合、100 冊のみを表示する必要があることが示されています。

したがって、TDD では、

1. BooksLimit()データベースに 200 冊の本を保存し、 を呼び出しDisplayBooks()、 を実行する単体テストを作成することから始めますAssert.AreEqual(100, DisplayedBooks.Count)。
2. 次に、失敗するかどうかをテストします。
3. 次にDisplayBooks()、結果の制限を 100 に設定して変更します。
4. 最後に、テストを再実行して、成功するかどうかを確認します。

BooksLimit()では、直接 3 番目のステップに進み、単体テストをまったく行わない方がはるかに簡単ではないでしょうか。そして、要件が 100 冊から 200 冊の制限に変更される場合、テストを変更し、テストを実行して失敗するかどうかを確認し、コードを変更して、テストを再度実行して成功するかどうかを確認する代わりに、1 文字だけを変更する方がアジャイルではありませんか?

注: コードが完全に文書化されていると仮定しましょう。それ以外の場合は、完全な単体テストを実行すると、ドキュメントが不足しているコードを理解するのに役立つと言う人もいますが、それは正しいでしょう。実際、BooksLimit()単体テストを行うと、表示する書籍の最大数があり、この最大数が 100 であることが非常に明確に示されます。非単体テストのコードにステップインすることは、はるかに困難です。for (int bookIndex = 0; bookIndex < 100; ...または実装されていますforeach ... if (count >= 100) break;。

WebサーバーとSQLServer2008データベースが同じサーバーファーム内の異なるボックスに配置されているWebアプリケーションがあります。

モノリシックストアドプロシージャをいくつかの小さなストアドプロシージャに分割して、クライアントコードが1つではなく複数のストアドプロシージャの呼び出しを担当するようにすると、Webアプリケーションのパフォーマンスが大幅に低下することに気付くでしょうか。

追加の背景情報：

決定ロジック、更新ステートメント、そして最後にデータのセットをクライアントに返すselectステートメントを含む数百行のコードを含むストアドプロシージャがあります。

コンポーネントDLLを呼び出すクライアントコード（この意味では、クライアントコードはデータベースサーバーを呼び出しているASP Webサーバー）に機能の一部を挿入する必要があります。ただし、ストアドプロシージャはレコードセットを更新し、同じ呼び出しで更新されたデータを返します。理想的には、決定ロジックと更新ステートメントが呼び出された後、データがクライアントに返される前に、コードを呼び出す必要があります。

この機能を機能させるには、既存のストアドプロシージャを少なくとも2つの部分に分割する必要があります。1つはデータベースを更新するストアドプロシージャで、もう1つはデータベースからデータを取得します。次に、これらのストアドプロシージャ呼び出しの間に新しいコードを挿入します。

この問題を見ると、コードメンテナンスの観点から、すべての更新と選択ステートメントをシンストアドプロシージャに分離し、ビジネスロジックをクライアントに任せる方がはるかに良いと思わざるを得ません。コード。そうすれば、クライアントコードに機能や決定ロジックを挿入する必要があるときはいつでも、巨大なストアドプロシージャを変更するのではなく、クライアントコードを変更するだけで済みます。

コードの保守の観点からは、シンストアドプロシージャを使用する方が良いかもしれませんが、データベースへのトリップ数を増やすと、パフォーマンスがどの程度低下しますか？データへの最終的な結果は同じですが、私はデータベースに頻繁にアクセスしています。アプリケーションをスケールアップして需要を処理する場合、このアプローチはパフォーマンスにどのように影響しますか？

私は、特にコードのメンテナンスに影響を与える場合に、パフォーマンスの最適化を何よりも優先するわけではありませんが、Webアプリケーションを拡張する必要があるときに、足を踏み入れて頭痛の種を作りたくありません。

私は.h最善の意図を持ってファイルを整理することから始めますが、どういうわけかそれらはうんざりするほど乱雑になります。

以下は例です（これはそれほど悪くはありませんが、私ははるかに悪いことを見てきました！）。でセクションをグループ化してみまし#pragma markたが、さらに乱雑に見えるようです。

すべてのUILabelsとUIButtonsは（上記のように）必須です。これらはWebサービスリクエストからのデータを表示しているため、InterfaceBuilderを使用してGUIを設計する場合はすべて必須です。たとえば、ラベルは製品の「重量」または「高さ」の特性である可能性があります。

誰かがこれらを最も保守可能で読みやすい方法で整理する方法について何か良いアドバイスがありますか？

乾杯

SQL Serverでは、テーブルに新しい列があります。

デフォルトの制約を指定せずにNOTNULLを指定したため、これは失敗します。テーブルにデフォルトの制約を設定しないでください。

これを回避するために、デフォルトの制約を使用してテーブルを作成し、それを削除することができます。

ただし、デフォルトの制約をこのステートメントの一部として指定する方法はないようです。そのため、デフォルトの制約を取り除く唯一の方法は、sys.default_constraintsでそれを検索するストアドプロシージャを用意することです。テーブル。

これは、頻繁に発生する可能性のある操作にとっては少し厄介/冗長です。誰かがこれに対するより良い解決策を持っていますか？

本The Art of Unit Testingでは、保守可能で読みやすい単体テストを作成したいということが述べられています。204 ページあたりで、1 つのテストで複数のアサートを避けるようにし、オーバーライドされた Equals メソッドでオブジェクトを比較する必要があると述べています。これは、期待される結果と実際の結果を比較するオブジェクトが 1 つしかない場合にうまく機能します。しかし、上記のオブジェクトのリスト (またはコレクション) がある場合はどうでしょう。

以下のテストを検討してください。複数の主張があります。実際、アサートを呼び出す 2 つの別個のループがあります。この場合、アサーションは 5 つになります。1 つのリストの内容が別のリストに存在することを確認する 2 と、その逆の 2 です。リスト内の要素の数を比較する 5 番目。

このテストを改善するための提案があれば、私はすべて耳にします。現在は MSTest を使用していますが、MSTest の Assert を流暢な API (Assert.That) 用の NUnits に置き換えました。

現在のリファクタリングされたコード:

元のマルチアサート単体テスト:

equalsとhashCodeのリフレクティブヘルパーメソッドを作成することを考えています。

• 等しい場合、ヘルパーメソッドはリフレクションAPIを調べてobjectAのフィールドを調べ、それらをobjectBのフィールドと比較します。
• hashCodeの場合、ヘルパーメソッドはフィールドへのリフレクションAPIを調べ、反復ループでhashCodeを計算します。

良い点は、equalsまたはhashCodeの実装でフィールドが欠落していることを心配しないことです。悪いことは、パフォーマンスだと思います。このアイデアについてどう思いますか？ご意見をお聞かせください！

これは、equalsの最初のドラフトです。

}

}

乾杯、ケビン

テクノロジー: - Java 1.5 または 1.6 - Hibernate 3.4

列名またはテーブル名の変更時に複数の場所で列名が更新されるのを避けるために、同じ定数ファイルが必要です。

次の質問がありますか?

• 考えられる解決策の 1 つは、データベース内のすべてのテーブルの列名の定数を格納する 1 つのグローバル ファイルを維持することです。お気に入り

  /li>

上記の場合、employees はテーブルの名前で、performance_desc は列名の名前です。そのため、2 つの異なるテーブルの 2 つの定数に列名がある場合に、それらの間の衝突を回避するために、定数の名前付けには tablename__columnname 形式が使用されます。

このアプローチの問題点の 1 つは、データベースが大きくなると、このファイル内の定数が数千に増え、管理が困難になることです。その他の問題は、テーブル名が変更された場合、すべてのテーブルのプレフィックス テーブル名を変更する必要があることです。

• 上記の例の列の名前を performance_desc から achievements_desc に変更するとします。この場合、定数も EMPLOYEE__PERFORMANCE_DESC から EMPLOYEE__ACHIEVEMENT_DESC に変更したいと思うでしょう。この場合、列名と定数名の両方を変更する必要があったため、コードで列名の代わりに定数を直接使用することはあまり見られませんが、定数名を変更すると、屈折を使用して定数を反映できるという利点が 1 つあります。名前の変更。定数をあまり使用していないか、間違った方法で使用しているようです。

• プロジェクトコードでは、テーブル列リストごとに1つのクラスを定義して、以下に示すように定数を定義しているようです。

  /li>

これにより、テーブル名の変更がクラス名の変更のみにつながるなど、グローバル ファイルに関するいくつかの問題を解決できます。これに関する大きな問題の 1 つは、定数を定義するためだけにクラスを使用していることです。これは、適切なコーディング方法ではありません。

• java 1.5または1.6で使用できるかどうか、および特定のシナリオで使用することをお勧めするかどうかは不明です。

• 指定された db 定数を定義するためのベスト プラクティスは何ですか?

• db 定数を使用することは本当に便利ですか?

• 上記のようにテーブルごとに1つのクラスを使用する場合、直面する1つの問題は命名規則です。テーブルの列の定数を定義するテーブルの名前と対応するクラスの名前との関係は何ですか。

• 上記のケースは、テーブル名ではなく列名のみのケースをカバーしています。コードでテーブル名ではなく定数を使用したい場合があるため、テーブル名の定数を定義するためのアプローチは何ですか。

• 製品または関連バージョンがリリースされると、テーブル名と列名はあまり変わらないとよく言われます。テーブル名と列名の変更は、ほとんどの場合、開発段階または機能強化 (新しいバージョン) で発生します。テーブル名または列名に定数を使用しないことは強い議論ですか?

  どうすれば質問をより表現しやすくすることができるか、または質問が投票されないために何が欠けているかを提案してください。

this、this、thisのように jquery を使用して dom 要素を挿入するグッド プラクティスに関する良い投稿を見つけました。

いくつかの要素を挿入する必要があるだけの場合は問題ありませんが、これらのオプションは保守性の観点から非常に悪いように思えます (コードは 2 回繰り返されるため、変更が必要な場合は 2 回行う必要があります。非常にエラーが発生しやすい)、

これは（ほんの一部）私が持っているものです

これを達成するためのより良い方法はありますか？jquery に dom ツリーの一部をコピーし、挿入するフラグメントとして使用するように指示する方法はありますか?

代替案を学びたい