1514

1514

全部学习汇总： GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month. (github.com)

这一个章节的内容比较多，值得去思考的点也比较多。初步我会考虑分成两部分来整理我的读书笔记。

章节的开篇3页我全都留下来了，一者我前面的笔记基本都是如此，二者我觉得这里还是让我想到了一个问题点。那就是，其实在软件开发中有很多对立的观点但是彼此却都是正确的，只是在不同的场景或者条件之下彼此各有各的有点。就像是这一章引用的格言，对于同一个事物以及结论不同人可能会有着截然不同的看法。而这个，其实也可以归到前面分析的软件开发固有的复杂性当中。

其实，从前后文看，作者想要表达的观点是软件发展的路子是走错了。但是，我顺便借着这个具有模糊或者说歧义的翻译写了一下当时的想法。其实，我觉得软件的发展本来就没有什么正确与错误，对于软件来说，只有是否合适的说法。为什么呢？软件或者硬件的发展根本的目的还是要去符合用户的基本诉求，既然经过了一路的历史洗礼依然能够存活，说明至少曾经的主流技术路线还是让人们所接受的。由此，至少技术发展到现在都算是合适的。当然，我们可以说这并不是最优的发展结果，也没有经历最优的发展路线。

很难说这本书是一本软件行业的书籍，毕竟对于工程师来说没有技术上的实际提升。因此，更多的来说，其实这本书反应的是一种行业的大局观。当然，如果我们说这个是一个关于团队描述的书籍也是合适的。

由这方面的一些职责可以看得出来，这个结构师需要掌握的技能结合今天的技术来说会是一个很大的挑战。

其实我觉得关于功能以及性能的总和平衡与评估在项目之初做完整性的概念阶段就应该评估出来，这样就可以很大程度上避免这样的回溯可能性。

曾经的word居然只需这么少的内存，现在想想不敢想象。但是，这又不得不引起我的好奇，之前的这个版本的word究竟提供了什么样的功能呢？

对于需求类的说明来说，首先得要有，不管是否合适，至少可以让工作减少很大的盲目性。

以前其实考虑过这个由来，但是没有深度思考。现在想想的确是，很多图形化实现的操作其实理念来自于现实世界。

这里开始我有点误解，但是两个模式却都是值得去尝试的。第一个是充分发挥键盘的作用，而书中则是推荐两者的组合。结合后面的实际的例子说明，书中描述的部分如今是已经实现了的。

在人机交互的效率上，这里提出来了另一个可能性，那就是语音的介入。现在的设备其实这个已经基本都具备了，甚至有很多产品走了极端，类似老罗的TNT。我有点好奇，是不是老罗也读过这本书受到了什么启发？不过，我们很难想象在格子间的秘籍作业环境下，所有的人都使用语音的情景。因此，我觉得这个不能够作为一个通用型的解决方案。

很多计划的设定翻了一个程序设计经常犯的错误，那就是过于乐观。其实，在实际的进程中，很多推翻了重来的方案。其他人的设计我不是很清楚，就我个人的经理来说似乎在解决棘手问题方面这种经历并不罕见。

目前我接触到的很多项目中看不到这样的过程，我觉得并不是不存在而是因为他们被无意或者有意的进行了隐藏。我自己的开发经历中就是如此，或许项目经理看到的只是花了一定时间出了结果，仅此而已。中间的曲折过程或许根本就不会有什么人从项目管理的角度进行考虑。

这一次的阅读还是很有启发思考的作用的，也可以让我对过去的一些工作进行总结。这一次的小结先到此为止，剩下的篇章学习留待下次。