软件研发三大思维之三:工程思维

2019-03-29   出处:软件质量报道  作/译者: Test Ninja  

想成为一个优秀的软件企业,要培养自己的团队具有良好的产品思维、项目思维和工程思维。本文就产品思维、项目思维和工程思维进行讨论,帮助读者更好地理解项目管理、产品管理和工程管理之间的区别和联系。


工程思维


产品思维偏于感性,喜欢从人性、社会性角度去思考问题,从“人机交互”角度去思考,从用户、用户行为、应用场景、业务流程等角度去思考问题。而工程思维属于理性思维,喜欢从方法、技术角度去思考问题,从“数据交互”角度去思考,从数据流、业务规则、业务逻辑、异常条件、异常数据等角度去思考问题,如:

  • 用户不登录能看到哪些数据?

  • 系统登录时需要用户输入什么数据?

  • 对用户名和口令建立哪些验证规则(字母大小写是否敏感、口令长度、含哪几类字符等);

  • 口令或用户名输错了给予什么提示?

  • 口令输错多少次,账户被锁定?

  • 用户可能会输入哪些特殊字符?

  • 黑客有没有可能暴力破解口令?

  • 黑客能否在字符串类型域中输入script脚本?

从这样的思维过程,我们可以看到工程思维的轮廓。工程思维之所以是理性的、科学的和逻辑严密的,是因为工程本身具有系统性、复杂性、集成性和组织性,而且会涉及人们生命安全和财产安全。工程方法强调以人为本、安全第一,要考虑自然、环境、经济、管理、人文、伦理、社会、技术,做到工程与自然的和谐、工程与社会的和谐,持续优化,达到高度的安全性。


工程思维类似项目思维,我们常常将“工程”和“项目”组合起来,形成“工程项目”,但工程思维不同于项目思维。从一个工程看,资源、成本、质量这些概念也都在,似乎也离不开资源调剂、成本控制、质量保障等要求,似乎也是工程思维的出发点,工程思维也关注质量和效率、关注流程,按步骤、按流程实施工程。实际上,两者有比较大的区别,项目思维侧重从资源调度、进度控制、风险管理等来实现项目的目标,包括计划、平衡、沟通等,侧重管理。如果简单地说,项目思维更多体现在管理思维上。而工程思维侧重用工程技术与方法来解决问题,从提出工程问题到分析问题、解决问题,更多体现了工程方法和系统工程的思想。

工程思维,首先是一种技术思维,更多是想通过技术手段、通过工具来解决问题。产品思维定义一个软件产品,工程思维就会想如何选择合适的技术架构、如何设计系统内部的逻辑结构、选择什么编程语言来实现,从而在性能、可靠性、安全性等方面满足软件系统的要求。追求高性能和高可靠性、用机器来模拟人的行为(机器人)和推崇机器学习等,这些其实都是技术思维的体现。就一个直播App的开发为例,产品思维会考虑用户如何使用这个App以及如何获得良好的体验,如用户不注册就能看到几个精彩视频选段和目前受欢迎的主播列表,一旦点击某主播头像,这时要求用户注册账号,注册完后就能点击某主播头像、进入主播房间看直播,看直播过程中可以互动(点赞、打赏、和主播聊天等)。而工程思维想如何实现这样场景,满脑子是音频和视频、视频存储格式、摄像头兼容性、视频编码(encode)、视频解码(decode)、内容分发(CDN)、音视频同步、最大容量、性能瓶颈、高速缓存、播放器SDK等。


工程思维是一种抽象思维,需要将复杂的工程问题进行简化,去掉不必要的信息,抓住问题的主要特征,构建起能够描述问题的抽象模型。模型可以指为了解决特定视点而简化某些事物的任何抽象,从而成为不同研发人员或不同团队之间沟通的最好载体。借助模型,不仅有利于团队沟通,有助于我们看清问题的本质,而且建立了一种大家认可的标准,从而有效、彻底地解决问题,如过程模型、架构模型等。

  • 如何看清软件研发过程,从而建立研发流程?这就需要建立软件过程模型,包括瀑布模型、V模型、RUP统一过程模型、XP模型、Scrum模型、BDD模型等;

  • 如何让我们看清楚系统的架构?就是借助架构模型来表达团队共同的系统结构关注点,有助于软件系统的结构和设计中做出特定的权衡。软件系统架构,通常用不同的视图来描述,如UML将系统架构分为静态视图(如类图、对象图、组件图、部署图、包图等)和行为视图(用例图、序列图、通讯图、状态图、活动图),而C4 模型使用容器、组件和代码来描述一个软件系统的静态结构(如图1所示)等。 

图1  软件系统架构C4模型示意图


