互联网公司和软件工程那些事

　　关于软件工程，我一直有一些零散的想法，正好@技术人攻略这期聊这个话题，于是顺手写了这篇「散」文。

　　关于延期

　　2004 年，我大学毕业到新浪时，正好参与了一个大型的互联网项目——新浪教育频道见习就业项目。进度是由项目经理控制的，光是需求分析报告叠起来有一个 iPhone 侧面高。过程还算正规，有 ER 图，有数据结构表，还有界面示意图。从项目开始我们就天天加班到晚上四五点，回去睡个觉，早上 9 点回来接着干。还记得我和伟平半夜 3 点出去买烟，回来看见前端的妹子一边哭一边嵌页面。最后项目还是延期了蛮久。

　　出于对加班的恐惧，那时候我就对软件工程产生了兴趣，然后读了大量关于软件工程的书，统一过程、敏捷开发、极限编程以及最后期限、人月神话这些周边。我试图弄懂，为什么需求和开发之间，会有如此之大的鸿沟，以至于它能成为一门独立学科。

　　这个思索持续了多年，我一直没有找到合适的答案，直到 2009 年我回到新浪，担任新浪云计算产品经理。

　　SinaAppEngine 项目 8 月立项，11 月上线第一个版本，整体进度延迟 3 天（这就是为什么它是 11 月 3 日上线的），当时我们就五六个人。我在新浪云负责的最后一个大项目——新浪云商店第一期上线，没有进度延迟。

　　这让我发现，延期最核心的问题其实并不在于过程，而在于需求。作为一个曾经开发过亿访问量系统的产品经理，我可以异常精准的控制需求和进度。我 们在需求分解时，可以在技术实现级别讨论时间表。最终我们的时间表可以精准在小时级别，误差在天。这招屡试不爽，从快简历到 JobDeer.com，我们的进度延期都最多几天。

　　关于质量

　　再来说质量的控制。

　　如何提升软质量

　　程序员有一个习惯，就是把自己的高标准拿去要求别的人。所以我们会发明各种高效但是一点都不易用的框架，觉得——如果连这个都不明白，还当什么程序员。

　　我一直都是这么想的，但当我 08 年自己开工作室的时候，我发现我没法招到技术特别好的人，我们新招的同学甚至搞不明白面向对象。

　　于是后来我写了 LazyPHP 框架，这是一个用面向过程封装面向对象的框架。整个框架 20 个函数，搞定一切。它只有一个目标，让不懂面向对象的人，也可以写出强壮的 Web 程序。大体来说，它做到了。

　　再说一件事情。在设计 SAE 的时候，我们有一个最常讨论的话题，就是如何让那些写出不良代码的程序员进行自我修正。后来我们采用了云豆和配额两个方式来进行软性限制。现在 SAE 上访问量特别大的应用都优化得特别好。

　　如何提升硬质量

　　我从来不相信软件是什么艺术，艺术从来不会 Done is better than perfect。所以有些核心的质量指标是必须的，比如单元测试，比如编码规则，比如常规安全检查。而这些东西，不应该作为圣经天天念，而应该简单粗暴的 做到代码发布系统里边，不遵守就提交不了的代码。

　　关于软件工程

　　坦白的说，我觉得「软件工程」这个名字过时了，那是软件时代的遗物，在互联网时代是很诡异的。软件不再是被定义好的大规模工程，分发到外包公司去做实现。它是产品不可分割的一部分，是受需求影响最大最惨的部分。

　　需求分析，原来是软件工程的起点，现在已经由专门的产品团队来做了，这个决定创业公司生死存亡的东西，居然以前是程序员在做。user story，在没有用户画像、应用场景时也很容易失之千里。

　　我们需要一个新的，产品整体的工程化，以天为周期进行全产品流程迭代的过程。而我在这个方向找到的最接近的理论，是《精益创业》。它是精益开发在产品全流程的实现方法论。

　　我觉得，未来「产品工程」会替代「软件工程」。

　　大型互联网公司的技术团队会分成两类人，一类做私有云平台——提供通用技术能力（这部分前期可以用公有云），一类直接合并到业务团队做实现。

　　超大型项目，会被 API 分割成平台和应用，通过强隔离的方式有序生长；而以往那些依赖关系，也会在这个层面得到很好的解决。

　　大部分人不用关心系统，只需要关心自己的应用。

　　软件工程本身，则浴火重生，从一个面向过程式的管理，变成一个面向对象式的支撑环境（有点像对象容器）。

　　具体的东西，我没想太好，我就随便写写，您就顺便看看。