这个标题是今天在 InfoQ 上看到的一篇文章，编辑同学又坏坏的在文章的最后提问“您的看法是什么呢？您认怎样的代码“易于维护”呢？”，一场讨论又开始了。呵呵，不过我还是很喜欢 InfoQ 的这个做法的——把国外各大论坛上讨论的一些有趣的话题整理翻译出来，尽可能呈现一些针锋相对的观点，让大家去进一步思考和讨论。这个做法比直接转载一些所谓的 砖家 的文章要更好，对正处于“启蒙阶段”的中国IT行业帮助更大。
回到正题，说说我对《怎样才能“易于维护”？》的理解，对与不对，也欢迎大家拍砖献花。
很多类似的问题陷入深深的讨论却始终没有结论的原因之一，就是没有量化的标准。
是否容易维护，自然要考虑到负责维护的人的知识/经验，以及相关背景，而不能是凭借感觉。例如某个团队内部可以定义一个标准：N年工作经验，对Java某些领域开发，某某框架，某某行业的业务，有怎样的熟悉程度的人，花多长时间能上手维护的代码，才算是可维护的。
当然，也可以通过过程来规范。比如要求移交代码时，必须提交经过评审的相关设计文档，并通过IDE对代码规范做一些规范化要求，增加code review的覆盖率，这些都有助于增强代码的可维护性。
总结一下，可维护性要靠 团队+个人 两个维度来解决，在工作中逐步解决导致可维护性低的问题，逐步走向规范化。
