Web应用开发周期

原文链接

摘要: 这部分内容最早出自笔者写的文章《RePractise:Web开发的七天里》,原文简单描述了Web应用的生命周期。后来发现,这条路几乎是所有Web应用的必经之路。一个Web应用在其生命周期里,都要经历搭建开发环境、创建构建系统、编写代码、进行数据分析等,直至最后使用新的系统来替换这个遗留系统。

引言:这部分内容最早出自笔者写的文章《RePractise:Web开发的七天里》,原文简单描述了Web应用的生命周期。后来发现,这条路几乎是所有Web应用的必经之路。一个Web应用在其生命周期里,都要经历搭建开发环境、创建构建系统、编写代码、进行数据分析等,直至最后使用新的系统来替换这个遗留系统。如果你是一个有经验的开发者,相信你对这个生命周期一定也深有体会。
本篇文章是对《全栈应用开发:精益实践》这本书的一个简单概述。

Web应用的生命周期

  在我所经历的项目以及我所看到的Web应用里,它们都有相同的很有意思的生命周期。我们经常在网上看到某个知名的网站使用某个新的技术、语言来替换旧的系统,某个App使用新的框架来替换现有的App。我们所看到的都只是这些公司正在重构现有的系统,这实际上是一个周期的结束,以及一个新周期开始。其过程如图0-1所示。
                  
                       图0-1 Web应用的生命周期

  仔细一想就会发现:我们所经历的项目都在以不同的时间长度经历相同的生命周期。

遗留系统与新架构

在我开始工作的时候,接触的第一个项目就是一个遗留系统。在一次休息时,我们在比赛找最古老的源码文件,最后找到了10年前写下的一个文件。尽管在我们的代码里有单元测试、针对具体业务功能的测试,项目的代码已经超过20万行,项目中仍然有相当多的代码超出了我们所理解的业务范围。毕竟在这些年头里,有相当多的功能已经不存在了。后来,我们选用微服务重构了这个系统。对于中型的遗留系统来说,这算是一剂良药。
让我们先从某某网站使用新架构重新设计说起。当我们决定使用新架构重新设计系统时,原因可能是多种多样的,如果我们排除一些无法抗拒的因素(如政治),那么剩下的原因可能就只有两个。

  • 系统已经变得难以维护。这里的原因仍然有很多:大量的代码已经没有人知道其业务逻辑,变得难以修改;代码间耦合度过高,重构系统的难度过于复杂;项目所使用的技术栈已经过时,已经被市场所淘汰;团队的技术栈在成员变动的过程中,团队中大部分成员的技术栈已经和当前的项目不匹配了。
  • 系统的技术栈已经难以符合业务的需求。绝大多数情况下,我们在最初开始创建项目的时候,所选择的技术栈都是符合当时业务需求的技术栈、可以快速验证其业务价值的技术栈。而随着业务的扩张,现有的技术栈很快将难以满足当前业务的需求,或出现性能优化上的限制。

在多数情况下,我们都会将这种系统称为遗留系统。在这时团队里的气氛便是“能不动这些代码就尽量不去动它”。我们已经很难将项目的问题归为人的因素,多数时候都是受业务扩张的影响。作为一个专业的程序员,我们的本能就是将程序写好,而我们往往没有这样的机会。
  业务人员对项目经理说:“我们的竞争对手已经在本周上线了这个功能。”
  项目经理对开发人员说:“这个功能下星期就要上线!”
  是的,我们的功能不得不马上上线。这时候,我们往往要在代码质量和交付速度上做出一些妥协。妥协多了,系统也就变烂了。
  开发人员说:“这个代码我不太敢修改,要是出了什么大Bug怎么办?”慢慢地人们就开始讨论起重构系统的事宜,并开始着手设计新的架构—使之可以满足当前的业务需求、可预测时间内的业务与技术需求。

