問題タブ [maintainability]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
1533 参照

sql - 集計するか集計しないか、それがデータベース スキーマの設計上の問題です

最小/最大/平均のクエリを実行している場合、集計テーブルを使用するのと、単純に生のテーブルの行の範囲に対してクエリを実行するのとではどちらが好みですか?

これは明らかに非常に自由回答形式の質問であり、正解は 1 つではありません。そのため、人々の一般的な提案を探しているだけです。生データ テーブルが、タイムスタンプ、数値外部キー (ユーザー ID など)、および 10 進数値 (購入金額など) で構成されているとします。さらに、テーブルに何百万もの行があるとします。

私は両方をやりましたが、引き裂かれています。一方では、集計テーブルによってクエリが大幅に高速化されましたが、追加のテーブルが急増しました。集計範囲の現在の値を表示するには、元のデータ テーブルに完全に戻すか、より詳細な集計を組み合わせる必要があります。どの集計テーブルを照会するかをアプリケーション コードで追跡するのは、思った以上の作業であり、元の集計範囲では常に十分ではないため、スキーマの変更が必要になることがわかりました ("しかし、過去 3 回の支払い期間の売り上げです!」)。

一方、生データからのクエリは非常に遅くなる可能性がありますが、データ範囲について非常に柔軟に対応できます。範囲の境界が変更された場合、集計テーブルを再構築するのではなく、クエリを変更するだけです。同様に、アプリケーション コードの更新も少なくて済みます。インデックス作成についてもっと賢くなれば (つまり、常に適切なインデックスをカバーしていれば)、生データから選択する際のペナルティを減らすことができると思いますが、それは決して万能薬ではありません。

両方の長所を活かす方法はありますか?

0 投票する
6 に答える
570 参照

jquery - jQueryのリファクタリング/メンテナンス

私はSOを少し検索しましたが、私を助けてくれる質問/回答は見つかりませんでした。問題は、jQuery 関数呼び出しが大きくなりすぎて維持できないことです。もっとリファクタリングする必要があるのか​​、それともこれらすべての呼び出しを行うためのより良い方法があるのか​​ 疑問に思っています。1 つの呼び出しを行うと、関数の引数である無名関数が非常に大きくなり、コードの可読性が大幅に低下することがわかります。理論的には、これらすべてを独自の機能に分割することはできますが、それがベスト プラクティスであるかどうかはわかりません。これまでの jQuery の例を次に示します。

ご覧のとおり、私が呼び出している関数の多くは関数を引数として取るため、匿名関数を作成すると、最終的に大混乱になります (このコードには、さらに約 3 つの匿名関数宣言がありました)。

単純に一連の関数を作成し、それらを呼び出して読みやすくする必要があります。私がこれに反対する唯一の理由は、一度しか使用されない宣言された関数がたくさんあるからです。

助けてくれてありがとう!

0 投票する
7 に答える
670 参照

maintainability - コーディングの実践: 170 万の LOC プロジェクトについてどう思いますか?

「エンジン」は 1.3 ではなく、現在は 170 万行のコードであると述べているパネル ディスカッションを聞いています。それは私を怖がらせます。その行数やモジュールの量などを想像することはできません.C++は他の言語ほどモジュールを処理できないといつも感じていました。大規模なプロジェクトは管理が難しく、コード行を合理的に抑えることが好ましいと感じました。10kラインを打つと違和感があります。20k、50k、500k、または 100 万がどのように感じられるか想像できません。

この規模のプロジェクトを開発および維持する際に、どのような慣例がありますか?

0 投票する
2 に答える
16311 参照

c# - Visual Studio でのコード メトリクスの計算

次のコード メトリクスの計算に適したスコア範囲は?

  • 保守性指標
  • 循環的複雑度
  • 継承の深さ
  • クラスカップリング
0 投票する
1 に答える
105 参照

.net - 同じフレームワークとアプリケーションの2つのバージョンを維持する

ハードウェアデバイスを制御する.NETで作成されたフレームワークがあります。フレームワーク全体がMEFを使用するため、インターフェイスに大きく依存します。

私たちの制御が及ばない理由で、ハードウェアを変更する必要があり、それにはいくつかのインターフェースにいくつかの重大な変更が必要でした。

古いハードウェアのプロジェクトはしばらく保留され、新しいバージョンのフレームワークを使用するグラフィカルアプリケーションの作業を開始しました。

さて、ずっと後になって、彼らは私たちに古いハードウェアを再びサポートすることを望んでいるので、古いフレームワークを使用して2つのバージョンを維持するために既存のグラフィカルアプリケーションをバックポートすることを考えています。

フレームワークは、複数のプロジェクトを含む1つのVisual Studioソリューションであり、グラフィカルアプリケーションは、いくつかのプロジェクトを含む別のVisualStudioソリューションです。

一部の部分(フレームワークソリューションのプロジェクト)は、変更されたインターフェイスに依存していませんでしたが、他の部分は依存していました。

ソース管理用に、Subversionリポジトリがあります。

誰かがこのようなものを管理した経験がありますか?ベストプラクティスはありますか?提案?

0 投票する
4 に答える
4533 参照

android - アプリケーションの無料バージョンとプロバージョンの両方を維持する

Android用のアプリケーションのPROバージョンを作成したいのですが、リポジトリを構造化する方法を考えていました。

知っているので、私はトランクと機能ブランチを持っています。プロバージョンを別のブランチに配置したいのですが、もっと良い方法があるのでしょうか?たとえば、2つのブランチを作成する必要があります。1つは無料バージョン用、もう1つはプロ用ですか。

Proバージョンには追加機能があり、広告はありません。プロバージョンにAdMobライブラリを含めたくありません。

この場合、リポジトリを構造化するための最良の方法について、経験や提案はありますか?

編集:私はこのスレッドで(私のアプリに)最適な解決策を見つけたと思います:http://groups.google.com/group/android-developers/browse_thread/thread/4ad3d67f735f16d7/948b4f9eee2490a3

そこで説明されているトリックは、実際のアプリケーションでPRO機能のロックを解除する目的でのみ機能する別のアプリケーションを用意することです。ロック解除アプリは市場で支払われ、実際のアプリはデバイス上に存在するかどうかを確認するだけです。

0 投票する
1 に答える
68 参照

language-features - コードを非常に簡単に保守できるようにする特定のプラクティス、設計、言語/機能は何ですか?

コードを非常に簡単に保守できるようにする特定のプラクティス、設計、言語/機能は何ですか?

0 投票する
2 に答える
167 参照

php - 保守が容易で結合の少ないプログラムの作成方法を教えている本/チュートリアル?

私は PHP プログラマーであり、自分のコードの品質を向上させたいと思っています。そして最も重要なことは、プログラミングが上手になりたいということです。

結合が少なく保守が容易なプログラムを作成する方法を教えてくれる、どの本、チュートリアル、または記事を読むことをお勧めしますか? PHP、特に CakePHP フレームワークに関する特定のヒントはありますか?

前もって感謝します!

0 投票する
2 に答える
123 参照

function - トグル機能の有用性

明示的に何かを行う関数を作成する方が良いですか (つまり、HideForm/ShowForm など...)

それとも、「トグル」タイプの関数 (つまり、ToggleVisibility) を作成する方が良いですか?

コードを読んで状態を追跡するのは難しいため、トグル型の関数は扱いにくいと思います。

トグル型の機能どのような場面で役立ちますか?

0 投票する
8 に答える
471 参照

maintainability - 後悔したり、後回しにしたりしてしまうプログラミングの近道は何ですか?

この質問を見て、古い DataGrid の AutoGenerateColumns を思い出しました。それらを数回使用しましたが、標準の「データソース列を吐き出す」を超えたデータフォーマットが必要だったため、最終的にバックアウトしました。同様に、toggle を使用すると、時間の節約になるように思えますが、状態などを追跡する必要が生じ、それに応じてコードを書き直します。

時間の節約になると思って使っていたのに、必要な機能がなくて使い物にならなくなったものはありますか?