1510_人月神话阅读笔记_另外一面

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

软件开发除了实现设计之外，很重要的一点是需要面向用户以及未来的维护人员。因此，文档化的信息在整个软件得生命周期中是很重要的。

为什么新人不愿意写文档？可能是我们传授教授的方式不合理，有时候我们传授给信任的不仅只有相应的理念，也得去身体力行做一下给他们做一个范例。

上面列出来了一般的软件文档需要涉及到的方面，这个对于嵌入式控制软件可能并不是很合适。但是，这种方式以及思考的角度肯定是正确的。在不同的领域之中，可以针对性的总结一份类似的清单用来约束软件文档的内容。

有时候有些问题的解决可能换一个开发的模式就能够解决，我现在还不是很理解文学式编程的操作模式。但是从相应的描述来看，可能这种模式可以很好的解决这里提到的一系列问题。

针对电脑上的软件，很可能用户会基于相应的软件调用开发其他的功能。但是在嵌入式控制的领域这个有所不同，然而，如果用户采用的是你开发的模块驱动来进行二次开发，这样还是有一定的相似之处的。

现在的流程图在工作中越来越少见了，其实我觉得很重要的一个原因就是在于其效果以及效率方面的劣势。

我们在准备文档信息说明的时候，其实形式以及格式很多时候并不是很重要，关键还是在于表达的信息需要有足够的丰富度。

不仅仅流程图可能出现后面补充的现象，其他的文档或者信息也有这样的问题。或许我们应该反思一下，为什么？是我们本身的执行的确不好还是我们要这些信息本身就是一个错误？或许，有时候一些全新的工作模式会有颠覆式的效果。

自文档化，其实这个也应该是文学式编程的一个很好的优点。看起来，我应该花时间去研究一下文学式编程了。而最后的描述，其实本身也是文学式编程的自然产物。

前面我的批注多少是有点对我曾经工作的一点抱怨了，这里有我自己的私人想法，不见得适应市场的风格。但是，把一些标准化了的软件封装修改成非标准化的软件，很多时候工程师的工作少了创造性的乐趣，而这个过程也是一个让正确的设计理念不断扭曲的过程。因此，从一个结构师的角度思考，我觉得这种做法的确是不妥当的。

关于自文档化的代码，有一些推荐的技巧：1，命名规范； 2，排版统一； 3，合理的注释。我觉得很好的一点在于，汽车电子软件开发的一些规范中其实已经对此做了要求。

那么，为什么要写文档呢？我们的目标其实并不是文档本身，而是希望我们传播的信息有效且好用。而这里提到的计算机存储资源的限制早就已经让工业技术的革新给颠覆掉了，如今的存储早已经不是什么稀缺的资源了。