程序员的状态==代码的状态

周五的时候leader单独找我谈话,主题是关于另外一个工程师最近的状态。看来似乎所有人都发现他的状态不好。

一个人的状态怎么样是很容易看出来的。尽管可能口头上不说,或当你问起的时候回答“我状态挺好的啊”,但是身体语言不会说谎。这点小孩子都可以很容易看出他的玩伴某天的状态与往常不一样。当你问起的时候,如果他承认他状态不好,这说明他至少也希望积极寻求帮助让他恢复往常,但是当他不承认状态不好的时候,这说明他在回避,也就是说平常你看到的状态也是他回避之后的状态,那么他的状态可能比看到的还要差。特别是如果一个人平常很活跃的时候,那么在他低沉的时候反差就显得更大了。

回归正题,我想leader问我的原因可能有两个:
1. 作为朋友之间的关心。
2. 作为同事之间的担心。

第一点不用多说,朋友之间互相很了解,一个平常非常活跃的人最近的非常沉闷的状态确实让人担心。
第二点,同为一个项目组的人,如果一个工程师的状态不好,那么很有可能他的代码质量没有正常情况好。

记得一次跟SQA(软件质量管理)的人做Audit(考试)的时候,她就说根据她的经验,软件看似是跟计算机打交道,其实也是人与人的交道,就好比一个人今天感冒了,那么他在感冒期间做的工程质量或者效率肯定没有他正常状态做的好。

我们经常说通过一个人的代码风格可以看到这个人的性格怎么样,虽然感觉有点过(可能没有达到这个level),但是相信还是有道理的。一个稍显粗犷的人,可能他的OO思想用得很到位,大处着笔,大的框架默然于胸中;一个性格很细心的人,可能他的整体观点不太强,但是Coding style却能把握的非常好;一个处于思路清晰状态的人,他的代码也条理清晰,判断,循环井井有条;一个处于思路混乱状态的人,代码逻辑关联不强,东一处西一处,bug横飞。

又有一次,因为打包给客户,项目组弄到很晚的时间。根据我们的项目流程,我们每次必须只能一个人把自己的代码merge到总版本上去,然后test,然后下一个人merge。因为当时接近凌晨了,所以上一个工程师merge后没有test,然后我将我的代码merge上去,因为我们的作业范围是一致的,当我test的时候,发现系统crash了,于是我认为肯定是我的代码出错了(我此时不知道上个人没有merge),可是在我的版本上没有crash啊,于是我担心漏掉了什么没有merge,于是重新检查了所有的工作,最后断点debug显示crash的地方在前一个工程师那里。时间已经接近一点。
这个案例说明两点:
1. 前一个工程师如果测试一下他的代码会很快发现问题。
2. 我的检查方法应该先检查Onload()事件里面哪个function出了问题,再检查细节,这样会更快定位。
而这两点的潜在原因是因为时间太晚了,工程师因为太困没有状态,而犯了平常很低级的错误。

总体而言,调整为最佳状态工作是对软件工程师们非常重要的话题,根据我那一点点的经验,总结如下:
1. 要尽量早完成一天的工作。时间拖得太晚,状态就会下滑,效率也下滑,错误率会上升。
2. 如果突然接到任务而此时思路混乱,注意力不集中,就不要强行一直下去了。可以去用冷水洗洗脸,然后冲杯咖啡,有条件的可以去公司外面吹吹冷风。给自己一个时间,比如10分钟,那么10分钟不想项目的事情去好好调整,然后回来再想代码的事情,就发现原来被卡住的地方自然会通畅起来。
3. 如果是因为生病状态不好,可以去和主管说明情况,在保证质量和进度的前提下,可以先做些难度不大的代码编写,最后等恢复了些再做主要工作。实在不行就只好让别的工程师代理你来做了(根据主管安排)。

程序员应该有自己的一门语言

星期五的周会,让我们讨论到这个话题。之所以提起这个话题,是因为参会的总监提出影响一个项目有哪些方面,头脑风暴的结果分为4个方面:技术,沟通,管理,业务知识。

我们这个team的项目比较特殊,是用客户的一套API进行开发,这种API语言就是放在CSDN上也没人知道,因为这API只是针对这家北美客户的产品。技术含量比较低,但是好处是可以用来快速开发项目,有的项目甚至可以用4天开发完成。而且因为这套语言基于面向过程,所以对团队合作的要求更多。最后我们的一致结论是在沟通和管理方面学到很多,但是技术的成长却没有很多。

如果一个开发者对技术掌握的不多实际会非常心虚,而且对自己技术职业生涯的发展不利。

