Celiaki
小七，前端工程師，關注我一起學代碼，每天都有乾貨。
這個問題怎麼說呢，開發過程中會遇到各種各樣的問題，沒有一個人是全能的，也沒有人可以絕對的說自己在整個項目中不會遇到一點問題，不去查東西，自己大腦裡的東西完全可以讓我把這個項目測測底底的做完，並且沒有任何bug。
上班的時間，也沒有老闆或者誰在後面一直看著你去做東西，大家都挺忙。文檔是幹嘛的，文檔本身就是用來看的，甚至很多項目開始之前，總監都會讓你去搜集一些這個項目可能會遇到的bug，可能會用到的效果，儘量在之前找到比較好用的插件，這樣會節省很多時間，自己如果寫代碼的話不可能百分百的確定沒有人和bug，但插件不一樣很多插件都是前輩通過很長時間慢慢完善出來的插件，所以很多人才會用。所以你提問的可以肯定的回答你允許。
哎吆喂網絡前端
先開個玩笑，提此問題的兄弟或許是軟件公司主管，或者是一家小軟件公司的老闆，或者是剛被領導剋了的程序員，不知猜對了否？呵呵
首先給個結論，上班時間花大把的時間看編程說明文檔不可取，尤其是那些拿著高薪的資深程序員。
現在各行各業都不容易，對軟件企業而言，時間就是金錢，效率就是生命，更是如此。公司請你來是幹活的，要以比競爭對手更快的速度做出更好的產品，而不能把寶貴的上班時間浪費在看編程說明書上。
實際工作中程序員或多或少會在工作時間看說明，工作不是很緊張或時間不長或者是新手問題都不大，難免。但是時間長了領導和老闆會留意的，有時他們不一定直接說出來，但心目中會對你留下一個不好的映像，轉正加薪提升可能在不知不覺中受到影響。
但是，對於新的語言或開發技術，的確需要看看SDK手冊或程序範例，怎麼辦？建議大家自己辛苦下，下班週末等業餘時間利用起來，或者下班後有意識的加加班，這時看說明就沒什麼問題了。
還有就是儘量邊幹邊學，在戰鬥中快速成長，不必讓人家看到專門拿時間去正經八百地看說明。
作為程序員，快速學習、快速上手是必備的基本功，練就此功後就沒必要在上班時間專門看說明了。
也許我上面的回答讓有些年輕的朋友
覺得是不是太小氣，搞得連學習時間都不給。沒辦法，現實就是這樣，想在公司快速冒尖，只能對自己狠一點，快速成長起來後你回發現，你的一切努力絕對是值得的。
2018.3.5夜於武昌
軟件之道
首先，我不是程序員，我是一個設計工作者，不過我來說一下我的觀點：很多人以為程序員像電影裡的一樣，啪啪啪幾下鍵盤，屏幕數據颼颼的變，其實真實情況是程序員寫代碼就像學生寫作文，也會遇到不會的詞語跟修辭手法，那這個時候就要停下來想一想，查一查，看看例子是怎樣寫的怎樣用的，寫錯了還要劃掉（刪掉）再來，至於這個大量不大量看的情況，如果這個是個新手，那肯定是可以的，那如果是個老手，還需要大量時間查說明文檔，那就說明這個項目肯定不會小，不是一兩天能做完的，那一個用月做單位的項目，用一個天做單位的時間來查文檔，不過分吧！程序員也是人，不是因為他的工作高端，就覺得這個人萬能，他也會當機，要吃飯，要休息，也會忘記一些東西，所以請各位多多體諒，能一起工作實屬不易，感恩2018，謝謝。
好人王小明
當然允許看文檔。
要知道，隨便哪個類庫，都有無數的類和方法，每個方法又有若干參數，鬼知道它們都是什麼意思，誰的腦子能記得那麼多內容。別說是人家提供的類庫，就是自己寫的代碼，過一段時間也不記得什麼意思了。沒有註釋和文檔，怎麼看懂代碼？
如果沒有需求分析文檔，程序員怎麼理解正在開發的這個軟件的基本業務流程？
如果沒有架構設計文檔，程序員怎麼理解軟件各個功能模塊之間的功能與業務邏輯？
如果沒有接口文檔，那麼多類和方法，都怎麼調用，會返回什麼值，難道靠猜？
……
在日常開發工作中，不僅允許看文檔，還會強迫你寫文檔。如果你寫的文檔別人看不懂，別怪領導罵你不認真。文檔對於軟件開發的重要性是不言而喻的。
還有一個秘密告訴你，那些經常寫文檔的程序員，要比不寫文檔的程序員工資更高。
真的！！！
迎娶白富美，從會寫文檔開始！
學習考試系統
程序員日常開發工作，基本是上離不開閱讀文檔，這也是很多程序員喜歡兩個顯示器的原因。
項目方面
架構文檔：這個是進入一個新項目之後，最快了解項目的方法，也是從宏觀瞭解項目的最佳途徑。
設計文檔：其實設計文檔很多項目都是缺少的，我的建議是設計文檔可以不用寫的很正式，但設計的思路最好可以存留。
需求文檔：沒有需求文檔，沒辦法開發吧。開發的過程中，也要不斷地、反覆的閱讀需求文檔，甚至有可能在開發的時候發現需求不合理的地方。
技術方面
是不是很多人都認為，如果在開發過程中，還要不斷地翻技術文檔，說明他的開發能力不紮實。其實不是這樣的。
首先IT行業技術升級換代的速度太快，當我們大多數公司還在用Java8的時候，Java11都已經出來了。如果非得要程序員熟知每一個類、每一個方法，是很不現實的。
很多時候我們只需要瞭解有這麼一個東西，作用是幹什麼的，具體的細節可以在用的時候再去翻文檔，比如方法名字是什麼？參數有幾個，都是什麼類型的？
所以我們都習慣至少兩個電腦屏幕，一個屏幕寫代碼，一個屏幕看文檔；如果豪一些的話，再加一個屏幕展示日誌信息。
看文檔的屏幕要買豎屏！
我們團隊
我這幾年也帶過幾個團隊，對於每個團隊成員，我對他們的要求是：實現需求的前提下，最好能對所用的技術有一定的瞭解，千萬不要從網上抄過來一段代碼就用，這樣是很危險的行為。所以鼓勵大家多找一些資料，最好是閱讀框架的官方文檔。
現在的團隊，我已經這樣要求了：代碼寫累了，或者覺得自己沒有狀態寫代碼，可以找點兒自己有興趣的技術文檔學習學習，這個技術甚至是可以跟現在的項目沒有關係的。
會點代碼的大叔
兄dei，假設你是程序員，你在寫程序時，旁邊會有人守著你嗎？
假設你不是程序員，你在做本職工作時，旁邊會有人守著你看你怎麼做事嗎？
答案肯定是沒有的。誰會閒著招個人去監督你，看你用什麼方式去完成給你的任務。
現在不管是大公司還是小公司，沒有人會在意你怎麼去完成你的工作，給你的任務，在很多時候，大家只關注結果。如果說有干預，最多隻是實現的方式。像寫程序，假設有個功能是即時通訊相關的，這種自己寫需要的時間成本投入較高，那麼很多公司就會選擇採用市面上比較穩定的第三方平臺。這算一種實現方式的干預。但是在接入的過程中，不會有人去管你是通過閱讀第三方SDK文檔，還是谷歌搜出來的，最後能達到預期效果就ok了
所以，其實你看不看大量文檔，沒有人會在乎，關鍵是你自己，建議自己寫東西時，不要一味的複製粘貼，要有自己的想法。太依賴文檔對於自己成長很不利
安之5
本人作為一個技術管理人員，分享下我的看法，首先你這個問題有點不對，也少了前題條件。看說明文檔基本都是允許的！我覺得問題側重點應是：應不應該。
對於新技術或攻關類項目，大量閱讀文檔是家常便飯，同樣對於新人來說，這也無可厚非。對於管理人員，在意的是學習能力、團隊溝通能力、獨立解決問題能力，所以對於有經驗的開發人員，能看文檔能解決問題的，還是能接受的，但是經常性看了文檔都解決不了問題就另當別論，另外，假如同樣的知識點，使用很久仍沒消化，嚴重依賴文檔的，那就是學習能力或態度問題，值得反思，多少會影響管理層對你的評分。
IT晴天看世界
程序員上班的主要工作就是看說明文檔，根據說明文檔編碼。如果實在沒有說明文檔，有時還得親自披掛上陣寫說明文檔。
寫接口的有API文檔，寫通訊協議的有協議字段說明文檔，寫數據庫的有數據庫規範文檔，
總之任何一個大公司文檔扮演的一個至關重要的問題，因為形不成文檔，公司管理就會陷入混亂不堪的局面，當某個核心員工離職後，下一個接盤的程序員會丈二和尚摸不著頭腦，一頭霧水，邊填坑邊罵娘，有了文檔就可以看文檔結合代碼，瞭解其中模塊邏輯以及結構，包括哪些坑不能踩等等好處。有些公司會專門有文檔工程師這個職位來專門負責整理各種文檔，並且保存在服務器上。
好的文檔都是程序員等人智慧的結晶，是一盞指路明燈，是一條通往光明的道路。程序員不能看說明文檔等於在黑暗裡摸爬滾打，有了說明文檔才迎來了黎明的曙光。
電視鵬
這個問題要根據具體開發的功能模塊來看，不過原則來說，花大量的時間看說明文檔，至少給人的印象是經驗不夠豐富，開發能力有待提高。
具體來說，如果是普通的功能開發，技術挑戰不大，這種如果還要看文檔，會被認為是開發能力問題。如果是有一定的技術挑戰，公司在這方面的積累比較少，開發團隊也對此有共識，這種問題看文檔無可厚非，當然如果能業餘時間學習相關的知識，會給團隊留下開發能力強的印象。對於一些前瞻性研究，公司沒有任何技術積累，或者全新的技術方向，這個看說明文檔是加分的，甚至可以要求公司購買相關書籍或者在線培訓，當然，自己啃下來會更NB。
麗莎公主的爸比
題主對文檔的定義不是很明確
第一個是需求說明文檔
這個是在開發過程中必不可少的文檔，只有清楚了開發需求，程序員高效率的開發，程序員一天的工作時間並不是都是在寫代碼，而是在看文檔，瞭解需求，理清思路，只有什麼都清楚了，寫代碼或許只要十幾分鍾。
再者對於一個項目新人來說不看文檔瞭解需求，沒人給你從頭到尾的在講一遍需求，你不看文檔自己發揮？進入項目是和別人共同開發，你不肯能不顧及之前的代碼規範。
第二個是開發文檔
就拿微信開發來說，微信開發不是每個程序員必須會的東西，但是用到了怎麼辦，還不是去看他們的開發文檔，只有將開發文檔思路理清楚了，才可以進行下一步開發。
第三個是API文檔
在前後端分離的開發模式中API文檔是必不可少的文檔。不看API不知道數據是什麼樣。也就是不可能順利的和後端進行結合。
