Django:如何评估重构项目

在一个相当大的网站上工作了一年多后,我注意到的主要是关于我们的设计/编码。它不是纯粹的重构相关的,可能您已经知道很多了,但也许它可以帮助您:)。

1. 最重要的是,我们并不总是把代码放在正确的位置。视图方法中的功能太多,表单和模型中的功能太少。我经常看到这个问题。要处理输入,请使用表单,格式化/调整/…模型数据,使用模型方法或属性。说真的,有一次我把150行的视图缩小到了20行,只是把代码放在更好的地方。很好地提高了可维护性和可读性
2. 我们编写的许多代码实际上并没有真正使用Python和/或Django的全部功能。对于第一个,读一些像 Dive Into Python 这是一个很大的帮助,在第二个方面,我跟踪了我们构建的所有复杂的构造(大部分是0.96的遗留代码),并查看了django文档中是否有其他的选择。当然,不要浪费时间试图将所有内容都简化为一行程序,但当然,使用遗留代码,这有助于提高可读性和可维护性。
3. 总是在网站上看起来像 django-snippets , google code ,…如果有体面的现有Django项目,可以带走你的很多功能。通常,这些项目被更多的人关注,因此更稳定和更具执行力。如果一个项目不能满足你所有的需求,那么它甚至可以是一个好主意,只需自己添加需求,而不是为你的站点定制。
4. 尽量减少应用程序的交叉依赖关系。当你绘制一个依赖关系图(例如通过链接每个有外键的应用程序)时,它应该是清晰的,而不是每个应用程序链接到任何其他应用程序的地方。通常,您会有一些“帮助”应用程序(如用户系统、标签),许多应用程序都使用这些应用程序,而所有其他应用程序实际上都只依赖于这些应用程序。
5. 写测试,Django有一个优秀的测试套件,所以使用它。当然,对于许多应用程序所共有的部分代码,这些代码可能会改变。真的,没有什么比突然注意到4个月前你解决的一个bug更让人恼火的了,你也不知道从那以后哪个更新又坏了。
6. 再看一看数据库规范化,django-orm模型仍然与关系数据库紧密耦合,因此它是一个重要的概念,当然,当您使用可能在稍后扩展的模型时。

关于真正的重构,我能想到的唯一重要工具是 South ,如果数据库方案发生更改,可以帮助您很多。否则,就像我已经给出的提示:编写测试以确保重构前后的功能保持不变。

你可以了解 code smells . 有些人说,如果代码有气味,就意味着需要考虑重构。

事实上,这是一个非常广泛的主题。记住:

过早的优化是一切的根源 邪恶——唐纳德克努斯

我个人认为这对于(过早)重构也是有效的。

编辑:这也是关于代码气味的一个很好的资源: http://www.codinghorror.com/blog/2006/05/code-smells.html