读《构建之法》

         按照精读的读法，细致的读完了《构建之法》的第一、二、十六章。结合书本内容与自我理解，提出以下问题。

     第一章

1.1软件=程序+软件工程

书中有这样一个例子：如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择：

1．  根本不考虑

2．  如果没时间实现这个功能就算了

3．  做了，但不告诉用户

4．  做了，而且不厌其烦地告诉用户如何使用

谜底是：

飞机的安全功能。

 

我的问题：只有安全功能被考虑在内吗？同理在软件功能中极少部分的使用就能不考虑吗？

一个民用飞机它的运行一定是商业的，根据书中前文中提到的：软件企业=软件+商业模式。同理用于航空公司。通俗地说，一个航空公司一定是要赚钱的，那么它所注重的，是用户的飞信体验，除开安全功能，他的其他功能的开发一定是为了有商业竞争力。

从海底捞的近几年的大火，我们可以看出，与众不同的营销能够让用户趋之若鹜，大家都愿意去海底捞，比起同价位的火锅店，他的服务更贴心，而且有他与别家不同的东西。同理在航空公司上，首都航空在飞机上禁用便携式电子设备的时候，飞机座位前人手一个pad，也许飞行疲惫，都利用短暂的飞行时间补眠，一个飞机上也许没有一个人使用它，但对于少部分精神很好的人，pad的存在无疑是一个很好的打发时间的娱乐工具。

再说到现在的南航等部分航空公司开放飞机wifi，这难道在各航空公司的竞争中不是一个强有力的武器。就算以后所有的飞机都有飞机WiFi，人们记住的是先行试用的南航的惊人的行动力，致力于提高用户的飞行体验。

由此看出一个软件也应该做到这样吧？

第二章

对于第二章，都起来就不向第一章那么清楚明白了，例如回归测试，效能分析等，读了很多遍还不是很懂。

文中有关于确保团队里的成员是合格的软件工程师，一个团队需要一定的流程来管理开发活动，每个工程师在软件生命周期所做的工作也应该有一个流程。那就是所以提到的psp。

 

我的问题：当一个软件被分成模块，一个模块由这个模块的作者完成，代码的作者最了解代码的目的，特点，和实现的局限性，然而当一个模块它已经可以可以完成这部分的功能而他隐藏的局限性并没有被作者发现出来，那么这个问题一定会影响以后的运行。这个问题又应该怎么解决？

第十六章

我的问题：第十六章整章都在讲一个创新，对于一个新兴行业来说，软件的更新日新月异，这样就无可避免的有重复性能的软件出现，怎么样的创新才算创新？在目前已知的领域、已知的需求里面，真正适用的好的软件还少之又少，谈创新只是企业一个宣传噱头还是认真的？

以下观点来自豆瓣论坛：

现实中多数设计者都期望设计出的东西覆盖更多的人，往往这就是败笔的开始。

创新是生产力发展的第一要素和最主要驱动力...软件只是服务于人类发展的一种工具，软件创新就是顺应人类需求发展而对旧理念的突破...只要是能够对提高生产力有帮助的都叫创新，任何事物都是不会停止发展的，当然发展过程中不适应发展的创新必然会被淘汰...