互联网开发模式一:核心问题

互联网开发的核心问题

当我1999年进入互联网行业工作的时候,华为刚刚通过了著名的CMM认证。当时作为一个小程序员,非常向往业界经典的软件开发模式。因为看上去,如果企业实行了CMM,我们程序员就不用再天天为了老板一个拍脑袋的主意而加班开发了,各种各样的奇葩需求和无理变更,也会烟消云散。但是,在接下来的十几年,几乎没有那个互联网公司再去通过CMM认证。是否CMM这种软件开发模式,就根本不适合互联网行业呢?这是一直以来我都在思考的问题。反而是跟随着互联网企业的一步步长大,我无意识的体验了很多现在流行概念的早期实践:敏捷、重构、持续集成、DevOps,这些实践一开始都非常的幼稚粗糙,但是却真正的伴随着互联网业务的逐步成长。所以,在讨论互联网服务的开发模式时,我认为必须要先搞清楚互联网服务开发的核心问题是什么。

本质:服务,而不是产品

软件到底是“服务”还是“产品”,这个话题一直都非常具有争议。作为程序开发者,实际上是非常希望软件能够是一个产品,因为软件的后续维护和修改,往往是“导致”项目失败的最常见原因。然而事与愿违的是,在互联网企业中,打多数的软件项目,表现出来的是典型的“服务”特征:

  • 没有明确的需求合同。这导致了没有办法为软件设计固定的开发方案,也难以确定长期目标。
  • 没有预付款和客户验收。互联网服务用户来了就用,爽了就给钱,不爽了就走,连沟通的机会都不会有。
  • 甚至连明显的销售环节都没有。很多互联网公司只有市场推广部门,而没有所谓“销售”部门,因为推广就几乎等于销售,在推广的同事,就必须把销售的事情一起做了。

因此,在互联网行业中,软件开发更多的是以一种服务的形式存在。这种特征,在对需求的分析管理;开发技术的选择;集成与测试;运营和客服四个方面,都导致了不同于“产品”型软件的巨大差异:

  • 对于一项服务来说,需求是持续变化的,你可以找到一些通用的模式,但是必须保持变化。
  • 开发效率是第一重要的,因为市场竞争中,应对需求变化快的单位将获得更多的客户。

由于服务必须保持长期的稳定可用,又要具备快速的更新部署能力,所以系统集成的效率和质量要求非常高。所幸的是系统运行的环境大多数都是在可控制的空间里(比如开发公司自己的机房内)。

服务是公司和客户的一种持续沟通和交互的过程,并非一个单向的发售行为,所以互联网服务需要更多细致的运营和维护的工具,否则难以做到迅速而细致的满足海量的互联网用户的需求。

小米的MIUI开发节奏

管理:手段.vs.工具

在各种项目管理的课程里面,陈述了大量针对人去工作的方法。各种会议、报告、表格、评估、测量多不胜数,然而软件项目进度的控制,依然是一个难度堪比登月的事情。—————对于很多项目经理来说,程序员们基本是一个黑盒子,他们自己都不知道一个事情需要多长时间干完,就更别提别人怎么去预估和控制。这里最大的问题,我觉得是:我们往往总是想着怎样“控制”住软件项目的进度,而忽视了如何减少不利于项目进度的因数。实际上影响软件开发进度的主要因数,一般有一下几个:

  1. 程序员的能力水平。有一些项目其中的技术,是程序员完全没接触过的类型,这里包含了学习、调试的时间。
  2. 开发过程中的各种修改变更。由于对可行性、需求确认等方面的因数,开发往往会走“回头路”。有些项目做到一般会发现技术上不可行,需要修改需求;而另外一些项目是在项目做到一半甚至快完成的时候,需求方发现需要修改产品设计,因为在产品可体验之前,完全无法想象到最后会是现在的样子。
  3. 各种和开发无关的过程中的事务。这里包括开会、写报告、沟通、等待开发电脑编译、处理开发服务器故障、各种开发环境和测试环境的问题处理等等……这些事情往往都看起来不是非常“有技术含量”,但是实际上会严重影响开发进度。因为开发工作需要一个稳定、专心的工作环境,频频的被各种事务打断,会让程序员反复的花费时间去“进入”工作状态————面对成千上万行程序代码,要找到之前写到哪个部分,其实不是那么简单。

针对上面说的几个问题,很多都可以通过应用更好的开发工具来解决。比如一些新的需求类型,我们可以求助于互联网上丰富的开源软件和开源库;面对需求变更,我们可以使用设计模式、单元测试等工具;开发中的事务问题,更是可以有大量业界先进工具可用:SVN,Git,Jira,Project,IDE,Chef,Docker……

