软件技术基础第二次作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/zjlg/rjjc20
这个作业的目标	<读构建之法，对书中内容提出三个问题或者想法>
姓名-学号	<杨晓健>-<2018330301169>

第一个问题

我看了这样一段文字：

过早优化：既然软件是“软”的，那它就有很大的可塑性，可以不断改进。放眼望去，一个复杂的软件似乎很多模块都可以变得更好。一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化，无视这个模块对全局的重要性，甚至还不知道这“全局”是怎么样的。这个毛病早就被归纳为“过早的优化是一切罪恶的根源
-- 引用自P49《构建之法》工程师的思维误区

产生了这样一个看法：
过早优化并不一定是起负作用的。我认为既然作为一个已经提上日程的项目，每一个参与的工程师都应该对项目或者说全局有一个基本的认知，起码是要了解项目的功能和目的的。作为写程序的人，我认为可以在了解项目功能的前提下，对项目进行预估，留出优化的空间和接口，这样可以大大减少后期整合优化的时间和精力以提高效率。并且我认为书中提出的雨伞例子并不妥当，因为小飞对全局连一个基本的了解都没有。他在雨淋湿自己衣服的时候就应该知道这样的行为不可行。

我查了资料，有这样的说法：

代码优化却是不应该是早期应该关注的事情。除非你对自己的代码已经非常有把握。
就是说前期主要是关注代码的稳定性。包括是否有自己没有考虑到的， 需求变化自己的代码能不能应付的了（能不能通过改少量代码来应对变化）。
也就是说写任何代码，稳定性 可移植性 通用性 才是关键。
说道能力，就是掌控能力，能不能有能力控制得住。
如果有控制能力，那么过早优化也可以。
但人非圣贤，还是按照客观规律办事比较稳妥。
--引自csdn

我的感悟：
我认为上述说法更贴合实际一些，或者换个思维，在项目功能发生变化时，过早优化就会带来诸多不必要的麻烦。

第二个问题

我看了这样一段文字：

巴克斯顿说技能的反面是"Problem Solving”一“ 解决问题”，这个听起来有点绕，我们看看一个例子吧。一个IT专业的大学生来面试，简历上写“技能:精通Visual Studio C#编程”。于是面试官请他用Visual Studio IDE写-段程序。- -个“不精通”的面试者的编程过程实际上就是一个“解决问题”的过程。例如:
●嗯，怎么开始一个C#的命令行程序呢?
●定义数组是怎么弄的?是“int [] arr” 还是“int arr[]"， 还是ArrayList.还是Array 。 哦,我平时都是上网查的。哦，我不知道还有MSDN网站。
●嗯，为什么编译没过呢，哦，这里少一个分号。
●嗯，怎么设断点?怎么定义命令行参数?额，我要查- .查.....
你发现他把时间都花在“解决(低层次)问题”上了，你想考察的“算法技能”、"C# 程序设计技能”都无暇顾及。注意，这是在他认为非常精通的编程工具和编程语言中出现这样的问题。你要这样的员工么?
那怎么提高技能呢?答案很简单，通过不断的练习，把那些低层次的问题都解决了经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。
--引自P57《构建之法》技能的反面

我产生了这样一个问题：
如果对于底层的功能和应用都采用反复不断的练习以达到机械化和下意识的自动操作来解决，这必然会导致知其然而不知其所以然。这其实是会影响后续发展的。如果一个程序员连对最基层的操作的理解都没有，完全是靠肌肉记忆一样的方法来运用他的知识，当面对要求更为复杂和细致地运用基础知识时程序时，会导致出错甚至在不知所措。

我的想法：
应该对所学习的知识融会贯通而仅仅停留在皮毛和应用上。

第三个问题

我看到这样一段话：

如何验证正确性:那就要用断言（Asser)。断门和错误处理是什么关系!当你觉得某事肯定如何时，就可以用断言。
Assert (p != NULL);
然后可以直接使用变量p。
如果你认为某事可能会发生，这时就要写代码来处理可能发生的错误情况
--引自P70《构建之法》

我的问题：
虽然是看完了整段话，但还是不明白断言和错误处理的关系，还有断言具体的使用方法，文中只是说了可以直接使用变量P,那么用P干嘛呢？不是很明白。