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

作业要求来源

• 第1章 概论

本章主要从软件的定义、软件工程的定义这两大方面进行概述。我的总结和感想：软件=程序+软件工程，程序是软件的源代码，软件工程则是对软件进行工程化开发。源代码是软件的基本构成，是软件对于开发者而言最直观最直接的体现，是开发者和软件进行“沟通”的桥梁。程序的作用只是单纯的实现功能，我们通常所说的敲代码，也就是针对源程序而言，这其中或多或少忽略掉工程化的思想。软件具有特殊性，软件开发的过程包含了复杂性、不可见性、易变性、服从性、非连续性的难题。随着日益增长的软件数量、软件危机的爆发，工程化成为开发软件的迫切且必要手段和要求。工程化适用于各行各业的大项目，比如建造一栋摩天大楼，需要建筑工程，生产一个机器零件，需要流水线工程。同理，开发一个软件，亦需工程化思想来指导和支撑。软件工程的思想，让软件不再只是立足于源程序，而是以客户需求为中心，进行软件的规范化开发。程序只是静态的数据，工程师需要将它们构建成可执行代码，并且需要最大限度的减少运行错误的发生，而不是简单的代码堆砌和拼凑。软件工程师的任务和使命是构建软件，正如哲学家的使命是思考哲理，科学家的使命是发现未知。软件工程的目的就是让软件工程化，创造出“足够好”的软件，这其中包含了构建管理、源代码管理、软件设计、 软件测试、项目管理等一系列开发活动。在现实生活中，一个成熟的软件不是个人单纯的疯狂想法和业余爱好的玩物，而是由一个有序、规法、协调的团队开发的可控性强、拥有一套完整体系的商业软件，好的软件也不是由软件团队中的某个英雄或者成员长期加班突击出来的，而应该是各个小组成员协调合作形成的团队作品。

本章中有段文字：“软件的行为和用户的期望值不一样，就叫Bug。是否是Bug，取决于用户、开发者的不同角度。”这点我不完全赞同。维基百科给出的定义是：“程序错误（英语：Bug），是程序设计中的术语，是指在软件运行中因为程序本身有错误而造成的功能不正常、死机、数据丢失、非正常中断等现象。有些程序错误会造成计算机安全隐患，此时叫做漏洞。” 按我的理解，我们通常所说的软件中的Bug，应该是软件运行中的错误，比如抛出异常、运行异常终止、运行结果错误等，Debug就是开发者解决这些出现的软件运行错误，而不是取决于不同的角度。用户认为软件缺少功能，应该是需求分析不当，属软件分析范畴；开发者未经用户允许安装捆绑软件，应该是开发者有意为之，属商业运行模式范畴。Bug应该是客观上的软件运行错误，是软件的运行结果是否符合开发者预期的结果这一方面，是开发者必须解决的程序错误。用户或开发者发现的运行错误或漏洞，都属于软件的Bug，这是客观的而非主观的。

---

• 第2章 个人技术和流程

本章主要介绍PSP（Personal Software Process)即个人软件开发流程及其与之相关的单元测试、回归测试、效能分析工具基本概念和技术。我的总结和感想：单元测试是为减少当某一单元模块的功能被他人调用时出现的误解、疏忽、歧义、错误等问题，尽量使模块功能明确、模块内部的改变不会影响其他模块的一种解决方案。单元测试不能随便应付，尽管枯燥乏味，但在写技术模块的说明书时，要越详细越好，最好各项要求都能表示为一个单元测试用例。模块在各个场合各个时间的使用，需要将“单元”要做的事以及不能做的事，用单元测试清晰且详细的表达出来。同时，单元测试能帮助程序员记录这个模块的历史和设计变更的理由。一个好的单元测试，应该有以下标准：1、在最基本的功能/参数上验证程序的正确性。2、由作者来写。3、单元测试过后，机器状态保持不变。4、速度快。5、产生可重复、一致的结果。6、具有独立性。7、覆盖所有代码路径。8、集成到自动化测试。9、和产品一并保存和维护。回归测试是测试软件是否发生“倒退”现象，即某一模块在新的建构中，从正常的工作状态退化到不正常的状态。其目的是：1、验证新的代码的确改正了缺陷。2、验证有无“退化”。 回归测试最好自动化，因为这样有利于尽早发现问题。能效分析工具，是分析一个程序运行效率的工具，这里介绍了Microsoft 的VSTS简单应用的例子。在这里，值得一提的是，如果我们不经分析就盲目优化而过早优化，结果可能是恰得其反。PSP是着眼于软件开发的流程，纪录软件工程师实现需求的效率一套流程方案。这期间需要软件工程师自身投入时间和精力分析自身的开发情况，以及想法设法提高自己的开发水平，具有很强的个体参与性。

本章中有段文字：“单元测试应该集成到自动化测试的框架中，这样每个人都能随时、随地运行单元测试。”这里，我查阅了网上相关资料，依旧对这种说法不太理解，前面提到单元测试最好是由最熟悉这块模块的作者来写，可是怎么保证能让团队中的每个成员不改变作者最初的设计思路、能够参与到单元测试自动化的体系中？为了能够做到随时随地进行单元测试，应该怎样管理项目和协调成员合作？

---

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

