程序员之我看“软件工程”

       笔者有7年的工作经验，但是平时对编码以及计算机相关的具体技术投入较多，对于软件工程这类涉及项目管理的专题思考以及经验不多。最近看了《构建之法》这本书，对软件工程进行了相关思考，现分享如下。

       软件工程，可拆为软件+工程，即针对软件开发的工程。工程又可拆为工+程，即工作的流程。具体到软件工程的实践上，可以抽象出如下公式：软件工程=工具+方法+过程。

      这里从过程开始分析，分为想法、概念、计划、设计、开发和发布六个阶段，更加具体可以分为：立项、可行性分析、需求、设计、模型、前端交互开发&后端逻辑开发、测试、部署、维护。

关于开发设计

      接下来从软件工程师的角色出发讨论本职责相关的工作方法优化。对于7年的老司机，编码的工作已经很熟练，主要在设计上。一开始如果能够对一项工作内容有总体的把握和设计，中间的”弯路“也会少很多。所谓的设计也要遵从从外到里的原则，这里的外就是业务，这个就是著名的领域建模。所谓领域建模，就是建立一个模型，从业务上看这个模型能够反映业务上的关键实体及其之间的交互关系，而后开发设计也以这个模型来进行划分。后面业务人员和开发就能通过这个模型进行沟通，后续的接手人员通过这个模型也能够快速地了解业务与代码思路。

      这是针对某一个功能的设计，如果范围扩大到整个业务的设计呢？可以参照以下步骤：

一、构造总体模型

进入条件：团队已经选好问题领域专家、主程序员、架构师

任务1：决定建模小组成员，一般团队成员可以轮流参与，一般团队成员可以轮流参与

任务2：问题领域专家概要介绍问题领域知识。大家学习已有的参考资料（已有的建模文件、数据模型、功能需求、用户文档）

任务3：以不超过3人的小团队构建子问题领域的模型，并在适当的时候补充总体模型

任务4：记录模型的信息并保存为文档

 

验证：

和团队内部或外部的利益相关者验证模型以及它们对用户和业务活动的影响

 

出口条件：

总体模型已经建好；各个实体（类）的关系也已经表达清楚，各个实体的属性和函数有初步定义；数据流、事件流程等说明文档已经完备

 

二、构造功能列表

进入条件：团队已经选好问题领域专家、主程序员、架构师

主要任务：构造功能列表

功能：把大的问题领域分解为小的主题领域，然后描述在主题领域中出现的业务活动

 

三、制定开发计划：

1、各种实体和功能之间的依赖关系

2、实体和功能的复杂程度

3、高风险和高难度的功能要适当提前

 

四、功能设计

 

五、具体实现

当然以上都是有前提的，如果是非常熟悉的功能或者项目，大家都是老手了，许多步骤就可以简略化，就像王勃的“腹稿”。

 

关于“砍需求”

        这些是开发的份内事，但是是不是一个需求或者改动来了，开发就照做呢？“高级”的开发应该更进一步，对需求有更深入的理解，从而砍掉不需要的需求，或者需求中不需要的部分。

这个需要对需求和用户有足够的了解。笔者的操作方法如下：简言之，就是把自己想象成用户，每天做着实际用户的工作，每日的工作重点是什么，这个需求点是否对自己造成很大的时间浪费，以及与工作重点是否相关。 

如果是，那么这个需求点的关键是什么，解决它要处理哪些数据？（产品设计中是否牵涉了许多不相关的数据以及流程）

如果都认同，那就开发；否则就可以找产品掰扯。

 

      说到产品设计，这是产品经理负责的，那么他们设计时的原则是什么？产品是为用户服务的，所以要从用户角度看待产品；但是产品又是有自己的着重点的，即主打满足用户的什么需求。例如，作为一个论坛,stackoverflow需要有发帖等基本功能；但是作为一个以技术相关内容为重心的论坛，它的网站功能设计就要围绕这个来展开，相关的衍生产品也要围绕技术产生。在平时产生新的需求想法或者用户提交了新的需求时，就可以以这个作为判断依据。这个需求是我们主打的吗？是刚需吗？