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

作业来自：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

第一章 ：概论

  第一章讲诉了什么是软件工程，其中还掺杂了几个例子，让我更好的理解软件工程的概念，同时使我觉得这本书不会太枯燥无味，加强了我看书的耐性。首先,文章对于程序.用户需求.工程等等概念用了阿超给儿子编写的一个出题程序来分别解释了个中的含义,尤其是程序和工程的区别,程序大概就是用很多语言或工具编写的一个简单能实现目标要求的一行行代码,而工程就是在这个程序的基础上不断满足用户的需求.修复程序的bug.提供后续维护等服务. 需求分析:梳理需求,逐步展开后续工作,如设计(软件架构).实现(写数据结构和算法),测试,发布软件 软件=程序+软件工程(软件企业=软件+商业模式) 软将工程的核心部分:构建管理.源代码管理.软件设计.软件测试.项目管理 问题 ：能力弱的同学该怎么学这门课程？我们现阶段可以从哪方面开始培养自己的开发思维和能力，向工程师迈进？

第二章：个人技术与流程

  其实说到单元测试，对于我这样的菜鸟，最烦的就是测试，你要说单元测试几乎不可能啊，每个单元都有联系，不太可能隔离开啊。现在回过头看，把每个程序都隔离开来分开分析测试，的确是可以大幅节省时间的。编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应，并且要对最初的开发工作遗留下来的Bug进行修改。现在再回过头看我从前的程序，每个部分含糊不清，不利于隔离测试，所以要更加注意。我从前的状态是：不知道怎么编写单元测试，项目没有要求，所以就不编写单元测试，也认为单元测试价值不高，完全是浪费时间。读了书之后我希望我以后能改掉这个错误的观点。第二章说软件工程师是大四毕业生的关系是多读了三年书，有个软件工程师已经进行了三年的测试和分析，达到的高度自然不能和我们这些大学生能够企及的。所以有回归到最基本的问题了，编程的练习。到了现在阶段我觉得我们的编程已经不是简单的能正确运行,而应该是能够更加正确的运行，要保证程序的健壮性。我觉得书里面一句话说的特别正确“输入的质量不高，程序员的输出往往质量也不高，然而这并不能全部由程序员负责。”问题：在单元测试中，一定要要求代码覆盖率达到100%吗？

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

   第三章提到了成为软件工程师所要具备的条件，分别是：1.积累软件开发相关知识，提升技能技术。2.积累问题领域的知识和经验。3.对通用的软件设计思想和软件工程的理解。4.提高职业技能。5..实际成果。这让我认识到自己离一个软件工程师还有很远的距离。软件工程把相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营、维护的效率，以及提升用户满意度、软件的可靠性和可维护性。软件开发流程不光指团队的流程，还包括个人开发流程，因为软件团队是由个人组成的。个人在团队中也有独立的流程。把每个人的工作有序地组织起来，就是团队的流程。“有序”，并不是“无争论”。在大部分成功的软件团队模型中，各个角色有不同意见的冲突在所难免，解决冲突、意见统一是团队要做的。作者用足球队来做举例，足球队有个人流程，有单个运动员的技术、体能要求，在单个运动员的技术、体能达标的情况下，再去讲团队的阵型和战略，还有团队的交流。软件系统的绝大部分模块都是由个人开发或维护的，这里又出现了新名词IC（Individual Contributor）：单个成员。问题： 我们是否应该赶在毕业前成为一个真正的软件工程师。

第四章：两人合作

第四章讲诉了在我们写代码是应该要注意代码的规范，不能够只能让自己看的懂，也要让别人看得懂。在合作中在客观全面的对待自己的结对伙伴，懂得相互鼓励，相互学习。

在第四章中说“合作的最小单位是两个人“，两个工程师相互看代码并给出自己的意见，所以代码的规范性是极其重要的，我们的代码不仅要让机器读懂也要人也能读懂，在第四章的学习中，我也尝试着和别人结对来编写一个程序，效果相当的不错，规范的代码让我们都能够方便读懂对方的程序，同时也能提高彼此的能力，取长补短，形成互补。

4.1大节提到的代码规范，我们编写代码时要注重代码风格规范和代码设计规范，无论是类名，对象名，缩进还是行宽什么的，在结对子编程时都要有所规定，不然到后面出现的类或是对象多了，就很容易混乱，分不清楚谁是谁。要学会封装，编写函数，将功能模块具体化，减少主方法里面的代码，避免大规模的出错。

4.4中提到了代码复审，在平时编程程序时，我也会从头到尾的查看自己的代码，运行程序，若是多次结果相同，无误就可以了。没有想过发现代码错误外，还去思考逻辑是否有误，算法够不够优化等其他问题。他人能否觉得我所编写的程序是否简单易懂，能否从中学习。

4.5结对编程，两人合作，一同思考一同编写程序，有利于提高效率，相互学习。所以要学会4.6节提到的合作的不同阶段和技巧，一开始探索项目时，中途遇上不可解决问题时，后期简单的复查时，可以独立思考，期间思路清晰，沟通良好时，一起结对编写，加强合作。在合作中在客观全面的对待自己的结对伙伴，懂得相互鼓励，相互学习。问题 ：什么是断言？

第五章：团队和流程

  第五章为我们介绍了团队合作的几种模式，以及团队中的几种开发流程。让我明白从现在开始就应该着重培养自己的团队合作意识。史蒂夫·迈克康奈（SteveMcConnell）在这里提到了不少开发流程。第一个提到的开发流程。这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。但是，要写一个有实际用户、解决实际需求的软件，这个方法的缺点就太大了。然后我学习了瀑布模型当软件行业还在年幼的时期，它从别的成熟行业（硬件设计，建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循 [分析→设计→实现（制造）→销售→维护] 这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题：又如，温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本（Simulation of FinalProduct），在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。问题： 团队合作模式和开发流程的关系密切？两者能否脱离？