問題タブ [maintainability]

PHP や JavaScript などのインタープリター型プログラミング言語では、手続き型アプローチよりもオブジェクト指向アプローチを採用すると、どのような影響がありますか?

特に私が探しているのは、Web アプリケーションを作成し、速度だけでなく保守性も最適化するために、手続き型アプローチとオブジェクト指向アプローチのどちらかを選択する際に考慮すべき事項のチェックリストです。これをさらに調査する記事を知っている場合は、引用された研究とテストケースも役立ちます。

結論: インタプリタ言語で OO と手続き型を使用した場合、実際にパフォーマンスへの影響が (あるとすれば) どのくらい大きいのでしょうか?

複数のエンティティのデータを管理する Web サイトを開発しています。エンティティ間でデータは共有されませんが、同じ顧客が所有している可能性があります。顧客は、単一の「ダッシュボード」からすべてのエンティティを管理したい場合があります。では、すべてに対して 1 つのデータベースを使用する必要がありますか?それとも、データを個別のデータベースに分離しておく必要がありますか? ベストプラクティスはありますか? 持っていることのプラス/マイナスは何ですか:

• サイト全体のデータベース (エンティティには「customerID」があり、データには「entityID」があります)
• 顧客ごとのデータベース（データには「entityID」があります）
• 各エンティティのデータベース (データベースと顧客の関係はデータベースの外にあります)

複数のデータベースを使用すると、パフォーマンスが向上する (行と結合が少なくなる) ように見えますが、最終的にはメンテナンスの悪夢になる可能性があります。

McCall の Quality Modelによると、製品改訂は、ソフトウェア製品の品質属性を説明するための 3 つの主要な視点の 1 つです。製品改訂の観点では、保守性(欠陥を見つけて修正する能力) は、ソフトウェアを改訂する能力に影響を与える主要な品質要因として識別されます。

明らかに、改訂プロセスのある時点で、人間の関与、特にプログラマーの関与が必要になります。コードのフォーマットは、ソフトウェアを効果的かつ効率的に修正するプログラマーの能力に影響を与えます。

コード改訂プロセスでプログラマーの効率と有効性を最大化するために、一般的に受け入れられている、言語に依存しないコード フォーマット ガイドラインは何ですか?

私が現在書いているソフトウェアのいくつかは、30 年後に使用されると思います。しかし、その多くが 1970 年以降の秒数として時間を公開するという UNIX の伝統に基づいていることも認識しています。

実行結果は次のとおりです。

• 1970 年 1 月 1 日（木）00:00:00
• 土 8 月 30 日 18:37:08 2008
• 火曜日 1 月 19 日 03:14:07 2038
• 金 12 月 13 日 20:45:52 1901

関数 ctime()、gmtime()、および localtime() はすべて、エポック (00:00:00 UTC、1970 年 1 月 1 日; time(3) を参照) からの秒数を表す時間値を引数として取ります。

この分野でプログラマーとして何か積極的にやるべきことがあるのだろうか、それともすべてのソフトウェア システム (別名オペレーティング システム) が将来何らかの方法で魔法のようにアップグレードされると信じていいのでしょうか?

更新実際、64 ビット システムはこれから安全であるように思われます。

• 1969 年 12 月 31 日水曜日 16:00:00 PST
• 2008 年 8 月 30 日 12:02:40 PDT
• 8 月 16 日（土）23:12:55 PST 292278994
• 日 12 月 2 日 08:47:04 PST 292269055

しかし、292278994 年はどうでしょうか。

CSS（特に色）で値を再利用することは、そのCSSを維持することになると私にとって常に問題でした。変数を作成するため、または一般的にCSSで保守性を向上させるための最良のツールは何ですか？

非常に大規模なデータ セットを毎月処理する一連の大規模で複雑なストアド プロシージャを継承しようとしています。

VB6 で書かれた元のプロセスと一致するように、それらをデバッグ中です。t-sql で書き直すことにした理由は、vb プロセスに数日かかり、この新しいプロセスに数時間かかるためです。

これですべて問題ありませんが、これらの大量の t-sql コードのチャンク (1.5k 行以上) をリモートで読み取り可能/保守可能にするにはどうすればよいでしょうか。

t-sql をあまり頭が痛くならないようにした経験があれば大歓迎です。

私は、異なるプログラミング言語でいくつかの異なるが関連するプロジェクトに取り組んでいます。これらのプロジェクトのいくつかは、他のプロジェクトによって書かれたファイル名を解析する必要があり、特定のファイル名パターンを想定しています。

このパターンは現在、いくつかの場所といくつかの言語でハードコーディングされており、保守爆弾になっています。特定のプロジェクトでこのパターンを 1 回だけ定義するのはかなり簡単ですが、すべてのプロジェクトと使用中のすべての言語に対して、このパターンを 1 回だけ定義する手法は何ですか?

私はかなり複雑なプロジェクト、カスタム暗号化ルーチンに取り組んでいます (楽しみのために)。コード レイアウトを設計する際にこの問題に遭遇しました。

インデックスで呼び出せるようにしたい関数がいくつかあります。具体的には、暗号化プロセスのためにランダムに呼び出すことができる必要がありますが、復号化プロセスでは特定のインデックスによってそれに対処します。

私は古典的な関数配列を検討していましたが、私の主な懸念は、関数配列は維持するのが難しく、少し醜いということです。(目標は、コンパイル時間を短縮し、コードを管理しやすくするために、各関数ペアを個別のファイルに入れることです。) 関数配列の代わりとして、より洗練された C++ ソリューションを持っている人はいますか? 速度はそれほど問題ではありませんが、保守性が心配です。

-ニコラス

私は何人かの Python プログラマーがかなり一貫して次のスタイルを使用しているのを見てきました (スタイル 1 と呼びます):

このスタイルをサポートするために、「明示的は暗黙的よりも優れている」という格言を引用できます。他のプログラマーがこのスタイル (スタイル 2) を使用しているのを見てきました。

スタイル 2 に見られる主な利点は保守性です。特にダック タイピングの理想では、some_module を some_other_module に交換したいと思うかもしれません。また、スタイル 2 は「読みやすさが重要」という格言でポイントを獲得していると感じています。私は反対する傾向がありますが、検索と置換は、最初のスタイルを使用する場合と同様に優れたオプションであると常に主張できます。

補遺:スタイル 1 で からへasの切り替えを解決するために使用できることに注意してください。現在のモジュールに実装することを決定することも一般的であることを忘れていました。これにより、同等のコンテナーの作成が少し厄介になります。some_modulesome_other_modulesome_identifiersome_module

クライアントのニーズとより一般的なロードマップのリズムで進化するソフトウェア製品があります。

私たちは SCRUM プロジェクト環境にいるため、新しい機能が製品に導入されることが非常に定期的に発生し、次の選択に直面します。

• この機能をすでにリリースされているブランチに実装する (実際にはブランチを持つポイントではありません)
• 新しいブランチを作成します - しかし、その後、3 週間ごとにブランチを作成し、もはや維持できなくなります

新機能をリリースしないという選択肢はありません。クライアントは、必要な機能を取得するための長期的なマイルストーン計画を待ちたくありません。また、機能をクライアント モジュールに移動することが常に可能であるとは限りません。変更が必要になる場合もあります。商品の核となる...

この種の制約が与えられた場合の優れた実践についてのフィードバックはありますか?