软件工程之思系列---初窥门径

一、啥是软件工程？

"软件开发领域里对工程方法的系统应用"

"以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题"

"将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"

" 为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则 "

"研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科"

就上面这定义估计一般人理解不了

1、软件工程起源：

上古时期怎么做软件？----- 一顿猛敲代码，能用就行，随心所欲，快意恩仇

但是，这样造出来的软件，缺乏规划，不好扩展，基本就是一次性的。

这种缺乏规划的做法，导致软件开发中出现大量的 进度延迟 、 预算超支。

——其实不光软件，各种项目大多如此，俗话说“预算就是用来超的”。

计算机行业发展迅速，痛点越来越不能忍！人们称之为“ 软件危机 ”！

1968年，“北大西洋公约组织(NATO)科技委员会”决定一举灭掉这个痛点！

他们提出了“ 软件工程 ”的概念，试图是用“工程化的方法” 解决 “软件危机”。

从此，软件开发归为工程之列，成为工程项目领域最年轻的成员。

从此，程序员也叫“软件工程师”（这可是猿到狮的升华）

至于软件工程的目的，教科书上讲的都很晦涩；

其实总结来说很简单，就是—— “多快好省”地造软件 。

还有一点注意：软件工程关注的是 大型软件， 所以很多“攻城狮”并没有真正的看到或感受到软件工程具体是个什么玩意。

2、软件工程的本质特性

1. 大型项目——软件工程的提出，主要是解决政府的大型软件开发问题，没考虑小型软件；

2. 项目把控——软件工程的中心课题是 控制 复杂性，使软件项目不是空

3. 团队合作——大型软件项目，自然要很多人合作开发；

4. 需求变更——软件经常变化，要适应不要抵制；

5. 开发效率——开发软件的效率非常重要；

6. 用户体验——软件必须有效地支持它的用户；

7. 业务流程——在软件工程领域中，创造软件产品的软件工程师们 往往缺乏产品相关业务领域的知识。

3、软件工程7条基本原理

美国国家工程院院士 巴利·玻姆（Barry W. Boehm），1983年发表论文，总结了软件工程的7条基本原理：

（1） 用分阶段的生命周期计划严格管理——各种工具往上顶、契合公司的可信活动

（2） 坚持进行阶段评审——需求、设计、开发、测试、上线、运维、优化，周而复始

据统计，软件的错误中，设计错误占63%，编码错误占37%；越晚发现错误，代价越高。

（3） 实行严格的产品控制——需求不是你想改，想改就能就改

（4） 采用现代程序设计技术——先进的技术可以提高开发/维护效率，提高质量（技术选型）

（5） 结果能清楚地审查——各种监控工具给我上，不玩虚的，数据说话

（6） 开发小组的人员应该少而精——敏捷的精髓就是精兵强将

（7） 承认不断改进软件工程实践的必要性——也就是“精益求精”、“工匠精神”什么的。

二、软件工程师的价值是啥？

    技术市场就像这喜怒不定的天气，今天下个大数据的雨，明天刮个人工智能的风，面对琳琅满目技术浪潮的冲击，程序员难免深感无力，深怕错过了技术潮流从而失去了职场竞争力。 有时候我会思考难道在技术领域内不断紧跟新潮，不断提升技能就是我的价值所在?那么我是技术的主人还是技术的奴隶？

    人之所以迷茫往往是找不到工作生活的重心，感受不到工作或生活的价值。那么什么是价值呢？说的大一点就是我改变了世界，说的小一点就是我的所作所为改善了某些问题。如果不清楚自己的行为、目标、价值三者的关系，那么又何来重心？又如何能分得清重要性与优先级呢？
    程序员的迷茫不仅仅是面对技术繁杂的无力感，更重要的是因为长期埋没于软件世界的浩大的分工体系中，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系所致。
    很多程序员打心底不喜欢业务，这一点我现在也没改变(惭愧，努力中)，我更宁愿从事框架工具、技术组件研究的相关事情。

    我有个朋友灵魂三问:"你研究那么多技术，有啥用？想做业界标准？给部门带来了多少收益？"

    仔细想想很多时候业务在我们脑海中存留的只是逻辑和流程，我们丢失的是对业务场景的感受，对用户痛点的体会，对业务发展的思考。这些都是与价值紧密相关的部分。我们很自然的用战术的勤快掩盖战略的懒惰！那么这样的后果就是我们把自己限死在流水线的工位上，阉割了自己能够发现业务价值的能力，而过多关注新技术对职场竞争力的价值。这也就是我们面对繁杂技术，而产生技术学习焦虑症的根本原因。

    那么什么是业务呢？就是指某种有目的的工作或工作项目，业务的目的就是解决人类社会与吃喝住行息息相关的领域问题，包括物质的需求和精神的需求。使开展业务活动的主体和受众都能得到利益。通俗的讲业务就是用户的痛点，是业务提供方（比如公司）的盈利点。而技术则是解决问题的工具和手段。

    以我所在部门（制造部）为例，软件活动的一切目的都会围绕提高生产质量、提升生产效率、节约生产成本，协助部门实现伟大的战略规划。 技术如果脱离了业务，那么技术应用就无法很好的落地，技术的研究也将失去场景和方向，而业务脱离了技术，那么业务的开展就变得极其昂贵和低效 。