本章主要阐述有关软件工程师个人发展和职业发展的内容。我的总结和感想：个人能力有多种指标衡量，re-work（返工）次数和是一个方面。在一个团队中，开发进度、完成项目的时间是极其重要的，所以，稳定、一致的交付时间是衡量一个员工能力的重要方面。在开发项目时，软件团队的凝聚力也是很重要的，小组成员的交流合作能力体现了团队的合作能力，一个优秀的软件开发人员应该能够积极与小组成员有效交流，而不是各自干各自的，同时在自己的开发进度上，能够按时交付属于自己的一部分项目，并且能够及时参与团队活动，因为IC的开发进度属于团队的开发进度的一部分。软件开发应该避免出现分析麻痹、不分主次、过早优化、过早扩大化、画扇面等思维误区，无论是团队还是个人，都应该注意。谈到软件工程师的发展，我的理解是，需要弄明白专和精的关系，作为软件职业开发者，懂得软件开发的基本操作，会利用相关知识解决相关问题，此为专业；擅长某一领域，在特定方面有一定的个人成就（比如个人研发的技术），此为精通。在现实开发中，软件开发者需要理清两者之间的关系。我比较赞同的观点是：中国目前的IT行业发展迅猛，软件开发的人才需求日益增长，商业化软件呈现竞争激烈、你追我赶的现象，且随着经济高速带动发展，导致了在一定程度上，中国目前是工程型而不是研发型的国度，如何快速解决软件问题、如何给出最优的方案是目前的紧要问题。所以，会利用现有技术解决问题的开发者才是目前市场上最受欢迎的。既然如此，在校生就需要提高自己筹码，以后才能在大风大浪中处于不被淘汰的地位（程序员的核心竞争力是什么？）。

本章中有段文字：“全国计算机等级考试和全国计算机技术与软件专业技术资格考试等考级有以下好处：国家认证，有一定的权威性和通用性。”在这里，对于全国计算机等级证书，我查阅了网上相关资料和说法，大致分为两大派：一种是看好的态度，认为其含金量比较大，持有该证书在工作等方面会有帮助；另一种是不看好的态度，认为该考级主要的意义是让非计算机专业的人员可以直接“证明”自己拥有相应的计算机水平，而对于计算机专业的学生来说意义不大，企业注重的是实践经验而这些非意义不大的证书，甚至有些公司在浏览简历时看都不看一眼。我赞同”’证‘多不压身“的说法，但我的疑惑是在如今社会中，IT公司如何看待这类证书？是否有把它列入考核 一个应聘者的标准之一？重视程度如何？

---

• 第4章 两人合作

本章主要介绍代码规法和两人合作的结对编程问题。我的总结和感想：从一开始接触编程的时候，我们总被教导编程时代码要规范以及重要性。每一个程序员编程时应该准守行业准则，目的是为了让开发流程更顺畅，让团队合作更轻松。谁都不愿意看到凌乱的代码，本来光在理解代码思路时就已经让人费脑，然后又要对着千奇百怪、极具艺术抽象派韵味的代码风格实在难受不堪（前不久的一则新闻 ---美程序员枪击4同事，竟因代码不写注释? 实在令人震惊......）。为了减少不必要的麻烦和损失，程序员应当养成良好的代码习惯。代码规范有两个方面，一个是代码风格，这个方面没有牵扯到技术层面；另一个是代码设计规范，牵涉到程序设计、模块关系，这一点相对需要花多点时间学习。这里，需要注意的点是：代码设计规范目的是为了提高设计效率，不能单纯的为了规范而“形式规范”。在团队合作中，团队成员之间肩并肩、平等、互补的合作方式的结对编程成为提高个人编程效率的一种方法，也是提高团队开发效率的一种新的尝试。结对编程运用得当可以提高成员之间的合作能力以及代码质量，使他们在合作中各自起到了激励、互补和促进作用，达到“1+1>2“的效果。最重要的是，结对编程的主要好处是：进行不间断的代码复审，这点可避免传统复审的缺点且效率显著提高。在团队合作沟通中，应该借鉴”三明治“方式。说话是一门艺术，如何正确表达自己的想法以及让他人更容易接受需要时间的沉淀。

本章中有段文字：“并不是所有的项目都适合结对编程，下面是一些不适合使用的例子：1、处于探索阶段的项目......”。在这里我查阅了网上相关资料，对结对编程的使用规则仍不太理解。我们知道，结对编程能提高开发效率，但我见过的、使用的最多的是个人编程，那么在如今的软件团队中，国内外结对编程的运用真实情况如何？是否大部分团队更偏向推崇个人编程而非结对编程？

• 第5章 团队和流程

本章主要介绍软件团队模式和软件开发流程。我的总结和感想:软件团队是一个具有明确目的、分工和协调合作的群体，而不是乌合之众。软件团队一开始可能是一窝蜂模式，经过发展，会演变成以下几种模式：主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、官僚模式、功能团队模式。软件团队的模式取决于当前的境况和企业发展的方向，有些模式虽然看似不合理、效率不高，实际上软件团队也能交付出好产品。但无论怎样，最终的趋势是功能团队模式。对应软件团队模式，软件开发也有其不同的开发流程:写了再改模式、瀑布模型、瀑布模型的各自变形、RUP统一流程、老板驱动流程、渐进交付流程。比较广为人知的流程应该是瀑布模型，这种文档驱动的单向生产模式，虽然理论上这种严格性较强的开发流程可以开发出较为完美的产品，但其产品最终模样只能在最后才能看到的局限决定了瀑布模型只适用于某些场合而非全部。而实际上，MVP（Minimum Viabal Product）方法成为具有较高可行性的开发模式。这种以最快速度开发出用户可看到软件原型的模式，已经成为解决因用户反馈不及时导致项目失败的方案。MVP方法核心是为用户服务，适应于交付时间紧迫的项目。TSP（Team Software Process）原则成为软件团队提高软件生命周期的方法。

本章介绍了软件开发流程，各自有特点和适应范围，团队模式结合开发流程可提高开发的软件质量。我的疑惑是作为团队中的一个成员应该怎样配合团队模式和流程？在校生应该怎样训练和提高自己的团队协作能力？