公司招人的目的是讓你完成任務的，這是終極目標。至於具體的過程，各有各的方法，不是那麼重要的。

作為程式設計師，就是把專案功能說明書轉換成程式碼，實現客戶的要求。文件不但要看，而且要深入的理解專案的記憶體邏輯才行，只有這樣才能完美的實現專案要求。而且在程式設計的過程中，有可能會發現專案需求邏輯或功能上的錯誤，這時候還要透過專案經理與客戶溝通，對說明文件進一步修改。

如果是嵌入式軟體工程師的話，還需要看與硬體相關的說明書，這些都需要大量的閱讀，可以說，文件的閱讀是貫穿整個程式編寫過程的。

任何專案文件最重要了，時間久了，就算自己做的，也需要藉助文件才能做好維護修改工作，it 行業人員流動頻繁，沒相關文件，接手的過程將是漫長而痛苦的。

工作不是閉卷考試，只要你能比別人做的好，還高效。你就是人才。公司鼓勵看文件，規範，更專業一定不會有錯。除非你安排的任務完不成。但是對於努力學習的人，肯定會鼓勵的，但是能交多少成果拿多少錢。過程只要不違反犯罪，怎麼樣都根本不重要。

一個程式設計師在上班的時候當然可以看文件。在程式設計過程中遇到一些瓶頸，需要透過查詢文件來解決，但是你說的大量看文件是什麼意思？如果理解為只看文件，不動手寫程式。那我只能認為這個程式設計師的工作方式有問題，或者說是個菜鳥。因為一篇文件當中每一個字都是精華，但是這些精華在某一時刻只有那麼一兩句是對你有用的。你應該學會抓住重點。舉一個我舅舅的例子，我舅舅當時在供銷社工作，是供銷社會計室的一名會計，在九幾年剛剛實行增值稅發票的時候，所有的會計師都在研究增值稅發票方面的財務知識。只有我舅舅一個人抓住了重點，他說在有普通發票改成增值稅發票的過程當中，只要你抓住了期初庫存這樣的一個關鍵點，下面你的賬就好做了。我不是會計人員，不太懂他的意思。但是他們使用了他的方法之後，漲做得又快又好，第二年他成了會計室的主任。所以在工作中抓重點非常重要。遇到這種花一天的時間在看文件，看的暈頭轉向，程式碼不寫一行的程式設計師，我看你的方式有問題。

劍客要常看劍譜，琴師要常看樂譜，廚師要常翻菜譜，不為別的，就是要爛熟於胸。一本書看一遍叫過眼，看兩遍叫復讀，看百遍才敢稱略通。怎麼程式設計師看個文件還要提問？

開發文件是程式設計師必備伴侶，不會看文件的程式設計師才是沒有成長的菜鳥不是嗎？不僅要大量得看，還要廣泛的看我覺得才能不斷在現有演算法中找到最優解決方案。

常看文件是個好習慣。

幾百頁的文件，好幾本，就放在手頭。“開工前”，準備文件又寫了好幾遍，也有幾百頁吧。

這種開發工作，與現場編寫使用者業務流程真的有很大不同。

這是個典型的偽命題！因為你要是不讓他大量查文件，那麼他要麼工效低，要麼盯著螢幕發呆。請問這樣的人企業聘來幹啥？你如果讓他大量查文件，肯定浪費大量的工作時間，而且因為不熟練，交付的東西肯定質量好不到哪裡去，同樣工效低，這樣的人哪家企業願意用？所以，這樣的程式設計師肯定是要下課的，現實不會出現。如果有，他們也一定得將勤補拙，笨鳥先飛，多多利用業餘時間來提升自己，趕工作進度，否則下課不可避免。

在實際工作中，程式設計師是必須嚴格按照文件來程式設計序的，不允許不看或不按照文件要求來程式設計序，文件就是程式的靈魂，比較重要的文件有：需求說明，設計說明，api手冊，硬體使用手冊，程式設計規範，大公司裡還會分得更細，程式寫完同行評審的依據就是你的code和document之間是不是文實相符，你說要不要要看文件，最好是配兩個屏，一個程式碼，一個手冊

