第四章 两人合作
通过对于《构建之法》第四章的阅读使我对代码规范 、 代码复审 、 以及结对编程有了更加深刻的认识，所谓代码规范可以分为两个部分，代码风格规范和代码设计规范，代码风格规范的原则是：简明 、 易读 、 无二义性，代码书写的形式，变量命名的方法，注释程序如何工作都有详细的介绍，令我受益颇多。代码设计规范不光是程序书写的格式问题，而且牵涉到咸亨需设计 、 模块之间的联系 、 设计模式等方方面面，函数的设计，语句的使用，错误的处理，这些都是我们在进行程序设计的时候需要注意的地方。代码的复审主要是为了看代码是否在代码规范的框架内正确的解决了问题，代码复审的形式以及代码复审的步骤，都对于我们进行代码复审，跟好的完善我们的程序提供了好的方式。再来就是结对编程，再接下来的作业中我们也会进行结对编程，在阅读了这一章中的介绍后，我对于接下来的结对编程有了更加清晰的认识，也对于结对编程的优点有了新的认知，以及如何进行结对编有了更加透彻的了解。
问题一
对于4.3.4 中提出的虚函数以及析构函数的概念我不是特别理解，什么样的函数是虚函数 、 析构函数，并且这两个函数在程序设计中 又起到了什么样的作用？
通过查询我得到如下答案
虚函数：在某基类中声明为 virtual 并在一个或多个派生类中被重新定义的成员函数，用法格式为：virtual 函数返回类型 函数名（参数表） {函数体}；实现多态性，通过指向派生类的基类指针或引用，访问派生类中同名覆盖成员函数。
简单地说，那些被virtual关键字修饰的成员函数，就是虚函数。虚函数的作用，用专业术语来解释就是实现多态性（Polymorphism），多态性是将接口与实现进行分离；用形象的语言来解释就是实现以共同的方法，但因个体差异，而采用不同的策略。
析构函数
析构函数(destructor) 与构造函数相反，当对象结束其生命周期时（例如对象所在的函数已调用完毕），系统自动执行析构函数。析 构函数往往用来做“清理善后” 的工作（例如在建立对象时用new开辟了一片内存空间，delete会自动调用析构函数后释放内存）。
以C++语言为例： [1] 析构函数名也应与类名相同，只是在函数名前面加一个位取反符~，例如~stud( )，以区别于构造函数。它不 能带任何参数，也没有返回值（包括void类型）。只能有一个析构函数，不能重载。如果用户没有编写析构函数，编译系统会自动生成 一个缺省的析构函数（即使自定义了析构函数，编译器也总是会为我们合成一个析构函数，并且如果自定义了析构函数，编译器在执行 时会先调用自定义的析构函数再调用合成的析构函数），它也不进行任何操作。所以许多简单的类中没有用显式的析构函数。
析构函数的作用
析构函数的作用：用于在撤销对象前，完成一些清理工作，比如：释放内存等。
每当创建对象时，需要添加初始化代码时，则需要定义自己的构造函数；而对象撤销时，需要自己添加清理工作的代码时，则需要 定 义自己的析构函数。
问题二
对于注释，我就是一个写程序不愿意去写注释，甚至有点不会写注释的人，通过阅读书中的内容我对注释又有了新的认识，对于写注释也有了一些新的看法，可是我对于该在什么地方写注释，注释应该怎么写还是没有更加清晰的认识。
书中写到，复杂的注释应该写在函数头，可是什么样的注释才算是复杂的注释呢，还有就是注释只能用ASCII字符，不能使用中文或其他字符，而我看见的代码中的大部分注释就是用中文写的，那么使用了又会有什么样的后果呢？
对于如何写注释我的查询如下
1：一般情况下，源程序有效注释量必须在20％以上。
2：说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。
3：源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。
示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。
4：函数头部应进行注释，列出：函数的目的/功能、输入参数、输出参数、返回值、调用关系（函数、表）等。
5：边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。
6：注释的内容要清楚、明了，含义准确，防止注释二义性。
说明：错误的注释不但无益反而有害。
7：避免在注释中使用缩写，特别是非常用缩写。
说明：在使用缩写时或之前，应对缩写进行必要的说明。
8：注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
9：对于所有有物理含义的变量、常量，如果其命名不是充分自注释的，在声明时都必须加以注释，说明其物理含义。变量、常量、宏的注释应放在其上方相邻位置或右方。
10：数据结构声明(包括数组、结构、类、枚举等)，如果其命名不是充分自注释的，必须加以注释。对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释放在此域的右方。
11：全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
12：注释与所描述内容进行同样的缩排。
13：将注释与其上面的代码用空行隔开。
14：对变量的定义和分支语句（条件分支、循环语句等）必须编写注释。
说明：这些语句往往是程序实现某一特定功能的关键，对于维护人员来说，良好的注释帮助更好的理解程序，有时甚至优于看设计文档。
15：对于switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，必须在该case语句处理完、下一个case语句前加上明确的注释。
16.注释格式尽量统一，建议使用“/* ……*/”。
第十七章 人 ， 绩效和职业道德
通过对于第十七章的阅读使我对团队合作又有了全新的认识，一个好的软件的开发不可能是仅仅是靠一个人的努力就能完成，是一个团队的齐心协力才能够取得成功，而一个好的团队既需要团队成员的通力合作又需要领导的英明指导，以及团队成员的积极配合，缺一不可，否则，那就是一个失败的团队，是一个假的团队，这个团队也就不会有一些好的发展和成就，好的团队是需要磨合 、需要沟通的，只有大家彼此了解才能够是一个完美的团队，而一个完美的的团队需要做的就是戒骄戒躁，自我感觉良好也不是什么好兆头。每一个行业都有自己应该遵守的职业道德，软件行业也不例外，身为一个软件工程师更应该严格遵守自己的职业道德，为广大认命群众带去福利。
问题一
通过阅读第十七章，使我对于绩效管理有了新的认识，一个团队中的每一个人都有各自的努力和作用，如何衡量个人在团队中的绩效呢？我认为这个问题真的是令所有的人都十分困扰的，书中提到了，用工作量，可是有的人工作量的确很多，可是他做的都是一些无用功，不能够对团队起到任何帮助，比资历，大锅饭，比效率 、比不犯错误 、 这些都有其不合理之处，那么到底该如何根据什么标准给予不同的待遇？
所谓绩效管理，是指各级管理者和员工为了达到组织目标共同参与的绩效计划制定、绩效辅导沟通、绩效考核评价、绩效结果应用、绩效目标提升的持续循环过程，绩效管理的目的是持续提升个人、部门和组织的绩效。
实施原则
首先讨论素质。什么是素质？按词典的定义，它指事物本身所具备的性质和特征。对人而言，通常指后天的培养和锻炼所形成的特点或特征，既有道德层面的，也有非道德层面的。
下面几点对软件工程师而言，应该是最基本的要求：
有高度的责任心和强烈的使命感
有自觉的规范化和标准化意识
有强烈的相互协作的团队精神
有良好的和同事沟通的能力
正确对待客户需求，认真弄懂客户需求，不任意解释客户需求
有自觉的保密意识和产权意识
通过实践养成良好的文档习惯
通过学习和总结而引发出创新精神和创新能力
服从上级主管分配的任务和安排
具有软件工程的概念。
软件工程师的基本修养
接下来讨论修养。修养一般指自我锻炼和自我培养，目的是达到更高的水准，以期符合社会的需求。同时修养的高低，也体现了一个人的水平和格调。下面十项要求，应该是软件工程师不断追求的目标，也是判断软件工程师是否成熟的标准。
熟悉并严格遵循相关的工作标准和规章制度
严格遵循规定的编写程序的流程，养成良好的程序注释习惯
自觉地按照规范建立正规的、有一定质量的文档
遇到属于自己能力领域以外的问题，主动咨询该领域专业人士的意见
工作中发现的问题，应及时提交主管人员
有复用性设计和模块化思维的能力
不仅有研究需求的习惯，还应通过研究做到深刻理解需求的方方面面
具有坚定的专业精神
自觉拓展自己的知识领域，以满足公司发展的需要。
软件工程师的职业操守
社会对不同职业的工程师在职业操守或职业行为方面有不同的要求。职业操守反映了一个职业人员的品质和品德。不仅关系到个人名誉，更重要的是关系到个人的事业发展和职业生涯。任何机构都是不会对品德有缺陷的人委以重任的。
在工作中获得的不属于公共范围的信息应予以保密
在工作中编写的代码和文档应视为公司的财产
不得有意破坏或窃取公司的文档资源和代码资源
不得在程序中嵌入非法或不安全代码
不使用非法或非合理渠道获得的软件
在任何条件下不兼职从事与公司业务相关的事情
不违背规定私自进入计算机系统
任何情况下不泄漏公司商业秘密，更不得为获取私利而出卖商业秘密
克尽职守，自觉维护所服务的组织的合法利益。
以上就是我阅读第四章和第十七章的问题和感悟