圆木菠萝罐

前同事离职，我接手他的项目，到现在为止，缝缝补补敲敲打打接近2个月（包括十一休假）。中间有大量的技术重构情节，于是总结和思维拓展一下关于重构的话题。当然，接下来不会讲技术细节。

项目背景是要将原来一个程序从本地版移植成在线版，说白了就是从本地读数据变为发web service从服务器拿数据。这么说其实这个项目本身就是一个大的“技术重构”，因为程序的关键点在于拿数据的方式不太一样，大部分的业务逻辑是可以复用的。当然由于在线版取消了SD卡，所以需要考虑性能和磁盘空间的问题，比如展现数据的列表就需要加上分页的功能，所以部分的表现层逻辑也需要相当的修改。编程语言是面向过程，特定平台的移动开发方式也是逻辑和界面混合编程，再考虑服务器端的编程，这确实不是一个简单的工作。

接手原来的同事的项目为什么也需要技术重构？坦白讲，前同事离职期间比较赶工，加上在原来的代码基础上修改，而且项目的需求又不太明确，所以很多情况下做出来的东西像半成品 -- 表面上一个普通的bug，实际分析后可能需要重写相应模块才能从“根本”上修复掉这个bug。苦不堪言，为什么苦？不是因为重写模块多么复杂，而是表面上的这一个bug给客户的管理层，公司的管理层，以及自己带来了“一个bug应该马上可以修复掉”的期望，但重写相应模块甚至重新设计相应的技术架构又需要相对较长的一个时间并且没有产出！这对于软件服务公司来说“没有产出”是很让人hold不住的事情。奋战了将近两个月，这个项目基本稳定了。

最近做一个项目，带着团队里面的两个新人。两个新人在平时的评价都是非常聪明，学东西很快，可是因为项目原因不得已一直在做一些维护项目，只是修复下软件缺陷，从来没有做过新的项目。而这次恰好赶上我工作比较忙，便有了这次机会。

前两天，随着我开始做代码评审，发现项目上的质量问题越来越多，最后导致其中的一位新人昨晚通宵了，因为他做的一个模块被我看了之后需要全部重写。另外一个新人虽然没有通宵，只是因为他的模块在之前看过，结果也是全部重写。这两个新人的错误很有代表性，在这里马克一下，我认为这些是很多新人编程容易犯的错误。

1. 不读懂需求就开始写代码。

2. 写代码没有任何思考。

这是一篇迟到的总结，原因是此iPhone项目从2010年12月初做到12月底，31日晚上7点才将最后的包交付出去。一般来说项目团队都会精简成2人，但是由于这个项目极具战略意义，客户副总裁是Project Owner，我们将5个人全投入进去，美国那边也投入了全部的资源，所以这个项目还比较有意义。iPhone开发技术见长是一方面，从项目角度来说也学到了不少的东西。

在软件开发的日常工作中，经常会遇到这样的场景：客户（专业咨询顾问）发来一个邮件说某项目有个新需求需要对原来的程序进行修改，然后客户会列举他想到的可能的业务逻辑，我们的工程师接到需求邮件后会先看看有没有什么需要补充的或者问题跟客户确认。

通常情况下，这样的需求邮件有70%是需要二次甚至多次确认的，原因如下：1. 业务需求模糊。2. 需求说明没有覆盖所有的点。3. 需求改动成本估计。

回到最原始的工作技巧：提出问题的同时提出解决方案。
第一，客户没有开发者熟悉软件。
第二，开发者提出解决方案是份内的事。
第三，提出解决方案就占据了主动。
 

那么话说回来，既然开发者已经有这么一个解决方案，他为什么又不告诉客户呢？其实一句话回答就够了，开发者不愿意或者惧怕承担责任。

牵着客户还是被客户牵着？“客户是上帝”告诉我们应该被“客户牵着”，但是客户之所以找到你帮他工作是因为“你在软件开发领域比他熟悉”。主动提出解决方案，帮客户想到他没有想到的问题，不知不觉你就会“牵着客户”了。

这大概是两个星期之前发生的事情了，这个星期一直很忙，于是没记下，再拖就一个月了，决定今天，现在，记下这个教训。

经验总结，关于该不该发未完成的包：

如果提交对象是非技术型客户，不能发，因为没有任何意义；

如果提交对象是技术客户，谨慎考虑，尽量不要发。如果实在有原因要发，要在邮件写清楚，并且注意把握可能发生的风险。

发未完成的包都会因为误解、沟通丢失等带来各种各样的问题，决定发的人要为此负责。

有这么一个场景：

