1. 將資料按照技術類和管理類文檔分類.並寫出技術類和管理類文檔的區別
一、 建築工程資料的分類與編號
（一）建築工程資料分類的原則
建築工程資料的分類是按照文件資料的來源、類別、形成的先後順序及收集和整理單位的不同，來進行分類的，以便於資料的收集、整理、組卷。
從事體上把全部的資料劃分為4大類，即分為建設單位的文件資料、監理單位的文件資料、施工單位的文件資料、竣工圖資料。其中，建設單位的文件資料又劃分為立項文件、建設規劃用地文件、勘察設計文件、工程招投標及文件、工程開工文件、商務文件、工程竣工驗收及備案文件、其他文件等8小類；監理單位的文件資料劃分為監理管理資料、監理質量控制資料、監理進度控制資料、監理造價控制資料等4小類；施工單位的文件資料劃分為施工管理資料、施工技術資料、施工物資資料、施工測量記錄、施工記錄、隱蔽工程檢查驗收記錄、施工檢測資料、施工質量驗收記錄、單位（子單位）工程竣工驗收資料等9小類；竣工圖資料劃分為綜合竣工圖、室外專業竣工圖、專業竣工圖等3小類。在每一小類中，再細分為若干種文件、資料、或表格，見表1-1.
2.施工資料的分類應根據類別和專業系統來劃分。
參見表1-1及《建設工程文件歸檔整理規范》GB/T50328-2001、《建築工程施工質量驗收統一標准》GB 50300-2001。
3.施工資料的分類、整理和保存除執行《建設工程文件歸檔整理規范》或地方標准及規程外，尚應執行相應的國家法律法規及行業或地方的有關規定。
（二）建築工程資料編號的方法
對各大類的編號
分別大寫的英文字母「A」、「B」、「C」、「D」來表示建設單位的文件資料、監理單位的文件資料、施工單位的文件資料。即分別編為A類、B類、C類、D類等4大類資料。
2.對各小類的編號
對於A類資料中所含的8小類資料，分別按照A1、A2、A3、A4、A5、A6、A7、A8的順序來依次排列編號；B類資料中所含的4小類資料，分別按照B1、B2、B3、B4的順序來依次排列編號；C類資料中所含的9小類資料，分別按照C1、C2、C3、C4、C5、C6、C7、C8、C9的順序來依次排列編號； D類資料中所含的3小類資料，分別按照D1、D2、D3的順序來依次排列編號，見表1-1.
1. 對具體文件、資料或表格的編號
在每一小類中，再仔細分的若干種類的文件、資料彧表格等的編號。按如則編號。若是A1中的第9種資料，就編號為A1-09，如果是B2中的第10個種資料，就編號為B2-10,見表1-1.
2. 程序員在上班時，允不允許大量的看說明文檔來幫助寫程序
程序員日常開發工作，基本是上離不開閱讀文檔，這也是很多程序員喜歡兩個顯示器的原因。
項目方面
技術方面
是不是很多人都認為，如果在開發過程中，還要不斷地翻技術文檔，說明他的開發能力不扎實。其實不是這樣的。
首先IT行業技術升級換代的速度太快，當我們大多數公司還在用Java8的時候，Java11都已經出來了。如果非得要程序員熟知每一個類、每一個方法，是很不現實的。
很多時候我們只需要了解有這么一個東西，作用是干什麼的，具體的細節可以在用的時候再去翻文檔，比如方法名字是什麼？參數有幾個，都是什麼類型的？
所以我們都習慣至少兩個電腦屏幕，一個屏幕寫代碼，一個屏幕看文檔；如果豪一些的話，再加一個屏幕展示日誌信息。
看文檔的屏幕要買豎屏！
我們團隊
我這幾年也帶過幾個團隊，對於每個團隊成員，我對他們的要求是：實現需求的前提下，最好能對所用的技術有一定的了解，千萬不要從網上抄過來一段代碼就用，這樣是很危險的行為。所以鼓勵大家多找一些資料，最好是閱讀框架的官方文檔。
現在的團隊，我已經這樣要求了：代碼寫累了，或者覺得自己沒有狀態寫代碼，可以找點兒自己有興趣的技術文檔學習學習，這個技術甚至是可以跟現在的項目沒有關系的。
首先，我不是程序員，我是一個設計工作者，不過我來說一下我的觀點：很多人以為程序員像電影里的一樣，啪啪啪幾下鍵盤，屏幕數據颼颼的變，其實真實情況是程序員寫代碼就像學生寫作文，也會遇到不會的詞語跟修辭手法，那這個時候就要停下來想一想，查一查，看看例子是怎樣寫的怎樣用的，寫錯了還要劃掉（刪掉）再來，至於這個大量不大量看的情況，如果這個是個新手，那肯定是可以的，那如果是個老手，還需要大量時間查說明文檔，那就說明這個項目肯定不會小，不是一兩天能做完的，那一個用月做單位的項目，用一個天做單位的時間來查文檔，不過分吧！程序員也是人，不是因為他的工作高端，就覺得這個人萬能，他也會當機，要吃飯，要休息，也會忘記一些東西，所以請各位多多體諒，能一起工作實屬不易，感恩2018，謝謝。
這個問題怎麼說呢，開發過程中會遇到各種各樣的問題，沒有一個人是全能的，也沒有人可以絕對的說自己在整個項目中不會遇到一點問題，不去查東西，自己大腦里的東西完全可以讓我把這個項目測測底底的做完，並且沒有任何bug。
上班的時間，也沒有老闆或者誰在後面一直看著你去做東西，大家都挺忙。文檔是幹嘛的，文檔本身就是用來看的，甚至很多項目開始之前，總監都會讓你去搜集一些這個項目可能會遇到的bug，可能會用到的效果，盡量在之前找到比較好用的插件，這樣會節省很多時間，自己如果寫代碼的話不可能百分百的確定沒有人和bug，但插件不一樣很多插件都是前輩通過很長時間慢慢完善出來的插件，所以很多人才會用。所以你提問的可以肯定的回答你允許。
程序員上班的主要工作就是看說明文檔，根據說明文檔編碼。如果實在沒有說明文檔，有時還得親自披掛上陣寫說明文檔。
寫介面的有API文檔，寫通訊協議的有協議欄位說明文檔，寫資料庫的有資料庫規範文檔，
總之任何一個大公司文檔扮演的一個至關重要的問題，因為形不成文檔，公司管理就會陷入混亂不堪的局面，當某個核心員工離職後，下一個接盤的程序員會丈二和尚摸不著頭腦，一頭霧水，邊填坑邊罵娘，有了文檔就可以看文檔結合代碼，了解其中模塊邏輯以及結構，包括哪些坑不能踩等等好處。有些公司會專門有文檔工程師這個職位來專門負責整理各種文檔，並且保存在伺服器上。
好的文檔都是程序員等人智慧的結晶，是一盞指路明燈，是一條通往光明的道路。程序員不能看說明文檔等於在黑暗裡摸爬滾打，有了說明文檔才迎來了黎明的曙光。
說個我遇到的2個真事吧，
第一個，公司找的外包公司寫項目程序，已經要交付了，發現有幾個功能沒做，產品經理和開發那邊都找我，我一個搞運維的又不懂，只能讓他們去對開發文檔，我也就順便看了看，開發文檔中明確的寫明怎麼做，然後就讓他們就重新按開發文檔繼續寫，
另一個，由於 歷史 原因業務系統處於託管狀態，只有部分參考文檔可用，開發那邊只能按當前已有文檔進行開發參考，開發那邊也一直在根據現有相關文檔進行開發，杯具的是這幫子不仔細看，有問題總想著我能直接給他們答案，我也只是會用而已，開發我還真搞不來，然後和他們一起看開發文檔，加密演算法部分給她們指出後，問題解決了。
所以我覺得，開發團隊在開發中很有必要閱讀開發文檔，這可以避免繞圈子，也會清楚開發文檔中提供的內容。
先說觀點，我認為看文檔沒什麼問題，但是「大量」這個程度很難衡量，按照需要看文檔是個非常重要的事情。
需要花費時間的情況 不需要花費大量時間的情況 小結
在工作中閱讀文檔其實也是工作內容的一部分，而且現在大多數互聯網公司都靠KPI進行考核，平時就算你把時間都用來看文檔沒關系，最後KPI沒完成一樣會被公司淘汰。所以公司不會阻攔你花費時間看文檔，最多你老闆會提醒你浪費這么多時間看文檔而沒有實際的產出會對你年終考核造成影響罷了。
題主對文檔的定義不是很明確
第一個是需求說明文檔
這個是在開發過程中必不可少的文檔，只有清楚了開發需求，程序員高效率的開發，程序員一天的工作時間並不是都是在寫代碼，而是在看文檔，了解需求，理清思路，只有什麼都清楚了，寫代碼或許只要十幾分鍾。
再者對於一個項目新人來說不看文檔了解需求，沒人給你從頭到尾的在講一遍需求，你不看文檔自己發揮？進入項目是和別人共同開發，你不肯能不顧及之前的代碼規范。
第二個是開發文檔
就拿微信開發來說，微信開發不是每個程序員必須會的東西，但是用到了怎麼辦，還不是去看他們的開發文檔，只有將開發文檔思路理清楚了，才可以進行下一步開發。
第三個是API文檔
在前後端分離的開發模式中API文檔是必不可少的文檔。不看API不知道數據是什麼樣。也就是不可能順利的和後端進行結合。
兄dei，假設你是程序員，你在寫程序時，旁邊會有人守著你嗎？
假設你不是程序員，你在做本職工作時，旁邊會有人守著你看你怎麼做事嗎？
答案肯定是沒有的。誰會閑著招個人去監督你，看你用什麼方式去完成給你的任務。
所以，其實你看不看大量文檔，沒有人會在乎，關鍵是你自己，建議自己寫東西時，不要一味的復制粘貼，要有自己的想法。太依賴文檔對於自己成長很不利
當然允許看文檔。
要知道，隨便哪個類庫，都有無數的類和方法，每個方法又有若干參數，鬼知道它們都是什麼意思，誰的腦子能記得那麼多內容。別說是人家提供的類庫，就是自己寫的代碼，過一段時間也不記得什麼意思了。沒有注釋和文檔，怎麼看懂代碼？
如果沒有需求分析文檔，程序員怎麼理解正在開發的這個軟體的基本業務流程？
如果沒有架構設計文檔，程序員怎麼理解軟體各個功能模塊之間的功能與業務邏輯？
如果沒有介面文檔，那麼多類和方法，都怎麼調用，會返回什麼值，難道靠猜？
……
在日常開發工作中，不僅允許看文檔，還會強迫你寫文檔。如果你寫的文檔別人看不懂，別怪領導罵你不認真。文檔對於軟體開發的重要性是不言而喻的。
還有一個秘密告訴你，那些經常寫文檔的程序員，要比不寫文檔的程序員工資更高。
真的！！！
迎娶白富美，從會寫文檔開始！
這個問題要根據具體開發的功能模塊來看，不過原則來說，花大量的時間看說明文檔，至少給人的印象是經驗不夠豐富，開發能力有待提高。
具體來說，如果是普通的功能開發，技術挑戰不大，這種如果還要看文檔，會被認為是開發能力問題。如果是有一定的技術挑戰，公司在這方面的積累比較少，開發團隊也對此有共識，這種問題看文檔無可厚非，當然如果能業余時間學習相關的知識，會給團隊留下開發能力強的印象。對於一些前瞻性研究，公司沒有任何技術積累，或者全新的技術方向，這個看說明文檔是加分的，甚至可以要求公司購買相關書籍或者在線培訓，當然，自己啃下來會更NB。