1493_人月神话阅读笔记_未雨绸缪

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

看完了整个章节的内容之后，我觉得未雨绸缪的说法虽然也能够表达一定的表述意图，但是似乎也不能够直接让人联想到真正想要做的事情。其实，这个章节最主要的讲解内容就是如何去应对开发过程中的临时版本，而这种临时版本很多时候只是一个阶段性的临时品，最终废弃。

章节中的插图。引入这样的插图，可能是想说这个工程的设计少了一个中间的原型做验证，因此导致了严重的后果。

这个世界上唯一不变的就是变化本身。

当面对新的处理任务的时候，如果对此不熟悉，不妨先试一下，至少迈出第一步。然而，当我们发现自己尝试的路线错误之后，应该用于自我批判，坦诚承认自己的失误。

原型到产品有时候会有一道难以实现的障碍，因此，产品化的过程有时候是阶段性的。

为了满足客户的要求，有时候可能会出现一些临时方案，然而这些方案最后会被废弃掉，成为开发过程中投入的牺牲品。快速推出原型可能有一定的好处，但是也有太多的痛。

如果我们是在做产品，有时候就得放弃完美主义。我们交付的内容很多时候是一个满意度而不是设计上的完美。

在应对变化的过程中，自文档化的设计会很有帮助。由此，我再次想起了高德纳的文学式编程。

这里提到了另一个观点，我觉得其实也是很有道理的。有时候，临时版本的提交会给开发人员带来很多麻烦，因为这可能需要他反复去解释。

两种模式各有利弊。如果采用两条线的方式或者更多条线的方式来管理，其实需要一个高于几条线的人员权威的决策角色。否则，会出现很多的权力对立。

不管是管理还是技术，都该去涉猎一下。学无止境，成长的过程很多的乐趣在于体会我们自身的成长变化。

从某个角度上讲，产品的维护也可以是维护一下使用说明。存在问题的地方禁止用户采用相应的方法操作或者应用，或许，也可以存在一定的体验改善。

bug的维护如果大量安排新手，的确会是新的问题引入的风险点。

在产品不断更新的过程中，可能产品会被修改的面目全非。但是，正是这样的现状催生了很多新的技术与新的产品设计以革新当前的凌乱。