1.像这一类书籍，怎么阅读才更有效？

　　来自百度：

　　实践表明，直接光看书效果是不大的，必须learning by doing，寓学于干，看了书的知识，只有马上通过工程实践尝试过，才有直观深刻的印象，才能发现问题和优点。所以，我觉得我们边上课边做项目的课程安排是很合理的。

2.命名规范为什么是加前缀？

　　在平时使用VS等编程软件时，我们都知道，打出变量的前几个字符，vs会根据这几个字符自动帮你搜索可用的变量，那么如果加了前缀，不是阻隔了这一功能吗？我每次都要先把前缀打完才能像以前一样，并不如加个后缀来的方便。

　　来自百度：命名规范的事情——能不能不要在每个名字前面加一个前缀……

　　像Numerical的东西我还可以理解，有精度，字长以及等等的问题，但是例如像一个类，他本身是多态的，那我如何来给他起一个固定的前缀？呃，叫它的基类吧……不过忽然有一天，某人兽性大发说要Refactor一下，钛合金F2轻轻一按，牛逼风范，然后所有的变量名都2了……敢问为什么要在现代型编程语言中使用这种复古的思想？难道是WINAPI的历史遗风？

3.对于一个已经有一定规模的软件，增加功能重要还是精简功能重要?

　　来自百度：《移山之道》的最后一章，讲“发布阶段和之后”，提到如果一个模块如果不能实现预期的设计需求，就要视状况砍掉。除此之外，用户/场景分析,迭代式开发等方法强调的都是不断地”增加”，就像微软的大多数软件，体积庞大，功能复杂，保住了大多数的用户，但是也造成了大量的浪费。

4.程序质量控制的重要性？

　　来自百度：每个人写程序都会犯2，所谓Zero-Bug的程序，我觉得是不存在的。这句话，按我的理解，意思是“一个程序员由于不用心，写错了程序，最后倒霉了”。但是按照我的理解，事实情况应该是“一个程序员非常用心，但是倒霉了，所以写错了程序”。过分追求质量控制会丧失敏捷性。Y Combinator的Startup培训教育大家说，有BUG没关系，尽快拿出来给用户用，Feature最重要。请问这个问题怎么解。

5.DEV要不要TEST自己的代码?还是一直专注于写?让专门的TEST来做?

　　最熟悉自己程序的肯定是编写者，当程序比较大时，比如这次的电梯程序，涉及到许多类之间的协调，那么测试者就会十分痛苦，因为他要先搞清楚程序的运行机理，那我才能给出比较好的测试用例，出现bug时，debug人员也要先搞清楚程序的机理才能debug。如果是编写者，输出的数据发生异常时，他比其他人更容易想到这个错误的原因，那么是不是当程序比较复杂不好测试不好debug时，由编写者自己来做一部分测试工作？

个人阅读作业——读移山之道想到的问题