問題タブ [maintainability]

PHP で試すフレームワークを決定しています。CakePHP と CodeIgniter に絞り込みました。両方を使用したことがある、またはよく知っている方にいくつか質問があります。

1. 私は、CakePHP がデフォルトでほとんどのコードを webroot の外に保持しているという事実が気に入っています。特に、複数のアプリに対して 1 つのフレームワーク インストールを使用することになる可能性があるためです。CodeIgniter もそれを行うと思いますが、それを構成していくつかのものを移動する必要があります。その回避策は安全で信頼できるものですか、それとも後付けのハックですか?

2. 両方ではないにしても、どちらがアップグレードしやすく、長期にわたって保守しやすいですか? フレームワーク (および PHP 自体) の新しいバージョンが登場すると。自分のものが壊れたり、時代遅れになったりしたくありません。

編集：

これは非常に古い投稿ですが、Kohana を使用するという最終的に行ったことで更新すると思いました。

ベクトル、行列、四元数などを処理するための多数の数学ルーチンを備えた C ライブラリがあります。組み込み作業や Lua 拡張としてよく使用するため、C のままにしておく必要があります。さらに、より便利なオブジェクト管理と、C API を使用した数学演算の演算子のオーバーロードを可能にする C++ クラス ラッパーがあります。ラッパーはヘッダー ファイルのみで構成され、インライン化が可能な限り使用されます。

C コードをラップすることと、実装を C++ クラスに直接移植してインライン化することとの間に、かなりのペナルティがありますか? このライブラリは、タイム クリティカルなアプリケーションで使用されます。では、インダイレクションを排除することによるブーストは、2 つのポートのメンテナンスの頭痛の種を補うのでしょうか?

C インターフェイスの例:

C++ ラッパーの例:

小さくても複雑なコードを書くのに役立つアルゴリズムについて勉強しています。150 行の if-else ステートメントを書く代わりに、20 行でそれを行うアルゴリズムを設計できます。問題は、これらのアルゴリズムの多くが複雑になる可能性があり、それらを理解するために多くの計算が必要になることです。彼らのことを理解しているのも、この辺では私だけです。

コードの保守性のために、他の人が行うようにコードを書く方が良いでしょうか、それともアルゴリズムを使用する方が良いでしょうか?

保守性指数（MI）の推奨値は次のとおりです。

• 85以上：良好な保守性
• 65-85：中程度の保守性
• 65以下：本当に悪いコード（大きな、コメントされていない、構造化されていない）で維持するのが難しいMI値は負になることさえあります

これらの値はテクノロジーに依存していますか？たとえば、70の値はメインフレームには適していますが、Javaでは維持するのが難しいですか？

テクノロジーに関係なく同じ基準を使用できますか？

可読性を向上させるために、コードで真のクエリ言語としてLINQを使用し始めています。最近まで、LINQ to SQLチームがEntityFrameworkチームの下に移動したため（ここでその会話を無視しようとしているため）、LINQに触れることを恐れていました-LINQクエリ言語は今後安全な賭けになります（これほど高速なものと同じくらい）引っ越し業界）？

Do n't-Repeat-Yourselfの原則を守りたいのですが、PHPをHTMLとCSSと一緒に作成するときに、同じコードをさまざまな状況で再利用すると、すぐにコードに非常に多くのコードが含まれるようになります。それ以外の場合、コードは簡単に保守できません。

ほとんどのコードエディタは{if}{else}{/ if}と一致しないため、テンプレートエンジンであるSmartyを使用する場合、これはより大きな問題になる可能性があります。したがって、プログラマーは一致するタグを視覚的に探す必要があり、簡単ではありません。ネストされた{if}{else}{/if}のレベルが3つまたは4つある場合。

そのような状況では、DRYに固執する方法はありますが、それでも優れた保守可能なコードがありますか？

これは別の質問について少し話し合うきっかけになったようで、私はそれ自身の質問にスピンする価値があると思いました。

DRYの原則は、メンテナンスの問題と戦うための私たちの選択の武器のようですが、テストコードのメンテナンスについてはどうでしょうか。同じ経験則が適用されますか？

開発者テストコミュニティのいくつかの強い声は、セットアップと分解は有害であり、避けるべきであるという意見です...いくつか例を挙げると：

• ジェームス・ニューカーク
• ジェイフィールズ、[ 2 ]

実際、xUnit.netは、まさにこの理由でフレームワークからそれらを完全に削除しました（ただし、この自主的な制限を回避する方法はあります）。

あなたの経験は何ですか？セットアップ/ティアダウンは、保守性のテストに悪影響を及ぼしますか、それとも役立ちますか？

更新：JUnit4やTestNG（@ BeforeClass、@ BeforeGroupsなど）で利用できるようなよりきめ細かい構造が違いを生むでしょうか？

さて、これがシナリオです。

プロジェクトAには、そのために開発されたクラスライブラリがあります（これをMyLibと呼びます）。MyLibのバージョン1でプロジェクトA（社内プロジェクト）をリリースします。

プロジェクトBで開発を開始しましたが、既存のタイプに対するいくつかの最適化を含めて、MyLibをバージョン2に拡張します。

Mylib2をプロジェクトAとプロジェクトBの両方にリリースした場合、タイプの変更をサポートするためにプロジェクトAを再コンパイルする必要がありますが、これに対する解決策が試されて真実である人はいますか？