Q1、关于过早优化问题。
既然软件是“软”的，那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似乎很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化，无视这个模板对全局的重要性，甚至还不知道这个“全局“是怎么样的。这个毛病早就被归纳为”过早的优化是一切罪恶的源泉“。 ——《构建之法》的第三章
- 在我还没看见这段话之前，我的课程设计编程永远是边编程边优化程序，写写停停，中途如果对于某个模块有新的想法的话总是会停下当前的工作去实现自己的想法，这样导致的后果就是有时候无法完成课程设计的项目，有些时候就是有那么几个模块设计的很好，但是有些模块却一塌糊涂。这里我就有问题了，我们在编程时应该何时优化？可能每次课设都是我一个人写的没有考虑太多的东西前期没有构思好，往往会漏掉一些东西。
在知乎上也有人跟我提出了一样的问题其中有个用户的回答我还是比较能够理解的。
先有质量地实现你的需求，写够testcase，然后做profile去找到性能的瓶颈，这个时候才优化他。
- 对于这句话的理解就是首先要实现自己开发这个软件的基本要求条件下，然后再去追求更高的性能吧。
Q2、关于单元测试的问题
单元测试必须由最熟悉代码的人（程序的作者）来写
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。 ——《构建之法》的第二章
- 在一定角度上不太赞同这句话的，单元测试也可以让一个比程序的作者更了解这段代码的实现功能的人来写，当一段代码量比较少简单易懂，但是由于程序的作者的一个疏忽，敲错了一个单词实现的功能却是和起初所要实现的功能完全不一样的或者程序的性能较大程度上受到影响，但又是不可见的，程序的作者无法找出错误的点，那么这时候让一个更了解代码的人来写单元测试可能会发现这个问题所在，并加以解决。但是当代码量比较大的时候，我觉得单元测试还是由程序的作者来做比较合适。但是还是有个弊端，找不出错误的模块。
Q3、关于代码规范
代码规范可以分成两个部分：
代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。
代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。 ——《构建之法》的第四章
- 代码规范真的那么重要吗？对于课本上的那一段代码看的比较吃力，但是还是可以看得懂得。那么这代码规范真的重要吗？答案是非常重要。我去知乎上找到了一篇文章关于代码规范性的：软件团队一定需要代码规范吗？
也许作者将代码规范这一部分内容放在两人合作有一定的道理，一个人编程不需要考虑任何的格式问题，只要自己看的懂就好，那么当与其他人合作编程时就应该考虑到不规范编码给团队带来的工作量，以及对整个项目的影响。
Q4、关于团队的模式
软件团队模式有各种形式，适用于不同的人员和需求。主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。 ——《构建之法》的第五章
- 我认为团队模式对于当前的在校大学生来说显得不是那么重要，当一个团队中有一个编程大佬时，团队合作就显的不是很明显，完全就是一个“明星模式”。全部的代码依赖于一个人完成，通常并不是我们不写代码，而是在一定的时间内，个人的能力限制了自己的发挥水平，往往就是拖了整个团队的后腿的那一个。所以通常在学校内的软件编程是一个人独立完成的。
Q5、关于创新
迷思之二：大家都喜欢创新
谁不喜欢创新呢？然而细细想来，创新就是做和以前不一样的事，并不是所有的人都喜欢“不一样”。 ——《构建之法》的第十六章
- 创新难道一定就是做和以前不一样的事吗？
这里找到了百度百科对于创新的定义：
创新是指以现有的思维模式提出有别于常规或常人思路的见解为导向,利用现有的知识和物质，在特定的环境中,本着理想化需要或为满足社会需求，而改进或创造新的事物、方法、元素、路径、环境，并能获得一定有益效果的行为。
-创新可以是做同样的事，在一定程度上改进事物，那不也是创新的吗？就好比编程一般，同样是实现同一个功能，用一个全新的方法，能够提高性能，是不是也应该说是创新的吗？难道一定要做不一样的事？？？