技术选型与验证

  在讨论新架构的过程中,不同的人可能会有不同的技术偏好,也会因存在一些政治因素导致不同技术方案的产生。如团队中的一些人可能出于稳定缘故而选择Java,一些人可能出于对新技术的需求选择Scala,而另外一些人可能考虑到团队中大部分人可能因为都会使用JavaScript而选择使用JavaScript。如图0-2所示,我们的考虑应该不仅仅取决于这一系列的技术因素。
                      
                       图0-2 技术选型考虑因素

  需要注意的是:在做技术选型的时候,要尽最大可能以团队为核心。在做决定之前,我们要提出不同语言、框架下的技术模型,并且进行验证。随后就需要快速搭建出一个原型,并针对这个原型进行假想式开发,然后验证原型本身是经得起考验的。
  在这一阶段,我通常喜欢在GitHub上搜索一些名字中带有boilerplate的项目,即模块文件。而当一个框架很流行的时候,我就会去相应的awesome-xx寻找,如awesome-react就可以寻找到react相关的项目集。然后,克隆这样一个项目,开始依照现有的系统创建简单的Demo。随后,就可以依据我们的业务试着在这上面进行扩展。最后,再决定是否使用这门技术和这个框架。
  通常来说,在选择一门新技术设计系统时,需要承担的风险相当大,而如果能成功,那么它可能会带来巨大的收益。从这点看,使用最新的技术与赌博无异。在一些成熟的公司里,会有专门的技术委员会负责对新技术进行审核,来决定是否可以在某个项目里使用新技术。除了考虑其为开发带来的便利性,他们更多地还会考虑其成熟度、安全和技术风险等。

搭建构建系统

  决定好架构并选择完技术栈后,我们就开始着手创建项目的构建系统,设计项目的部署流程。构建系统不仅包含项目相关的构建流程,还从某种意义上反映了这个项目的工作流程。
  创建完“hello, world”程序后,我们要着手做的事情就是创建一个持续集成环境。这样的环境包含一系列的工具、步骤及实践,从工具上说,我们需要选择版本管理工具、代码托管环境、持续集成工具、打包工具、自动部署脚本等一系列流程,这些流程将会在《全栈应用开发》一书第4章详细讨论。
  图0-3便是笔者之前经历过的一个项目的构建流程。
          
                          图0-3 构建过程

  这是一个后台语言用Java、前台语言用JavaScript的项目的构建流程。

迭代

  在互联网行业里,能越快速地对市场需求做出反应,就越能有更好的发展。只要你细心观察就可以发现,大部分互联网公司都在以一定的规律更新产品,或者一周,或者两周,又或者一个月等,这种不断根据反馈来改进产品的过程称为迭代。如图0-4所示是一个简化的迭代模型。
                       
                        图0-4 简化的迭代模型

   当一个迭代开始时,我们需要收集上一个迭代的反馈或者新的需求,然后开始开发代码,最后再发布产品。开发的产品在这个过程中不断地增强功能。为此,还需要选择一个好的迭代周期。一个好的迭代周期既应该有充足的时间修复上一个迭代的Bug,又能在下一个迭代开始之前交付重要的功能。当然,如果交付的软件包里出现了重要的Bug,那么我们也能在第一时间使用旧版本的包,并在下一个迭代交付。在这样的开发节奏里,一周显得太短,一个月又显得太长,两周会是一个很不错的时间。
  当一个团队在这方面做得不好时,那么他们可能在一次上线后,发现重要的Bug,不得不在当晚或者第二天更新他们的产品。即使是有经验的团队,在开发初期也会经常遇到这些问题,而这些问题可以依赖于在迭代中改进。好的迭代实践都是依据团队自身的需求而发展的,这意味着有时候适合团队A的实践并不一定适合团队B。
  随后,我们会在这个“hello, world”的基础上不断添加各种功能。

Web应用开发步骤

  令人难以置信的是,我们做了这么多事情以后还没有开始写代码。事实上,在这一步里,我们已经搭建好了一个最小可运行的Web应用。在这之后,我们所要做的事情就是提交代码即可。将代码从本地提交到服务器后,持续集成服务器将帮我们运行测试,在测试通过后,打包、发布现有的代码,最后部署到测试环境里。