程式設計師就是用文件來交流的，無論看什麼型別的文件。只要看不懂的就要看，不看完成不了開發任務，到後面吃虧還是自己。

這問題真有趣，不給開發人員看，那麼為寫文件而死的腦細胞豈不是死的太冤了？你特麼以為文件是誰寫的？還是開發人員寫的！

如果你永遠做某些低檔的工作就不需要看說明，如果你經常做前沿或超越的工作不看說明你是神仙啊？經常看說明一般說明你的工作處於上升狀態。

沒有允許不允許之說，看你做出來的質量好壞，誰管你看什麼，你是不是書呆子？問出這樣的問題換我是老闆你給我滾蛋回家。

之所以有些程式設計師能夠不看說明文件，也不用查各種谷歌、百度，那是因為熟能生巧罷了。

在不熟練的時候，看說明文件，各種搜尋，不能說是不正常的工作狀態。

當然，能夠記住的話，對於整體開發效率會提高不少，但並不是必要條件。

先說觀點，我認為看文件沒什麼問題，但是“大量”這個程度很難衡量，按照需要看文件是個非常重要的事情。

接手一個專案，需要透過文件來了解整個專案的架構、介面、規範等等，這是必須要花費的時間。不然在不瞭解專案的情況下貿然去做需求，不見得會好，反而會事倍功半。

使用一個新的框架或語言。當大資料剛開始興起的時候，不見得人人都會hadoop，如果你需要完成一個使用Hadoop的專案，自然需要花費大量的時間學習Hadoop的使用，MapReduce任務的編寫等等。那現在機器學習、深度學習的興起，如果要使用Tensorflow等框架進行模型開發的話，也是有學習成本的。我現在使用tensorflow的時候，也時不時的回去查API文件，不然這麼多API，版本更新又快，靠記憶很難準確的記住全部介面的功能、用法之類的東西。

程式語言的基礎用法：這個很好理解，如果隨便寫個程式碼都要靠百度，那麼這個工程師是不合格的。

基礎演算法：比如工作中需要實現一些排序演算法、資料結構等，如果還要靠查書籍、文件、搜尋引擎等，那麼這個工程師也是不太合格的。

在工作中閱讀文件其實也是工作內容的一部分，而且現在大多數網際網路公司都靠KPI進行考核，平時就算你把時間都用來看文件沒關係，最後KPI沒完成一樣會被公司淘汰。所以公司不會阻攔你花費時間看文件，最多你老闆會提醒你浪費這麼多時間看文件而沒有實際的產出會對你年終考核造成影響罷了。

程式設計師上班的主要工作就是看說明文件，根據說明文件編碼。如果實在沒有說明文件，有時還得親自披掛上陣寫說明文件。

寫介面的有API文件，寫通訊協議的有協議欄位說明文件，寫資料庫的有資料庫規範文件，

總之任何一個大公司文件扮演的一個至關重要的問題，因為形不成文件，公司管理就會陷入混亂不堪的局面，當某個核心員工離職後，下一個接盤的程式設計師會丈二和尚摸不著頭腦，一頭霧水，邊填坑邊罵娘，有了文件就可以看文件結合程式碼，瞭解其中模組邏輯以及結構，包括哪些坑不能踩等等好處。有些公司會專門有文件工程師這個職位來專門負責整理各種文件，並且儲存在伺服器上。

好的文件都是程式設計師等人智慧的結晶，是一盞指路明燈，是一條通往光明的道路。程式設計師不能看說明文件等於在黑暗裡摸爬滾打，有了說明文件才迎來了黎明的曙光。