总监的观点是站在公司项目的角度看的,他认为如果一个项目锻炼不了技术,而可以锻炼你的沟通和管理,那么你就锻炼你的沟通和管理,自己看书学习语言会很慢,还是要结合项目才能从技术语言层面快速成长。他提到一个“势”的概念,程序员要借势,借什么势?借公司项目的势,如果一个项目涉及一个语言,那么你做这个项目,就可以乘机将这个语言学到熟练或精通。这个和我当时大学老师讲的“借力打力”应该是同一个意思。

Tech-Lead(技术主管)的观点则是走微软路线,确切的说是准备开始学习WPF(Windows Presentation Foundation)。她是从大学期间便开始学习C#,一直是微软的忠诚Fans,在比较了Java和微软之后,她还是选择了微软,因为微软有健全的体系和规范的文档,不像Java那样“杂”和“乱”。这样其实挺好,代表了一种观点,当你熟悉一种语言或者一种framework的时候,你再去学习这个框架之内的其他技术,就不需要太多的学习成本,因为很多习惯都传承下来,特别是微软的体系。

另外有一个技术非常好的工程师,他的观点是根据自己的兴趣去学一门技术。他的兴趣是做底层或者是研究算法,举例说明,贪食蛇之类的游戏算法,他认为传统的“数据库读写”系统(类似CMS)没多大的意思。他是技术导向型的,根据自己的爱好去研究一门技术,觉得做出来一个东西很有成就感就OK,不管是否有市场,因为目的是锻炼自己的技术。这种观点适合大多数技术人才的想法,从技术层面来讲,我也支持这种想法,就像《功夫熊猫》里面传承的观点一样,有梦就去追,有什么想法就去做,不要考虑太多的东西,挺好的。

还有一位工程师,技术不是非常好,兴趣也不在技术上,而在市场方面。他认为技术应该结合市场才有用,没有市场的技术没有太多的价值,因为第一不会带来利润,第二这门技术也因为没有市场而没有实际给人们带来价值。所以他对技术层面究竟使用哪种技术不care,而是要去调研市场,看客户有什么需求,把需求问清楚了,再结合技术方面看哪种技术更适合实现,就用哪种技术。

百家争鸣,每个人有每个人的态度和观点,不同的价值取向思考方向也各自不同,这之中没有对与错,只有选择。

我的观点比较赞同最后那位工程师,可能因为我也不是一名纯技术人员缘故。

对于总监的观点,我基本支持,因为结合项目来学习是我不只听到一位业内人士这样说过,而已经在我身上被证明。(进公司的两个月的实战training)可是我想说,如果目前这个API项目一直持续下去而你本身一直持续待在这个项目,做这样的工作无疑对技术的成长是不利的,所以我们应该在工作时间之外学习一门语言,这是我们技术世界的立身之本。

对于Tech-Lead的观点,我有我自己的想法。我对Adobe比较感兴趣,准备业余时间也去学学。因为现在的世界开始进入Web,微软帝国的时代已经过去,正如微软鲍尔默所说,他们害怕的不是Google,而是开源和免费。正值金融危机的寒冬,每家企业都在缩减银根,能开源和免费的为什么要用收费的呢。这样来说,针对Linux, BSD, Android,这样的开源系统的应用就会多。所以我觉得至少选择一门跨平台的语言很重要。而.NET只能在Windows上面运行,这就减少了一部分市场,不过未来微软会怎么走还不确定。至少现在Adobe有一种优势,Flash是既跨平台,又跨浏览器,市场占有率98%以上的新媒体,随着RIA的概念席卷世界,相信未来人们开始越来越习惯双击浏览器而不是双击exe,而人们越来越习惯富媒体而不是单纯的HTML。这便是我对ActionScript3有兴趣的原因,作为一门能够连接Adobe各种产品的语言,从Web到桌面,也越来越扮演着举足轻重的作用。

现在的软件工程师不会只用一种语言,他们会“Programming in”很多语言,但是总应该要一个“Programming into”的语言。这也是CSDN副总裁韩磊在 《C#,你真的入门了吗?》里面所讲到的一样。

也许未来会调到另外的项目组而学习新的语言以更好的工作,但是只要在职业生涯的技术阶段,总要定一个“Program into”的语言去学习。

《谁动了我的代码》

本博决定推出《谁动了我的代码》系列文章,文章不定期更新,主要是记录自己在公司的收获和软件方面的些许思考。《谁动了我的代码》标题创意取自于《谁动了我的奶酪》,在这个变化飞快的世界里,我们要做的就是Change with speed,然后记录下变化的种种历史,以便用来”数据挖掘”得出新的思考和收获。

第一篇是《程序员应该有自己的一门语言》,来源于上周的一次有总监参与的项目周会。

希望在自己的职业生涯的技术阶段能够持续更新。