1 . 编码

  如果不考虑技术难度的因素,写代码看上去就是一件很简单的事。我们只需要按照需求,将功能一点点往上叠加即可。如果不考虑这个过程中添加的代码质量,将会得到一个难以维护的系统,并且在拿到需求后的第一反应也并非直接开始实现功能,而是首先应该考虑可以将这个需求拆分为几步,我们将这个过程称为Tasking。
  假如,我们正在实现某个详情页的显示功能,它依赖于前端和后台。那么可以直接先做后台API,再实现前台API,最后依据需要微微调整API。我们也可以先用Mock的数据实现前端页面,再依据定义出来的数据格式实现后台API。在这两种不同的实现中,我们都有一个明确的先后步骤。同样,对于一个更加复杂的功能来说,需要切分得更加仔细,每一次只挑选其中一个任务,实现后,再一步步往下执行,最后实现这个功能。
  有意思的是,当我们已经决定切分为多步来实现功能的时候,就可以在每一步里进行几次不同的代码提交,以便以后知道每一步中做了什么内容。如果只是在最后一步直接提交代码,那么在未来修改代码时,便难以理清当时的思路。
  一个合理的编码过程不仅包括功能的实现,还应该有测试。尽管出于项目进度的原因,多数项目都不存在测试,而正是因为没有测试,使得整个项目更加混乱。新的功能容易影响旧有的代码,除非有足够多的测试人员,否则我们无法保证所有的功能都是正常的。在有限的条件下,我们应该编写重要的测试,以保证核心功能不被破坏。在条件允许的情况下,我们应该尽可能地保证测试对重要功能的覆盖。由于代码库不只有一个人在提交,如果在某次提交中测试被破坏了,就可以知道谁破坏了测试,他/她应该有责任来修复这个测试。
  在完成功能后,我们还可以对代码进行重构,以此来保证代码的质量。此外,在日常工作中,我们会用Code Diff(代码检视)来帮助大家提高代码质量。因此,并不是实现了功能就完事了,我们应该尽量保证代码的质量。

2 . 上线和数据分析

  好了,现在是时候上线了。在以前,上线就是登录到服务器做数据备份。随后,在本地构建、上传软件包,安装软件的依赖。最后,重启服务器、Done。
  在今天看来,这是一件相当费力的事,我们可以使用自动部署工具来加快这个流程,甚至当我们有足够的测试覆盖率时,可以直接将测试通过的代码直接部署到产品环境。不过,要这样做应有相当的技术能力,并且要保证我们可以协调好开发人员、运维人员等。从技术上说,这可能是一件容易的事,但是从组织结构上说,这并不是一件轻松的事。
  而故事并没有因此而止步于上线,在产品上线时,我们可以通过数据分析工具来监测用户的行为、网站的访问量等信息。
  对开发人员来说,这样的分析平台可以帮助我们解决用户在使用过程中遇到的Bug—他在哪一步出的问题?他在出问题前做了什么操作?
  对业务人员来说,他们可以借此来分析产品受欢迎的程度、用户及流量来源、转化率等信息,并依此来对着陆页、转化率等进行优化。几种常见的流量来源包括搜索引擎、外部链接、付费搜索等,这些都可以依此来做出一些调整。从技术角度说,我们可以提高网站的SEO(搜索引擎优化)水平来添加流量,这将在《全栈应用开发》一书第7章中进行讨论。

小结

  本篇文章是对《全栈应用开发:精益实践》这本书的一个简单概述,点此链接可在博文视点官网查看此书。
                      
  《全栈应用开发》这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍,而是以实践的方式,将这一系列的领域及理论知识结合到一起来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用。

原文链接

时间: 2024-10-21 12:22:40

Web应用开发周期的相关文章

移动Web开发调研

