2017-03-23更新
抱歉现在才更新。
看完《构建之法》，有几点困惑：
一、软件测试是不是测试软件的可行性，包括代码是否错误，是否有溢出，是否能处理异常；
如果是上述的测试，那码代码的过程中不可以一步一步测试并且解决吗，为什么需要软件测试这一流程。
二、结对编程中，如果两者出现大的分歧，并且两者的水平相差较大，那么在和队友沟通（其实是争论）上花了大量的时间，
出现了1+1<2的情况，还需要结对编程吗？
三、在过去几周的作业中，我发现，拿到一个题目（例如，结对作业1，设计具有页面的四则运算程序），看着题目的要求，
在脑子里过一遍流程，认为应该不难。但是在实际的开发中，发现不是那回事，大大小小的困难都会占用时间去解决，所以
剩下的时间不多，又要按时提交。就只能剔除一些功能，或者对一些设计的要求降低。导致后来提交的作业的质量不好。
想问的问题是：当时间不够的时候，可以以削减产品质量来换取准时提交吗？如果不是应该怎么处理？
以下原文：
第一次打开《构建之法》的时候就产生了很深的兴趣，这本书的排版，字体，插图，和表达方式与其他书不同，让人觉得有趣。
于是连续看了两章的内容，有了一点收获：
1. 要求同学们开通博客和群，这样课余时间可以进行交流，这应该就是一个IT人应该的素养；
2. 让同学们使用专业的网站和工具，不再仅仅限于课堂上的教学，更多的是教大家如何进一步变得专业；
暂时这些收获，今后更新；
讲讲目标：
1. 多了解一些IT方面的网站和软件，多接触新的便捷的产品；
2. 时间规划。在编程方面要花更多时间，养成独立思考和独自解决问题的能力；
3. 一周之内看完构建之法；
预期结果：
编程能力和算法能力有所提升，可以熟练开发小型产品；