前言
在读这本书的过程中，我一直在反复问自己一个问题，自己是有感而发，还是无病呻吟，为此我在不断揣摩作者本来用意的同时，又联系了自己的亲身经历，在其中加入了自己的思考，力求不仅仅是为了“看”，而是用心去读，在第四章，主要讲述了与他人合作编程的一些技巧，包括代码规范，代码复审以及合作的的不同阶段和技巧问题，这使得我对接下来的结对项目有了一定的信心；在第十七章，主要探究了如何领导一个团队，如何进行绩效管理以此软件工程师的职业道理规范等问题，这使得我对如何快速融入一个团队有了初步的认识，并且也让我展开了对于软件工程师职业道德的探索。具体的问题与看法请看下文：
第四章
问题一
原文：
现代程序设计设计语言中的绝大部分功能，都是在程序的函数（Function、Method）中实现。关于函数，最重要的原则是：只做一件事，并且要做好。
疑惑：以函数为程序的基本单位，有什么好处?
看法：
在求解一个复杂问题时，我们通常采用的是逐步分解、分而治之的方法。也就是说程序员在设计一个复杂的应用程序的时候，往往也就是把整个程序划分为若干功能较为单一的子模块，然后分别予以实现，最后，再像搭积木一样装配起来。这也正是模块化程序设计方法的精髓。
在C语言中，函数是程序的基本组成单位，因此可以很方便地用函数作为程序模块来实现C语言程序利用函数，不仅可以实现程序的模块化，程序设计得简单和直观，提高了程序的易读性和可维护性，而且还可以把程序中普通用到的一些计算或操作编成通用的函数，以供随时调用，这样可以大大地减轻程序员的代码工作量。
联想上一周做的四则运算小程序，我将其划分为三个模块：一是生成随机运算式，二是计算生成的运算式，三是将运算式打印到result.txt文档中。中间还声明了实现小功能的方法，比如，生成随机随机运算符，将真分数化解的gcc方法等。这种模块化编程的方法不仅思路清晰，而且易于维护和增加新的功能。
问题二
疑惑：在4.4小节中，书中讲解了代码复审的重要性以及如何进行代码复审，我的问题是代码复审要达到什么样的程度才可以，也就是什么样的代码才算是复审后符合规范的代码？
看法:
我平时会在oj上刷一些算法题，做ACM题的过程中也会进行代码复审。复审的前提条件往往是自己的编的程序没有通过oj的审核，在重新检查代码的过程中我往往会关注于编译错误，算法错误以及算法的时间复杂度是否合理等问题。复审的标准也很简单，那就是能够通过oj的审核就可以了，从此就把这段程序甩手放一边了。然而实际开发软件的过程中不可能这么容易，即使满足了用户提出的功能，也要进行一定的算法优化，而且一味地追求时间复杂度低的算法也是不合理的。一方面，你的编程效率可能会因此降低，另一方面，复杂的算法在维护起来会有所困难。所以，我觉得在实际开发过程，要对算法的时间复杂度与算法的可读性之间做一个折中。
第十七章
问题一：
原文描述：信任的一个重要因素是“敢于互相分享自己或其他团队的薄弱环节”
感悟：
我对这句话深有感触，对于一个团队，敢于承认并去面对自己的薄弱环节，需要的是一种勇气。盲目自大，隐瞒自己团队的弊端，就好比治理洪水时，只堵不疏一样，看上去问题是解决了，但总会有一天洪水会冲破大坝，到时候，需要面对的难题会更多。而且，无论从团队的角度，还是从个人的角度来看，有针对性去想办法去弥补自己的薄弱环节，才是解决问题的根本所在。
问题二：
原文描述：
承诺并不意味着团队在达到共识之后，我才决定做某件事。在实践中可以有“保留意见，但坚决执行”的做法。等到项目结束后的“事后诸葛亮会议”上，大家在来盘点复查。
疑惑：如果在实际开发的过程，你的想法与团队其他一部分成员的观点相违背，你该如何处理这类情况？
看法：
在我看来，当领导着还未做决定之前，协商与讨论是必要的，讨论正是深入思考的一个过程，要敢于提出与他人不一样的想法，一个没有冲突的团队，未必是一个团队，相反适当的冲突会化解团队内部隐藏的一些不满；当领导做完决定之后，如果我还认可我的想法的话，我会保留我的意见，但坚决执行领导的决策；最后，毕竟“实践是检验真理的唯一标准”，在“事后诸葛亮会议上”，我会重述自己的观点，并做相应的总结。当然这仅仅是我个人的一个观点，也欢迎大家提出不一样的看法。