以终为始,方得始终。
我们开发软件最终的目的是交付出完整的软件项目或可靠的软件服务。但是我们在开始软件开发之前,拿到的需求大多数情况下是模糊的,不准确的。假设在我们的组织架构中没有一名专业的产品相关人员对需求进行沟通和整理,这就要求我们的开发人员具备整理需求并将需求转化为完整的软件产品的能力。
如果要将需求转化为一个完整的产品,那么按照标准的软件开发流程,我们往往需要形成产品文档、技术文档、接口文档和产品文档等等一系列文档。但是因为我们工期太紧张,往往没有充足的时间去整理这些文档。
在高质量、高可用和紧张工期的矛盾之下,我们必须对软件开发流程进行标准化、流程化、规范化设计并且对“三化”的具体细节根据我们的需要进行贴合我们工作情况的取舍。
软件开发流程
在百度百科中,软件开发流程分为需求分析、概要设计(系统设计)、详细设计、编码、测试、软件交付、验收和维护八个阶段。
但是我们在工作中一般不会严格按照这八个步骤进行系统设计开发。
我们一般使用到的阶段会有需求分析、系统设计(概要设计+详细设计)、编码(后端编码、前端编码、前后端联调)、测试(开发人员自测、内部测试)、软件交付、验收和维护。
需求分析
在需求分析阶段,我们的工作方式一般是由销售人员口述客户需求或者由技术人员直接跟客户进行对接的方式进行需求交接。
在需求交接完成之后,由技术人员自行分析需求并进行软件开发。
但是在对接完成之后就进入紧张的开发阶段,却没有足够的时间编写相关文档或者制作原型图给需求方进行确认,这就可能会导致双方对需求的理解不一致从而导致交付的软件和需求方需求不一致的问题。
所以在这个阶段需要产生一个基础的功能框架,比如线框图形式的原型图或者脑图。
这样,让需求方和开发方都能够大概的知道要做什么事情并对要做的事情有一个直观的概念。
系统设计
在系统设计阶段,分为三部分。分别为后端系统设计、前端系统设计、前端设计图。
前端设计图
在确定了需求之后,我们通常会找设计部门的同事进行设计图设计,此设计图将会交给客户进行确认,以使客户能够对最终交付的软件有一个直观的认识。也方便用户根据设计图了解到最终交付的软件和自己的需求是否有出入,以便进行需求修正。
但是,我们面临的内部问题是我们并没有专业的 UI 设计师。设计师并不具备 UI 设计相关专业技能,更不必说考虑软件交互。
在面临这种情况下,我们只能寄希望于设计人员的审美没有问题。但是在软件页面元素和交互方面只能靠我们通过做一个高保真原型让设计人员只需要考虑美化就好了。
后端系统设计
后端系统设计没什么可说的,因为后端开发人员从需求整理到软件生命周期结束是全程参与的,而我们在软件质量、接口安全等方面只能依靠我们的后端人员了。但是这样开发软件也是感觉挺悲哀的。竟然连一个完整的团队都没法拉出来,队伍配置不完整必然是存在隐患的。
在后端开发的过程中,为了能够清晰的知道自己到底做了哪些事情,让软件变的更加可控,我设想在后端开发过程中,使用思维导图工具将后端功能和接口整理为一个可视化的思维导图,这样既方便后续进行接口联调,也方便交付软件或者给后来者做参考。
后端开发人员在完成开发工作之后,需要产出的除了代码之外,还包括接口文档,接口文档是用来提供给前端开发人员进行接口对接的。
在我编写接口文档提供给前端同事使用的过程中发现前端同事往往不能够知道我的接口到底是写给哪里使用的,所以后来我们约定了接口文档中的标题的命名规则,那就是:模块名-接口功能,比如:首页-商品推荐列表。这样,不论是自己再看接口文档的时候还是前端人员在根据接口文档进行开发的时候都能很清晰的知道接口到底应该使用在哪里,这也算是一种提高开发效率的办法吧。
前端开发
因为在原型设计阶段、后端开发阶段已经做了大量的工作,所以前端人员的工作就相对轻松一些。前端人员只需要按照设计图将设计实现出来然后和后端进行接口对接或者做一个简单的切图仔,只需要完成基本的页面开发然后交给后端开发人员集成到项目中即可。但是现在大部分团队采用前后端分离的开发方式所以前端人员做切图仔的机会也越来越少了。
接口联调
在前端开发人员按照设计图将页面全部都开发完成之后,即可按照后端开发人员提供的接口文档进行接口对接,在接口对接的过程中可能会发现接口不好用或者缺少某些接口,这就需要前后端经过协商之后补充或者修改接口了。
测试
在接口联调完成并且确保所有设计的功能都已经开发完成,生产出的软件已经是一个完整的软件并且可以形成一个闭环之后,就可以进入测试阶段了。
在测试阶段,需要对软件功能,软件流程,软件安全,软件性能等进行一系列测试。
但是在小公司里边一般是不编写测试用例的,所以都是人肉测试。这个时候就不免会有一些缺失。我们在前面整理的思维导图也就到了发挥作用的时候了。我们可以将思维导图中的内容当做一个checklist进行一个相对完整的测试。
软件交付