梦想风暴

做集成，最大的缺陷在于工作肯定是最后完成，即便代码编写得再完美。因为任何人出错了，最终都会在这里暴露出来。现在是算法移植工作，也就是把原来用Matlab编写的代码改成C语言实现。我编写的是算法部分集成的代码，谢天谢地，在我后面还有一个人负责将算法集成到应用中，所以，大多数时间，我是比较轻闲的，但无论如何，我的人得在，即便什么都不做，因为谁也无法保证不出任何错误。

最初选择Matlab作为实验平台，看中的是它的便利，而现在用C，无它，性能。语言之间的差别不仅仅是在语法上。任何一种语言背后都是一个环境、一种文化。使用Matlab这样相对高级的语言开发，好处是让一些在编程方面的新手能够快速的进入角色，他们不必像编写C代码一样顾虑很多与问题本身无关的细节，比如内存管理。但坏处也就此浮出水面，因为他们对编程的理解很还处于刚刚起步的阶段，所以，对于一些内部质量相关的因素考虑甚少。当代码在自己手中维护的时候，这个问题还不是很明显，但到了移植阶段，尤其是别人移植他们代码的时候，一切问题就都暴露了出来。

在我们的移植过程中，就有这样的模块，Matlab版本由一组人开发，而移植工作交给了另外的人。这两天许多让我们倍受折磨的问题基本上都源自这个模块。按照领导的本意，负责算法研究的，只关心算法研究就可以了，而移植工作交给负责程序开发的人，按照分工合作的策略，这本是不错的选择。遗憾的是，负责程序开发的人也是一个新手，对算法不甚了解不说，对程序设计也没有太多的感觉，所以，只能选择原样照搬。偏偏对应时存在一些偏差，不在逻辑而在语言本身，比如Matlab数组坐标从1开始，而C是从0开始，这样，问题就来了。

这些天改程序越发体会到“高内聚、低耦合”的重要性。因为有全局变量，为了方便，就出现了许多访问全局变量的代码，这样，也就有大量代码依赖于全局变量，而实际上，其中的很多代码完全可以通过多传几个参数消除对全局变量的依赖。虽然全局变量在各处都可以访问，但依赖它们就意味着，陷入泥潭无法自拔，因为这些代码将暗中与其它使用这些全局变量的代码耦合。事实证明了这一点，常常是改了一个地方，其它地方会莫名奇妙的出错，原因就是因为随处可用的全局变量。虽然，在很多公司中，严格区分编码和设计的人，但在我看来，如果想编好代码，不真正理解设计原则——比如“高内聚、低耦合”——是不可能的。

领导问我，改程序的感觉如何，我答，C++真好。这里我想说的是最简单的C++功能，封装。封装意味着提高抽象能力，隐藏细节。其实很多后来的语言都成功的运用了封装，比如Java封装了内存管理的细节，许多动态语言封装了一些标准的数据结构。我们使用Matlab的目的也是如此。C在语法层面上对封装支持得不够好，所以，我们不得不在面对具体问题的时候，还要考虑语言的细节。在Matlab中，每个数组都有自己的长度，而在C里面，我们单独维护一个数组长度的变量，就是这样简单的差异，就造成了无数次的崩溃，仅仅是因为变量没有正确的赋值。原因很简单，因为原来Matlab版本中根本没有维护长度变量的代码，所以，移植的人在这个问题上出错也就不足为奇了。

虽然我们的程序存在这样那样的问题，但想想去年刚开始什么都没有的时候，已经不知道好了多少。经过大家一年多的努力，能形成现在这样一个看上去还可以接受的程序，不禁让人感叹人的潜力无限。很多问题看上去很困难，有时甚至让人绝望，但真正走过去之后，才发现“原来一切就是这么简单”。

春节放假前的最后一天，原本今天已经放假了，结果还有些收尾的工作，领导决定，晚放一天，晚归一天。连续几天都加班到了很晚，终于要休息了。

无论是流言蜚语还是亲身体验，时间总是与软件开发过不去，很少听说哪个项目拥有充足的时间，等待我们的似乎只有拼命的与之赛跑。有时，项目到我们这里时，最后期限便已经确定了下来，至于项目中究竟有多少内容，能否如期完成，没人真正关心过，而且通常是时间不够用，所以吃亏的肯定不是制订期限的人。

曾经，我畅想做一个宽松的项目，但后来，我告诉自己，这是不太现实的。假设真有这样的机会，那在制订项目计划的时候，除了必需的工作时间之外，我们还应该将一些缓冲时间考虑进去，以应对难以预知的一切。拿到这样一个时间表，你会做何感想。由于站的角度不同，我们会下意识的忽略缓冲时间，于是，我们认为时间充足。既然时间尚早，我们便不会着急动手。等神游归来，时间不知不觉已经逝去许多，原本充裕的时间也变成了紧张。这种感觉很熟悉吗？我读小学的时候，我和许多同学在假期作业的问题上经常面临这样的尴尬。项目负责人们估计都很清楚这一点，于是，干脆取消了缓冲时间，甚至在时间表上压缩必要的工作时间，给人制造出一种压力，以防止心理上的懈怠。