所以：

软件工程师的价值是啥？------利用技术手段创造行业价值

啥是研发部门？-------研究点高大上的工具，供别人使用

啥是IT部门？------ 用研发部门的工具写业务系统

三、如何做好一个项目/产品？

A、软件项目管理的金三角：时间、成本、范围

任总说过： 我们各级管理者和全体员工都不得以进度、功能、特性等为理由来降低可信的要求，确保可信的要求在过程中不变形。

这句话讲的就是软件项目里的金三角：时间（多久可以完成）、成本（花多少钱）、范围（需要实现多少功能），这三个要素决定了最终交付的软件的质量。

看到没？是三要素决定了软件质量，质量不是最初确定的，也不是神圣不可侵犯的，随便一个糟糕的设计、一行坏味道的代码都能让软件质量体无完肤，保证质量，谈何容易？

想要软件的成本低，又想要质量好，那就得等；想要便宜又想快速上线，那就得接受质量不好的现实；想要质量好又想要快速上线，那就得花钱；想要价钱便宜、质量好，又要快速上线，是没有这种好事的。

借鉴一下著名的"金三角"理论：瀑布模型种范围是固定的，时间和成本是可变；敏捷开发中成本和时间是固定的，范围是可变的。

B、Supercell公司浅析及个人感悟

Supercell（超级细胞） 是一家 芬兰 赫尔辛基 的电子游戏开发商。公司成立于2010年。知名的作品包括《 卡通农场 》、《 部落冲突 》、《 海岛奇兵 》、《 部落冲突：皇室战争 》、《 荒野乱斗 》。

Supercell 只有 200 多名员工，一个游戏的研发人员只有 4-5 个，这跟国内公司大队伍作战很不一样，都没有一个部门的人多。介绍一下这200人的作战模式

- 容忍失败

团队人员提出一个游戏 Idea，团队成员就一起去实现它，但在开始之前会先设定一些指标，比如玩家留存、参与度，当游戏进入公测之后，如果指标未达到，他们就会选择放弃。supercell 允许各个小团队不断快速试错，快速验证，这个过程其实时间是非常宝贵的。

- 快速尝试

曾经在两年内，他们只发布了一款游戏「皇室战争」，但期间取消了 9 个项目，和若干很多优秀的创意原型。所以今天我们看到支撑 Supercell 百亿美元估值仅仅几款游戏，但其实其背后有数不清的被验证失败的项目作为垫脚石。

- 优秀的人（一群体态臃肿的大胖子组成的团队，我看你咋敏捷，累死你）

采用倒三角的模式组织团队，一个游戏公司下面分成了若干游戏小团队，决定权不在公司管理者手中，而是在各个小团队自己决定，因为小团队 才是真正知道产品的人，但产品目标没达成就必须中止。这决定了团队的每一个人是足够 Super 的 Cell。

为了实现快速尝试的目标，每个游戏的研发人员只有 4-5 个左右，他们是如何 Cover 原本繁杂的游戏开发流程，同时保持敏捷。其原因是他们开发一些基础设施、内部开发工具和平台，为其他小分队提供工作的工具和框架。这样研发人员只需像涂秘密花园一样，按照自己的想法进行上色即可，大大提升开发效率和降低出错可能性。这个过程其实 Supercell 是将游戏开发过程中需要用到的一些公共内容进行抽取，组成一个个公共的 Component，当新起一个项目的时候，取所需的 Component，自定义部分还是交给各个项目 Idea 开发者。

看到 “公共内容的抽取” 会觉得与平台概念类似，这两者之间是否存在什么区别呢？ 平台化更多的是技术层面的能力抽象 ，例如：统一用户、统一权限、统一登录，更多的是技术能力的复用 （jalor6、H.A.E、AUI？个人理解差距还是很大的） 。中台范围会更加大， 除了能力复用，还有数据的复用 ，重心是为业务服务，快速响应客户需求。（ 后续再聊中台、微服务、数据湖 ）