一位穿白大褂的医生脸色凝重地走进ICU（重症监护室），对躺在病床上的70岁老人的家属说：太太，CT显示您先生大脑里有一恶性肿瘤，不过这个恶心肿瘤现在是可以通过手术来完全移除的。
太太：那好啊，什么时候安排手术？
医生：不过。。您先生岁数太大，身体机能无法承受手术中的创伤。虽然手术可以完全移除肿瘤，但是只怕先生挺不到手术结束了。
太太：那怎么办？
医生：那就保守疗法，将就活着呗，直到自然死亡。虽然会有痛苦和随时死亡的风险，但是比在马上的手术中死亡要好。
太太：……

与此同时。。。

一位穿着衬衫的高级软件工程师脸色凝重地走进办公室，对底下的工程师说：你的代码在项目结束前的Code Review(代码评审)中发现一个严重的性能瓶颈风险，现在体现不出来，但是在客户那边数据到达一个数量级就会体现出来了。。还好我已经有解决方案了。
工程师：那好啊，现在开始改？
高级工程师：现在来不及了，项目已经接近尾声。这个项目必须在明天提交客户上线，现在做出如此多的变动风险太大。
工程师：那怎么办？
高级工程师：先发给客户呗，在Release notes里面写清楚风险。随后我们开始做软件更新，然后再发个Patch过去。不过这段时间成本客户是不会给钱的，而且客户满意度会因为这个patch下降。
工程师：……

上面的两个场景有一个共同的尴尬：有一个解决问题的方案，但是因为时间（或者岁数）的关系来不及执行下去。
引发这种尴尬的核心原因是：发现问题太晚，总是在deadline前后发现。

最近的一次项目尝试使用上面的方案，客户在电话里面说非常满意软件质量。

于是，就出现下面一个场景：

一位穿白大褂的医生表情轻松地走入了病房，对一个躺在病床上的小伙子说：CT显示你的大脑里面有一颗良性的肿瘤，现在用手术可以轻松解决。但是如果现在不做手术，你70岁的时候可能要在ICU（重症监护室）里面度过了。
小伙子：谢谢医生，现在可以手术吗？
医生：嗯，马上！

与此同时。。。

一位穿衬衫的高级软件工程师表情轻松地走入办公室，对一个正在埋头写代码的工程师说：刚才我花了半个小时做了个Code Review Sprint，发现你的代码里面有一处性能瓶颈风险。现在如果不改的话，那么将对以后的代码造成严重的影响，最后到客户那边的大数据负载下会不堪重负。
工程师：谢谢，您辛苦了，现在我可以将改动Commit进去吗？
高级工程师：嗯，马上！

一个人如果没有目标，就会迷失，就会拖沓，就会慢下来。

这句话用在大方面可以上升到职业或人生规划，小方面则可以具象到每天的工作。

对于一个每天都必须要有产出的团队，我们的风格是“敏捷”，我们的目标是把事情搞定。(Get Things Done)

在最近的一段时间，工作上经常会扮演团队管理者的角色。随着新人慢慢适应了新环境，接下来要让他们真正成长的重任落到了我的肩上，当然，这也是我成长的过程，也是团队成长的过程。

上个星期接到了一个任务，我们开发的一个最大的系统在经过了上线的考验后，又来了一批共8个的需求更新。我想了想，决定让新人来做这次更新：如果让熟手做可以很快做完，但是新人又会少一次成长的机会；新人一上手就这样大的项目更新是有风险的，于是为了控制风险：新人写代码，熟手来看他们更新的代码并负责测试。这样在有效控制风险的同时，新人也得到了锻炼。

还是以案例来说，以下几个案例很有趣值得人思考：

1. 不注重用户行为的一致性（consistency）

2. 只看自己要更新的需求描述。

3. 不抓住本质核心

其实在修复bug的时候，特别是针对这样的特大系统，思考力变得重要，开发人员不要仅局限于某一块任务，也不要上手就开始写代码，多思考可以让人尽快抓住bug核心，从而用最少的代码解决最正确的问题。

在这整个作业流程当中，特别是第三个案例，在我们会议室交流了两个小时的时间里面，发现了大量的沟通问题：往往两个人对话，听别人讲的那个人往往看似听到了，其实什么也没听。在沟通中不会听是致命的，这些沟通方面的问题暴露，大大坚定了我下一步抓沟通的决心。

 在十月SOHO期间，办公室的同事和我就密码的问题MSN了一段讨论，这段讨论引发了对软件工程师“专业性”的思考。

技术人员通常有荣耀感，会坚持自己的技术观点不动摇。这一点挺好，但是如果做出了一个错误的判断仍然将一句真理作为支撑自己的后台的时候，有管理角色的人就应该想办法让技术人员心服口服地改变自己把持的观点。所以焦点就在于如何反驳“密文更加Professional”这句看似的真理。

不管是软件工程师，还是其他职业，专业性是显示其职业成熟度的一个重要指标。随着经验的积累，面对同一个事情所显示的专业性具体表现也会跟着改变。是为记。