读后感——《软件工程》——软件的本质及软件工程

前言

　　最近由于工作的感悟和需要，希望能够成体系得重新思考研发部门的实施方案以及与之配到的人员分工、结构层次、绩效考核以及协作流程等内容。于是就想起了软件工程这个学科，希望借助重新阅读《软件工程——实践者的研究方法（第8版）》一书，能够理通我这条路，让我能够找到合适的思路和落地的方案。
　　已经读了两章，第一章：软件的本质，第二章，软件工程。说实话，我的内心是很震惊的。因为，在十年前，我刚开始读软件工程这个专业的时候，因为我爸的问题，他问我说：软件工程是什么呀，和计算机科学与技术那个专业有什么区别呀。我一个高中毕业生懂什么嘛，所以，就带着问题来上大学。刚入学拿到课程表，发现，没人说这事，也没哪提到了，但是，听说软件工程，是门课，于是我就去图书馆借了两本讲软件工程书回来读了读，隐约记得叫软件工程导论。说实话，没读完，读到后面就读不懂了。但是，我了解了软件工程的历史，以及他要解决的问题，和他的基本方法论。由于软件危机，人们希望用工程化的方法解决软件开发不可控的问题，使用的过程模型是以瀑布式模型为出发，逐渐深入的迭代和螺旋模型啥的，要达到的目标分为稳定性、可扩展性、健壮性、可维护性等等。后面工作后发现，人们都拿这些东西当笑话看，说这些是对的，但是并不会执行。随着工作的深入，认识到为什么，也开始接触敏捷等方法论，也有过部分的实践。但是，我还是觉得我没法分析这个问题，甚至无法描述我要解决的问题。当我再寻求答案读到这两章的时候，第一次在书中感慨，时代在进步，软件工程的方法论已经如此落地和成熟了。

什么是软件

　　教科书上的定义如下：
　　1、指令的集合（计算机程序），通过这些指令可以满足预期的特性、功能和性能需求。
　　2、数据结构，使得程序可以合理利用信息
　　3、软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序的操作和使用。
　　但是更完整的解释或许还是无法让我们对软件有感觉，而如果我们说软件和硬件的区别是：软件不会“磨损”，不知道大家是不是有醍醐灌顶的感觉，反正我是感觉豁然开朗。
　　但是，软件虽然不会磨损，但是会退化，因为需求在变化，因为软件在迭代，一个软件会逐渐退化解决不了预期的问题，从而不再被人们所使用。

软件的应用领域

　　书中列举了七个，我这里仅作记录：系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、web/移动App、人工智能软件

遗留软件

　　遗留软件一向是一个老大难问题，而其根本原因是需求变了，技术变了。而我们必须承认的一个事实就是，这两个一定会变的，有变化是正确的，不可阻挡的，所以，我们要让自己适应变化。

软件工程

　　　先给定义吧：
　　　1、将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
　　　2、对1中所述方法的研究。
　　　可以看到软件工程大概分两部分，一部分是使用工程化的方法开发软件，一部分是研究和改进这些方法。

方法

　　记得不管是上课的时候还是在公司的时候，一提到软件工程的方法，大家想到的就是一大堆的流程节点和一大堆的规范的文档。而这些，大家之所以抵触，是因为这些方法成为了团队的负担。而这里也指出了，这些方法也需要可适应性和灵活性。而这种性质，似乎是通过将它的方法论变成一个层次化的技术，来进行的。

质量关注点

　　质量关注点，是根基。怎么理解呢？任何工程方法（包括软件工程）必须构建在质量承诺的基础之上。这又怎么说呢？我是这么认为的，我们开发软件，是为了解决问题，能否在解决问题，解决到什么程度，是衡量我们的质量的最终标准，而如果没有这个关注点，一切方法都是空谈。我对这个根基的理解，就是这样了。

过程

　　过程，是软件工程的基础。软件过程将各个技术层次结合在一起，从而使得合理、及时地开发计算机软件成为可能。，构成了软件项目管理控制的基础，建立了工作环境以便于应用技术方法、提交工作产品（模型、文档、数据、报告、表格等）、建立里程碑、保证质量及正确的管理变更。
　　过程，是工作产品构建时所执行的一系列活动、动作和任务的集合。

活动：主要实现宽泛的目标（如与利益相关者进行沟通），与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系。动作：包含了工作产品（如体系结构设计模型）生产过程中的一系列任务。任务：关注小而明确的目标，能够产生实际产品（如构建一个单元测试）

