《构建之法》第四、十七章读后感

阅读了第四章、十七章之后我有一些自己的思考以及疑问，如下：

第四章

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档等。结对编程不是程序开发者独到的发明，在现实生活中，也存在类似的搭档关系；越野赛车（驾驶，领航员）驾驶飞机（驾驶，副驾驶）这些任务都有共同点；在高速度中完成任务，任务有较高的技术要求，任务失败的代价很高。结对编程中有两个角色：

1、驾驶员（Driver)：控制键盘输入。

2、领航员（Navrgator）：起到领航、提醒的作用。

        我觉得在结对编程中两个人共同互补地完成一项工作是很有趣的事情，程序员之间可以互相帮助，互相教对方，可以得到能力上的互补，可以让增强代码和产品质量，并且有效的减少Bug，降低学习成本。一边编程，一边共享知识和经验，有效的在实践中进行学习，也可以更快地解决问题。

但是我觉得结对编程中也存在一些不好的地方：如果两个人之间对一个问题各执己见，都不愿意改变自己的想法（代码风格可能是引起技术人员口水战的地方），争吵不休，反而会产生很多不必要的消耗。面对这种问题以及还有别的问题，难道结对编程不应该是一种不明智的选择吗?

第十七章

加入一个团队时，要弄清自己在团队中的级别是什么，别人的期望值是什么。不要拿着卖白菜的钱，操那卖百粉的心——太不值得

        我觉得这句话说的很对，往往在团队合作中，大家的分工不是很明确，甚至是一个人管多职，这是团队合作中最常见的事。比如我们科研立项的项目是开发一个图书馆占座实时查询系统，目的是用一种红外感应装置来探测座位是否有人，超过三十分钟，将由图书馆管理员人工清理座位，给后来需要学习的同学提供座位。我们团队有5个人组成，两个人负责前端开发，一个人负责后端开发，一个人负责嵌入式方面，还有大一的学妹就负责文件资料管理以及发票报销等文职工作。但是在实际的工作中，其实一个人所负责的方面不只有一个面，相反那个比较操心的人要负责方方面面，而别的同学可能因为有这样一个人的存在就将自己手头的任务交手给操心的人。并不能说这样就会怎样怎样，但我觉得至少明确分工会提高团队工作的效率，每个人根据所得做所对应的工作，但是我想问的是，难道多做一点就没法从中获得一些别样的收获吗？