1

当我开始制作一个移动应用程序(在服务器上使用 laravel)时,我决定不深入研究测试或编码标准,因为我认为最好先真正获得一个工作应用程序。

几个月后,我有了一个可以工作的应用程序,但我的代码没有遵循任何标准,也没有编写任何测试。

我正在使用的当前目录结构是:

在此处输入图像描述

app/controllers:包含应用程序使用的所有控制器。控制器并不是很薄,它们包含大部分逻辑,其中一些甚至有多个条件语句(if/else)。所有数据库交互都发生在控制器中。

app/models:定义与其他模型的关系,并包含与特定模型相关的某些功能,例如。验证功能。

app/libraries:包含自定义帮助函数。

app/database:包含迁移和种子。

我的应用程序目前正在运行,松弛的原因可能是因为我独自在应用程序上工作。

我的担忧:

  1. 我应该继续发布应用程序,然后看看它是否值得努力重构,还是我应该先重构。

  2. 我确实希望重构代码,但我不确定我应该采取什么方法。我应该首先获得正确的标准,然后让我的代码可测试吗?还是我不应该担心标准(并继续使用类映射来自动加载)并尝试让我的代码可测试?

  3. 我应该如何构建我的文件?

  4. 我应该在哪里放置接口、抽象类等?

注意:我正在从我能找到的任何资源中挖掘测试和编码标准,但如果你们能指出一些资源,我将不胜感激。

4

1 回答 1

2

哦亲爱的。遗留代码的经典定义是没有单元测试的代码。因此,现在您处于不幸的境地,如果您必须修改/增强/重用此代码库,您将不得不承担大量成本。您获得的当前实施距离越远,成本就会越高。这就是所谓的技术债务。拥有可测试的代码并不能摆脱它,它只是降低了利率。

你应该这样做吗?好吧,如果您现在发布,并且它获得了一定的知名度,因此需要做更多的事情...

如果它会以完全冷漠或沮丧的尖叫来接收,那么发布它根本没有意义,事实上这会适得其反。

如果您选择继续使用代码库,如果没有单元测试来证明您没有破坏应用程序,我看不到任何有效的方法来重构编码标准。如果您发现可测试和测试的编码标准不是其中的关键部分,请忽略它,这是胡说八道。

当然,您仍然存在如何更改代码以使其可测试而又不破坏它的问题。我怀疑你可以在你的胖控制器中通过说委派来迭代这一点,而不会有太大的困难。两个关键点。至少先做一些测试,即使它是完全手动的,在你做任何事情之前先打印出网页。一组集成测试,也许使用自动化套件会非常有用,尤其是在您已经遇到耦合问题的情况下。

另一个是,不要一次进行太多更改,太多我的意思是应用程序中有多少操作会受到此代码的影响。

如果您想了解更多信息,Robert C Martin(没有任何隶属关系)的 Working With Legacy Code 将是一个不错的选择。

希望这个教训已经被吸取了。不要再这样做了。

最后但并非最不重要的一点是,做这种练习是一种很好的学习体验,请放心,您会遇到(很多)这种常年错误的情况。

于 2014-07-10T17:15:36.803 回答