　　过程不是对如何构建计算机软件的严格的规定，而是一种具有可适应性的调整方法，以便于工作人员（软件团队）可以挑选适合的工作动作和任务集合。其目标通常是及时、高质量地交付软件，以满足软件项目资助方和最终用户的需求

过程框架

　　如果说 上述过程的定义，给了我们软件的生产流程核心概念的定义，那么，过程框架，就是生产流程中，必经环节的诠释或者说，必须解决的重大问题。
　　沟通 我很诧异这会列在软件过程之中，也很遗憾，我们一直没有明确这是一个重要的步骤。在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作，极其重要，目的是理解利益相关者的项目目标，并收集需求以定义软件特性与功能。在软件构建的过程中，我们往往只注意了需要的需求，而遗忘了利益相关者想要解决什么问题，甚至忘了问，这很可怕，不，这太可怕了。
　　策划 理解了目标，了解了需求，就需要策划如何落地。值得注意的是，策划，不是设计或者建模，它是软件项目计划，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。其产出可能是你们的一个项目计划文档，但是，那个文档，仅仅是这些工作的结果，而不是敲字打出那个文档就可以的，探索清楚这些事项，是需要工作量的。
　　建模 这个环节，大家都比较了解，或者，比较熟悉。但是，这也不是为了编写概要设计文档或者详细设计文档，而是为了更好地理解问题并找到解决方案，我们需要画一张草图来辅助理解整个项目大的构想——体系结构、不通的构建如何结合，以及其他一些特性。我们还可以把草图不断细化，以便更好地达到上述目标。这是必要的，如果尚未建立模型，就开始构建，很多时候，我们就可以开始准备下次重新再来了。
　　构建 包括编码和测试。这是一个谁都不会忽略的环节，但是这也是一个经常被我们放大的环节。为什么说放大呢？因为前几步做的不好，所以这一步就不太走得动，或者说会走很多弯路，那么，就都在这一步买单了。于是，这里机会做沟通的活，因为我们还没了解目标或者不是很清晰，所以有些需求不是很明确；我们会做策划的活，因为当时没有想得很全；还会做些建模的事，因为发现当初建立的模型串不起来，或者说不通。
　　部署 软件（全部或者部分增量）交付给用户，用户对其进行测评并给出反馈意见。这个步骤，我见过最多的是，收不到反馈意见，也就是没有用户测评，只有用户抱怨，很明显，是这一步没有想清楚。
　　上述过程说实话，还是会让我想到瀑布模型。但是，当时我就有一个思考：其实，瀑布模型是对的，只是我们太死板了。而现在的螺旋模型，敏捷模型以至于测试驱动和极限编程，其实，都是这个模型的变种，理论过程并未发生改变，只是经过思考后的不同落地。

普适性活动

　　过程框架定义了软件生产的基本流程，而普适性活动，则定义实现落地这些过程的活动。
　　软件项目跟踪和控制 项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。如何保证项目按进度计划进行，这就是个大问题了，加班？强压？加人？估计身处这个行业的都会动穿，这些都不是推进软件进度的好方法。那怎么做呢？欢迎探讨。
　　风险管理 对可能影响项目成果或者产品质量的风险进行评估。这里，我所经历的团队一般都有，但是，问题是，管理者自认为可控的风险是否还是风险？我个人的意见是，是风险，只是危险程度的高低不同罢了。
　　软件质量保证 确定和执行保证软件质量的活动。这个就很抽象了，我理解的也不是很具象，欢迎讨论，另外，我看看后面的章节是否可以解答我的疑惑。
　　技术评审 评估夫案件工程产品，尽量在错误传播到下一个活动之前发现并清除错误。这个活动，我也经常见到，但是，大多数都是走过场。项目组完成概要设计或者什么，把一帮人叫到会议室讲一遍，然后评审的人说通过，然后就完事。看似很正常，不正常的是，我没见过不通过的。直到我开始做评审的人我才知道为什么。评审的有效性，是我的责任，但是，项目的按时上线也是我的责任，如果我说评审不通过，那等下次评审，整个项目计划就会拖后，最后我是一定要倒霉的，但如果通过了，我说点简单的意见，那就没我啥事了，因为，最后这件事是可以让项目组买单的，或者说根本就可以蒙混过关，那就你好我好大家好，何必找不自在和所有人作对呢？那为什么要这样设定我的责任呢，为什么要把上限的责任也绑上我呢？无非就是怕中间我支持的不尽心嘛。所以，这件事，领导些要想清楚呀，你们想要的到底是什么？时间？还是质量？都要？如果只能保一个的时候，你选哪个？
　　测量 定义和收集过程、项目以及产品的度量，以帮助团队在发布软件是满足利益相关者的要求。同时，测量还可以与其他框架活动和普适性活动配合使用。说实话，我不是很理解该活动，希望后面的章节可以让我理解，也欢迎讨论。
　　软件配置管理 在整个软件过程中管理变更带来的影响。这个，说实话，我不知道怎么做。但是，从其作用来说，是我们现在的团队很需要的事情，很期待后续的章节。
　　* 可复用管理*定义工作产品服用的标准（包括软件构件），并且建立构建复用机制。可复用的构建，其实每个设计者或者开发者都想实现，但是，却发现每次构建出来的都不会被复用。有的是需求变了，有的是你复用的单元不合适，当然还有一个很重要的东西，没有纳入管理。没有纳入管理，就意味着没有人知道，没有人认可，这样就不会有人探讨他的正确性也不会有人思考它是否可以重用，等真到要来用的时候，要么不用你的重新写，要么用你的发现要改很多，所以，纳入管理，很重要。
　　工作产品的准备和生产 包括生产产品（如建模、文档、日志、表格和列表等）所必须的活动。这里我们就经常性的问题是，认为这些都是顺带着出来的，但是，这些是需要正式的活动的，也就是说，这些东西的产出是需要不低的成本的，否则，你就只能拿到一个应付差事的东西，但那又有什么用呢。毕竟，我们的根基是质量关注点。

