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