对《构建之法》的相应思考

第一章 概述

理论和知识点：计算机科学的领域（p11），软件工程（偏实践）与计算机科学（偏理论）的关系，软件的特性（复杂性、不可见性、易变性、服从性、非连续性），软件工程的定义与组成部分

（一）引用原文：IT专业的大学毕业生找工作时声称：我精通Java，会用C++写“Hello World”，我懂软件工程，我画了很多图，写了很多文档，最后得了很高的分数…… 这些同学是真的懂软件工程，是一个合格的软件工程师吗？ p7

相应思考：合格的软件工程师绝不只有这些技能。个人认为首先要具备良好的编程能力，编程能力直接决定了项目开发的效率，这要求软件工程师至少精通一门编程语言，熟悉它的基本语法、技术特点和 API；要具有自觉的规范意识和团队精神，随着软件项目规模越来越大，仅仅依靠个人力量已经无法完成工作，因此，现代软件企业越来越重视团队精神；还要具有软件工程的概念，从项目需求分析开始到安装调试完毕，软件工程师都必须能清楚地理解和把握这些过程，并能胜任各种环节的具体工作。综上，此类大学毕业生绝不是一个合格的软件工程师。

（二）引用原文：1.2.2软件工程与计算机科学的关系，很多同学在报名时不知道他们的区别，发现除了收费高低不同，学的科目差不多，毕业后大部分同学都是写程序，似乎差别不大？ p10

相应思考：软件工程与计算机科学的区别还是挺大的。计算机科学的理论研究部分，大多可以从形式上证明，与离散数学、数理逻辑密切相关，计算机科学中实践相关的部分都和数据以及其他学科发生关系；软件工程则和人的行为、现实社会的需求息息相关。书中表1-2列举出了软件工程与计算机科学的不同侧重点，个人认为计算机科学偏理论一些，软件工程偏实践一些。

 

第二章 个人技术和流程

理论和知识点：单元测试（自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证），回归测试（Return to a worse or less developed state）,效能测试（抽样、代码注入）、个人开发流程（哼，我们程序员有任务清单的！）

（三）引用原文：阿超要我们注意：100%的代码覆盖率并不等于100%的正确性  p27

相应思考：首先百度了代码覆盖测试的定义，代码覆盖(Code coverage)是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，所得比例称为代码覆盖率，标准为达到80%-90%。对文中阿超的分析进行总结，代码覆盖率对“应写但没有写的代码”无能为力，因为文件不存在或权限问题，使代码不能进行相应测试，所以100%覆盖率并未达到100%；代码效能问题，代码效率非常低，可针对代码效率写一个单元测试；多线程环境，和代码执行时序、共享资源的锁定有关；代码是否进行了全覆盖，是否有遗漏，如条件语句中未被考虑的语句等；其他外部条件问题。

（四）引用原文：在代码注入时，果冻修改for（ ）代码，为缩短耗时，有人提出可以提高排序的性能用以提高程序的效能，但图2-6显示排序只占不到1/50的时间，可见提高排序并不能改善太多耗时问题，还有哪些方法可以提高程序的效能？ p34

相应思考：可以提高程序的效能列举：一、尽量减少值传递，多用引用来传递参数；二、循环：循环内定义，还是循环外定义对象，要避免过大的循环；三、局部变量VS静态变量，很多人认为局部变量在使用到时才会在内存中分配储存单元，而静态变量在程序的一开始便存在于内存中，所以使用静态变量的效率应该比局部变量高，其实这是一个误区，使用局部变量的效率比使用静态变量要高；四、避免使用多重继承；五、多用直接初始化。

 

第十六章 IT行业的创新

（五）引用原文：向电报公司，提出想法是改进电报技术，一定会受欢迎，这一类创新是改良式的创新；向电报公司推销电话，会引起现有技术拥有者的极大不安，这类创新是颠覆式创新。改良式创新和颠覆式创新的联系？ p342

相应思考：我们需接受一个事实，绝大多数创新，并不是颠覆，而是改良。改良式创新有三点忌讳，其一，不能为了创新而创新，很容易导致公司悲剧；其二，不能为了招揽新客户而创新，而是要为了更好地服务老客户而创新；其三，改良式创新要有连贯性，不能反差太大。创新是必须的，创新也是很难的，颠覆式创新的确能快速塑造一个新时代，不过其发生的条件却极其苛刻，没有强大实力的公司难以做到。对于一般公司而言，改良式创新才是王道。