C、个人解读：

软件工程三要素： 方法、工具和过程 ，这无可厚非。但是我认为项目的成功与否关键的核心点是 “人”， 无论你多NB的理念、方法没有人去做或是做不好那就一点P用没有。。。

涉及的人员包括：产品经理、BA、SE、开发人员、DBA、测试人员、运维人员、平台技术支持人员、周边协作团队。

D、目前我参与的和见过的项目流程

1、立项

上会！（研究一下能不能上？咋上？谁上？啥时候上？怎么上？）

2、产品/项目规划（暂时没见过有这个规划）

3、业务需求澄清阶段

（1）讲业务价值（有的讲、有的不讲、有的讲不清楚）

（2）讲解需求（要有需求文档，详细的！！！能指导做设计的那种）

（3）理解需求（这个有难度，可能存在就是理解不了的情况）

（4）修改需求后再次讲解需求、理解需求（可能还是 存在就是理解不了的情况 ）

4、环境准备阶段

（1）上会！（ 叫啥忘记了，看看把你这个项目塞到哪？是别人的子还是自己的父 ）

（2）申请APPID（名正言顺了）、申请子模块（大树底下好乘凉了）

（3）申请服务器（得求助运维）

（4）绑定部署单元（得求助大佬）

（5）各种环境配置（得求助好多大佬）

5、项目搭建阶段（终于到SE的环节了）

（1）jalor6还是H.A.E（基本都是jalor6）

（2）Gauss还是Oracle（基本都是Guass）

（3）maven多模块项目结构规划

（4）GIT库创建

（5）多租户

（6）网关

（7）各种第三方组件引入（lombok、swaggerUI、mybatis。。。。）

（8）公共模块编写（统一restful返回值、统一异常处理、工具类、消息队列、redis缓存、上传下载、导入导出、定时任务、UEM、监控策略、数据源配置、事务配置）

6、开发阶段

（1）概要设计

（2）详细设计（表设计、服务设计）

（3）开发人员开始CRUD

（4）核心人员解决技术难题和复杂逻辑

（5）自测

（6）转测

（7）申请变更号

（8）上线、有BUG、回退、挨批、找BUG、修BUG、再上线！

（9）运维，现在都在推行DevOps，自己的狗粮就自己吃吧

7、求助阶段（这个能力太重要了！！！）

（1）求助团队内部同事

（2）求助部门平台组同事

（3）求助流程IT平台组同事

（4）求助关系不错的同事（目测这个是最管用的途径）

这一顿操作下来，整个开发链条上涉及的人员较多，如果某些环节出现了问题（人出现了问题），说实话，项目失败的概率很大，成功的概率不敢妄自揣测、估计。

上一幅极具代表性的图片：

按照从左到右，从上到下的顺序依次来说说每幅画的意思：

1. 客户：我家有三个小孩，我须要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。客户在描述需求时倾向于提供过多的信息。

2. 产品经理：秋千这东西太简单了，秋千就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。

3. 工程师按照产品经理的要求设计产品。两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。

4. 程序员：开始写程序。两条绳，一块板，一棵大树，接在树的中段；太简单了，工序完成。

5. 测试人员：收到开发部门的产品进行测试。一根在末端系了个圈的绳子。

6. 销售人员：终于产品完成，销售人员开始向客户推销：通过人体工学，工程力学多方面研究，本着为顾客服务出发，我们的秋千产品让您如同坐着沙发一样舒适。

7. 当需要用到文档的时候，总是找不到。这么小的工程没有文档很正常，只要需求说明书与合同就可以了。

8. 实施人员交付的产品的时候，只要把绳子系在树上就可以了。

9. 客户：花了这么多钱，真的能和过山车相媲美了。

10. 客服解决问题的方法简单粗暴。

11. 市场营销做的广告那是相当的高大上。

12. 瞧！客户真正想要的只是一个简单的轮胎秋千。

计算机科学是跨学科特别明显的，包括但不限于高级代数、概率论、离散数学、数据库、数据结构、大学物理、汇编语言、编译原理、计算机网络、操作系统，计算机组成原理、数字电路、模拟电路、工程学、博弈论、信息论、密 码学。。。。在这个领域时刻要保持小学生一般的求知欲与谦卑姿态，当你知道的越多，你不知道的会更多

切记不要手里拿着锤子，就把所有问题看做钉子！

未完待续。。。。