软件开发人员该如何深入理解自己的代码

我最近碰到一个让我很蛋疼的事情。一个C#程序员很自豪的宣布，说自己已经看不懂他一个星期前写的代码了。说实话，我真想知道他有什么可值得骄傲的，我完全搞不懂嘛。他自豪的是，他每天写了很多很多代码？还是任何人都愿意给他钱，让他写代码？

对于此事我的观点是： 对于一个职业C#程序员来说，不能理解你在一周前或者一年前写的代码是一件不可原谅的事情。

是的，我是么说的。容我说明一下。我把软件开发作为职业 已经有15年了。在较早的时候我接受了一些软件开发信条，它们至今还伴随着我。我依然可以很容易的理解我一年前、两年前、或者十二年前编写的代码。无论它以什么语言编写，无论你称其为域、算法、分析器、网络应用、嵌入式控制器、脚本、连接器或者其它的什么。哪怕是更早的代码，即使对我来说难以理解，我也能辨识出当时已经开始出现的某些模式。

其实，让自己读懂自己以前写过的代码这事，目的是 要让代码具有可读性。无论是你自己还是别人。 代码失去可读性，就像代码不能正常工作一样糟糕，或者比这个还糟糕。如果你自己在一段时候后都不能读懂你写过的代码，那么对于其他人来说，读懂你的代码更是不可能。

对于我来说，强调轻松的阅读和理解你的程序代码是是如何的重要，不仅因为它是一个更好的产品，别人维护的，而且你的程序源码是在你个人的工具箱中，在你的 职业生涯中，你将使用和重复使用它。并且这个工具箱特别授权，对于一个有经验的程序员来说是一个最显著地特点之一。我不能指望我的问题能够立即被解决，面 临着在过去有类似的东西，挖掘我自己的代码档案，找到一个解决的方法，或者相类似的问题。很显然，你不能将无法理解的代码放在你的工具箱中。

如果完成后至少没有试图解释如何可以实现这一壮举，这将是不公平的。坦率地说，这是不容易的表达清楚的，但我可以尝试。

我可以肯定，这一点主要针对作家（嗯，也许也包括他创意相关行业）。当你敲下了几行代码（越短越好），你最好驻足于此，用一点点时间来检查这段东西是否能 够让人理解。多读几遍，不要怕麻烦。想一想，假设自己是第一次看到这段代码，还能理解不？如果悲剧的发现不可以……为啥？不要犹豫，一定要将“可读性”作 为代码质量的衡量标准，坚持下去，直到你的整段代码都是可以理解的。

一旦你因为这些结果寻得乐趣，继续再读一遍，过几天再读一遍，这提醒我写更有技术含量的博客文章：我写的每一个句子都要反复斟酌20几遍重写5变，通常也是我写代码的事实情况，通过与生俱来的天赋和不断的实践反复的练习获得完美，由于我没有前者，所以我只能靠后者来实现勤能补拙。

最后，是重构和大胆的完善。如果你遇到一段可以被写的更加清晰的代码，那么就让它更加清晰易懂吧。提高代码质量是我们分内的工作。他的好处有的时候很难被量化，但是如果你参与了一两个那种很多人参与，耗时很久的大型项目之后，你就会自然而然的明白了。