改和看别人的代码是一种什么感受

工作里面可能会沉淀下来很多的东西，比如文档，代码/脚本，或者图片，甚至你留下的趣事或者“案底”。

对于修改代码，我很多年前就体验过一次，是修改自己写的代码，记得刚毕业的时候写了一个小的项目，是使用Java的Swing技术实现的，能够对一个表格做数据的增删改查。当时写得真是昏天暗地，坐地铁回家的时候都有一种头重脚轻的感觉。这仅仅是一个开发前的纯技术练习而已。写了一周的样子，把代码推给自己的导师来看，导师从各种角度提出了很多的问题，有的问题确实是硬伤，有的问题感觉是理解的角度不同，所以带着半推半就的态度开始第二版，第二版很快就迭代出来了，完成的这种感觉就跟你考完试一样，再也不想看自己写的代码了。第二次的时候，导师从设计模式的角度给我提出了一些建议，然后我开始重新审视自己写的代码，改一改，调一调，看起来是那么回事了，依稀记得当时使用的是命令模式。这一次自己感觉确实是差不多了，从代码的命名规范和“优美”程度来看，感觉已经很难挑出问题了，导师看了下，整体给予了肯定，然后把自己的代码发给我，互相参考学习。这个时候换了一个全新的角度，可以发现很多地方自己还是有待改进的地方。程序开发就是如此，总是有很多待改进的地方。

当然我也碰到了一些比较尴尬的情况，比如我们之前开发一个相当复杂的业务，一个类竟然已经被上百个人改过了，看着一条条的代码改动标记和注释，就会对已有的程序能够稳稳当当运行起来抱有一种崇敬之情。程序的逻辑太多，所以很多时候发现设计模式用不上了，因为满足业务优先，你做了大的改动，代码看起来优美了，业务肯定就崩了，我确实这么尝试过，当时的场景也确实很尴尬，所以我们习惯在程序里面打代码补丁，这是我自造的一个词，意思就是代码里的补丁，比如逻辑判断的部分，发现某个场景会触发一些异常，所以我在逻辑判断的时候塞进去一个if判断，然后中间来控制一下这个变量的变化，然后又很纠结的重新定义一个变量。业务是跑起来了，后来的人可就惨了，我记得当时看一个类的方法，差不多有上千行，我看逻辑已经快懵了。然后小心翼翼的在里面添加一堆逻辑，为了不和其他人的逻辑干扰，我自己抽取了一个段代码。

程序开始调试了，还算勉强通过，结果我旁边的同事有些奔溃了，笨重的服务器跑起来了，发现代码执行逻辑的部分还没有运行到他写的代码就奔溃了，可以想象那种排队的感觉有多无奈。

如果代码层面的问题得以解决，或者说能行得通，那么前端部分的纠结也蛮多，记得比较有意思的一个案例就是当时开发的一个网上营业厅的页面，我们测试了IE的低版本还有firefox,chrome等，显示都是正常的，当时比较新的浏览器版本是IE8,结果客户反馈一上线发现页面的字体显示有些错乱，细细了解了下问题，发现原来是客户的领导的电脑上是这样的，他的电脑浏览器版本比较新，而其他人还是习惯用相对较低的一个版本，都没有问题，碰到这种情况怎么办，改吧，首先要满足第一层的需求。当时找公司同事来提交补丁改已经来不及了，我现场打开电脑，查看代码，硬生生的调了一版，想起来除了无助就是无奈。

慢慢的，也确实有了一些经验，所以会时不时的看看别人写的代码，我觉得基本有两种状态。一种是看了之后有种惊喜的感觉，要不是里面的代码风格很清新，代码看起来就好比一个装饰品一般，低调奢华，要不是代码的逻辑非常缜密，很多你没想到的点，这里都考虑到了，设计中的幂等性在这里是完美的体现。或者是代码的精道，原来的一小段逻辑判断，可能人家一行代码就搞定了，这种情况立马打开电脑默默的模仿一些，记下这个绝技，这是好的一方面，当然还有一种情况，也不一定是极端，可能是大多数人都会犯的错误，程序就好比一个喝醉的人一样，只考虑正常的逻辑，不正常的逻辑说明逻辑不正常，不需要考虑，当然我写的很多代码也确实是这样，从小步快走，快速迭代的方式来说，这种方法是对的，代码代码不够充实和健壮，能够一气呵成是意料之外的。

还有一个痛点就是经常会看着看着自己就纠结起来，为什么要这么实现呢，明明有更好的方法，可能在某个时间看看代码，终于能够体会写脚本的人的痛处了，原来是有这么一个坎，只能不得已为之，当然这种情况确实很少，一方面能耐下心来认真看完代码还不如自己去好好实现一版。所以你会在行业里看到很多类似的情况。

对我来说，代码的意义本身就是服务于业务，作为一个服务的载体，代码问题肯定无处不在，一味的追求代码的完美在工程实践中还是很可能会做妥协，而不管不顾方法论，只是堆砌代码也是万万不可的，从某种程度上来说，代码的逻辑清晰和设计上好的风格可以保证程序的健壮性，当然还有一点很重要就是最起码得有一些代码的解释。