阅读《构建之法》第四章、第十七章
阅读这一章的时候，我意识到了很多以前写程序没有注意到的地方，以前写程序就只知道能运行就好，根本不管自己写的程序占多少内存，运行的时间，是否有优化的空间，写代码的时候也不注意规范，有时候设计的函数根本用不上，造成代码冗余。同时也认识到结对编程的重要性，没读这本书之前就觉得结对编程就是两个人一人负责一个模块，然后合在一起，调试调试。但实则不然，真正的结对编程应该像书中那样，一个是驾驶人，一个是领航人，两个人有规律的进行编程。期间，一人编程一人复审，极大地提高了效率和编程水平。
第四章
原文：在C语言家族中，比较通用的，也是经过了很多实践检验的方法叫“匈牙利命名法”。例如：
fFileExist，表明是一个bool值，表示文件存在；
szPath，表明是一个以0结束的字符串，表示一个路径。
问题一：以前有的学长学姐给我们开讨论班的时候一般会提到驼峰命名法，所以对驼峰命名法比较熟悉看书上可能有点没太看懂“匈牙利命名法”的命名规则是什么？
回答：在网上找了几篇博客了解了一下，感觉有了点收获。
http://blog.sina.com.cn/s/blog_810c86000101at9g.html
https://blog.csdn.net/haiross/article/details/45147993
https://blog.csdn.net/andrewniu/article/details/50477050
命名规则：变量名=变量类型+变量的英文意思（或缩写）
开头字母用变量的类型，其余部分用变量的英文意思或其英文意思的缩写，尽量避免用中文的拼音，要求单词的第一个字母大写。
例如：1.指针变量命名的基本原则为：“p”+变量类型前缀+命名
2. 全局变量用 g_ 开头,即：变量名=g_+ 变量类型+变量的英文意思（或缩写）如：int g_nCount=0;
3. 静态变量用s_ 开头, 即：变量名=s_+变量类型+变量的英文意思（或缩写）如：static int s_nCount;
4. 成员变量用 m_开头,即：变量名=m_+变量类型+变量的英文意思（或缩写）如：int m_nLineCount;
5. 对const的变量要求在变量的命名规则前加入 c_,即：c_+变量命名规则 如：const char* c_szFileName;
原文：
断言
如何验证正确性？那就要用断言（Assert）。断言和错误处理是什么关系？
当你觉得某事肯定如何时，就可以用断言。
Assert（p！=NULL）；
然后可以直接使用变量p。
如果你认为某事可能会发生，这时就要写代码来处理可能发生的错误情况。如.........
问题二：什么是断言？断言与异常有什么区别？
通过百度我了解到断言是用来检验非法情况的。用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状况。断言通常用于调试版本，用来发现程序中的逻辑错误。
虽然看了几篇博客，但是感觉对于断言和异常理解的仍然不是很透彻。
原文：如何处理C++中的类
虚函数
（1）使用虚函数来实现多态。
（2）仅在很有必要时，才使用虚函数。
（3）如果一个类型要实现多态，在基类中的析构函数应该是虚函数。
析构函数
（1）把所有的清理工作都放在析构函数中。如果有些资源在析构函数之前就释放了，记住要重置这些成员为0或NULL。
（2）析构函数也不应该出错。
问题三：虚函数、析构函数是什么？该如何使用？C++中的多态和Java中的多态有区别吗？
虚函数
一个类函数的调用并不是在编译时刻被确定的，而是在运行时刻被确定的。由于编写代码的时候并不能确定被调用的是基类的函数还是哪个派生类的函数，所以被成为“虚”函数。虚函数只能借助于指针或者引用来达到多态的效果。
析构函数的作用是用来完成对象被删除前的一些清理工作，也就是专门的扫尾工作。
析构函数与构造函数的作用正好相反，如果构造函数打开了一个文件，最后不需要使用时文件就要被关闭。析构函数允许类自动完成类似清理工作，不必调用其他成员函数。析构函数也是特殊的类成员函数。
Java中的多态的三个条件是继承、多态和父类引用指向子类对象。而C++中，如果父类中的函数前边标有virtual，才显现出多态。读了一篇博客分享给大家。
https://www.cnblogs.com/plmnko/archive/2010/10/19/1855760.html
第十七章
原文：软件团队如何做人员的效绩管理？有人说用工作量来衡量、有人说按照角色来定位、有人说根据工作时间来衡量。但是在软件团队中，不合理的效绩考核不但影响个人的收入，而且会影响人员的士气、流动、后续的合作以及产品的质量，不能不慎重。
问题四：如何进行效绩考核才是最深入人心的呢？
我的看法：我觉得效绩考核首先应该考虑的是团队贡献维度，在一个团队项目中，你不是为自己做了多少，而是为了一个团队付出了多少，是否有积极带动团队中的人员更加高效的工作，是否对团队有正面影响，可以通过团队成员进行投票选择。其次，我觉得应该考虑个人的效率及其对产品的贡献，个人效率体现出这个人时候将精力投放到项目中，如果将大部分的精力都放在项目中，那么他的代码质量会很高，测试人员能够减少一些调试时间，会积极促进项目的开发速度。我们所希望的最好的团队就是大家都能全身心的投入到工作中去，身边的人互相影响、积极带动，一起DeBug！
原文地址：https://www.cnblogs.com/BoscoJK/p/8684878.html