阅读《构建之法》1-5章有感

第1章：概论

        读了《构建之法》的第一章，我着重看了软件开发的不同阶段，首先书本将其分为4个阶段：玩具阶段、业余爱好阶段、探索阶段、成熟的产业阶段，这很好地说明了软件开发不同阶段的不同情况，例如：在玩具阶段中，我们能用程序练习数据和算法，能用新的语言写出文字，再深一个阶段，可以用js，asp等写写网站，在深一个阶段可以专研新技术，应用技术在软件行业的创新，达到了最深的一层可以制作出银行系统，互联网搜索行业等电子商务系统等，在一个成功的软件开发出来前，你永远不知道经历了多少人，多少工序，多少流程，多少相关知识和验证，就以航空工业飞机飞行为例子，以为从制造飞机发动机开始到飞机正常运行，实现这个流程根本无法想象，我看到一个问题，就是飞机故障的两个案例，飞行过程中氧气瓶爆炸和起飞后碰上飞鸟，引擎发生故障，程序在飞机发生故障后，保证没有异常和错误的情况下使飞机安全飞行降落，飞行系统可以做到这样，人们才安全无恙。假如是软件在高速运行中发生异常呢？如何处理程序中的异常/错误？异常处理在程序中有什么作用呢？我们都知道异常处理分离了接收和处理错误代码。这个功能理清了编程者的思绪，也帮助代码增强了可读性，方便了维护者的阅读和理解。异常处理（又称为错误处理）功能提供了处理程序运行时出现的任何意外或异常情况的方法。异常处理使用 try、catch 和 finally 关键字来尝试可能未成功的操作，处理失败，以及在事后清理资源。异常处理通常是防止未知错误产生所采取的处理措施。异常处理的好处是你不用再绞尽脑汁去考虑各种错误，这为处理某一类错误提供了一个很有效的方法，使编程效率大大提高。例如我们编程的时候会考虑到很多情况，会先用try来进行情况的尝试，把try块放在while循环里,这样就可以不断的进入try块,直到得到满意的结果。软件开发不只是开发功能，还要有容错和可维护，一个合格的工程师，不是自己做出来自己用得多好证明了软件的优秀，是别人用得多满意才是真的成功，异常处理得好，用户就少了很多麻烦。

第2章：个人技术和流程

       第2章读过后，知道具体的理论和知识点是分为单元测试，回归测试，效能分析，个人软件开发流程（psp），而我比较感兴趣的是个人软件开发流程，因为个人软件开发流程是每个人都必备的，工程师都知道，常规的软件开发流程有几个大步骤，即为计划、开发、报告、总结等，其中计划是对用户的明确需求和其他相关因素，指明关系，开发是需求分析、生成设计文档，设计复审、具体设计等，报告即为测试报告，计算工作量等，如果进行官方一点的回答就是：软件开发流程即软件设计思路和方法的一般过程，包括对软件先进行需求分析，设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题，如果有更高需求，还需要对软件进行维护、升级处理，报废处理。我研究的是大学生在psp数据中大学生和工程师所花的时间百分比，其中有比较大的出入的是需求分析，具体代码的编写和测试，我们通过分析这个时间比例知道区别，可以合理认识时间的安排从而提高开发软件的效率。通过查阅了解，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。在需求分析上要多下功夫，那么在后面的功能编写就得心应手了，而具体编码的方面，工程师比学生少很多，这是因为工程师编写的代码比大学生多得多，熟能生巧，最后测试部分工程师花时间更多，所以了解到在工程师的软件制作过程中，更偏重于设计和测试，所以设计出来的软件在用户方面的考虑会更加全面，而大学生方面，时间多用于编写，调试维护的时间少，说明对用户的需求可能在某方面会考虑不周。所以大学生要多点联系编写的部分，代码熟练了，那么考虑需求测试部分时间多了，软件的开发会比原来流畅。

