Celiaki
先說觀點，我認為看文檔沒什麼問題，但是“大量”這個程度很難衡量，按照需要看文檔是個非常重要的事情。
需要花費時間的情況
接手一個項目，需要通過文檔來了解整個項目的架構、接口、規範等等，這是必須要花費的時間。不然在不瞭解項目的情況下貿然去做需求，不見得會好，反而會事倍功半。
使用一個新的框架或語言。當大數據剛開始興起的時候，不見得人人都會hadoop，如果你需要完成一個使用Hadoop的項目，自然需要花費大量的時間學習Hadoop的使用，MapReduce任務的編寫等等。那現在機器學習、深度學習的興起，如果要使用Tensorflow等框架進行模型開發的話，也是有學習成本的。我現在使用tensorflow的時候，也時不時的回去查API文檔，不然這麼多API，版本更新又快，靠記憶很難準確的記住全部接口的功能、用法之類的東西。
不需要花費大量時間的情況
編程語言的基礎用法：這個很好理解，如果隨便寫個代碼都要靠百度，那麼這個工程師是不合格的。
基礎算法：比如工作中需要實現一些排序算法、數據結構等，如果還要靠查書籍、文檔、搜索引擎等，那麼這個工程師也是不太合格的。
小結
在工作中閱讀文檔其實也是工作內容的一部分，而且現在大多數互聯網公司都靠KPI進行考核，平時就算你把時間都用來看文檔沒關係，最後KPI沒完成一樣會被公司淘汰。所以公司不會阻攔你花費時間看文檔，最多你老闆會提醒你浪費這麼多時間看文檔而沒有實際的產出會對你年終考核造成影響罷了。
深空智能
一個程序員在上班的時候當然可以看文檔。在編程過程中遇到一些瓶頸，需要通過查詢文檔來解決，但是你說的大量看文檔是什麼意思？如果理解為只看文檔，不動手寫程序。那我只能認為這個程序員的工作方式有問題，或者說是個菜鳥。因為一篇文檔當中每一個字都是精華，但是這些精華在某一時刻只有那麼一兩句是對你有用的。你應該學會抓住重點。舉一個我舅舅的例子，我舅舅當時在供銷社工作，是供銷社會計室的一名會計，在九幾年剛剛實行增值稅發票的時候，所有的會計師都在研究增值稅發票方面的財務知識。只有我舅舅一個人抓住了重點，他說在有普通發票改成增值稅發票的過程當中，只要你抓住了期初庫存這樣的一個關鍵點，下面你的賬就好做了。我不是會計人員，不太懂他的意思。但是他們使用了他的方法之後，漲做得又快又好，第二年他成了會計室的主任。所以在工作中抓重點非常重要。遇到這種花一天的時間在看文檔，看的暈頭轉向，代碼不寫一行的程序員，我看你的方式有問題。
崔傑8476
小七，前端工程師，關注我一起學代碼，每天都有乾貨。
這個問題怎麼說呢，開發過程中會遇到各種各樣的問題，沒有一個人是全能的，也沒有人可以絕對的說自己在整個項目中不會遇到一點問題，不去查東西，自己大腦裡的東西完全可以讓我把這個項目測測底底的做完，並且沒有任何bug。
上班的時間，也沒有老闆或者誰在後面一直看著你去做東西，大家都挺忙。文檔是幹嘛的，文檔本身就是用來看的，甚至很多項目開始之前，總監都會讓你去搜集一些這個項目可能會遇到的bug，可能會用到的效果，儘量在之前找到比較好用的插件，這樣會節省很多時間，自己如果寫代碼的話不可能百分百的確定沒有人和bug，但插件不一樣很多插件都是前輩通過很長時間慢慢完善出來的插件，所以很多人才會用。所以你提問的可以肯定的回答你允許。
哎吆喂網絡前端
你好 做程序員肯定要看文檔，不僅要看，還要熟悉文檔中內容。我做程序員九年了，我來說說我們平時工作有哪些文檔要熟悉。
無論是項目還是產品，相關文檔必不可少。主要文檔有需求分析說明書（需求設計原型說明書）、數據庫設計說明、接口設計說明書、概要設計說明書、詳細設計說明書、用戶使用說明書、系統測試報告、安裝部署手冊、系統運維手冊等文檔。這些文檔對於一個項目來說都是必備的。 
對於程序員來說：這些文檔要麼出自你們手中，要麼讀的滾瓜爛熟。下面說說這些文檔，程序員在其中擔當的角色。
需求分析說明書，一個軟件的功能點，業務流程全在這個文檔，程序員想要實現軟件的所有功能和業務流程，必須熟讀需求分析說明書。並將文檔中文字描述變成對應功能點。這幾年技術發展很快，好多項目直接將需求分析說明書轉化成了功能原型圖。這樣比之前方便多了，直接設計軟件功能點給客戶看，讓客戶提前知道自己想要什麼樣展示效果。最後出需求設計說明書。程序員只要按照文檔中的截圖實現功能即可。
數據庫設計說明書，這個文檔出自程序員之手，軟件功能點對應的數據庫名稱、表名稱、表字段、表與表之間的關聯關係、E-R圖等等，全在這個文檔中體現。程序員要寫代碼之前，必須要完成這些功能，並出這份文檔。
接口設計說明書，接口設計對一個軟件來說，非常重要。接口設計的合理性，去耦合度與否，直接決定軟件好不好開發，好不好用。同樣出自程序員之手。
概要設計和詳細設計說明書，這兩份文檔都是介紹軟件架構設計，同時也包括數據庫設計、接口設計部分。有這兩份文檔為軟件二次開發，功能調整提供技術說明。 無一例外也是出自程序員。
剩餘幾個文檔是由產品設計、軟件測試、運維實施等完成。程序員只負責軟件研發過程中的文檔。這些文檔是軟件上線後，運維人員開展工作的依據。
對於程序員來說，寫代碼重要，熟讀文檔，領悟業務流程更重要。
說了這麼多，大家有疑惑，可以關注我，私信我，謝謝大家！！
紅臉濤哥
工作後你就會發現，不是在百度、Google，就是在doc上，一邊看，一邊複製粘貼，修修改改[大笑]
歪程序猿
兄dei，假設你是程序員，你在寫程序時，旁邊會有人守著你嗎？
假設你不是程序員，你在做本職工作時，旁邊會有人守著你看你怎麼做事嗎？
答案肯定是沒有的。誰會閒著招個人去監督你，看你用什麼方式去完成給你的任務。
現在不管是大公司還是小公司，沒有人會在意你怎麼去完成你的工作，給你的任務，在很多時候，大家只關注結果。如果說有干預，最多隻是實現的方式。像寫程序，假設有個功能是即時通訊相關的，這種自己寫需要的時間成本投入較高，那麼很多公司就會選擇採用市面上比較穩定的第三方平臺。這算一種實現方式的干預。但是在接入的過程中，不會有人去管你是通過閱讀第三方SDK文檔，還是谷歌搜出來的，最後能達到預期效果就ok了
所以，其實你看不看大量文檔，沒有人會在乎，關鍵是你自己，建議自己寫東西時，不要一味的複製粘貼，要有自己的想法。太依賴文檔對於自己成長很不利
安之5
程序員日常開發工作，基本是上離不開閱讀文檔，這也是很多程序員喜歡兩個顯示器的原因。
項目方面
架構文檔：這個是進入一個新項目之後，最快了解項目的方法，也是從宏觀瞭解項目的最佳途徑。
設計文檔：其實設計文檔很多項目都是缺少的，我的建議是設計文檔可以不用寫的很正式，但設計的思路最好可以存留。
需求文檔：沒有需求文檔，沒辦法開發吧。開發的過程中，也要不斷地、反覆的閱讀需求文檔，甚至有可能在開發的時候發現需求不合理的地方。
技術方面
是不是很多人都認為，如果在開發過程中，還要不斷地翻技術文檔，說明他的開發能力不紮實。其實不是這樣的。
首先IT行業技術升級換代的速度太快，當我們大多數公司還在用Java8的時候，Java11都已經出來了。如果非得要程序員熟知每一個類、每一個方法，是很不現實的。
很多時候我們只需要瞭解有這麼一個東西，作用是幹什麼的，具體的細節可以在用的時候再去翻文檔，比如方法名字是什麼？參數有幾個，都是什麼類型的？
所以我們都習慣至少兩個電腦屏幕，一個屏幕寫代碼，一個屏幕看文檔；如果豪一些的話，再加一個屏幕展示日誌信息。
看文檔的屏幕要買豎屏！
我們團隊
我這幾年也帶過幾個團隊，對於每個團隊成員，我對他們的要求是：實現需求的前提下，最好能對所用的技術有一定的瞭解，千萬不要從網上抄過來一段代碼就用，這樣是很危險的行為。所以鼓勵大家多找一些資料，最好是閱讀框架的官方文檔。
現在的團隊，我已經這樣要求了：代碼寫累了，或者覺得自己沒有狀態寫代碼，可以找點兒自己有興趣的技術文檔學習學習，這個技術甚至是可以跟現在的項目沒有關係的。
會點代碼的大叔
說個我遇到的2個真事吧，
第一個，公司找的外包公司寫項目程序，已經要交付了，發現有幾個功能沒做，產品經理和開發那邊都找我，我一個搞運維的又不懂，只能讓他們去對開發文檔，我也就順便看了看，開發文檔中明確的寫明怎麼做，然後就讓他們就重新按開發文檔繼續寫，
另一個，由於歷史原因業務系統處於託管狀態，只有部分參考文檔可用，開發那邊只能按當前已有文檔進行開發參考，開發那邊也一直在根據現有相關文檔進行開發，杯具的是這幫子不仔細看，有問題總想著我能直接給他們答案，我也只是會用而已，開發我還真搞不來，然後和他們一起看開發文檔，加密算法部分給她們指出後，問題解決了。
所以我覺得，開發團隊在開發中很有必要閱讀開發文檔，這可以避免繞圈子，也會清楚開發文檔中提供的內容。
仞渣不渣
劍客要常看劍譜，琴師要常看樂譜，廚師要常翻菜譜，不為別的，就是要爛熟於胸。一本書看一遍叫過眼，看兩遍叫復讀，看百遍才敢稱略通。怎麼程序員看個文檔還要提問？
開發文檔是程序員必備伴侶，不會看文檔的程序員才是沒有成長的菜鳥不是嗎？不僅要大量得看，還要廣泛的看我覺得才能不斷在現有算法中找到最優解決方案。
常看文檔是個好習慣。
匠心1123
在實際工作中，程序員是必須嚴格按照文檔來編程序的，不允許不看或不按照文檔要求來編程序，文檔就是程序的靈魂，比較重要的文檔有：需求說明，設計說明，api手冊，硬件使用手冊，編程規範，大公司裡還會分得更細，程序寫完同行評審的依據就是你的code和document之間是不是文實相符，你說要不要要看文檔，最好是配兩個屏，一個代碼，一個手冊
