4.5，天气晴好，北京，植物园，溜达…

日子晃晃就过了，如今的博客更新，也变得像女人的月经了！ 忙了一段时间，手上的工作也算收尾了。回想，一个人忙忙碌碌从设计到实现，从Rose到Visio，从各个框图到一段段代码，虽然疲惫和压力并存，但也算乐在其中。只是每天下班就感觉已经精疲力尽了，于是走人，坐车，吃饭，小歇，回家再排排兵步步阵。经过长达一个月的连续奋战，总算把先前脑中的想象变成了现在一动鼠标便可触及的现实。 不过… 老板似乎不为所动，尽管我做的好，很好，或非常好。 想想也没什么，这只是一份工作，一份现在你不去做，别人抢着做的工作，只要不做差了，便没人说你。 最近看完了《朗读者》，基本上是在公车上给看完的，回头也把电影看了！在我看来，文艺类的电影需要揣摩的太多，先看书，再看电影，仿佛才能那些拼凑的画面给看明白，否则可能会云里雾里，只想睡觉了。事实证明，于我也的确如此。 比对书中的描述，除了法院那一段，我觉得这个电影整体做的都还好。法院那里，如果处理得再压抑点，就更自然了，这比较符合主人公的心境，相比来说，电影中的法庭也太明亮了点，整个故事根本就没有一点打开天窗说亮话的迹象嘛！ 书看了，电影也看了，但还是有一点没明白，那个真的是爱情？我觉得是爱或情！也许我终究是个很俗的人，不能体会这么罕见而又抽象的概念！ 哦，上周末还玩了下游戏，真是好久没玩游戏了，极品飞车12，出来似乎也有段时间了。关于极品飞车，我记得上次玩的时候是在大四的寝室里，好像是version 10。貌似这次是抱着一个怀旧的心态在玩的，于是在其中开着我那兰博基尼在街上遛达之际，心中时不时萌生一股物是人非的惆怅感来。这个游戏把我的暴力倾向给彻底的释放了一次，酣畅淋漓，痛快！ 不能泛滥，收尾了！

今天，北京的天气又被打回了原型，冷如前日，于是才意识到原来这个冬季还没结束… 情人节，~~~~ 每次走在街上，人山人海之中，只感觉自己快要被湮没。 我属于这个社会，这个社会却在被我排斥！ 思考良久，深究其因！ 貌似源于自信的一点一点消失，于是无所适从。 我知道其实这个社会，那些人，无非也就是那样！ 于是告诫自己，没什么不同！ 只是我的平衡杆好像从来掌握好！ 若非天降降大任也，必先苦其心志… 如果年轻，还可以被当作安慰之语，如果一而再，再而三，老了，就很是自欺欺人了！ 我不期待大任，我只是一凡夫俗子。 一首《Chasing Pavements》，被我移花接木后，听了很多次！ [Audio clip: view full post to listen]

2008年的工作，我只觉得很一般，不满意，也不遗憾。不满意的是自己做的工作太过杂乱，其中涉及到了很多项目很多模块，但我觉得都是一些添砖加瓦、拾遗补漏的工作，所以并不喜欢。虽然对于工作的内容并感到不满意，但我还是硬着头皮并且尽力做下去了，而且基本上在保证质量的情况下按时完成了各项任务，所以我也并不感到遗憾。 一年的工作下来，大的收获不敢奢求，但小的认识我想还是有的，比如在代码阅读方面，比如在软件架构和重构方面。 接触过这么多不同的项目，代码看的多是一定的。看的代码多，自然也还是有好处的，当然前提是代码不能太烂，烂到那种鬼画符的地步。 因为经验不足，初次接触到大量代码，难免手忙脚乱，脑袋膨胀。所以在刚开始看的时候会经常被迷惑，会失去方向，会无形中在后期的开发中去模仿，毕竟模仿是一生中做的最多的事。随着看的代码越来越多，我似乎也能渐渐的明白，哪里写的比较好，哪里需要改一下，以及怎么改才好，等等诸如此类的问题。也许这就是一个晋级的过程，虽然很无形，但你不能否认它的存在。 说到看代码，以前我也像大多数人一样，认为代码还是只看好的，好的看的多，自然学到的也都是好的，不是有句话叫“近朱者赤，近墨者黑”嘛。不过在硬着头皮看了一大堆有问题的代码后，发现看这类代码也并不是一点收获都没有，至少我认为它更能激发人去思考。碰到这些代码，潜意识里会产生一种排斥感，这种排斥感促使着我总想找到更好的实现，于是乎，我会不断的去怀疑，去思考，直到我发现了能取代之的更好的实现方法，虽然这不总能成功，但至少这个过程让我学到了更多，也正因为如此，我才能渐渐的有了判断代码好与差的能力，并且在实践中将其一步步完善。 所以说看差的代码也并非一无是处。差的代码，尤能让人去怀疑和思考，并且由于此认知是出于自己思考感悟得出的，而常常能被记得更牢。总的来说，不管是好的代码还是差的代码，关键还是要在看的过程中去怀疑去思考，若非这样，即使是看好的代码，收获也是很有限的。 软件的架构和重构，对于我来说，也只是看了一些这方面的书，在接触过的代码中认识到了其重要性，至于在实现方面，也还是经验不足，捉襟见肘。不过，这并没有妨碍我停止寻求好的实现的信心。 维护一段代码，特别是扩展已有的代码，都是一件吃力不讨好的事情。如果已有的代码设计很烂，那更是一件在挣扎中前进的工作。当需要在差的设计上做一些扩展的工作时，我时常要在“是否要重构”这个问题上做一些决定，虽然我很不情愿，但实在不忍放任手头的代码再继续混乱下去。如果我按现在的设计扩展下去，我便会做很多伤神费力的工作，而且还需要足够的细心，不能有一处的遗漏；如果我将前期的设计做些修改，那么当前的扩展便会很容易，但这个工作又会带来其他的一些工作，比如考虑这个设计对依赖于它的模快的影响，以及修改后的测试等一系列的工作等等，另外你还得估计下时间，因为老板给你的时间可不包括你额外考虑的这些工作。 维护或扩展一段设计不好的代码，有时就像是在做着帮人圆谎的工作。因为前期的一个设计不佳，在碰到了改变后，我便要痛苦地去做出更多的工作才能继续下去，而且这样的继续只会带来更多的混乱与漏洞。其实这就是所谓的“破窗理论”：没修复的破窗，会导致更多的窗户被打破。