工程思维是一种上下文驱动思维,上下文(context)在软件工程中是一个非常重要的概念,无论是选择怎样的过程模型、还是选择怎样的系统架构。图1中系统架构的第一层“软件系统”就是系统上下文,需要考虑该系统与用户、其他软件系统之间的关系,明确系统之间的接口,实现安全、无缝的集成。构建一个软件新系统,需要考虑的上下文,不仅是与之相联、相关的已有系统,还需要考虑其它上下文因素:

  • 谁使用这个系统?有哪些用户?用户数量多大?同时在线用户有多少?

  • 处在什么业务领域?是性命攸关还是使命攸关的行业?

  • 是产品线开发还是一次性的项目?是现场开发还是外包到乙方的项目?

  • 是全新版本开发还是在已有版本上进行版本升级(功能增强、修改等)?

  • 团队掌握哪些开发技术?其技术水平如何?

  • 公司的薪水是否有竞争力?团队是否稳定?

不同的上下文,工程的解决方案是不一样的。


工程思维是一种分析性思维、批判性思维,也是逻辑演绎的思维。软件工程的核心是分析问题和解决问题,在这过程中有很多假定和推理,需要我们做出正确的判断,在做出判断前,要质疑,所以软件工程中分析性思维或者说纵向思维是主导性思维,虽然也需要创造性思维、水平思维。分析性思维强调假定、推理过程,如果假定有问题、推理过程有问题,就需要质疑,所以常常需要用批判性思维武装我们自己的头脑,在评审需求、评审设计时,应具备良好的批判性思维,质疑其中模糊的、有歧义的描述,质疑某些缺乏可信度的信息来源或脱离实际的假设,从而发现需求和设计中的问题。如果假定或推理不可信,那么结论就不可信;如果觉得结论不靠谱,那问题就出现在虚构的假设或不合理的推理之中。例如,在综合考虑各种因素之时,许多情况下需要运用批判性思维:

  • 利益相关方所提供的信息是否出于自己的利益?所以更相信利益无关方所提供的信息;

  • 如果支持结论的证据不是客观事实或缺乏可信度,那么这个结论就值得质疑;如长时间从事于某工作的这一事实,并不等于对此拥有丰富的经验。

软件系统常常是一个复杂的系统,将复杂的问题逐步分解为简单问题,各个击破。工程思维往往是逻辑演绎思维。实际上,1968年软件工程诞生时,就提倡结构化分析与设计的方法,结构化方法的核心就是自顶向下分解,包括业务的分解和系统结构的分解,先分解再合成,通过将系统分解为模块,厘清和优化系统的结构,实现高内聚、低耦合,然后实现一个一个模块,然后经过单元测试、集成测试,最终合成为一个系统。


工程思维是一种系统性思维,不管是分析问题还是解决问题,而非“头痛治头,脚痛治脚”,要正确又彻底地分析和解决问题,必须具有系统性。工程思维往往把一个软件产品看成是一个系统,有哪些组件构成,内部逻辑结构是怎样的,能否分解为前端、中间件、后端等组成部分,强调系统性解决问题。在分析问题时,不局限于某一个方面,而是尽可能从各方面(如人与组织、流程、技术、环境、管理等)寻找问题产生的原因,类似鱼骨图、故障树分析方法,通过多层分解,不断细化、演绎推理,将思考的触角伸到该主题相关的地方,不漏过任何影响因素,确保分析的完整性。系统思维方式可以帮助我们更好地理解系统内部构成之间的关系、系统与外部之间的关系,例如在软件测试中,系统思维可以帮助更好地理解测试方法:

  • 白盒方法:就是探讨系统内部结构,面向系统结构进行有针对性的逻辑覆盖测试,也称为结构化方法;

  • 黑盒方法:就是探讨系统外部关系,把系统看成整体,了解系统的数据输入输出、系统运行的环境以及可能受到的限制条件,也称为数据驱动方法。

这里也看到工程思维,不仅是系统思维方法,而且离不开逻辑和数据。


工程思维不是数学思维而是比较、择优的思维,工程方案不是唯一的,一定有多种解决方案,其中必有一种相对优秀的方案,这样又把问题转化为“如何对解决方案的评价”,评价方法成了关键,且这种评价是多因子的综合评价,每个因子会有不同的权重。软件工程也就是在不断优化过程中发展起来的,从量变到质变。


软件工程思维也可以分为宏观思维和微观思维,宏观上要思考将事实与工程原则、价值观和想法区分开来,认识到技术、法律/法规、经济、环境和安全所带来的影响,思考解决哪些关键问题(类似产品思维)、技术解决思路、方案评估标准、制定工程规范的原则、简化工程、如何开展质疑活动等。微观上要思考具体的业务数据、具体的假定、识别和应用适当的模型、质疑不完整或含糊不清的信息、为设计结论提供适当的证据、分析解决方案和测试数据的差异等。

工程思维比较抽象、模型化,是系统的、科学的、量化的思维,经验、类比、评估、迭代等元素也存在,并不断趋于成熟。最后,通过一张表格(表1)了解产品思维、项目思维和工程思维之间的区别,而通过图2了解它们之间的关系,产品思维和项目思维之间交集偏少,而工程思维和项目思维、产品思维交集较多。

表1  产品思维、项目思维和工程思维之间的区别

图2 产品思维、项目思维和工程思维之间的联系


欢迎给测试窝投稿或参与内容翻译工作,请邮件至editors@testwo.com。也欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,并与我们的编辑和其他窝友交流。
250°|2507 人阅读|0 条评论

登录 后发表评论