《构建之法》随笔感想
《构建之法》将软件的开发流程从需求设计直到后期维护每一步都讲解了一遍，从大一学习编程到现在，我对软件开发有着3次不同的认识；大一时认为，软件开发就是编码工作。大二认为，软件开发是要保证编码灵活性的状态下（通过设计模式）进行编码。现今认为，软件开发是要根据用户不同的需求，权衡软件编码的灵活性以及软件的性能，在满足用户的需求前提下，尽可能的保证软件拓展性以及性能。当然目前的理解肯定还存在很大的偏差，但相比大一而言，已经不再是同一个认知水平了。
《构建之法》中提到了合作编码这一块，在大型的项目中，如何高效的进行合作开发，这是在大学课程中并没有提到的问题。合作开发不是单纯的1+1这样的效率叠加，如果方式不妥当，多人合作可能比单人工作效率更低，尤其是在编码这一方面，以前我个人对编码规范并不重视，认为这并不重要，经常把变量或者常量定义为a、b……诸如此类，并且还经常把完全不相关的方法变量记录在同一个类中，通过阅读《软件工程》以及《构建之法》，我对此有了新的认识，从而提高了我与他人合作的容错率。
软件测试也是《构建之法》中一个重点提及的模块，软件测试不是单纯的想到什么测试什么这样一个状态，应该有序而详细的进行测试。软件开发不是单纯的意味着实现了功能就完事，程序中出现了异常，这属于编码过程中应该解决的问题，但是功能能够使用了只是代表着有效路径测试成功，无效路径并没有被测试到，如果无效路径能通往有效路径的终点或者无效路径会使程序出现异常并且这个异常并没有被捕获进行异常处理，那么这个程序的设计是有问题的，用户体验非常糟糕，这样的软件质量低下。而且，对于一个项目团队，不能总是以完成时间来定义个人的能力强弱，有的人在完成功能设计之后完全不考虑bug的问题，把所有bug的检测全部扔给测试人员，使得测试人员压力倍增，有些bug是程序在功能设计过程中产生的逻辑bug，这样的bug修改起来费时费力，类似《构建之法》17.3中所提到的萝卜与白菜这个故事。应该在程序设计的过程中就开始执行测试，如单元测试，同时设计者本身也要经常思考这样设计会不会导致出现bug，保证在项目完工时测试人员与开发人员皆大欢喜。
对于《构建之法》中我也存在几个问题：
1、从软件测试的角度，如果对一个系统进行性能测试，那么性能测试应该采取白盒测试还是黑盒测试？
2、进行性能测试的话，应该采取怎样的标准才能表明这样测试出的数据能意味着这样的项目设计比之前的更好？（比如一个web项目一分钟2万访问量，那如果我只做单表查询内容也不复杂，页面就一个表单，那我也能达到300多qps，这要怎么区分谁好谁坏）