導語：一個成功的人的標志是什么？是堅持。一個非常成功的人的標志是什么？是面對自己最討厭的事也能夠一如既往的堅持，并且堅持到底，直至成功。
我這個 尼古拉斯·澀郎·非著名程序員的心靈雞湯，講的不是堅持的力量，而是面對討厭而抵制，并戰勝討厭的力量。
我們其實大部分程序員都聽過這個段子，程序員最討厭的四件事，是哪四件事呢？
寫注釋、寫文檔、別人不寫注釋、別人不寫文檔。
其實，我認為還有比這更嚴重的問題，那就是：程序員也不愛看文檔?？赡苡悬c絕對，但是大部分程序員都不愛看文檔。
其實，說到這個話題，還是因為作為一個團隊領導之后才深刻意識到的，畢竟敲代碼少了，寫文檔多了。慢慢的我突然發現一個很嚴重的問題，那就是大部分程序員都不愛看文檔。
舉個例子：
程序員小猿，在開發一款手機軟件，拿到需求說明書和原型圖之后，大致瞄了兩眼，然后問 UI：設計圖搞好了沒？發過來，然后就看著原型或者設計圖，開始了開發工作。當中遇到了一些技術問題或者某些控件的屬性不記得了，甚至忘記了，然后找度娘和 Google ，一搜，噢，這樣用??！復制粘貼，完畢。最后也如期交工了。
讀完上面一段話，不知道大家有所反思嗎？發現問題了么?可以思考一下，自己的開發過程是不是大致是這樣的？三個反問，好好問問自己。
其實作為一個部門或者團隊領導之后，我對這個問題才有了深刻的意識。畢竟作為團隊負責人可能更多的工作重心在制定任務，協調關系，定需求，制定開發文檔，管理團隊，并協調整個團隊開發順利完成任務，開發出產品來。這時，不免要寫很多文檔，需求文檔，開發文檔等等。然后在開發過程中，處在開發之外的我（當局者迷，旁觀者清），往往很容易發現：程序員不愛看文檔，而且更多得去問產品經理，這個業務邏輯是什么？或者在測試過程中，讓測試測出來這個業務邏輯不對。再進一步反思一下，想一想，其實連 API 文檔估計很多程序員都不愛看，不愛讀。
關于需求說明書
其實團隊的產品經理和負責人可能已經把需求說明書已經寫得很清楚了，整體的交互設計也能從原型圖上體現出來，業務邏輯也有對應的介紹。但是還是有很多程序員在開發之前連自己讀一遍的時間都沒有，我不知道這是不是懶？
其實關于需求說明書，我認為程序員必須通讀一遍，而且得配合著原型交互。最最應該通讀和研究一遍的是后端程序員，因為產品設計初期，后臺的架構和數據庫設計必須依賴這個，如果你都沒讀明白這個產品的業務邏輯，設計出來的后臺數據庫，架構以及接口可能前端對接起來很困難，可能不止一遍又一遍的聯調，還有可能重新設計。這是非常耗費時間和精力的。這些都是成本。
前端程序員當然也有必要一讀，不要簡簡單單的認為照著設計師設計的效果圖，照著葫蘆畫瓢就可以了。你的每個界面的跳轉和后臺接口的對接都需要熟悉整個業務邏輯，前期不讀，后期改，一樣是浪費時間。
我就發現很多程序員，遇到設計上的問題，產品交互上的問題，就大喊產品經理：你這里是怎么設計的？什么邏輯？明明人家已經寫的很清楚了，產品經理還得背這個鍋。所以，需求說明書，原型設計圖，不只是放在那里的一張廢紙，而且產品的血液。你讀了，才會流暢。
關于 API 文檔
其實學習一門語言，一個技術，最好的資料就是官方的 API 文檔，不是市面上某某大神的秘籍，也不是某某教學視頻網站上的教學視頻?？偢杏X自己身邊的東西不值錢，能夠直接拿來看的不珍惜，而且喜歡去買什么書籍，學什么視頻？Java 剛出來的時候，沒書籍，那些初學的大神不是看的文檔么？Android 剛出來的時候，沒有書籍，他們不是看的文檔么？文檔你們都不讀，而是去看那些通過學習文檔成為大神而出的書籍和視頻。
我發現身邊很多程序員朋友，在開發的過程中遇到問題的第一時間是去找度娘和 Google ，而不是查文檔。你說這文檔是寫給誰看的？跟個擺設，古董物件似的。這么一說的話，我們程序員都是不懂古董的收藏家，只收藏，不欣賞。
我只是弱弱的想問一句：你們有這個嚴重的問題么？有的話，歡迎大家留言交流。
