Eyoung's Blog

2008年的工作，我只觉得很一般，不满意，也不遗憾。不满意的是自己做的工作太过杂乱，其中涉及到了很多项目很多模块，但我觉得都是一些添砖加瓦、拾遗补漏的工作，所以并不喜欢。虽然对于工作的内容并感到不满意，但我还是硬着头皮并且尽力做下去了，而且基本上在保证质量的情况下按时完成了各项任务，所以我也并不感到遗憾。

一年的工作下来，大的收获不敢奢求，但小的认识我想还是有的，比如在代码阅读方面，比如在软件架构和重构方面。

接触过这么多不同的项目，代码看的多是一定的。看的代码多，自然也还是有好处的，当然前提是代码不能太烂，烂到那种鬼画符的地步。
因为经验不足，初次接触到大量代码，难免手忙脚乱，脑袋膨胀。所以在刚开始看的时候会经常被迷惑，会失去方向，会无形中在后期的开发中去模仿，毕竟模仿是一生中做的最多的事。随着看的代码越来越多，我似乎也能渐渐的明白，哪里写的比较好，哪里需要改一下，以及怎么改才好，等等诸如此类的问题。也许这就是一个晋级的过程，虽然很无形，但你不能否认它的存在。

说到看代码，以前我也像大多数人一样，认为代码还是只看好的，好的看的多，自然学到的也都是好的，不是有句话叫“近朱者赤，近墨者黑”嘛。不过在硬着头皮看了一大堆有问题的代码后，发现看这类代码也并不是一点收获都没有，至少我认为它更能激发人去思考。碰到这些代码，潜意识里会产生一种排斥感，这种排斥感促使着我总想找到更好的实现，于是乎，我会不断的去怀疑，去思考，直到我发现了能取代之的更好的实现方法，虽然这不总能成功，但至少这个过程让我学到了更多，也正因为如此，我才能渐渐的有了判断代码好与差的能力，并且在实践中将其一步步完善。

所以说看差的代码也并非一无是处。差的代码，尤能让人去怀疑和思考，并且由于此认知是出于自己思考感悟得出的，而常常能被记得更牢。总的来说，不管是好的代码还是差的代码，关键还是要在看的过程中去怀疑去思考，若非这样，即使是看好的代码，收获也是很有限的。

软件的架构和重构，对于我来说，也只是看了一些这方面的书，在接触过的代码中认识到了其重要性，至于在实现方面，也还是经验不足，捉襟见肘。不过，这并没有妨碍我停止寻求好的实现的信心。

维护一段代码，特别是扩展已有的代码，都是一件吃力不讨好的事情。如果已有的代码设计很烂，那更是一件在挣扎中前进的工作。当需要在差的设计上做一些扩展的工作时，我时常要在“是否要重构”这个问题上做一些决定，虽然我很不情愿，但实在不忍放任手头的代码再继续混乱下去。如果我按现在的设计扩展下去，我便会做很多伤神费力的工作，而且还需要足够的细心，不能有一处的遗漏；如果我将前期的设计做些修改，那么当前的扩展便会很容易，但这个工作又会带来其他的一些工作，比如考虑这个设计对依赖于它的模快的影响，以及修改后的测试等一系列的工作等等，另外你还得估计下时间，因为老板给你的时间可不包括你额外考虑的这些工作。

维护或扩展一段设计不好的代码，有时就像是在做着帮人圆谎的工作。因为前期的一个设计不佳，在碰到了改变后，我便要痛苦地去做出更多的工作才能继续下去，而且这样的继续只会带来更多的混乱与漏洞。其实这就是所谓的“破窗理论”：没修复的破窗，会导致更多的窗户被打破。