我寫過技術文檔，如果不把內容抽象成模型總結成公式，那樣效率就太差了_風聞

作為做過程序設計，寫過技術文檔的人來説一下為什麼會出現這個情況。編寫教材和文檔的人是非常熟悉其理論和內核的，就我開發了一套框架，我知道它內裏有什麼坑，要怎麼避開它，但這些坑是適配問題帶來的，不是我的框架本身的問題，所以我的文檔上就不會寫，寫上去就顯得非常囉嗦，但別人總會遇到這個問題的，於是就掉進坑了。舉個最簡單的例子，Windows系統是CRLF（回車換行），Linux系統則是LF（換行），mac系統則是CR（回車），所以同一個文件在不同的平台存放就會遇到文件md5不一致的問題，在校對的時候會出錯，但我不會把這個情況在文檔裏寫明，因為這個問題對我們來説是，常識。我寫文檔的時候，不可能從最最基本都問題寫起的，要我跟你從打字機開始講起，好好了解一下最早的撥號上網以及50hz的工頻電流導致的必須使用兩個佔位符才能保證傳輸的準確性嗎？那恐怕和我的文檔確實是關係不大。我寫是為了什麼，是一本操作手冊和説明文檔，為了讓人快速上手，理解運作的原理，我必須全部抽象成模型，總結成公式，我才能講下去，而不是東一片西一片的，那樣效率太差了。所以實際上我是能理解的，你看這個函數多漂亮多方便哦，如果你要靠自己去實現這個功能，我保證你得多花兩百行，還不一定能搞定，為什麼？因為我見識過二十多年前用古老的語言（vb）寫的四萬多行的地獄代碼，然後要把這些東西搬遷到新的項目上，真就要死了，簡直就像是在考古哦。所以一本教材，有些東西真的是覺得理所當然的（比如三角函數），如果連半角公式都看不懂，那這課還真就講不了，還有一些呢，不講可能確實難以理解，講的話又牽扯太大，根本講不完的，就像前端在ie時代為了給各種瀏覽器適配而不得不寫的各種奇葩hack，你永遠無法想象人類的智慧會用在什麼地方，這個真就是變化太多了，需求的情況也非常複雜，不可能一一講解的，只能舉常見幾個例子，但該被坑的地方還是得踩坑。

本評論由用户“北方不吃麪男孩”推薦，來自《國外教材比國內教材更易懂的説法， 你怎麼看？》一文。內容僅代表用户觀點，標題為北方不吃麪男孩用户添加，更多熱乎討論請移步原文。