读《构建之法》第4、17章
第4章：两人合作
·代码规范
·极限编程、结对编程
·两个人合作的不同阶段
·影响他人的技巧
在阅读这一章的过程当中，我意识到了许多曾经在写代码的过程中不太注意的问题，例如：代码复审、有无资源泄露、优化空间、效能分析等。这些问题在以后的编程中我都会有意识的去考虑，以确保项目更好的开发和使用。由于这两周内就要进行结对项目，本章内容也详细的描述了如何结对编程以及两人合作的技巧，这对于接下来的作业起到了很大的指导作用。在阅读过程中，我也产生了以下的疑问：
问题一：这一章涉及到的一些词汇是我第一次看到，对于它们具体的含义并不理解。在查询资料后也的到了相应的解释。
断言：关于断言，我在阅读了一些博客之后，认为这一篇的解释是相对较好的：https://www.cnblogs.com/zoraliu66/p/6537066.html，但这其中也提到了：“现在主流的Java IDE工具默认都没有开启-ea断言检查功能。这就意味着你如果使用IDE工具编码，调试运行时候会有一定的麻烦。并且，对于Java Web应用，程序代码都是部署在容器里面，你没法直接去控制程序的运行，如果一定要开启-ea的开关，则需要更改Web容器的运行配置参数。这对程序的移植和部署都带来很大的不便。”这样看来，在Java中是否还有必要使用断言进行对程序进行调试。
硬编码：硬编码和软编码的区别是：软编码可以在运行时确定，修改；而硬编码是不能够改变的。所有的硬编码和软编码的区别都可以由这个意思扩展开。在计算机程序或文本编辑中，硬编码是指将可变变量用一个固定值来代替的方法。
关于goto语句：goto关键字很早就在程序设计语言中出现。事实上，goto是汇编语言的程序控制结构的始祖：“若条件A，则跳到这里；否则跳到那里”。随着Edsger Dijkstra著名的“Goto有害”论的问世，goto便从此失宠。事实上，真正的问题并不在于使用goto，而在于goto的滥用。而且在一些少见的情况下，goto是组织控制流程的最佳手段。尽管goto仍是Java的一个保留字，但并未在语言中得到正式使用；Java没有goto。那作者所提到的：‘函数最好有单一的出口，为了达到这一目的，可以使用goto’,这在Java中并不适用？
问题二：关于结对编程，书中提到：‘在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。’ 在现实的结对项目完成过程中，我们是否也要以这样的模式进行开发？两个人坐在一起，使用一台电脑这真的有必要吗？
第17章：人、绩效和职业道德
·领导力的要素，绩效管理的几种办法
·RASCI模型，能力和动力模型
·团队成长的几个阶段，团队解决分歧的办法
·IEEE软件工程师的道德规范
这一章中，讲述了很有趣的例子，比喻恰当，形象的阐述了一个团队中各个成员所担任的角色，并且详细的分析了作为一个领导，如何带领自己团队成长，当然这期间你所带领的团队会面临很多难题，作者也提出了相应的策略应对各种问题。相信这些建议在以后的团队合作中会起到很大作用。关于软件工程师的职业道德，我非常赞同P414页爱因斯坦的那句话，在大学里不仅仅是要学习知识，更要学习做人。当然，我也有一些自己的思考:
问题1:关于绩效分析，在我们之后的团队合作项目当中，肯定会面临这个问题。作者也对如何进行绩效分析做了详细的阐述。但我认为这样的做法更适用与企业当中。我们合作的过程当中，面对朝夕相处的同学，大家之间都有着深厚的友谊，在这种情况之下，如何进行作者所说的“区别对待”，又由谁来进行划分等级？这也是实实在在会遇到的问题，怎样做才能保证公平性，合理性，又不会影响大家之间的感情？
