文/邱俊涛
过去的几年中,我参加过好多次Hackday活动。每次看到在为期两天的时间里,2-3个人将一个想法变成现实,都会有一种强烈的成就感。而且这个Hack的过程中,会重拾编程的乐趣,大家的积极性都非常高,用着各种有趣的技术(大数据,开源硬件,Node.js,GIS系统),逐步的将模糊的想法,变成现实,并最终为客户带来价值。
通过这些Hackday的经历,以及在众多项目中的经验,我总结了一些轻量级的方法/实践。这些方法/实践非常容易落地,并且久经验证。在很多项目中已经在不断的使用。它们可以帮你更好的将一个想法变成现实,并且在随后的开发中还可以继续发挥作用而不至失效(测试,构建脚本,自动化部署等等)。我希望你可以在自己的项目中尝试这些方法/实践,也希望这些方法/实践可以真正的帮助你和你的项目取得成功。
细化你的“点子”
根据一个已有的产品来参考,演绎,并形成自己的产品并非难事,而创新则是一件非常困难的事情,因为你需要“无中生有”。在ThoughtWorks,我们有这样一些步骤可以帮助客户来梳理信息,并最终交付产品,简而言之,可以归结为这样几个步骤:
- Discovery(用户研究,探索)
- Define(归纳洞见,发现)
- Design(原型设计,验证)
- Delivery(制定计划,实施)
上图是一个“点子”的原型(一个交换技能的应用,用户可以教别人自己擅长的技能,作为交换,也可以从别人那里学习心得技能),原型事实上是第三步的产物。我们通过一些调查(口头采访,或者问卷调查)得到一些基本的信息,然后归纳这些信息,并和真实用户再次确认,得到一个概念。有了概念,再来设计一个基本的原型,这个原型还可以迭代数次,然后进入下一个阶段。
前三个阶段更多的是用户体验设计师,以及客户的业务人员参与的。在前三步完成之后,进入实施的时候,软件工程师开始投入。这篇文章更关注第四步(Delivery)中的各种实践,通过这些实践,我们可以很好的完成交付计划,使得我们的好想法最终可以变成为用户提供服务的产品。
实现“点子”的方法
在软件领域,将一个想法变成实际的产品需要经历若干个阶段。按照传统的软件开发方式,会有前期的调研,需求分析,概要设计,详细设计,编码实现,测试,发布等一系列的流程。这种方式对每个阶段的定义都非常明确,而且每个阶段需要依赖前一个阶段的输出,因此往往被称为“瀑布模型”。后来慢慢发现,这个模型的反馈周期太长,一个软件从调研到发布往往需要数年,当发布之后,可能市场早已经沧海桑田。人们后来发明了更加符合现代市场需求的“敏捷开发”,在敏捷中,更加强调短平快的将需求变为产品。
简而言之,敏捷开发更强调:
- 快速发布
- 渐进增强
- 小步迭代
而在敏捷开发的继承者精益中,这几点理念也被更进一步的深化。由于没有办法预见未来,我们只能用一种边做边看的方式来验证想法。简而言之,就是先根据经验和调查,做出一个合理的推断,然后定义好范围,构想出一个最小可行产品(MVP),这个MVP的功能非常内聚,非常紧凑,我们需要尽可能快的让其上线,并被真是的用户使用,测试。根据这些用户的反馈,我们会做一些调整,比如去掉那些很少人使用的功能,聚焦在用户喜欢的功能上;从用户的实际使用中,调整界面元素的位置,子功能的入口等等。这个过程会持续多轮,最后的结果会是一个有真是用户使用,并且比较贴近真实需求的产品。当然这还不够,我们需要不断的打磨,渐进式的增强产品的功能,逐步完善功能等。
有一个非常形象的图,可以看出瀑布模型和敏捷开发两种方法的对比:
敏捷开发通过逐步细化,迭代前进的方式,分阶段的将需求实现,在整个过程中,更容易做到快速调整。
所有的这些过程,都非常依赖“快速”这个关键点。如果MVP花了3周就产生了,但是为了让其上线,你花费了1个月,那么很可能这个MVP已经过时了;如果你确实快速的将MVP发布了,在得到了用户的很多反馈之后,花费1个月来实现这些反馈,又会让你落在竞争对手之后;如果快速的发布了多次,并且幸运的是,你的用户量变多了,如果花费很长时间来调整架构,则可能失去当前的市场窗口。也就是说,你需要非常快速地对变化做出反应!
轻量级的开发方式
开发中的三个重点
在工程实践中,我认为有三个特别需要注意重要的点,这三点可以极大程度的改善项目现状,提高效率,并使得产品的高质量交付成为可能,它们分别是:
- 自动化(自动化一切)
- 质量内嵌(defect的数量,是否真正满足了需求)
- 代码本身的质量(可读性,可维护性,可扩展性)
自动化包括,自动provision,自动部署,自动化测试,自动打包等等。这是提高团队开发效率的必要工具。比如书中提到的grunt/gulp脚本,jasmine/rspec/capybara测试,部署脚本,vagrant/Chef等,都是关于如何将日常开发中的任务尽可能的自动化。
软件没有Bug当然是所有人都追求的,我们有很多中方式来保证代码质量。而在编写产品代码的同时,写大量的自动化测试,是投入产出比最高的一种了。通过单元测试,集成测试,以及一些有限但是关键的UI测试,我们可以覆盖很多的需求,而将这些测试自动化起来之后,可以节省大量的开发/测试成本,并减少回归测试的代价。
要支撑快速的发布,我们需要一系列的技术实践。这些技术包括环境的搭建,框架的使用,代码的编写,产品的发布;而且包括后台的数据库设计,业务代码,同样还有前端的展现等。
何为轻量级?
在《轻量级Web应用开发》中,我介绍了一系列的实践/工具,这些实践/工具贯穿整个软件开发的生命周期,使得敏捷开发/精益的开发方式变得可以“落地”。比如如何使用轻量级的开发框架来搭建API原型,如何将应用发布在免费的云平台上,如何通过虚拟化技术快速搭建开发环境,从而节省环境配置的投入,如何快速平滑的发布,如何使用测试先行的方式来保证代码质量,如何做高效的自动化UI测试等等。
- 轻量级Web框架
- 前端开发流程
- 构建工具
- 环境自动化(开发环境的搭建,CI服务器的搭建)
- 自动化部署
- UI测试
- 实例驱动(书中有很多的实例,也有很多从项目中总结出来的实践)
这是一本主要关注开发实践的书,书中通过很多实际的例子来帮助读者建立一套完整,高效,轻量级的开发方式,这些方式可以直接在你的下一个项目中使用。甚至如果项目的技术栈变成了另外一种语言,你也可以迅速找到同类的替代品。比如rake之于gradle,sinatra至于spring-mvc等等。
每个组件都是可以替换掉的,比如ORM,如果你觉得DataMapper无法满足实际需要,那么可以换成ActiveRecord。如果Rails太重,使用Sinatra或者Grape或许是一个更好的选择。AngularJS包含了太多东西,Backbone.js或许适合你的场景,而也未尝不可以用Riot.js来替换掉Backbone中的view层。
在本地,可以将应用部署到一个vagrant+chef来provision的环境中,而通过部署自动化,这个动作可以很容易的在AWS的云上实现。轻量级的开发方式,帮助你用最小的代价来替换系统中的任意一个组件,因为每个组件在一开始都是按照可替换原则选用的。
另一方面,轻量级的另一个意思是:现发布静态的版本,然后再将内容替换为动态版本。发布一个静态的页面非常容易,具体细节可以参考这篇文章。当需要动态内容是,免费版的Heroku是一个触手可得的选择,AWS则是一个更加专业的选择(各种服务都配置完善,你只需要关注自己的应用部署即可)。
</div>