与其我们拿着鞭子抽打程序员,还不如给程序员更好的开发工具,这样对于项目进度的推动,其实更有好处。

资产:代码.vs.流程

互联网公司是由人组成的,人是会流动的,有一些小型的公司,往往会因为一两个核心员工的离职,造成整个系统的代码无法看懂,无法修改,从而最后导致公司完蛋。这种糟糕的情况,不止一次的出现过。然而,如果我们能有一套完善的开发流程,或者是习惯,以及配合良好的开发环境,加上有一定质量的代码,是完全能做到把项目代码,在不同程序员之间顺利交接的。可惜我们很多公司管理者,并不重视程序员用什么工具开发软件,也不知道如何去提高代码的可读性,所以造成我们的项目特别害怕人员变动。如果我们把人员变动看成是一个必然会发生的事情,那么我们就会更重视整个代码的开发环境和开发过程,从一开始就把开发规范确定下来,规定使用什么环境,应用何种工具,并且坚持执行,同时在实践过程中不断的改进。只有这样有预备的去做,最后才会保留的住公司真正的资产。

一家互联网公司,我们在评估其开发资产的时候,并不应看他“拥有”多少行代码,因为这些代码是无法直接卖钱的。而互联网公司的开发速度,以及这个速度背后的能力才是最重要的。

感谢大家的阅读,如觉得此文对你有那么一丁点的作用,麻烦动动手指转发或分享至朋友圈。如有不同意见,欢迎后台留言探讨。

原文发布于微信公众号 - 韩大(handa1740168)

原文发表时间:2016-08-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

9 条评论
登录 后参与评论

相关文章

来自专栏AI科技大本营的专栏

Python爆红的5大理由,爱它没错!

Python 诞生之初就被誉为最容易上手的编程语言。进入火热的 AI 人工智能时代后,它也逐渐取代 Java,成为编程界的头牌语言。 另外Python 已经进入...

3167
来自专栏Golang语言社区

微服务架构:敏捷软件架构的实际体现

正如敏捷开发能够解决工程技术瓶颈,微服务则能够解决架构层面的瓶颈。 2014年出现的“微服务”理念仿佛一道闪电,让技术人员意识到这一全新架构风格的重要意义。面向...

3055
来自专栏ThoughtWorks

王健:技术雷达之微服务架构

作为一家服务于全球不同类型客户的IT专业服务公司,ThoughtWorks一直追求最卓越的技术,并用它们来解决客户实际的问题。而为了体现技术卓越,Thought...

2917
来自专栏鹅厂网事

变更管理点滴分享

互联网企业的变化节奏太快,流程和工作效率都需要兼顾,对变更活动潜在的风险无形中会放大,导致故障几率会成倍增长。

19810
来自专栏飞总聊IT

互联网企业的开源使用窘境与出路

1 自从Hadoop生态圈流行开来以后,以Apache基金会为代表的开源社区空前强大,国内外互联网公司都纷纷使用开源软件。然而参与开源社区并非是一件容易的事情。...

3408
来自专栏python小白到大牛

Python是如何战胜其他编程语言,强势夺魁!

世界上的编程语言有600多种,但真正主流使用的也仅有二三十种。且随着计算机的发展,新的语言在不断的诞生,过时的语言也在不断的被淘汰。因此,IT开发人员应与时俱进...

896
来自专栏JAVA技术zhai

图解:在资深架构师眼中的架构应该是怎样的?

大概在7~8年前,我曾经有一个美国对口的架构师导师,他对我讲架构其实是发现利益相关者(stakeholder),然后解决他们的关注点(concerns),后来我...

3355
来自专栏不想当开发的产品不是好测试

测试分层

看看市场上的测试岗位,大多数都是围绕这这些来设定的:功能测试,自动化测试,测试开发,性能测试,服务端测试

691
来自专栏大魏分享(微信公众号:david-share)

开源软件应用在企业客户的企业级应用,可否?

近些年,开源软件在国内受到越来越多人的追捧,开源带来的好处是显而易见的。与此同时,很多人也提出了一些质疑。本文讨论的核心是,开源软件究竟是否可以用在企业级客户的...

3319
来自专栏Golang语言社区

微服务架构:敏捷软件架构的实际体现

正如敏捷开发能够解决工程技术瓶颈,微服务则能够解决架构层面的瓶颈。 2014年出现的“微服务”理念仿佛一道闪电,让技术人员意识到这一全新架构风格的重要意义。面向...

3387

扫描关注云+社区