首先，沒有一個公司的程式碼是由一個工程師寫的，就算是由一個人寫的，一般程式碼的規模是很大的，時間一久一個人勢必對程式碼的細節會有疏漏和記不清。所以，文件是必要的。不給看文件會導致工作效率大幅度提升，你想鬼知道介面的正確使用方法，不看文件出了問題查也很花時間！

好的公司都有很全的文件提供給工程師和合作夥伴，說到底，軟體工程師一個集體開發的工作，協作才是最重要的！

先開個玩笑，提此問題的兄弟或許是軟體公司主管，或者是一家小軟體公司的老闆，或者是剛被領導剋了的程式設計師，不知猜對了否？呵呵

首先給個結論，上班時間花大把的時間看程式設計說明文件不可取，尤其是那些拿著高薪的資深程式設計師。

現在各行各業都不容易，對軟體企業而言，時間就是金錢，效率就是生命，更是如此。公司請你來是幹活的，要以比競爭對手更快的速度做出更好的產品，而不能把寶貴的上班時間浪費在看程式設計說明書上。

實際工作中程式設計師或多或少會在工作時間看說明，工作不是很緊張或時間不長或者是新手問題都不大，難免。但是時間長了領導和老闆會留意的，有時他們不一定直接說出來，但心目中會對你留下一個不好的映像，轉正加薪提升可能在不知不覺中受到影響。

但是，對於新的語言或開發技術，的確需要看看SDK手冊或程式範例，怎麼辦？建議大家自己辛苦下，下班週末等業餘時間利用起來，或者下班後有意識的加加班，這時看說明就沒什麼問題了。

還有就是儘量邊幹邊學，在戰鬥中快速成長，不必讓人家看到專門拿時間去正經八百地看說明。

作為程式設計師，快速學習、快速上手是必備的基本功，練就此功後就沒必要在上班時間專門看說明了。

也許我上面的回答讓有些年輕的朋友覺得是不是太小氣，搞得連學習時間都不給。沒辦法，現實就是這樣，想在公司快速冒尖，只能對自己狠一點，快速成長起來後你回發現，你的一切努力絕對是值得的。

2018.3.5夜於武昌

我們弄清楚主次。

程式設計師上班，對公司，對老闆而言最重要的產出是什麼？是可工作的程式碼，可工作的程式碼，可工作的程式碼。

好了，目標確定了，衡量指標也就確定了，只要你能產出了計劃的可工作程式碼。

不論你是看大量文件來幫助的，還是你本身就很熟悉直接寫出來的，我覺得都可以。

不是有那麼一句話麼，只看一些文件就寫程式碼的人，不是菜鳥就是高手。

本人作為一個技術管理人員，分享下我的看法，首先你這個問題有點不對，也少了前題條件。看說明文件基本都是允許的！我覺得問題側重點應是：應不應該。

對於新技術或攻關類專案，大量閱讀文件是家常便飯，同樣對於新人來說，這也無可厚非。對於管理人員，在意的是學習能力、團隊溝通能力、獨立解決問題能力，所以對於有經驗的開發人員，能看文件能解決問題的，還是能接受的，但是經常性看了文件都解決不了問題就另當別論，另外，假如同樣的知識點，使用很久仍沒消化，嚴重依賴文件的，那就是學習能力或態度問題，值得反思，多少會影響管理層對你的評分。

不但允許，而且鼓勵多看文件，特別是官方文件。文件在程式設計的作用和教科書不太一樣，它提供的是一種程式需要，或者某個模組，甚至某個功能的完整說明。

程式設計師不到要多看文件還要自己寫，讓其他程式設計師能夠透過文件瞭解你的程式結構，思路，還有應用方法自己現存什麼問題。

題主的問題一看就是從“考試能不能看書”這個角度出發的，寫程式不是考試，程式設計師也無需去大量記憶文件，需要的時候現查即可。很多常用的函式一些程式設計師已經用的爛熟，但是你要他們完整說出函式每個引數的定義，每個定義代表的含義，不一定都能說出來。