微软的反击September 13, 2009

和朋友调侃时说到，在国内 IT 圈有这两种人：一种是骂着微软却还在用他产品（可能还是盗版）的人、还有种就是直接无视微软的“神人”。

微软在技术人员圈子中的口碑似乎都不是很好，它没有 Apple 的浪漫、Google 的理想、IBM 的工程师气质 -- 或许它只是家彻彻底底的商业销售公司。

从 Windows Mobile 的难产、Zune 的夭折、Bing 的换汤不换药、再到 Vista 彻彻底底的 失败，微软这些年的确是流年不利。

微软其实它自己也意识到了自己已步入中年危机。它开始进行一系列的措施，例如其中有项就是加快产品的更新速度：记得从 XP 到 Vista 经历了五年，而从 Vista 到 Win7 只用了两年。

同时，微软开始逐渐得重视社区尤其是草根开发人员的力量。微软放下了当年“技术引导者”傲慢（想想当年 .NET 发布时它的姿态）取而代之的是以“技术提供者”自居“谦逊姿态”。

在那届 D2 时，微软的超群在介绍 IE8 新功能时的那句：“Firefox 有的功能，现在 IE8 也有了”，使得在场的观众哄笑不已。

说到此，又想到了近期 WordCamp 上微软提升对 PHP 的支持的新闻。

纵观互联网已将企业间的争斗从产品转向了平台间的圈人运动。微软以操作系统先入为主的地位短期内虽无法撼动，但同作为竞争者的 Apple 和 Google 还是会将未来搅拌得扑朔迷离。

还记得那鲍尔默豪放的三声啸叫 ：“Web Developer!Web Developer!!Web Developer!!!!”。时隔境迁，虽然现在无法得知当 时他的真正用意，但从现在回望似乎微软正在逐步的实施其制订的反击计划。

未来的结果谁都无法预料，交给时间我们拭目以待吧…

-- EOF --

对于此次项目的些随想August 23, 2009

零九年似乎一直都在赶项目，而这次和阿软 UED 合作的项目情况尤为特殊，但这次项目让我获得良多。

不同风格和节凑的团队如何融合一起

每天都在用阿里旺旺，这次让我更近得了解了他们的开发团队。 本以为阿里系 UED 都是差不多风格，但我发现还是有各自的特色。搬到阿里软件的头几天， 就碰到如何相互分工合作的问题。

首先，我们花了些时间熟悉对方的产品以及代码产出物，以便熟悉其代码和设计风格。 然后，在大范围的空间中，约定了些大框架的规范（包括视觉规范、DPL、代码规范 等）。流程方面情况比较特殊，我们尽量简化和精简了开发流程。

然后，在产品分模块以后，明确了小组对应每个模块开发的负责人。前端和视觉不同的负责 人将对应的开发模块逐渐的连线，这样在方便了各自了解进度的同时，也可以让身处不同小 组的人员相互的熟悉。

经过一段时间的磨合，两个不同的团队已经可以很默契的配合了。顺便在这里惊叹于， 在出发点以及目标一致的情况下，各小组的人员的动能是如此的强大。

人件

项目进度的瓶颈在于我看来，不是时间、不是技术而是人。天时地利，还需要人和。这里所 谓的“人和”，指的是小组各成员的士气以及状态。在这段“特殊时期”中，我能想到些措施

1. 放音乐，缓解下气氛
2. 自由上下班时间，只要不是“太过份”即可
3. 适当调整下工作内容，不要让组员太枯燥
4. 小的练手的技术点，可以使用“竞标”政策
5. 在群里贴美女照片 :^)

进度和质量之间的博弈

尤其紧急的项目，PM 和 PD 对于项目进度就抓得越紧。这有时候未必会是件好事， 开发们会以为，可以因进度就可以抛弃些更为重要的点。

我曾经不止一次在邮件列表中将这一情况加入到“风险点”中，好在经过沟通我们的 PM 站在了我们这边。项目的开发人员也逐渐明白，在核心质量的代码上现在花些时间， 对于以后维护而言是有好处的。

如何避免因赶进度而带来的产品质量下降等风险，这说到底其实是个博弈问题，这就看开发 人员以及 PM 对于该项目是如何定位的了。

对于加班的态度

几乎每个管理人员都会认为，加班是赶项目进度的救命稻草，我个人对此持保留态度。坦白讲， 每个人都不喜欢加班，尤其是无偿无理由的加班，更不期望看见因为 KPI 而加班。

让员工每天朝九晚九以及周六都过来加班，他们的个人时间受影响不说，还可能使他们的士气受 挫，甚至会因此而产生抵触情绪。长此以往，这种情况得不到解决，那么后果将会很严重。

对于管理者而言，都恨不得项目第二天就上线，但毕竟罗马城不是一天就建成的。与其做好我们 这些底层开发人员的思想工作，还不如让那些管理人员想明白些这些事理更能治本。

最后，还是期待公司能有套更为合理的奖励体系，毕竟每个员工对于公司的付出，他们总是期望能得到肯定的。

谦逊编程（翻译整理）July 27, 2009

译注：开发人员如何从无休止的需求、项目进度中摆脱烦躁的心态，这是每个人都值得思考的话题。无意间看见了这篇文章，恐于太长遂将其精简翻译，错误之处难免欢迎指正。

