人月神话，初看书名以为是一本有关古代传说的书，实际上它却是一本为我们软工人的一本指导书。
这本书以“焦油坑”一章开篇，书中说道：过去几十年的大型系统开发就犹如这样一个焦油坑，
很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统。不过，其中只有非常少数的项目
满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，
团队的行动就会变得越来越慢。
软件的文档是与机器同样重要的，即使是对于极其私人的程序，说明文档也是必须的。不应该由于进度压力等任何原因忽视文档的编写。
绝大多数的文档失于概述部分过于简略。程序的概述应包括目的、运行环境、输入输出的范围、函数和应用的算法、输入输出格式、操作指令、
选项、运行时间、准确性。修改一段程序也需要有一段概述，应包括流程图或者子程序结构图、详细的算法描述、所有文件的说明、通过结构的
概述以及对最初设计进行更改的原因的说明。传统的用流程图说明程序的方式基本已经过时，因为如果流程图超过一页，将变得极其难懂。在源
代码中嵌入说明的自说明文档方式是很好的改进。使用自说明文档的方式应注意以下几点：使用程序名和变量名携带更多的文档信息；使用空间和
格式来显示子程序、嵌套，增强可读性；插入必要的段落说明，尤其是在模块的开头；另外在多说明使用的原因，而不是仅仅是怎样使用，因为动机
是理解的关键。
个人感受:
在过去的学习和开发中，我很少有些注释和说明文档的习惯，在看别人的代码时发现有的人也没有写注释或者说明文档，
在理解他人代码时就显得格外费力，经常搞不懂他的某部分代码作用是什么，耗时耗力效率很低，生气他们为什么不写害的我分析大半天；
而在看有些具有写注释和文档的人的代码时，差距就显现出来了，他们的代码看起来通俗易懂，自己需要参考什么也格外清楚。
但是自己却因为写这些东西太过麻烦，老想着偷懒，想着自己看懂就行了，导致在编写项目时还要回顾一遍自己代码的含义和作用，没有
养成好的习惯。
那么如何解决这个问题呢，我决定在每个项目的创建初，就创建一个文档，开发文档，记录每天的开发进度和遇到的问题，以及
自己怎么解决的。每当看到这个文档，就提醒自己编写代码和文档，今后的开发中要更加注重一些习惯，编写开发文档，制定进度表。