全部学习汇总： GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month. (github.com)
前面总结了没有银弹的章节，多少还是让我想到了一些其他的方面：全新的技术模式、新的开发语言、新的开发工具、新的技术思想以及原有技术上可能存在的重用性改造。在这些方面上必须得时刻保持着自己对于相应方法的敏锐程度，因为随时出现的新方法都可能颠覆整个行业。这一个章节，其实是上一个章节话题的延伸。
开篇的这个照片，我觉得多多少少会让我往软件可重用性上去思考。
如果，当我们面对销售人员，听着他们介绍自己的产品能够十倍甚至百倍的速度提升效率的时候又该有足够的谨慎度。为什么呢？非常简单，十之八九这都是骗人的话术。
这一页，再次重申了软件设计中的主要问题以及次要问题。如果做一个总结，主要问题应该是指架构设计相关的部分，而次要设计则是实现的过程。很多时候，我们所关注的实现部分其实在整个项目之中获取起不到决定性的因素，即使是从技术方面考虑，成败的关键也不在于这个部分。
这一页主要值得思考的问题：我们在软件工程中主要面临的挑战其实并不是实施本身，而是方案的设计。这一部分如果能够取得数量级的效率提升，或许我们的开发速度会有显著的改善。我觉得，以前或许联想不到，不过如今的人工智能似乎在这方面给了我们很多的选择。
我在这里写了一下费曼，其实也不过是一个纯粹的联想而已。当然，我觉得可能性不大，这里的这个人恰好跟费曼进行过交流？
其实，我觉得SICP中很多理念在于简化软件设计过程中的复杂度方面效果显著。但是，学院派的技术路线有时候跟产品化以及大众化的路线又有一些不同，因此有时候这里需要什么比较好的契机让相关的技术能够得到融合似乎会更好一些。
软件领域的乐观主义我是领教过的，而且在过去的十年中不断在领教。因为，我看到的项目里面能够做到不延期的并不是特别多，比重占了少数。我经历的第二家公司或许是一个例外，老板是一个极其优秀的项目经理，整个公司运行的项目不多，因此在项目事实上的成功率的确非常棒。某种程度上，这种少数项目为主线的模式可能会给工程师一定的自信。
上面所说的软件特性，其实是前面提过的复杂性以及各种可变性。其实，我曾经在之前的章节中增加了几条，从我自己经历的角度做了补充。我在这里重写了一下这个问题放到了批注之中，因为我觉得这个应该是值得我们每一个人思考的一个问题。而且，这个问题需要我们进行深度的思考。
我觉得画出来的这部分内容算是作者的一次辩驳，但是，我觉得他辩驳的有道理。如果能够带着我们现在所有的历史记忆退回到上世纪50年代来看这本书，我觉得能够看到的更多是准得令人发抖的猜测。
看这本书的时候总是会发现之前的软件设计所用的资源很少，之前的计算机能力很弱。其实，这倒是给了我们另外一个思考的问题：如今，我们面对着数量级倍数与之前的设备以及条件，是否能够做出对等数量级优秀的产品呢？
我觉得这个画出来的论点是正确的，很多时候我们解决软件问题的时候借助的是一些类比的模型。就我个人的经历来看，很多复杂的问题都是借助于一些可视角度的模型来进行推理实现的。
这里提到过一个很有特点设计也非常优秀的微软的产品，但是我的确是没听说过，后面得去了解下。
我曾经简单了解过面向对象，但是没有从方法论上给我什么大的冲击。可能是这方面的思考深度不够，不过这也是很好的一种现象。我一直想让我未来的余生中充满思考去读过每一天，这样的未解问题都可以作为我未来思考的一些对象。
这里面的OO思想，说起来我从现在的汽车电子软件设计中还是看到了很多痕迹的。但是，底层抽象其实是不成熟的。或许，这也跟我所面临的工作有关。我们存在的目的是为了让别人感受到更多的通用性。
另外，在嵌入式软件中有一个奇葩的小设计叫做Arduino，风靡全球。我觉得很大程度上，他们的成功是开源软硬件。但是，C++中绑定的一些天然的OO特性是否对他们的成功起到了推进作用呢？我觉得还是有可能的。
这里作者既然这么写，肯定是有自己的经验在里面。由此，我也第一次意识到我自己在OO方面思考上的一个缺点。我很少会考虑在模板中增加通用的方法，最多是组合相关的属性。然而，可能这正好是OO的一个很好的有点。
但是，针对这里的项目的经验时间我又觉得有一些疑问了。OO无法保证前面的开发速度，到了第五个项目才会明显有时间的减少。那么，其他的技术模式到了第五个项目呢？是否也会是减少呢？如果是，OO的有点又是什么呢？
在软件可重用性上有两种呈现模式，一个是软件包，另一个是程序。从Jones提到的数据看，可能我自己的积累量还是差很多。我自己做软件设计的时候，达不到这么高的重用率。
这里针对数学类软件设计的时候提出来了一个问题：这种软件一般很难懂，比较晦涩，每一行代码都需要大量的智商输入。看到这里，我不禁想了解一下：我现在接触到的软件究竟有多少的智商输入呢？
在软件重用方面，美国的公司做的非常一般，这一点结论多少让我有点觉得意外。
关于软件重用的确是需要努力的方向，我自己尝试积累了几年的时间丰富我自己的工具箱，现在看起来也并不是一个特别丰富的仓库。
软件发展的过程中，不断学习新的东西是一个必然。结合这里面的描述，其实bash命令中的各个参数选项的学习就是一个很好的例证。另外一个例证就是，面对不同的单片机，我们现在得接触大量的功能模块的缩写，而这个在不同的厂家之中又有较大的偏差。
在语言复杂度上，编程语言高于机器语言，而自然语言则高于编程语言。这个的确是我从来没有思考过的问题，的确是，其实说话不说错相比于写代码不写错来说更有挑战性。
软件固有特性中的复杂度一直是我们的实施方面的拦路虎，而复杂度本身其实可以从设计的随机性、不同人认识以及见识差异、不同人的表达能力等方面进一步派生。当复杂度跟人绑定在一起，而不是单纯的环境设备因素的时候，处理的难度就会更高一些。
