全部學習彙總： GitHub - GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month.
軟體開發除了實作設計之外，很重要的一點是需要面向使用者以及未來的維護人員。是以，文檔化的資訊在整個軟體得生命周期中是很重要的。
為什麼新人不願意寫文檔？可能是我們傳授教授的方式不合理，有時候我們傳授給信任的不僅隻有相應的理念，也得去身體力行做一下給他們做一個範例。
上面列出來了一般的軟體文檔需要涉及到的方面，這個對于嵌入式控制軟體可能并不是很合适。但是，這種方式以及思考的角度肯定是正确的。在不同的領域之中，可以針對性的總結一份類似的清單用來限制軟體文檔的内容。
有時候有些問題的解決可能換一個開發的模式就能夠解決，我現在還不是很了解文學式程式設計的操作模式。但是從相應的描述來看，可能這種模式可以很好的解決這裡提到的一系列問題。
針對電腦上的軟體，很可能使用者會基于相應的軟體調用開發其他的功能。但是在嵌入式控制的領域這個有所不同，然而，如果使用者采用的是你開發的子產品驅動來進行二次開發，這樣還是有一定的相似之處的。
現在的流程圖在工作中越來越少見了，其實我覺得很重要的一個原因就是在于其效果以及效率方面的劣勢。
我們在準備文檔資訊說明的時候，其實形式以及格式很多時候并不是很重要，關鍵還是在于表達的資訊需要有足夠的豐富度。
不僅僅流程圖可能出現後面補充的現象，其他的文檔或者資訊也有這樣的問題。或許我們應該反思一下，為什麼？是我們本身的執行的确不好還是我們要這些資訊本身就是一個錯誤？或許，有時候一些全新的工作模式會有颠覆式的效果。
自文檔化，其實這個也應該是文學式程式設計的一個很好的優點。看起來，我應該花時間去研究一下文學式程式設計了。而最後的描述，其實本身也是文學式程式設計的自然産物。
前面我的批注多少是有點對我曾經工作的一點抱怨了，這裡有我自己的私人想法，不見得适應市場的風格。但是，把一些标準化了的軟體封裝修改成非标準化的軟體，很多時候工程師的工作少了創造性的樂趣，而這個過程也是一個讓正确的設計理念不斷扭曲的過程。是以，從一個結構師的角度思考，我覺得這種做法的确是不妥當的。