时间表上的时间是固定的，但实际的时间却是稍有富余的，因为正常的工作时间一周只是40个小时而已，于是，加班成了一种让时间表看上去很美的选择。为了早日脱离加班的苦海，程序员们必须尽快的完成自己的工作，正所谓“上有政策，下有对策”，时间的压力会使我们放弃一些东西，一种常见的选择便是质量。

有过一些编程经验的人应该知道，实现同样功能的代码可能是千差万别，所以，才会有所谓高手的说法。《面向对象软件构造》教导我们说，软件质量分为内部质量和外部质量。站在用户角度，他们关注的只是外部质量，只要用起来感觉一样，他们不会介意内部质量的。既然外部质量容易为人察觉，那么时间压力让我们放弃的便是内部质量。对于软件开发人员来说，内部质量却是一个很关键的因素。除非你打算过河拆桥，做完项目便撒手不管，否则，差劲的内部质量会让未来的自己倍受折磨。但是，这种问题在短期内很少暴露出来，却是对项目的一个长期伤害。《程序员修炼之道》讨论过破窗户的问题，我也曾《体验破窗户》，而时间压力就是一个很好的产生破窗户的理由。

我们是唯美的程序员，我们不愿意编写令人作呕的代码。时间啊！别逼我们！

我参加了几天始业教育，没错，是始业教育。领导为了让我们更好的了解公司，宁可让我们一帮人放下眼下的工作去受教育。对公司最为全面的介绍莫过于始业教育，于是我有机会接受了一次再教育。上次参加始业教育已经是四年前的事，按照同事们之间的说法，那时候，我们还年轻。

与第一次参加始业教育更多的是在追随着讲师思路心潮澎湃不同，几年的工作经历让我能够很清楚知道讲师在说什么。在这种培训课程上，讲师更多的是在宣扬一些好的东西，也就是公司希望做到的，至于与实际之间的差别，他们是不会告诉你的，理想同现实之间的差距总会让人感觉残酷。所谓老员工的优势所在就是能够清楚的看到这一切。

公司已经不是几年前的那个公司，始业教育也上了一个台阶，所有的讲义也更加系统化了。公司的目标是成为了一个“大”公司，这一点从始业教育中所宣扬的东西中可以清晰的看出来。从前，我不是很理解为什么公司并不是非常重视个人的作用，直到我读《Joel说软件》，其中第三十三篇《巨无霸麦当劳与天才厨师Jamie Oliver》讨论的就是这样一个话题。不同的公司有不同的发展方向，“大”公司通过过程让能力一般的人也可以制造出足够优秀的东西，而“小”公司则需要充分发挥个人的能力，其结果往往是制造出更为优秀的东西。所以，“大”公司强调过程，“小”公司重视人。我们无法简单评述孰是孰非，方式方法不同而已。

最近看到的一些报道和一些招聘广告，现在许多“新”公司越来越强调人，为员工提供一个舒适的工作环境，自由的工作氛围，以便他们可以更好发挥自己的智慧，为公司创造更大的价值，这方面的典范是google。剥削的方式有许多种，让人心甘情愿被剥削是一种很高的境界。这个世界上真正重要的是人的智慧，人的智慧会让机器来做简单重复性的工作，到那时，等待做这些工作的人将会是什么呢？可想而知。

代码写得快也未见得是什么好事。周五下班前，我完成该写的代码，为即将到来的周末做好了充分的心理准备，这时，领导找到我。
“你那部分写得怎么样了？”
“完事了。”
“XX的部分没人写，你就把它写了吧！”
就这样，所有美好的周末幻想全部成为了泡影，可怜我的周末在公司编码中度过，。

我不喜欢加班，去年那一段让我心情沮丧的加班之后，尤其如此。何况，只见加班，不见加班费。在从前的部门中，私下里有一种说法，“能者多劳，累死拉倒”。领导会根据你的能力给你安排工作，也就是说，表现得越好，越有机会承担更多的职责，这会直接导致能力的不断提升，不过，薪水的成长却是“老牛拉破车”，一步一个深深的脚印，扎实得很，不匹配的结果就是公司成为了著名的人才摇篮。

熬过去年那段痛苦之后，这次还是我几个月来第一次周末在公司加班。干我们这行而没加过班的大概是稀有动物。其实，加班并不可怕，为了项目能够正常进行偶尔加一次也没什么大不了，可怕的是加班成为一种常态。

大多数时间里，我的工作对我而言并不是压力非常大，因此，我总有些闲心去偷懒。我也经常为自己的这种状态不安。与老妈谈起这个话题，老妈告诉我，当自己的绝大多数工作让自己用尽全力，恐怕自己的能量也就到头了。老妈的话让我释然，偷懒是一种释放压力的方法。虽说有人琢磨出“软件蓝领”的说法，但我们毕竟需要用脑子完成工作。在经常处于高压之下，脑子容易僵硬，比如，我这两天写的代码整体质量要比我之前写的那些差了许多，质量往往与压力成反比。

看过一些报道，虽然程序员每天上班八小时，但不可能真正的工作八小时，Joel的《Fire And Motion》（中文版《行进中开火》）很好的描绘了这种状态。Google懂得这一点，干脆给了员工20%的偷懒时间，于是，一批为人称道的产品出现在我们面前。

一张一弛，文武之道。