1） 回归第一周目标
对于第一周的目标，在提高代码量，多写多练方面达到了，之前结点编程时还不是很熟悉python，现在写的比较熟练了，同时学习了一门新的语言Julia，在学习的过程中也看了Julia和Flux的一些源码。之前比较不注意个人代码规范，在团队项目中被强行规范了。
2） 快速浏览《构建之法》的问题
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少很多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。
结对编程是个渐进的过程，有效率的结对编程不是一天就能做到的。
在做结对编程的项目中，我体会到了结对编程的优点，虽然刚开始对python代码队友比较熟悉，但是结对编程的时候我也能比较细致的找到bug，比一个人效率高，同时也是相互学习的过程，对于小而精的项目我觉得结对编程挺好的，从长期来看，成员互相提高，也能提高团队的效率。
软件在发展过程中用户需求是变化的，用户的数量和多样性也在增长，这时候我们是否应该重新定义我们的典型用户？
是的，虽然软件不是为所有人服务的，但是有了新的典型用户之后我们也应该根据新的需求增加对应的功能。
用网站当前的用户做实验，万一引起巨大的反感，用户就真的流失了。
如果用户体验反馈比较准确，那么测试用户的数量要大，来源是我们的真实用户，这样就存在文中的问题，那我们怎么把这种测试的风险降低呢？
在课上讨论过，我认为不能把测试的工作全部寄托于用户的测试，应该有专门的测试人员来保证质量，然后再去软件的“死忠粉”用户中测试，最后稳定了推广。
平时的时候负载不是很大，而在一些特定的时间，比如双十一等等负载急剧增大，在设计的时候是否有必要考虑这种负载？
我现在觉得我提的这个问题是没有意义的，既然考虑到了为什么不做呢....
成功的团队更能创新 我不能完全赞同这句话。我认为小公司创新难，首先小公司资源比大公司少，其次员工每天花在例行的琐事/工作上的时间多(人少),那么花在思考如何创新的时间少，再者，颠> 覆性的创新会带来产品和市场的巨大风险，小公司没有承受这种风险的能力，和用户基础。
这个问题只是我自己的一点思考....可能大公司会有更多的包袱，这个我觉得没有定论....
4）“事后诸葛亮”分析的感想
最大的感想是做一个项目或者事情之前要想清楚自己的目标是什么(或者用户的需求是什么)，怎么定义问题，定义明确的完成指标，不然到最后会陷入迷茫用力用错方向，比如julia项目后期....
5）对比一些技能评价表，你有什么提高？ 还有什么收获是不能用数字衡量的？
代码能力和规范方面的提高，以及代码的设计。还有的收获就是团队合作的能力和经验（失败的教训....）是不能衡量的。
6）设想一年之后， 你到了你职业发展的下一个阶段（高年级， 读研，工作），回头看这门课， 你对于这门课的教学方法， 老师和助教的工作，和其他课程的衔接，有什么意见和建议？
我觉得感触最深的就是团队项目真实的体验了在公司做项目会有怎样的流程，另外我觉得做团队项目之前，要求每个团队指定 清晰的目标/面向的典型用户/需求/可量化的完成指标/团队贡献/代码规范等等写成文档放在github里面，最后评价的时候就展示这个并答辩，其实这个过程老师带我们在课堂上做过，有一部分也要求写在团队博客里了，很大一部分是我们没有彻底执行的锅。。。
)