第3章：软件工程师的成长

    第3章是软件工程师的成长，主要是评价软件工程水平的主要方法，技能的反面，tsp对个人的要求，软件工程的思维误区，每个优秀的工程师都是从入门开始，那么如何评价一个工程师是不是一个优秀的工程师，在第三章有提到，个人和团队的问题，这是我特别感兴趣的，我们知道，软件工程师工作离不开团队和个人，那么优秀的工程师在团队和个人是怎么样分配的呢，我们知道，团队开发的大流程中，是每一个具体的个人在做开发，测试，用户界面设计，管理交流等工作，所以个人在团队中也有独立的流程，把每个人的工作有序地组织起来，这就是团队的流程，所以书本用足球队中的个人流程来表明，形象生动，用“阵型”“配合”“临场应变”三个重要的因素，大部分模块都是由ic即单个成员开发完成的，优质的个体会形成一个优秀的团队，一个优秀的团队又依赖个体，就如下图

在个人和团队的组合中，运用出个人的思维，业务，沟通能力，以及配合清晰的制作流程，先进的制作工具等来制作出好软件。问题又来了，有人说个人重要还是团队重要呢，这个说法是片面的，个人能力强，你可以制作出一个合格的软件吗？答案是不可能的，有了团队就可以了吗？团队要有一个合格的框架，才事半功倍，例如下面的效能模型

当然这个只是一个基本的效能模型，很对团队针对不同的情况，可以制定不一样的效能模型。团队和个人都优秀，软件开发才成功。

第4章：两人合作

   这个章节主要是说代码规范，极限编程，两人合作的不同阶段，影响他人的技巧。代码的编写老师经常说，自己看得懂的不是好代码，要别人也看得懂，所以不管各个细节都做要做到规范，所以书本提到了缩进，行宽，括号，断行与空白的{}行，分行，命名等等细节，做到统一，简明易懂，无二异性。代码的规范设计在后期代码维护修复的时候也会有很大的帮助，在代码后期的修复维护，往往有很多代码，成千上万行，我自己也遇到过这样的问题，例如我看到一代码删除的命名用的是shanchu，或者sc，导致老师的审查时出现错误，理应用delete，现在我都会规范命名，做到与行内同步。书本还提到两个人合作的不同阶段的技巧，分别列出了“萌芽阶段”，“磨合阶段”，“规范阶段”，“创造阶段”，“解体阶段”，我个人的理解是两个人的合作在这几个阶段再细分，自己能否影响到对方，自己是否知道对方工作，如何在做自己的工作的同时能配合到对方的工作，两个人有这样的想法，结合起来就会非常有默契。“每个人都有自己不同的想法，会出现不同的情况，在公平合作下，如何说服对方呢？如何做到有默契呢？”我就拿前端工程师和后端工程师来说，前端和后端是分开来做的，前端工程师在设计好网页之后必须配合后端进行调试，这也是两个人的合作，两个人的合作中会出现很多分歧，做到统一就必须在设计前商量好避免的错误，做到前端配合后端，后端配合前端，调试才可以成功。所以两个人的合作非常重要，默契度也重要，商量也少不了，所以两人合作也是软件开发非常重要的一个部分

