你如何保持一个低质量的代码库?

学科

不断的重构;当您打开一个代码文件,看到一些奇怪的东西时,您可以花费几分钟时间来改进现有代码的设计。

有一套单元测试可以帮助您完成这项工作,因为它可以让您相信您所更改的代码是否仍然有效,或者因为您的更改而中断。

这有点像在房子里有一扇破窗户的故事。当你看到一扇破碎的窗户时,你应该把它修好。 如果你不解决它,事情就会开始偏离那里,并且会导致一个无法形容的混乱。

我的大多数项目也被放置在Onder持续集成中;除了构建和运行UnitTests之外,还执行静态代码分析(FxCop)。偶尔,我会查看结果,并尝试修复一些正在报告的违规行为。

一般来说,您所描述的是任何代码基增加熵的自然趋势。它在每个项目中都是通过开发和维护来实现的。为了对抗这种稳步增长,我建议如下:

1. 团队中有足够权力的人必须关心。这是最重要的部分。如果没人在乎,那就做不成。这一点似乎很明显,但事实并非如此。

2. 制定标准和最佳实践。大多数语言都有一本关于最佳实践的书。例如,在Perl中,Damain Conway有一本非常好的Perl最佳实践书。除非您这样做,否则团队中的每个人都有自己的方法来编写代码、名称变量、注释等等。

3. 代码审查。您需要一个代码检查清单。您的更改有效还不够,它还必须符合最佳实践列表。我们设置了两层代码评审,第一层是对等代码评审,第二层是关注代码质量的发布管理器。

4. 设计评审。当bug或增强在bug跟踪系统中被填充时,由变更控制委员会对其进行审查是很重要的,该委员会决定工作的日程安排,以及谁需要审查工作的设计。这就是您维护代码抽象并确保更改符合项目的设计文档和目标的地方。团队的软件架构师或首席设计师应该是CCB的一部分。

5. 签入代码质量触发器。一些最佳实践可以通过代码直接实施。编写一些小脚本,检查代码的格式、制表符/空格的使用等。这将帮助您以不同的方式思考代码质量。

一些 reading 作为参考。

同行评审很快建立了一个代码质量标准,这在一张纸上很难量化。单元测试可以让您轻松地更改代码。纪律,很多。

一个相关的问题:人们如何摆脱编写低质量代码的困境?

这是答案。

对于我们行业中的不称职人员来说,一个好的策略是:

1. 培养特别是对非技术人员和半技术人员来说令人印象深刻的能力。能够对技术人员来说足够可信,足以让他们保持平衡。

2. 把你接触到的代码弄得一团糟。

3. 现在,这是最关键的部分:在你被发现之前离开并在别处找到一份更好的工作。最佳时机将取决于具体情况。

我想给你介绍一个我几年前听过的术语- 技术债务 . 这里有一个 (1) Wikipedia entry 另一个是马丁·福勒的 (2) web site .

从本质上讲,我认为人们开始并不是为了构建糟糕的软件。通常会发生的情况是,时间框架被压缩,需求被修改或替换为中期开发,任何其他商业现实都会咬到质量开发和设计的核心。

来自Fowler:

“以快速和肮脏的方式做事 给我们带来技术债务, 类似于金融债务。 就像金融债务一样, 债务产生利息,其中 以额外努力的形式来 我们以后要做的 因为发展迅速 肮脏的设计选择。”

维基百科:

“可能推迟的活动 包括文档、书写测试, 关注TODO评论和 处理编译器和静态代码 分析警告。其他实例 技术债务包括 不在组织内共享 代码太混乱了 很容易修改。”

我所看到的(并指导几个开发团队做的)是在开发迭代的早期重构和清理代码库,通常是在开发新工作之前开始。

同行评审、单元测试和专业软件测试人员都有助于偿还一些技术债务,以及良好的预测(以及良好的代码重用)。

如果您有预算,只要您愿意支付维护费用(时间、精力),自动化测试就可以是一项不错的投资。

现在有很多高质量的工具,比如fxcop(和其他类似的工具),但是你必须仔细选择你要娱乐的方法。

必须考虑到在设计和代码库中保持质量的努力,因此请仔细考虑对您的开发团队/产品/公司/客户等最有效和最有用的方法。

〔(1)〕 http://en.wikipedia.org/wiki/Technical_debt ]
〔(2)〕 http://martinfowler.com/bliki/TechnicalDebt.html ]

只有在这种情况下 你写代码 等 人们阅读它
1。离开了 不良习惯
2。 使用有意义 过程、函数、变量名
三。 使用文档 关于它(过程/功能/计算/等等)是如何工作的以及由什么导致的,不要做出任何不必要的评论。
4。尝试 为您的编码提供样式 所以人们可以知道它(比如使用GNU风格的代码)
或
用代码美化器
5。 考虑团队合作 (即使你是一个人)而且不仅是你会读你的代码(即使它是)
6。 重构代码 也应该是好的
7。 咨询你的队友 关于你写的代码,他们能读吗?
8。 向开源社区学习 ,如何工作和共享代码和补丁
9。如果可以,请使用 SVN或CVS 用于维护代码

并且记住 吻 原理(原理) K EEP 我 T S 简单的, S 丘比特)

当然 简单、苗条、平均和漂亮

如果它颠倒了(别人写,你读)我不知道该说什么:d(也许给那些高于建议的人lol)

文档,源代码控制,单元测试,并且是一个好的程序员。

一套全面的单元测试,允许更改和重构,而不必担心破坏现有代码。

我建议拿起迈克尔·费瑟的“有效地处理遗留代码”的副本。

电冰箱磁铁说: “呆板的程序员拥有完美的代码库”

当你是一个非常小的开发团队(在单个项目中少于10-20个人左右)时,你只能很难摆脱代码库的维护。如果您的项目增长,您的团队增长,要么您的实践将扩大,要么您将失败。

你所要求的改变本质上是从黑客到编程,最后是软件工程的转变。

对于软件工程,您认识到并非团队中的每个人都是完美的。您检查代码,确保其他人进行测试,并相互交叉检查。

您开始看到对架构师的需求,架构师可以消化客户的需求,并将其转化为设计文档。在其他人加入到项目中之前,这可以轻松地吃掉一个月的时间(但在开发过程中,时间可以节省几个月甚至几年!)他确保每件事都有意义,并且能够合理地结合在一起。

您有设计文档,通常基于UML,这样团队的不同部分就可以理解集成点。你认识到任何已经做过的事情,你可能需要在没有做过的人的情况下重新做,所以你把它记录下来。

您的质量过程变得更加严格,它们开始执行规则,就像您只签入在测试期间处理特定错误的更改一样。

测试、重构等显然是关键,并由同行和团队评审重新实施。

我不是说这种类型的东西总是必要的,显然不是,但是在你的问题中,你讨论的是粗略的代码基础,而这些好的实践常常是解决这个问题的方法。

通常,这些好的实践是在一个巨大的项目完全失败后实现的,因为代码库太糟糕了。然后,他们解雇那些不能逃避责任的人,雇佣那些希望在更大的项目上有一些经验的经理,并且(如果他们没有耗尽资金)从零开始重新开始。

至少这是我的经验。牛传染性胃肠炎病毒

你只需要练习,好的工具和能力,以及打破坏习惯和学习的意愿。

编码很像手写。每个人都有自己独特的风格。在维护遗留代码的过程中,我面临的最大挑战之一是试图弄清楚到底发生了什么。通常归结为代码库缺乏一致性。