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

关于延期

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 分割成平台和应用,通过强隔离的方式有序生长;而以往那些依赖关系,也会在这个层面得到很好的解决。

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

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

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

余下全文(1/3)

本文最初发表在get.jobdeer.com,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

《互联网公司和软件工程那些事》有1个想法

  1. jack 对这篇文章的反应是赞一个

发表评论

邮箱地址不会被公开。 必填项已用*标注