第5章：团队和流程

       这一章中讲述了许多不同的软件团队模式。软件开发流程包括需求分析、形式化说明、总体设计、详细实现、实现和运行维护，有不同的模型也体现了软件开发过程。本章作者主要介绍TSP、MVP、MBP和RUP之间的优缺点。关于团队模式书本中有介绍到的软件团队模式分为很多种，如主治医师模式、社区模式、爵士乐模式，官僚模式等等，它们各有优缺，应用于不同环境，不同类型的团队成员，比如主治医师模型适用于首席程序员极其优秀的情况等等。那么如此多模式中有什么模式如今对我们而言是比较好的呢？自我分析了两个模式，一个是交响乐团模式，另一个是功能团队模式。交响乐团门类齐全，各司其职，演奏都靠谱，同时看指挥；而功能团队模式是指具备不同能力的同事们平等协作，共同完成一个功能，在这个功能完成以后，这些人又重新组织，和别的角色一起去完成下一个功能，一个团队最终的任务就是完成任务，所以团队是能通过磨合，能够协同作战的，团队可以公开的讨论流程和工作的方式，协商制定计划；PM可以得到广泛尊重，有能力的成员也分担一定的领导职责；大家各司其职，平等协作，最后汇总各部分，完成任务。

    书中有提到一句话让我们了解到开发流程“我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程吧这些相关的技术和过程统一到一个体系中，叫做“软件开发流程”，软件开发流程的目的是为了提高软件的开发运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性。”不局限于我们书中的几种，随着不断地发展，软件开发流程也呈现百花齐放格局，不同流程适用于不同情境，我经过查阅资料了解到，瀑布模型描述了单向的、不可逆的生产过程，这种生产显然是有很大弊端，比如到最后阶段才发现初始阶段就有问题，那么由于不可逆只能推翻重来，浪费了大量时间精力与金钱，显然不是很可取。但是Winston Royce对此模型提出了一些改进的办法，比如相邻步骤的回溯，即做下一步之前要先解决上一阶段未能解决的问题；又比如将模型走两遍，即先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。尽管有了如此的改进，“瀑布模型”有了适用范围，但其还是有着一定的局限性，比如有些软件生产过程不能严格分离各步骤，回溯修改困难甚至不可能，不能尽早知晓原型并使用等等。为了解决这些问题，人们在实践中提出了“瀑布模型”的各种变形，如“生鱼片模型”“子瀑布模型”，但是这些变形虽然可以解决某一问题，但是不能解决全部问题。从“瀑布模型”开始的模型都有一个共同点：重计划，重事先设计，重文档表达，而Rational统一流程（RUP）就是该方法实践的翘楚。RUP要求团队的各种成员在不同阶段做不同事情，将一个周期的开发过程分为四个阶段：初始阶段（为项目建立一个业务案例）、细化阶段（建立工程计划和合理的体系）、构造阶段（建造系统）、交付阶段（把系统提供给用户）。在开发过程中用到了迭代，可以降低风险，得到用户早期的反馈，基于用户反馈，团队可以对系统进行修改，对功能进行调整，交付阶段的终点便是产品发布。除此之外，还有渐进交互的流程，当系统的主要需求和构架明确之后，团队进入“开发-发布-听取反馈-改进”的不断循环之中，直至时间金钱用完，用户很满意或很不满意方才停止。为了让用户尽早地给团队提供反馈，提出了一种新的方法：MVP，即把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，既避免了浪费也降低了成本。当然如果对用户需求了然于心，或者产品团队比用户更了解用户的需求，也可以直接把产品最美、最全的形态呈现出来，即MBP。软件开发流程必不可少也极其众多，但是它们各有其适用的范围，比如“瀑布模型”适用于产品定义非常稳定，技术非常成熟等条件下，而RUP适用于大型软件团队开发大型项目。虽然有些流程存在很多问题，但是只要清楚定位，在不同环境下使用不同的开发流程，就可以降低成本，节省时间，节约人力物力，以最小的成本达到各户的期望。（此处的观点参考 Leslieyz 的CSDN 博客 ）一个好的开发流程可以为开发商，用户，制作方都省下很多的资源，所以一个好的流程也是非常必要的。

 

总结：阅读《构建之法》第1-5章的知识内容后，我熟悉了软件开发各阶段的具体要求；了解了不同软件过程模型的好处和坏处；个体和团队该如何协调；如何认识一个号的开发流程对软件开发的意义；两人合作对软件开发的影响等等。在软件设计和开发过程中团队协调、团队合作有重大的意义，是成功的关键。对于我们大学生来说我们要接受多点信息，学习多点知识，培养自己的能力，把自己武装起来，要更了解软件开发的走向，顺应发展的潮流，锻炼自己的思维模式等等，读了这五章之后我受益匪浅。