软件工程实践

　　这里我就只列一下书中的提纲吧。
　　实践的精髓：

1、理解问题（沟通和分析）2、策划解决方案（建模和软件设计）3、实施计划（代码生成）4、检查结果的正确性（测量和质量保证）

　　通用原则：

第一原则：存在价值第二原则：保持简洁第三原则：保持愿景第四原则：关注使用者第五原则：面向未来第六原则：提前计划复用第七原则：认真思考

方法

　　为构建软件提供技术上的解决方法（如何做）。也就是过程中的活动具体的落地的解决方案，这里说的，就不只是编码的事情了，而是方方面面的技术，比如，如何沟通、如何策划等。

工具

　　为过程和方法提供自动化或半自动化的支持。如果一件事情做起来成本越低，我们就会更加频繁得使用。如果回归测试是自动的而不是拿人填出来，那我们就可以每天执行，从而得到更高质量的软件。由此看来，工具很重要。而这些过程、方法、工具中也体现出来了一个观点，高技术含量可以带来质的改变，它是无法通过低技术含量的工作相加来达到等同的效果的。

软件开发神话

　　软件开发神话，即关于软件及其开发过程的一些被人盲目相信的说法。下面我就只列举下吧，解释的话，篇幅太多，而且，基本就是抄原文了。

• 像所有领域的经理一样，承担着软件职责的项目经理肩负着维持预算、保证进度和提高质量的压力。就像溺水的人抓住稻草一样，软件经理经常依赖软件神话中的信条，只要它能减轻以上的压力（即使是暂时性的）。

• 我们已经有一本写满软件开发标准和流程的宝典，难道不能提供我们需要了解的所有信息吗。

• 如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度（即所谓的“蒙古游牧”概念）
• 如果决定将软件外包给第三方公司，就可以放手不管，完全交给第三方公司开发。
• 软件产品的客户可能是隔壁的某个人、楼下的一个技术团队、市场/销售部门或者签订软件合同的某个外部公司。多数情况下，客户之所以相信所谓的软件神话，是因为项目经理和从业人员没有及时纠正他们的错误信息。软件神话导致客户错误的期望，最终导致对开发者的不满。
• 有了对项目目标的大概了解，便足以开始编写程序，可以在之后的项目开发过程中逐步充实细节。
• 虽然软件需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。
• 在60多年的编程文化的滋养下，软件开发人员依然深信着各种神话。在软件业发展早期，编程被视为一种艺术。旧有的方式和态度根深蒂固
• 当我们完成程序并将其交付使用之后，我们的任务就完成了。
• 直到程序开始运行，才能评估其质量
• 对于一个成功的软件项目，可执行程序是唯一可交付的工作成果。
• 软件工程将导致我们产生大量无用文档，并因此降低工作效率。
  　　嘿嘿，是不是有些分不清上面的是事实还是我们不应该相信的软件神话？欢迎讨论。以上都是我们不应该依靠的软件神话，否则，你将会为此付出非常大的代价。