背景 在移动互联网浪潮下,移动设备普及,对配置需要考虑移动端设备可访问性.Web作为最贴近用户的配置手段,面向从PC端传统页面,向移动端页面的转型. 概念 PC Web: 面向传统PC电脑的浏览器开发的Web人机交互界面. 移动Web:面向移动设备的浏览器开发的Web人机交互界面.移动设备包括:手机.Pad等移动设备. 移动APP:面向移动设备开发的APP软件,直接运行于移动设备的系统上.不同于移动Web,其不需要借助中间软件运行. Web APP: 以浏览器为入口,实现 App 的 Web 化

Web Service简介

1.1.Web Service基本概念 Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的通讯技术.是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册. XML:(Extensible Markup Language)扩展型可标记语言.面向短期的临时数据处理.面向万维网络,是Soap的基础. Soap:(Simple Object A

【Web】Web1.0和Web2.0

具体请参照百度百科: web1.0时代是一个群雄并起,逐鹿网络的时代,虽然各个网站采用的手段和方法不同,但第一代互联网有诸多共同的特征,表现在技术创新主导模式.基于点击流量的盈利共通点.门户合流.明晰的主营兼营产业结构.动态网站.在WEB1.0上做出巨大贡献的公司有Netscape,Yahoo和Google. Netscape研发出第一个大规模商用的浏览器,Yahoo的杨致远提出了互联网黄页, 而Google后来居上,推出了大受欢迎的搜索服务. 中文名 web1.0 特    点 群雄并起,逐鹿

java web学习笔记-jsp篇

转载自:http://www.cnblogs.com/happyfans/archive/2015/03/17/4343571.html 1.java web简介 1.1静态页面与动态页面   表现形式 所需技术 静态网页 网页内容固定,不会更新 html,css 动态网页 网页内容由程序动态显示,自动更新 html,css,DB,java/c#/php,javascript,xml,主流的动态网页脚本(jsp,asp.net,php) 1.2搭建java web开发环境 jdk1.7+tomc

Web应用框架在WEB工程中的作用

Web应用框架(Web application framework)是一种开发框架,用来支持动态网站.网络应用程序及网络服务的开发.它的出现是为了减轻网页开发时共通性活动的工作负荷并且可提升代码的可再用性.它是经过长期实践被大家认可的,正确,高效的代码. 常用的Web应用框架有MVC,CMS等.而这次我们团队所使用的Web应用框架就是MVC模式,这种模式的优点有很多例如耦合性低.重用性高.部署快.维护容易等详情参考百度百科http://baike.baidu.com/view/5432454.h

构建移动Web应用程序的技术堆栈

编写web应用程序时,有很多的技术决策.笔者最近回来编写现代Web应用程序,并希望总结一些曾经在开发周期过程中做了记录零散的想法.这篇文章是关于一套对笔者最近开发的项目有帮助的框架.笔者重温了一些最重要的框架类型,其中每一个可以展开来写一篇文章.这并不是一个广泛的现有产品相比,只是一个笔者最近使用的部分技术. 虽然笔者的重点是移动优先, 笔者认为,这套技术可以应用在一般的web应用程序. 笔者的决定和数据支持考虑了几个要求: 基于JavaScript(CoffeeScript,Dart,绝对值得

Java开发web的几种开发模式

Java Web开发方案有多种可供选择,这里列举一些经典的开发模式进行横向比较,为Java Web的开发模式选择提供参考.除此之外还有好多方案(如Tapestry和Wicket等等)并不了解,这里就不列举了. JSP+JAVABEAN开发模式:    特点:该模式将业务逻辑与页面表现进行分离,在一定程度上增加了程序的可调试性和维护性.    缺点:页面将控制与显示集于一身.    结论:简单,适合小型项目的快速构建与运行. JSP+Servlet+JavaBean开发模式:    特点:JSP作

web service

Web Service基本概念 Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的通讯技术.是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册. XML:(Extensible Markup Language)扩展型可标记语言.面向短期的临时数据处理.面向万维网络,是Soap的基础. Soap:(Simple Object Acces

Web Service 的工作原理

Web Service基本概念 Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的通讯技术.是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册. XML:(Extensible Markup Language)扩展型可标记语言.面向短期的临时数据处理.面向万维网络,是Soap的基础. Soap:(Simple Object Acces