一、前言
在尽全力完成个人作业之后，我们迎来第一次结对作业，怀着对两个人共同合作的暗暗期待，我心里更加期望能最好地完成这次作业。于是我十分认真地阅读了有关的章节，希望能从中得到一些启示，下面就是我在阅读过程中得到的切身感受和遇到的一些问题。
二、关于第四章
Part 1感受与问题
在读到“当程序的主要功能实现后，一些程序员会乐观地估计只需要另外的20%的时间，给代码加一些错误处理就大功告成了，但是这20%的工作往往需要全部项目80%的时间”这里时，我的内心有很大触动。在上个项目的完成过程中，我也是花费了大量的时间来调试各种bug，不管是语法错误还是逻辑错误，要验证正确性都是一件及其费时间费心思费力气的工程。因为一直不太理解测试，所以查了一下有关资料，了解了断言和错误处理的关系。知道了assertion(断言)在软件开发中是一种常用的调试方式，assertion就是在程序中的一条语句，它对一个boolean表达式进行检查，一个正确程序必须保证这个boolean表达式的值为true；如果该值为false，说明程序已经处于不正确的状态下，系统将给出警告或退出。
从最简单的方式去理解，我觉得这个方式还是十分简单有效的，但是关于断言的代码我还是不太懂，这种方式的代码是对于所有的程序都有用么？都是用程序中的一个语句boolean表达值来验证程序的正确性么？（但是个人觉得这个方法是不是不具有普遍性呢？）
有关链接：https://zhidao.baidu.com/question/1638659990292306460.html
Part 2感受与问题
在团队合作时，“三明治”的方法是个非常可行的沟通方式，上学期也有一些国创科研的项目活动，我们组虽然没有走到最后，但是在仅仅的组成团队开发的前期，就产生了一些问题讨论上的分歧，导致有时内心也十分无力，从而深深地感受到了团队之间及时反馈和沟通的重要性。
对于“破窗效应”理论，很好奇，所以深入了解了一下。破窗理论认为：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些示范性的纵容去打烂更多的窗户。久而久之，这些破窗户就给人造成一种无序的感觉，结果在这种公众麻木不仁的氛围中，犯罪就会滋生、猖獗。
在看到书中关于“做中学”的的思想时，我比较疑惑，之前在学习的过程中提到过，如果不完全掌握一门技术就相当于在做手术的过程中并没有完全掌握医术，会危及到病人的危险，同时就相当于软件开发中也一定会产生各种严重问题，而在“做中学”不是和这种理论有些相悖么？那我们到底应该更倾向于哪种学习方式呢？
三、关于第十七章
Part 1 感受与问题
第十七章讲了人，绩效，职业道德之间的关系，书中的例子都十分生动详细，使人产生了很多思考也更加容易理解。
但是在看到绩效管理时，心中也存了一些疑虑，就如医生做手术似的，到底是一晚上抢救病人多但是失败次数高这样绩效高，还是没人来就医绩效高？同理，到底是精确完成少部分代码bug少绩效高，还是粗略完成大部分功能但是bug多的程序猿绩效更好呢？而我们到底应该选择哪种方式在以后的工作生活中去遵循呢？哪一种更加被同事领导所认可呢？
自己私底下认为还是要做精，毕竟慢工出细活，但是好像和后面书中讲的萝卜与白菜的故事相悖，故事中虽然白菜每天都完成了规定项目，程序中bug也很少，可是最终领导却会认为萝卜是个更有能力并且工作更努力的人，所以有些疑惑。
除了这些，我个人十分认同“任何一种衡量方法都比完全不量要好”的观点，因为我觉得只有有标准，有比较，人才能不断进步并认识到自己的不足，适当的衡量比较能让我们在学习生活中更加积极有动力。
Part 2 感受与问题
书中写的刷课软件和刷票软件是离我们生活非常近的部分，在大学里抢课一直都是个老大难的问题，而一些抢课抢票软件确实在一定程度上方便了我们的生活。但是到底应该怎么看待这个问题呢？
自己觉得这是个有双面性的问题，一方面它是个便利人们生活的创造，也表现了软件工程师的创造性，也是一种进步，但是另一方面有人觉得这并不公平，违背了大家公平竞争的原则，也造成了很多不满。当然生活中还有很多这样的例子，我的疑问是作为软件工程师，对于这类性质的软件，我们还应该支持它的发展么，还是要继续完善开发么，还是应该尽量拒绝这类软件的开发呢？现在内心也是有点纠结。
在看到最后书中的问题“软件工程师在企业中到底是劳动密集型的工人，还是有独创性的专业人士”时，内心也有一些思考，我更加倾向于有独创的专业人士，虽然软件工程师经常都是在修复bug，维护运行，有时也运用前人的代码，但是我认为之所以现代生活有这么多的便利，软件有一代代的更新，都是因为软件工程师不断地修复和创造，所以这是一个非常值得尊敬的职业。但同时我并不认为任何与报酬挂钩的绩效评估都是有害的，自认为有适当利益的趋势会让人更加努力，也会获得更加完美的结果。
最后，十分感谢老师的阅读并且欢迎指正。
