前路漫漫，且行且珍惜
二专这个坑
- 就从大学说起吧，进入相对较冷门的应用物理专业，一者我确信自己并不能在物理上有什么大的成就，在发布研究成果这类的领域基本和我接不上边，（当然，现在看来已经不仅是确信来形容了），二者就业方面的前景也并不是很乐观。因此在某种程度上来说，“迷茫式”再寻新路并不意外。这些尝试中，也包括了进入二专的学习。对计算机的感兴趣也驱使了选择“软件工程”为辅修专业。
- 谈谈主专业和二专上的学习吧。对于本专业来说，我希望自己保持一个不挂科的成绩，能弄懂的能完成的尽量在课堂上解决。而在二专上，老师的要求都不是很高，当然这点本身并没有错，我们认识的老师有说过这样一句话：“学多学少都由学生自己决定，不要以为说老师能教你变成大神，老师本身就不是大神，想成为大神都需要靠自己努力。”自助者天助之，自弃者天弃之。想来也是这个道理，所以有时间多补补对计算机方面知识的缺陷。庆幸的是，主专业所开设的课程也和计算机方面有部分相接，使得我学起来不是很费力。学线性代数和概率论，增加我对分析问题的能力，我们有一门课叫“计算物理”，其中就是通过分析物理公式，再通过编写代码模拟实验过程，最后运行程序就能得到结果。这种结合物理与计算机的知识才能达到解决问题的效果，是单单只学计算机达不到的。
- 此外，其他事物繁忙也占据了大部分时间，甚至还导致了一些类似难以静心学习副作用。 二专这条路似乎剩下一年了，但要真正走好这条路却还很长，还要付出更多的时间与精力，不后悔，且行且珍惜。目前大致以后端，服务端为后续发展方向，这段时间确定大富翁小游戏，以java为开发语言实现他。
对于《构建之法》的提问
时间的限制，粗略翻看《构建之法》，提出几个个人小疑惑。
- 测试的目的不是尽可能的发现更多的缺陷吗？在我看来用随机数的测试方法不仅“增加测试的真实性”，有时还能测试出个人缺漏的地方，由此我们也可以针对错误的结果，反向推导错误的产生原因，写出对应的单元测试。而教材中仅以“但不是在单元测试中”一句带过，那又应该是什么时候采取随机数测试呢？
- 文章中的结对编程，就如所比喻的那样，相当于“驾驶员”与“领航员”之间的关系，固然两人之间的交流能互相学习传递经验，而“驾驶员”与“领航员”之间也可能出现矛盾，一个想走这条路看看溪边的风景，一个想走那条路看看丛林中的花草。两者的搭配真的能高质量地产出吗？后文还提到了轮换角色，我想来想去这个过程还是有点难实现的理论。
- 以前经常听说，程序员工作模式：在deadline前一个晚上，拼命熬夜敲代码交付程序，看了这本书，仔细想想确实不可信也不科学，书上有提到“在团队工作中，稳定，一致的交付时间是衡量一个员工能力的重要方面”，当预计所需时间与自身实际所用时间趋于相近也是否意味着对自己工作能力的认识？但在面临预计所需时间与实际所用时间相差较大的时候，我是否该在下一次工作中延长预计所需时间？这样的方式是一种进步吗？
- 提到“需求”这个概念的时候，基本只能想到用户需求的联系，还想到到那一幅用户想要一个秋千，最后程序员弄出个轮胎的漫画。如何做到真正认识到用户的需求？书中还提到了技术团队本身的需求，企业方面的需求，这是之前所未思考到了，那么当着三者的需求发生冲突，又有什么标准来如何确认最后的供应吗？
- 就如文章所言，现在日新月异的计算机世界，一个新的事物很快就会崛起，甚至可能取代旧的事物，这是一个问题还是一个机会？这是否意味着我只要学习最新的事物就可以跟上时代？还是意味着我所不懂的事物越来越多？我应该先把现在正在学习的隔一段日子而转向新事物，还是继续扎实这部分的知识？