同时如果你有有关程序员修身养性的观点和心得，欢迎说说你的看法。

-- Split --

其实每个程序员或多或少都会有个毛病，就是具有某种有强烈的“优越感”。而这种“优越感” 有可能成为激励自身不断发展的动力，同时也有可能成为其职场中的绊脚石。

程序员的这种心态，源自自身掌握的技术、以及多年积累的经验。正如上面所言，这种心态 能使其一切都力求完美、同时准确按照自己的思路行事，能使其技术不断的提升。而另一方 面，如果将这种态度套用给身边其他的人（包括陌生人、同事、朋友甚至家庭），则会发现 他的生活将会如履薄冰 -- 他们只会看见完美的一面而忽略了更多更需要关注的事物。

总而言之，越早发现并解决这一问题，越对自身有利。套用 GeraldWeinberg 在《计算机编程心理学》中的一段话

这种想法是程序员必须解决的，他们对待自己的代码犹如对待自己身体的
一部分，因此他们拒绝所有的负面评价。相反，它们（指代这种心态）应
该及时的引导到正途，使其发挥真正的效用。人非圣贤，这不仅仅是心态
更是精神上的境界，并非所有人都能达到，但仍旧值得去尝试。

症状

那么，你如何得知这种“优越感”正在伤害到自己？除了应付那些没完没了的催促项目进度的 电话，以及给同事擦屁股的优化工程，其它的现象并非显而易见。

其实就我个人而言，时常也会自我责备，这就能窥出事态的严重。例如一方面你对项目疲于 奔命，而同时却忽略身边的人对你表达的看法（该死，这个时候我应该放下手头的工作听他 们说完的）。或者你“假装”静下心来听取他们的意见，但不就繁杂的工作却让你左耳进右耳 出。

其他的些症状

• 如上面所说的，不会妥善处理批评
• 不放心同伴的代码，经常性地对他们进行代码审查（Review）
• 报复性的编写大量充斥着错误的代码
• 个人的消极心态，对自身和团队造成不利的影响
• 必须要求进行测试，但出发点却是炫耀
• 对事物的看法仅仅局限于个人或者本职位的角度

这不仅仅是你个人的事情，编程以及项目开发实际上是团队活动。了解到这些，你将会意识到 你的心态将会直接影响到你的同事。

事实就是这样，当我对您的代码提出写意见甚至批评时，你应该听、并且认
真的听，这样你才能理解我的看法。

有可能最糟糕的情况就是，即便早已经收到其他同事的提醒，当事人已经陷入此泥潭无法自拔。

准则

让我们回到文章的题目本身，正如上面的例子中看到，“谦逊编程”不是编程技术本身，而是 种态度，但它的确会比你掌握的某种技术要有用的得多。

行为准则的确能改变人的心态，下面是些不成文的建议，或许你可以尝试下

• 不要草率的宣布你的决定，在大多数情况下，你应该和你们的同事们讨论
• 不要使用这些论调，这非常让人感到不适：“这是见过的最糟糕的代码了”，换之你可以这样说，“我有个更好的解决方案，要不看看？”
• 不要轻易认为他们没有考虑到你想的方式，即便很不幸是这样，应该善意的提醒。例如“你觉得我这个看法怎么样...”
• 不要无理由的批评你认为很弱智的现象，例如“我觉得 DBA 脑门子被夹了，这个字段竟然使用 INT 型”

更多的，可以参考 Tech Republic 中的“谦逊编程”十条诫律：

• 理解和接受你将犯下的“错误”。
  重点是及早的发现你已经犯下的错误，当代码投入使用以后，改动起来就会非常的困难。
• 你的代码不能代表你的人。
  记住始终要 Review 你的代码，即便你已经认为无懈可击，经验证明总能发现些错误。
• 不管怎么样，有些“奇技淫巧”总能派上用场，而可能这些技巧别人知道的比你更多。
  如果你坚持不耻下问，你的同伴总能分享你更多。
• 不要在完全没有沟通的情况下，自作多情的进行代码重构。
  当你确定要更改别人的代码时，必须加上良好的修改记录，这也是出于对他人的种尊重。
• 对待那些新手要保持充分的尊重、细心以及耐心。
  记住当他们成长起来后，能帮你解决的问题会比你想象中的还要多。
• 唯一不变的是变化。
  怀着开放的心态对待变化，对于各种需求、平台甚至开发工具的变更，应该是迅速适应而不是牢骚满腹 -- 这样解决不了问题。
• 真正的权威来自学识，而不是立场。
  权威源自学识、尊重源自权威。
• 优雅的接受失败。
  最终你的一些观点将会被推翻，即便你有能力证明你的观点是正确的，请不要重复的争辩。帮助其他人意识到这点的最好工具，就是你的理解以及时间。
• 不要成为“办公室男”。
  不要在昏暗的办公室里独自喝着可乐敲着代码。当与外界隔绝，离开同伴的视线，也就说明你离开了一个开放、合作的环境。
• 批判代码而不是编写它的人。
  要知道你的意见可以影响到代码也可以影响到其人，如果你想尝试下如何打击别人的自信并造成冲突，那么尝试下吧。