你不了解的软件开发过程


中国 IT 从业人员中对软件研发过程有系统认识的少之又少,甚至在工作中遇到的科班出身的研发同学同样不例外。相反,大家对于追求热点概念(例如:DDD,领域驱动设计)倒是不遗余力,满怀热情。

软件开发刚开始的时候,并没有很好的经验或思想来指导项目研发。从研发的各种名词中可以看出来,软件行业从建筑行业借鉴了许多经验。

  • 建筑行业涉及到不同角色协作:设计师、开发商(工人、电工和水暖工)、质量监理、等等。

    软件工程类似的角色:产品经理、研发(后端、前端、客户端)、测试、QA

  • 建筑行业遵循的流程:把端到端的项目分成不同的阶段,每个流程阶段由不同角色负责

每个阶段赋予角色的做法,有利于充分利用成本高昂的人力资源。在借鉴的基础的产生了第一个标准的软件开发流程

img

事实上,如同力学三大定律为物理学奠基一样,瀑布模型在软件行业的地位同样不可动摇。虽然随着历史的车轮滚滚向前,软件研发方法论的研究重点从瀑布模型的 “流程”,过渡到以交付速度和成功率为目标的敏捷开发、持续集成、持续交付、持续部署。但研发过程的核心步骤从未改变:分析、设计、开发

img

然而,不幸的是,因为追求交付速度、成功率,国内研发不仅丢掉了瀑布模型,也丢掉了核心过程。太多的研发以敏捷为理论核武,把设计完全抛掉,更遑论分析。如果系统确实太过复杂,抑或领导要求,那就装模作样加入一个设计阶段,设计一个看起来能够跑的通的架构。一旦软件进入实现阶段,所有的设计文档就被雪藏起来吃灰。

重视开发多于设计,不知分析为何物。架构凭经验和感觉,就像无根之水,即使再美也经不起业务变化和迭代的侵蚀,最终走向腐朽。最后不得不亮出终极武器:重构(其实,是“重做”)。

意识到需要做分析、设计,到知道如何做分析设计,中间有着不小的鸿沟。软件开发不是玄学,有着系统的方法论,以及完善的表达工具。需求分析从业务开始,层层剥开,直至实现。如果把软件想象成建筑,那么各种图就是从某一个特定的视角(viewpoint)表达软件的设计图纸,因此RUP C4+1 称之为 View model 也大抵表达该含义吧。选择合适的图表述,把软件表述清楚也能体现出工程人员的软件设计能力。

各个层级的分析对象

各分析阶段用于表达的图

具体使用细节,不再使用例子详细描述,可以参考: