为了能够维护我编写的代码，我必须很好地命名变量，记录我的代码，确保没有重复，抽象正在工作以便不需要hacks ..并且谨慎地评论因为注释经常中断我读了这段代码。
但我见过的许多其他代码库更像是一个漩涡。变量名称是foobar，即使从不需要计算东西，也会应用大量的黑客和补丁，抽象失败，部署脚本失败......代码是一个难以理解且几乎无法使用的汤。
原来如此！我很好奇。你如何设法保持低质量的代码库？
答案 0 :(得分：8)
不断重构;当你打开一个代码文件而你看到一些奇怪的东西时，你可以投入几分钟来改进现有代码的设计。
进行一系列单元测试可能会对您有所帮助，因为它可以让您确信您正在更改的代码是否仍然有效或因您的更改而中断。
这有点像在房子里有一扇破窗户的故事。当您看到窗户破损时，您应该修理它。 如果你不解决它，那么事情就会开始在那里起作用，并且会导致一个不可维护的混乱。
我的大多数项目也都是关于ContinuousIntegration的;在构建和运行单元测试之后，还执行静态代码分析（fxcop）。我不时地看一下结果，并尝试修复一些正在报告的违规行为。
答案 1 :(得分：5)
一般来说，您描述的是任何代码库增加熵的自然趋势。它通过开发和维护在每个项目中发生。为了对抗这种稳定的增长，我建议如下：
团队中有足够权限的人必须关心。这是最重要的部分。如果没有人关心，它将无法完成。这一点似乎很明显，但事实并非如此。
制定标准和最佳做法。大多数语言都有一本人写的关于最佳实践的书。例如在PERL中，Damain Conway有一本非常好的Perl Best Practices书。除非你这样做，否则团队中的每个人都有自己的方式来编写代码，命名变量，评论等等。
代码评论。您需要一份代码审查清单。您的更改工作是不够的，它还必须符合最佳实践列表。我们设置了两层代码审核，第一层是同行代码审核，第二层是关心代码质量的发布经理。
设计评论。在错误跟踪系统中填写错误或增强功能时，重要的是由变更控制委员会审核，决定工作的安排以及谁需要审查工作的设计。这是您维护代码抽象的地方，并确保更改符合项目的设计文档和目标。团队的软件架构师或首席设计师应该是CCB的一部分。
签入代码质量触发器。一些最佳实践可以通过代码直接实施。编写小脚本来检查代码，例如格式化，使用制表符/空格等。这将有助于您以不同的方式考虑代码质量。
一些reading作为参考。
答案 2 :(得分：5)
学科
答案 3 :(得分：4)
Peer评论很快就建立了一个很难在一张纸上量化的代码质量标准。单元测试允许您轻松改变代码。纪律，很多。
答案 4 :(得分：4)
一个相关的问题：人们如何逃避编写质量差的代码？
这是答案。
对于我们行业中不称职的人来说，一个好的策略是：
培养能够给非技术和半技术人员留下深刻印象的能力。对技术人员来说听起来似乎足够合理，足以使他们失去平衡。
弄清楚你触摸的代码。
现在这是至关重要的部分：在你被发现之前离开并找到更好的工作。最佳时机取决于具体情况。
答案 5 :(得分：3)
我想向您介绍我几年前听过的一个词 - 技术债务。这是一个(1) Wikipedia entry，另一个来自Martin Fowler的(2) web site。
基本上，我不认为人们开始的目的是构建糟糕的软件。通常情况下，时间框架被压缩，需求被修改或在开发中期被替换，任何数量的其他商业现实都是质量开发和设计的核心。
来自福勒：
“快速而肮脏的做事” 让我们承担技术债务， 这类似于金融债务。 就像金融债务一样，技术性 债务产生利息支付 来自额外努力的形式 我们将来要做的事情 因为快速和快速发展 肮脏的设计选择。“
来自维基百科：
“可能推迟的活动 包括文档，编写测试， 参加TODO评论和 处理编译器和静态代码 分析警告。其他的例子 技术债务包括知识 不在组织内共享 和代码太混乱了 容易修改。“
我所看到的（并指导几个开发团队要做）是在开发迭代的早期重构和清理代码库，通常是在开发新工作之前的开始。
同行评审，单元测试和专业软件测试人员都有助于偿还部分技术债务，以及良好的预测（以及良好的代码重用）。
如果您有预算，只要您愿意支付维护费用（时间，精力），自动化测试就是一项合理的投资。
今天有很多高质量的工具，比如fxCop（以及其他类似的工具），但是你必须仔细选择你要招待的方法。
必须考虑到在设计和代码库中保持质量的努力，因此请仔细考虑开发团队/产品/公司/客户等最有效和最有用的方法。
[（1）http://en.wikipedia.org/wiki/Technical_debt]
[（2）http://martinfowler.com/bliki/TechnicalDebt.html]
答案 6 :(得分：2)
当您编写代码并且其他人阅读时，就是这种情况
1.留下坏习惯
2. 使用有意义的程序，功能，变量名称
3. 使用文档关于它（程序/功能/计算/等）如何工作以及由什么产生的结果，不做任何不必要的评论
4.尝试为您的编码提供风格以便人们可以了解它（例如使用GNU样式代码）
或的
使用代码美化器
5. 考虑以团队形式工作（即使你独自一人），不仅是那些会阅读你的代码的人（即使是）
6. 重构代码也应该是好的
7. 咨询你的队友关于你所写的代码，他们可以阅读吗？
8. 向OpenSource社区学习，他们如何工作和共享代码＆amp;补丁
9.如果可以，请使用 SVN或CVS 来维护代码
并记住 KISS 原则（ K eep I t S 实施， S tupid）
和当然简单，精益，平均＆amp;美丽
如果它反转（其他人写，你读）我不知道该说什么：D（也许给那些人以上建议LOL）
答案 7 :(得分：1)
文档，源代码控制，单元测试以及成为优秀的程序员。
答案 8 :(得分：1)
一套全面的单元测试，允许更改和重构，而不必担心破坏现有代码。
我建议选一份Michael Feather的“有效使用传统代码”。
答案 9 :(得分：1)
Fridgemagnet说： “沉闷的程序员拥有完美的代码库”
答案 10 :(得分：1)
当你是一个非常小的（一个项目少于10-20人左右）的开发团队时，你只能勉强维护一个代码库。如果您的项目增长并且您的团队成长，您的实践将扩大规模，否则您将失败。
您所询问的变化基本上是从黑客攻击到编程，最后是软件工程。
借助软件工程，您认识到并非团队中的每个人都是完美的。您查看代码，确保其他人测试，您互相交叉检查。
您开始意识到需要一位能够消化客户需求并将其转化为设计文档的架构师。在其他人被添加到项目之前，这可以很容易地吃一个月的时间（但在开发过程中可以节省数月甚至数年！）。他确保一切都有意义，并且能够很好地融合在一起。
您拥有设计文档，通常基于UML，以便团队的不同部分可以理解集成点。你认识到已经完成的任何事情，你可能需要在没有这样做的人的情况下重新做，所以你要记录它。
您的质量流程变得更加严格，他们开始执行规则，就像您只检查在测试期间解决特定错误的更改。
测试，重构等显然是关键，并由同行和团队审核重新执行。
我不是说这种类型的东西总是必要的，显然它不是，但在你的问题中，你讨论了狡猾的代码库，而这些良好实践通常是解决这个问题的方法。
通常这些良好实践是在完全失败的GIANT项目之后实现的，因为代码库糟透了。然后，他们解雇任何无法逃避责任的人，聘请一些希望拥有较大项目经验的经理人（如果他们没有用完钱）从零开始重新启动。
至少那是我的经历。 YMMV
答案 11 :(得分：0)
你只需要练习，良好的工具以及打破坏习惯和学习的能力和意愿。
答案 12 :(得分：0)
编码很像手写。每个人都有自己独特的风格。我在维护遗留代码时面临的最大挑战之一就是试图找出正在发生的事情。通常它归结为代码库缺乏一致性。