原有问题
问题 1
我仍然认为用随机数以增加测试的真实性是可行并且必要的。关于作者提到的无法复现错误的说法，除了我之前提到的直接记录不通过的输入（随机数）之外，还可以通过记录随机数初始化种子来复现不通过的测试。
我这学期在实习的地方需要写一些go语言的程序，并且团队也很重视单元测试，所以我对go语言的单元测试进行了深入的研究。在Go程序设计语言这本书的11.2.1中，作者详细介绍如何进行随机测试，并说了一句话来说明单元测试的必要性。
虽然随机测试会有不确定因素，但是它也是至关重要的，我们可以从失败测试的日志获取足够的信息。
我很认同他的说法。通过记录随机数种子的方法来重现失败的随机测试的方法也是从这里学到的。
问题 2
我现在已经十分认同作者的观点“单元测试必须由最熟悉代码的人（程序的作者）来写。理由除了作者说的”代码的作者最了解代码的目的、特点和实现的局限性。“之外，我在最近的实现中还学习到测试驱动的开发(TDD)的优越性，在这种开发模式下，也只能是开发人员写自己的单元测试，而且是先于开发的代码。
至于我之前提到的疑问“自己的错误和缺点往往很难由自己发现”，这么说是正确的，这也是我们需要专门的测试人员的原因，但单元测试的目的是保证开发人员写的函数按照他的想法正常运行，不出现明显的bug。就像作者说的“单元测试不能解决所有的问题，不必期望它能发现所有的缺陷”。我还提出“开发人员同时作为测试人员既越俎代庖又效率底下”。经过我的实践，我现在的感觉恰好相反，认为测试人员写开发人员测单元测试才是越俎代庖、效率低下。在一次项目实践中，由于开发进度比较赶，一直没有做单元测试，直到后来有了时间，需要统一补齐之前的单元测试。我补的函数有些是自己写的，有些是其他人写的。给其他人写的函数做单元测试是一件痛苦的事情，你需要先了解他函数的企图和细节，如果开发人员本身水平和代码风格有问题的话，常常写一个函数就要花大量的时间，有时还需要找到底是谁写的这个函数，当面去问问清楚。可见，如果单元测试交付给专门的测试人员去写，而不是开发人员写，效率会有多低下。
问题 3
关于“效能过剩”，这个问题仍值得商榷，对于不同的人回答可能不一致。我作为一名计算机专业的大学生，从来不感觉“效能过剩”，相反认为过剩的效能总会慢慢的用尽。进几个月“吃鸡”这个游戏分外地流行，很多游戏爱好者发现自己的机器的性能不足，再加上最近内存条的价格疯涨，这时候就是效能不足。当然，这可能和吃鸡的开发团队技术上的能力不足有关，据说腾讯代理国服后，性能要求会有所降低。我另外还有一个感受，近些年智能手机内存和存储空间也一直在涨，从3G/16G涨到6G/128G，每次感觉都够用了，但用不了两三年，就发现又需要换手机了。当然这也和使用习惯有一定的关系。
问题 4
创新是人们一直在提也喜欢提的话题，但如果说“不但大众不喜欢创新，甚至连创新者自己也不例外，有些创新者甚至憎恨创新“，我到现在也还不是能够理解。或许这和我本身的性格喝年龄有关，我却是比较喜欢新鲜事物，也许过上一二十年的实践和学习后，我才能理解作者的这种观点。
问题 5
对于”统一不同设备上的用户体验“这句话，我现在有了比较深的认识。虽然UWP的尝试看起来失败了，但”不同设备、同样的体验“仍然是人们追求的目标。比如，Apple现在的Mac OS和iOS的体验就在不断的靠近，相同的系统应用，类似的操作和布局，同样的审美。作为一个用户，当我开始使用不同的设备时，我也期望能够有相同的体验，这样会让我的学习成本和操作流畅度提高很多。UWP的失败并不是因为它的统一用户体验，而是在于其他方面，比如Windows手机端的不给力，大量win32的用户和开发者安土重迁迁移成本高。不过，我们仍能看出，统一不同设备之前的用户体验是一个正确的趋势。
”做中学“到的知识点
需求
NABCD模型
设计
文学化编程(Literate Programming)
实现
模块对接时采用结对编程。
测试
测试矩阵的绘制。
发布
不同应用市场的审核机制。
维护
git和GitHub的使用。