不論是需求的原型，測試使用的TestCase，離職時候的交接文檔，個人的學習筆記，或者是怕忘記做的備忘錄，這些都算是文檔，你有寫文檔的習慣嗎？
甲：要求寫的時候寫，不要求寫的時候懶得寫
乙：有時候記點兒東西，腦子記不住，一般用有道雲筆記記錄一下
丙：有，離職的時候這些，必須要求寫的
……
如果你寫過文檔，或者有寫文檔的習慣，你上一次寫是什麼時候？距離現在有多長時間了？
甲：剛剛纔寫的，剛剛過來開會的時候，手頭的那些記下來
乙：好久了吧，現在寫的看起來像流水一樣，不像文檔
丙：不寫文檔……
……
你現在還寫文檔嗎？如果現在寫的少了或者已經不再寫了，是爲什麼呢？是時間不夠，手頭活太多了還是？
多人：活太多了……（附議中）
甲：沒時間感覺，一天到晚在忙
乙：沒有寫的習慣
丙：寫了用不上，需求改了文檔懶得改
……
其實，我也不喜歡寫文檔
沒時間，每個週期每個Sprint大家手上的活兒有多少，什麼時候開完測試完成都擺在那裏。先不說是否能在規定的時間內高質量的開發/測試完，如期上線，這些已經很佔用時間了，再加上分配Task的時候，除去測試以外，也沒有將文檔算在開發任務裏，沒有給相應的時間。所以最大的原因是時間不夠，哪怕是有寫文檔習慣的人，慢慢的也就不再寫了。
就像剛剛說到的，佈置分配Task的時候，沒有規定完成是否需要有相關的文檔，只要能見到代碼，能看到功能正常就行了。確實，事實上很多時候連代碼的質量都無法保證，沒有花時間去Review和重構，又哪會去寫文檔。不管是重構Code還是寫文檔，在很多公司裏，沒有規定和要求，本質是一種期盼，說白了，能做到最好，做不到也沒什麼……如果做了，那屬於額外的工作量。
額外的工作量是容易被忽視的東西，不會直接帶來收益
當時《甄嬛傳》很火，應該不少人看過吧。對這幅圖應該熟悉，當時扮演皇后的蔡少芬說：臣妾做不到啊。有的人說自己不擅長，不會寫。這也確實是，不管什麼事，做的少，大多數的人自然而然會失去做的勇氣
哈利波特可是當年風靡全球，當時波特還是小鮮肉，再看10年後，滿臉的絡腮鬍子，10年的變化真大。
我們這一行，坐的時間長，想減肥的人不在少數，明知道堅持下去，會瘦，不一定帥，但身體素質會提高，但是做到比較難，爲什麼，因爲短期內看不到效果。
我們寫代碼，寫幾行，可以運行F5調試，看到那幾行代碼運行的結果，寫的對不對，是不是我們想要的結果一下子就能看出來，這種結果獲取的速度很快。
如果是寫文檔呢？一筆一劃的寫完，沒有直接的刺激，在生理上，屬於一種慢速反饋，沒有那種享受和刺激，尤其是在現在這個快餐時代，追求的是快，快，快，所以這也是一種不願意寫文檔的原因
喬布斯當時最偉大的發明是什麼，iPone4的誕生，拋棄全鍵盤，改成一個按鍵，大膽的創新，他成功了。時隔現在iPhoneX都出現，還加了齊劉海。現在一個用戶不一定喜歡iPhoneX，但肯定也不會去買一個iPhone4或者4Pluse。爲什麼，過時了，就像現在出門也沒人用BB機、大哥大，消費也不帶着現金一樣，過時了。
寫測試用例是最有代表性的，有的公司TestCase是和開發並行的，寫了N多，需求一改，勢必很多會改。這還只是即時性問題。當時需要這份TestCase，寫到最好，但後續的開發週期裏，同一個模塊、功能變化，當初的文檔參考價值就會降低，甚至是過時。開發文檔這些都是一樣，事物的本質是在變化的。
但花費了精力、心思和時間寫的東西，會過時，次數多了，慢慢也會產生“反正會變，寫了也會過時”的想法，那必然也就不願意寫了。
剛剛，我們討論到不願意寫文檔的幾種原因。事實上，也有很多人在寫着文檔。我曾經看過一篇文章，程序員75%的時間是在寫文檔，先不論這個行爲是否對錯，也不論是否真的有公司或者開發者這樣做的，但至少存在着很多願意寫文檔的開發人員，我們分析一下他們的原因，爲什麼願意寫。
圖中，一個男孩，手裏捧着肉絲，單膝跪地，旁邊放着一個禮物，面對着一個女孩，應該是在表白或者求婚，你們說這個會成功嗎？
甲：不會，這個男的沒車，沒房……
已：不會……
你們還真是…..，我也不知道這個男孩會不會成功。這個女孩想要的是不是這些浪漫，這些我們不知道，所謂知己知彼，百戰不殆。
我們開發一個功能，有的時候，邏輯複雜。Jira上也沒寫的讓你非常清楚，你問了不及時記錄，也會忘記，這都是經常遇到的事情吧。甚至記得不詳細，還是不知道流程，越是這樣，開發的時候也會越沒底的。
如果一邊寫着文檔，就像提綱一樣，1，2，3……這樣的，然後下面開發。開發的時候遇到細節再補充到文檔裏。寫完一個模塊，能驗證有沒有疏漏，是不是產品想要的東西。這個我有親身體會，這樣磨刀不誤砍柴工，返工次數會少。
這個和上一點有些類似，也可以理解爲上一點延續出來的產物。開發遇到的細節，補充到文檔。整體一個模塊開發完畢，在對照着文檔檢查一遍，看看代碼和文檔是否一致。
畢竟沒有誰想讓自己的代碼Bug百出，有些對自己開發的質量高要求的人，這一步尤其看重。也許你會說，不是還有測試嗎？但是細節真正清楚的是你，你比產品、測試、項目經理都清楚。
這個是我加上的一點。說來有些小人了，想做到有跡可查，如果出了功能不對的問題，不是bug一類，是功能和想要的不一樣。我們來看看最後一次文檔就是這樣的，是校驗過的，有變動的話，是什麼時候和我溝通的。當然了，我們的共同目的是以解決問題爲主。
這個遊戲不是LOL，是現在火熱的王者榮耀。都是5V5的，除非是青銅分段的，否則一個亞瑟或者蓋倫不可能1V5拯救世界的。還是要打團的，這不是一個人的遊戲，需要配合的。
在今天這個分享前，Neo和我商量前後端接口，我直接發過去我的文檔，回覆我的是6個字，分2行。第一行是“很清楚”，第二行是“很方便”。在前幾天和求哥晚上加班，他問我接口，我直接發給他我的文檔，他說你們現在開發都這麼規範了嗎？就應該這樣做，很清楚。
現在都是前後端分離的模式在開發，需要多個人配合。就靠口頭說或者寫草書，在我見到的，沒有記憶力好的，一遍商量就可以不再重複討論的。重複討論不是因爲接口少東西，而是這個字段的類型忘了，那個字段的名字不記得了。這種事情雙方都煩，但是和那兩位同事合作的時候，一遍搞定，除非是接口少了些東西。
我在分享前，在網上找到一個寫文檔的好處，可以稱之爲“至高境界”，和大家分享一下。有經驗的開發人員流失造成開發低水平循環，開發經驗無法繼承。
這裏有經驗的指的不僅僅是開發人員、同樣產品也是，測試也是。
我剛來的時候，哪都不熟，產品產品不熟悉，功能功能不熟悉，開發的時候表不知道是哪個表，字段不知道是哪個字段，但是需要直接上手的，那怎麼辦，文檔沒有，問唄。口口相傳。那時候問軍哥多一些，後來軍哥離職後，還在問他。因爲沒有文檔，甚至有些問題反覆的問，畢竟業務不熟悉不同，名詞也不清楚。熟悉的過程是必須的，但是內耗的時間肯定是大於了熟悉需要的時間。
程序員有個現狀，大多數的還是屬於那種shy類型的，不願意開口問，尤其是初級或者剛入行的，他們消耗的時間肯定更多。實際我還是崇尚那種辦公環境，有什麼，扯開嗓子問一聲，唉，那個誰，那個XX是哪個字段來着……扯遠了。
這種站在公司利益角度上思考，確實境界更高。
還有一種低級的境界，是我的境界。代碼是可能會刪除的，會更新的。如果有一天，如果我離開了一個公司，但至少這個公司還保留着我的痕跡，這是讓我開心的事情。
程序員應不應該寫文檔，這種問題是個辯論題，用於辯論的問題就是沒有所謂的對和錯之說，就像開發語言哪個好一樣。不是說寫文檔一定是好事，不是說不寫文檔就是差勁的，這還是得看自己的風格和對自我的要求還有實際情況。
謝謝大家