问题标签 [maintainability]

我正在决定一个框架来试用 PHP。我已将范围缩小到 CakePHP 和 CodeIgniter。对于使用过或熟悉两者的任何人，我有几个问题：

1. 我喜欢 CakePHP 默认将大部分代码保留在 webroot 之外的事实。特别是因为我最终可能会为多个应用程序使用单个框架安装。我看到 CodeIgniter 也会这样做，但是您必须对其进行配置并移动一些东西。这种解决方法是安全可靠的，还是事后才想到的黑客攻击？

2. 哪个（如果不是两者）更容易升级和长期维护？随着新版本的框架（和 PHP 本身）的出现。我不想发现我的东西坏了，或者变得过时了。

编辑：

这是一篇很老的帖子，但我想我会用我最终做的事情来更新它，那就是使用 Kohana。

我有一个 C 库，其中包含许多用于处理向量、矩阵、四元数等的数学例程。它需要保留在 C 中，因为我经常将它用于嵌入式工作和作为 Lua 扩展。此外，我有 C++ 类包装器，以允许更方便的对象管理和使用 C API 进行数学运算的运算符重载。包装器仅包含一个头文件，并且尽可能多地使用内联。

包装 C 代码与将实现直接移植和内联到 C++ 类中是否有明显的惩罚？该库用于时间关键型应用程序。那么，消除间接性带来的提升是否弥补了两个端口的维护难题？

C接口示例：

C++ 包装器示例：

我正在研究可以帮助我编写更小但更复杂的代码的算法。与其编写 150 行 if-else 语句，我可以设计一个算法，用 20 行来完成。问题是很多这些算法可能很复杂，需要大量的数学才能理解它们。我也是这里唯一了解他们的人。

为了代码的可维护性，像其他人一样编写代码会更好，还是使用算法更好？

I have come across the recommended values for a Maintainability Index (MI) as follows:

• 85 and more: good maintainability
• 65-85: moderate maintainability
• 65 and below: difficult to maintain with really bad pieces of code (big, uncommented, unstructured) the MI value can be even negative

Are these values are dependent on technology? For example, is a value of 70 good for Mainframes but difficult to maintain for Java?

Can use same yardstick independent of technologies?

假设您有一个程序当前按应有的方式运行。该应用程序背后的代码非常糟糕，占用大量内存，不可扩展，并且需要大量重写才能实现功能上的任何更改。

重构在什么时候变得比完全重建更不合逻辑？

我开始在代码中使用 LINQ 作为真正的查询语言来帮助提高可读性。直到最近我还害怕接触 LINQ，因为 LINQ to SQL 团队在实体框架团队下移动（试图忽略这里的对话）—— LINQ 查询语言是否会成为一个安全的赌注（就像任何东西一样快速搬家行业）？

我一直认为 SQL 编译器会崩溃，但显然嵌套几乎是无限的。这段代码是要立即丢弃还是有一线希望这样的东西可以运行？

这个查询并不真正属于我，所以我不能发布它......但是让我们假装它是这个：

我想坚持 Don't-Repeat-Yourself 原则，但有时当我将 PHP 与 HTML 和 CSS 一起编写时，如果我在不同的情况下重复使用相同的代码，我的代码很快就会有很多 if- then-else 代码不容易维护。

如果使用Smarty这个模板引擎，这可能是一个更大的问题，因为大多数代码编辑器不会匹配{if} {else} {/if} 所以程序员需要直观地寻找匹配的标签，并不容易当有 3 或 4 层嵌套 {if} {else} {/if} 时。

在这种情况下，有没有办法坚持 DRY，但仍然有良好的可维护代码？

这似乎引发了关于另一个问题的一些对话，我认为值得转入自己的问题。

DRY 原则似乎是我们解决维护问题的首选武器，但测试代码的维护呢？是否适用相同的经验法则？

开发人员测试社区中的一些强烈声音认为设置和拆卸是有害的，应该避免......仅举几例：

• 詹姆斯·纽柯克
• 杰伊菲尔兹[ 2 ]

事实上，xUnit.net 已经完全出于这个原因将它们从框架中删除了（尽管有一些方法可以绕过这个自我强加的限制）。

你有什么经验吗？设置/拆卸是否会伤害或帮助测试可维护性？

更新：像 JUnit4 或 TestNG（@BeforeClass、@BeforeGroups 等）中可用的更细粒度的结构会有所作为吗？

好的，这就是场景。

项目 A 有一个为它开发的类库（我们称之为 MyLib）。我发布了带有 MyLib 版本 1 的项目 A（内部项目）。

我开始在项目 B 上进行开发，但将 MyLib 扩展至版本 2，包括对现有类型的一些优化。

如果我将 Mylib 2 发布到项目 A 和项目 B，我将不得不重新编译项目 A 以支持类型更改，是否有人对此有经过尝试且真实的解决方案？