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。