程序员观看新人代码

⑴ 程序员新人周一优化一行代码，周三被劝退

这周一，公司新来了一个同事，面试的时候表现得非常不错，各种问题对答如流，老板和我都倍感欣慰。

这么优秀的人，绝不能让他浪费一分一秒，于是很快，我就发他了需求文档、源码，让他先在本地熟悉一下业务和开发流程。

结果没想到，周三大家一块 review 代码的时候就发现了问题，新来的同事直接把原来 @Transactional 优化成了这个鬼样子：

就因为这一行代码，老板（当年也是一线互联网大厂的好手）当场就发飙了，马上就要劝退这位新同事，我就赶紧打圆场，毕竟自己面试的人，不看僧面看佛面，是吧？于是老板答应我说再试用一个月看看。

会议结束后，我就赶紧让新同事复习了一遍事务，以下是他自己做的总结，还是非常详细的，分享出来给大家一点点参考和启发。相信大家看完后就明白为什么不能这样优化 @Transactional 注解了，纯属画蛇添足和乱用。

事务在逻辑上是一组操作， 要么执行，要不都不执行 。主要是针对数据库而言的，比如说 MySQL。

只要记住这一点，理解事务就很容易了。在 java 中，我们通常要在业务里面处理多个事件，比如说编程喵有一个保存文章的方法，它除了要保存文章本身之外，还要保存文章对应的标签，标签和文章不在同一个表里，但会通过在文章表里（posts）保存标签主键（tag_id）来关联标签表（tags）：

那么此时就需要开启事务，保证文章表和标签表中的数据保持同步，要么都执行，要么都不执行。

否则就有可能造成，文章保存成功了，但标签保存失败了，或者文章保存失败了，标签保存成功了——这些场景都不符合我们的预期。

为了保证事务是正确可靠的，在数据库进行写入或者更新操作时，就必须得表现出 ACID 的 4 个重要特性：

其中，事务隔离又分为 4 种不同的级别，包括：

需要格外注意的是： 事务能否生效，取决于数据库引擎是否支持事务，MySQL 的 InnoDB 引擎是支持事务的，但 MyISAM 就不支持 。

1）编程式事务

编程式事务是指将事务管理代码嵌入嵌入到业务代码中，来控制事务的提交和回滚。

你比如说，使用 TransactionTemplate 来管理事务：

再比如说，使用 TransactionManager 来管理事务：

就编程式事务管理而言，Spring 更推荐使用 TransactionTemplate。

在编程式事务中，必须在每个业务操作中包含额外的事务管理代码，就导致代码看起来非常的臃肿，但对理解 Spring 的事务管理模型非常有帮助。

当然了，要想实现事务管理和业务代码的抽离，就必须得用到 Spring 当中最关键最核心的技术之一，AOP，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。

Spring 将事务管理的核心抽象为一个事务管理器（TransactionManager），它的源码只有一个简单的接口定义，属于一个标记接口：

通过 PlatformTransactionManager 这个接口，Spring 为各个平台如 JDBC(DataSourceTransactionManager)、Hibernate(HibernateTransactionManager)、JPA(JpaTransactionManager)等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

参数 TransactionDefinition 和 @Transactional 注解是对应的，比如说 @Transactional 注解中定义的事务传播行为、隔离级别、事务超时时间、事务是否只读等属性，在 TransactionDefinition 都可以找得到。

返回类型 TransactionStatus 主要用来存储当前事务的一些状态和数据，比如说事务资源（connection）、回滚状态等。

TransactionDefinition.java：

Transactional.java

说到这，我们来详细地说明一下 Spring 事务的传播行为、事务的隔离级别、事务的超时时间、事务的只读属性，以及事务的回滚规则。

当事务方法被另外一个事务方法调用时，必须指定事务应该如何传播 ，例如，方法可能继续在当前事务中执行，也可以开启一个新的事务，在自己的事务中执行。

TransactionDefinition 一共定义了 7 种事务传播行为：

01、 PROPAGATION_REQUIRED

这也是 @Transactional 默认的事务传播行为，指的是如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。更确切地意思是：

这个传播行为也最好理解，aMethod 调用了 bMethod，只要其中一个方法回滚，整个事务均回滚。

02、 PROPAGATION_REQUIRES_NEW

创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法都会开启自己的事务，且开启的事务与外部的事务相互独立，互不干扰。

如果 aMethod()发生异常回滚，bMethod()不会跟着回滚，因为 bMethod()开启了独立的事务。但是，如果 bMethod()抛出了未被捕获的异常并且这个异常满足事务回滚规则的话,aMethod()同样也会回滚。

03、 PROPAGATION_NESTED

如果当前存在事务，就在当前事务内执行；否则，就执行与 PROPAGATION_REQUIRED 类似的操作。

04、 PROPAGATION_MANDATORY

如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

05、 PROPAGATION_SUPPORTS

如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

06、 PROPAGATION_NOT_SUPPORTED

以非事务方式运行，如果当前存在事务，则把当前事务挂起。

07、 PROPAGATION_NEVER

以非事务方式运行，如果当前存在事务，则抛出异常。

3、4、5、6、7 这 5 种事务传播方式不常用，了解即可。

前面我们已经了解了数据库的事务隔离级别，再来理解 Spring 的事务隔离级别就容易多了。

TransactionDefinition 中一共定义了 5 种事务隔离级别：

通常情况下，我们采用默认的隔离级别 ISOLATION_DEFAULT 就可以了，也就是交给数据库来决定，可以通过 SELECT @@transaction_isolation; 命令来查看 MySql 的默认隔离级别，结果为 REPEATABLE-READ，也就是可重复读。

事务超时，也就是指一个事务所允许执行的最长时间，如果在超时时间内还没有完成的话，就自动回滚。

假如事务的执行时间格外的长，由于事务涉及到对数据库的锁定，就会导致长时间运行的事务占用数据库资源。

如果一个事务只是对数据库执行读操作，那么该数据库就可以利用事务的只读属性，采取优化措施，适用于多条数据库查询操作中。

这是因为 MySql（innodb）默认对每一个连接都启用了 autocommit 模式，在该模式下，每一个发送到 MySql 服务器的 SQL 语句都会在一个单独的事务中进行处理，执行结束后会自动提交事务。

那如果我们给方法加上了 @Transactional 注解，那这个方法中所有的 SQL 都会放在一个事务里。否则，每条 SQL 都会单独开启一个事务，中间被其他事务修改了数据，都会实时读取到。

有些情况下，当一次执行多条查询语句时，需要保证数据一致性时，就需要启用事务支持。否则上一条 SQL 查询后，被其他用户改变了数据，那么下一个 SQL 查询可能就会出现不一致的状态。

默认情况下，事务只在出现运行时异常（Runtime Exception）时回滚，以及 Error，出现检查异常（checked exception，需要主动捕获处理或者向上抛出）时不回滚。

如果你想要回滚特定的异常类型的话，可以这样设置：

以前，我们需要通过 XML 配置 Spring 来托管事务，有了 Spring Boot 之后，一切就变得更加简单了，只需要在业务层添加事务注解（ @Transactional ）就可以快速开启事务。

也就是说，我们只需要把焦点放在 @Transactional 注解上就可以了。

虽然 @Transactional 注解源码中定义了很多属性，但大多数时候，我都是采用默认配置，当然了，如果需要自定义的话，前面也都说明过了。

1）要在 public 方法上使用，在类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。

2）避免同一个类中调用 @Transactional 注解的方法，这样会导致事务失效。

在测试之前，我们先把 Spring Boot 默认的日志级别 info 调整为 debug，在 application.yml 文件中 修改：

然后，来看修改之前查到的数据：

开搞。在控制器中添加一个 update 接口，准备修改数据，打算把沉默王二的狗腿子修改为沉默王二的狗腿：

在 Service 中为方法加上 @Transactional 注解并抛出运行时异常：

按照我们的预期，当执行 save 保存数据后，因为出现了异常，所以事务要回滚。所以数据不会被修改。

在浏览器中输入 http://localhost:8080/user/update 进行测试，注意查看日志，可以确认事务起效了。

当我们把事务去掉，同样抛出异常：

再次执行，发现虽然程序报错了，但数据却被更新了。

这也间接地证明，我们的 @Transactional 事务起效了。

看到这，是不是就明白为什么新同事的优化纯属画蛇添足/卵用了吧？

⑵ 程序员是如何看待始祖代码的

就只是看看，不能改。有时候看到一些奇怪的逻辑，不要慌张，这里面一定有一个很长的故事。

⑶ 软件开发公司如何带新人

1 给新人制定学习成长目标
新人刚毕业，都会急切的想证明自己，我刚毕业的时候也是这样的。希望急切的进入到项目中。但成长是一个循序渐进的过程。比如制定成长目标：能够独立的承担系统的设计任务。包括前端，数据库，等等。制定一个月目标；三个月目标；半年目标；一年目标等等。
2 新人的目标需要细化与量化
新人刚毕业，需要学习的东西有很多，但是又很迷茫，需要学习的东西太多了，不知道那些是对工作有用的。这个时候，师傅需要给新人指点一些。将新人的需要学习的目标，细化到周为单位.
3 给新人的学习需要定时的检查与指导
新人最近学习的怎么样了？学习的时候有没有遇到什么困难？这个需要及时的和新人进行沟通和交流。
4 review新人写的代码，这点很重要
如果学习的过程中，新人也参与到项目的开发。那么需要review新人写代码。我在用smart svn中review新人写的代码的时候，就会发现新人在开发项目的时候，他们会犯一些自己不容易发现的问题。他们认为自己的代码写的没有问题，但老人一读就会发现，他们代码在效率，可读性，扩展性等，都会有很大的问题，需要及时指导。（师傅应该在早期时间内，对徒弟的代码应该抱有一种怀疑的态度，如果刚开始就很信任，那么代码上线后，有可能你就会等着哭吧。。。）
5 让新人去独当一面
新人学习到一定阶段，他有自信可以完成任务之后，可以尝试让他负责一个项目的所有过程。只有实战才是检验他学习的成果。实战后，他也会发现自己哪些欠缺，然后及时充电。
5 演示与练习相结合
模仿是最快速的入门学习方法。
当新人看了一定的技术书籍后，新人肯定特别希望能够做出东西，但是也不能着急；这时候师傅可以演示一个表的增，删，改查的操作；然后让
新人按照这个例子去练习；然后再逐渐加深难度的演示。
7 思想境界的提高才是王道
对新人技术与技能提高只是方式和方法问题。但是我个人觉得思想境界的提高才是王道。比如输送程序员的基本素养，公司的企业文化，程序员遇到复杂问题的心态，程序员对项目负责等等。（这方面我一直在思考这个问题，自己感觉做的也不是特别好，今后要加强。。。）

⑷ 为什么老程序员的效率如此高

程序员老师傅的解决问题能力要比初级甚至是普通的程序员都要高出很多倍，所以每个软件公司都会在保留1,2个经验丰富的资深级软件工程师，这样在遇到项目或者产品难点的时候能够力挽狂澜，这种水准的程序员也是很多公司追求的对象，而且和年龄没有太直接的关系，编程最终的就是给出解决问题的方案，从解决问题的角度出发解决方案还是非常多，但是在不同的人会给出不同的解决方案，但是有经验的程序员在解决问题的时候就会思考的比较多，不容易导致引入新的问题。

编程能力最直接的表现不是写代码的能力，因为随着时间的推移时间积累够了代码能力自然就上去了，很多程序员在工作多年之后虽然代码能力得到极大的提升，但是还是不具备独立的框架或者功能复杂的模块设计能力，所以很多人在工作多年之后工资一直不能得到上涨，这是主要原因编程的关键还是思路问题，关键点还是在于有正确的解决问题的思路，思路的切实性是需要经过项目实战的积累。

所以优秀的程序员一定是身经百战的经历过项目的洗礼，只有经历过项目才能真正意义上懂得编程是怎么回事，而且每次经历的项目都能够获取足够多的营养出来，越是优秀的程序员经历过项目之后知识体系构建越是完善，越是老程序员越是觉得程序深奥之初，所以老程序员轻易不动手都会思前想后把事情搞明白之后才去真正动手，所以讲老程序员真正动手写代码的时间还是非常短，大部分的时间都是在构思其可行性，真正动手的时间会非常短所以大家看到老程序员大部分的时间都是在看代码或者看一些资料，甚至有些人很少看到老程序员在大块的时间写代码。

越是老程序员对于编程语法看的越是淡薄，编程语言到了一定层面就是工具般的存在，就是为了编程思想服务，如果还在为了编程功能实现代码而烦恼证明了还在初级的学习阶段，度过了这个阶段之后就要考虑如何驾驭架构以及如何锤炼自己的编程思想了，编程的学习过程是需要循序渐进的不要觉得距离自己老程序员有非常遥远的距离，从开始入行就要慢慢去积累不断打磨自己的思想，希望能帮到你。

25年老程序员，20年CTO，来解答一下：

1、经验、教训使然，所谓亏吃多了，也就不吃亏了。

2、长久工作，养成了一定良好的习惯。

3、代码量到一定程度，自然而然会更熟练。

4、一些非技术的经验知识，还是需要时间来积累。

5、老程序员的思维经过多年的训练，更有利于直达本质。

6、他们的方案可行性更高，这样减少返工。

7、代码质量高，测试通过率高，考虑的因素更周全。

8、代码改起来更容易，找问题也相对容易。

9、对任务的理解更全面，能够从更多的角度去设计程序，权衡效率、速度、性能、扩展性等各方面的因素。

10、也不是所有的老程序员都能这样，这个还是跟这人的学习能力有关系，所以大家是能3年变成老程序员，还是10年，就看自己的个人努力了。

在IT编程开发的过程中，老程序员开发的效率会非常高。比如：一个网站模板，新程序员可能要花上一个星期的时间才可以完成，而老程序员却可能只需要1-2天就可以做好。这是为什么？莫非他们天生就有神相助。非也，这所以会这样，据我分析，主要有以下几点。

因为长期的编写代码，所以，会碰到非常多的问题，然后就会去解决这些问题，这就让老程序员有了丰富的实战经验。反观新程序员，碰到一个问题，因为以前没碰到过，所以要花大量时间去解决。而老程序员碰到问题，因为以前解决过，所以，很快就会弄好。

在IT编程中，很多的代码都是可以用来搬运的。因为长期的工作，老程序员会把一些功能代码记录或储存下来，以备后期使用。也就是说，他们就像记笔记一样，把一些功能代码记下来，以备不时之需。所以，在新的编程中需要用到时，他们就可以直接拿来就用，自然效率就高，开发就快。

老程序员在编写代码时，一般都会对代码的规范和格式比较重视，使用代码清晰有条理，阅读代码时就不费力气，而且还会做好每个功能代码的注释。这样，不管是对现有开发，还是对后期维护，都是非常有利的。如有代码出现bug，可以很容易地找到，这同样节省了大量的时间。

老程序员在编写代码时，会先从大处着手，把大的框架给弄好，然后，再对整个编程的细节有针对性地编写。这就好比开发一个高楼大厦，开发商会先把主体框架搭建好，然后，再一层一层地去弄每一层楼的细节。这样，往往目标会更加清晰，只要按步就班地执行计划，就可以很快完工。

熟能生巧

为什么老程序员的效率如此高？

首先， 敲代码的效率 != 工作效率

并不是老程序员效率就高，而是程序员要提高效率需要一些方法，这些 方法的学习和掌握需要一定的时间 ，结果就是老程序员的效率会相对要高一些。

我经常会看到一些新手程序员在写代码的时候需要频繁的去查看文档或者是网络搜索各种接口的用法，有时写一个功能要查个几十次，很多时间都浪费在了搜索上，真的写代码的时间很少。

而一个在这门语言浸淫了几年甚至是十几年的程序员，对这些接口了若指掌，使用的时候信手拈来，还知道接口里面的实现机制，可能会碰到哪些坑也一清二楚，减少了很多bug的出现。

你是不是有把那些接口拿出来反复琢磨，去研究它的源码，认真地了解它呢？

工欲善其事，必先利其器。

一个好的编程工具有很多可以帮助程序员减少工作量的功能，比如代码重构、自动格式化、语法检查、代码提示和补完等等，掌握这些也能大大提高开发效率。

随着IDE的发展和进步，现在很多工具都不需要太复杂的学习就可以操作，所以这个是一个投入小而回报很高的事。

代码是为业务服务的，我们首先得理清楚业务逻辑，才能知道要怎么写代码，而新手对业务不熟悉的时候，光是弄明白业务需求是什么可能都需要不少时间，有时候还可能会错误理解需求，导致写出的代码文不对题，只能重写。

所以多思考，多问，多讨论，不会花太多时间却会减少很多时间的浪费。

写出来的代码还需要经过测试，如果有bug就需要调试了。

很多新手只重视写代码的工作，对于怎么调试却忽略了，有的人甚至只会使用打印功能一步步通过排查找bug，并且对写出来的代码没有概念，连bug大概可能在什么地方也不清楚。

老练的程序员不只是靠打印，有时候只看报错信息就能知道bug大概在什么位置，配合上打印还有断点功能很快就可以找到bug的位置，更不要说他们很清楚怎么写出容易调试的代码。他们会在写代码的时候就对可能出问题的边界条件进行检查，并且会利用自动化测试来减少工作量。

新手很容易犯的一个错误就是拿到功能需求马上就开始写代码，可能写到一半会发现前面的代码有问题需要推翻重来，或者是写错了方向。

老程序员写代码之前会先进行构思，把功能需求拆解，分成不同的小模块，甚至会在纸上把这些想法画下来，基本上在这一步就把问题已经解决了，写代码只是把解决方案用代码表达出来而已。

所以，如果你也想做一个十倍程序员，记得不要只是埋头写代码，还要刻意去练习这些提高效率的好方法！

在写代码前，代码差不多已经刻在脑子里了，写代码的时候，总觉得双手敲键盘的速度赶不上脑子的速度，写出的代码几乎不需要调试，你说效率高不高？

因为老程序员经历多了，一些常规性的BUG基本不会出现，对用户需求也能做到最大的完善，还有对需求增加和修改有个大概了解，会提前预留接口和模块，还有对用户的硬件有了解，在程序上会有相对优化。所以老程序员写的程序不一定美观，也不一定最简化，但是可能是最合适的，可惜中国的程序员刚成熟就要面临失业。年轻的程序员啥都不懂，片面追求性能，美观简洁的程序，在兼容性和实用性上大打折扣，不顾用户的使用情况和硬件情况，项目一上线问题多。

老程序员分为两种，一种是年纪老，常常被换做“老X”，一种是能力老，常被人换做“x老师”。

老程序员之所以效率高，离不开几点：

程序员是一份高强度的脑力工作，能成为老程序员者，智力，体力无一不是同龄人中佼佼者。能够更加效率的工作自然是理所应当，方符合家有一老，如有一宝的普世价值。

祝广大码农早日修炼成为这样的老程序员。

老程序员，码代码速度并不见得比年轻人快。但老程序再面对需求时，能很快抓住技术关键点，难点，重点，如何突破都了然于胸。当出现问题，老程序员有经过实践的诊断定位排错的逻辑思路与手段 。其实这些熟能生巧是一方面，学习与实践 领悟是另外的方面。年轻人观察能力强 悟性高，也会青出于蓝

老成员就是图书馆，硬盘存满了各种经过调试且运行过的程序，只需要复制粘贴，效率肯定高

⑸ 程序员在上班时，允不允许大量的看说明文档来帮助写程序

程序员日常开发工作，基本是上离不开阅读文档，这也是很多程序员喜欢两个显示器的原因。

项目方面

技术方面
是不是很多人都认为，如果在开发过程中，还要不断地翻技术文档，说明他的开发能力不扎实。其实不是这样的。

首先IT行业技术升级换代的速度太快，当我们大多数公司还在用Java8的时候，Java11都已经出来了。如果非得要程序员熟知每一个类、每一个方法，是很不现实的。

很多时候我们只需要了解有这么一个东西，作用是干什么的，具体的细节可以在用的时候再去翻文档，比如方法名字是什么？参数有几个，都是什么类型的？

所以我们都习惯至少两个电脑屏幕，一个屏幕写代码，一个屏幕看文档；如果豪一些的话，再加一个屏幕展示日志信息。

看文档的屏幕要买竖屏！

我们团队
我这几年也带过几个团队，对于每个团队成员，我对他们的要求是：实现需求的前提下，最好能对所用的技术有一定的了解，千万不要从网上抄过来一段代码就用，这样是很危险的行为。所以鼓励大家多找一些资料，最好是阅读框架的官方文档。

现在的团队，我已经这样要求了：代码写累了，或者觉得自己没有状态写代码，可以找点儿自己有兴趣的技术文档学习学习，这个技术甚至是可以跟现在的项目没有关系的。

首先，我不是程序员，我是一个设计工作者，不过我来说一下我的观点：很多人以为程序员像电影里的一样，啪啪啪几下键盘，屏幕数据飕飕的变，其实真实情况是程序员写代码就像学生写作文，也会遇到不会的词语跟修辞手法，那这个时候就要停下来想一想，查一查，看看例子是怎样写的怎样用的，写错了还要划掉（删掉）再来，至于这个大量不大量看的情况，如果这个是个新手，那肯定是可以的，那如果是个老手，还需要大量时间查说明文档，那就说明这个项目肯定不会小，不是一两天能做完的，那一个用月做单位的项目，用一个天做单位的时间来查文档，不过分吧！程序员也是人，不是因为他的工作高端，就觉得这个人万能，他也会当机，要吃饭，要休息，也会忘记一些东西，所以请各位多多体谅，能一起工作实属不易，感恩2018，谢谢。

这个问题怎么说呢，开发过程中会遇到各种各样的问题，没有一个人是全能的，也没有人可以绝对的说自己在整个项目中不会遇到一点问题，不去查东西，自己大脑里的东西完全可以让我把这个项目测测底底的做完，并且没有任何bug。

上班的时间，也没有老板或者谁在后面一直看着你去做东西，大家都挺忙。文档是干嘛的，文档本身就是用来看的，甚至很多项目开始之前，总监都会让你去搜集一些这个项目可能会遇到的bug，可能会用到的效果，尽量在之前找到比较好用的插件，这样会节省很多时间，自己如果写代码的话不可能百分百的确定没有人和bug，但插件不一样很多插件都是前辈通过很长时间慢慢完善出来的插件，所以很多人才会用。所以你提问的可以肯定的回答你允许。

程序员上班的主要工作就是看说明文档，根据说明文档编码。如果实在没有说明文档，有时还得亲自披挂上阵写说明文档。

写接口的有API文档，写通讯协议的有协议字段说明文档，写数据库的有数据库规范文档，

总之任何一个大公司文档扮演的一个至关重要的问题，因为形不成文档，公司管理就会陷入混乱不堪的局面，当某个核心员工离职后，下一个接盘的程序员会丈二和尚摸不着头脑，一头雾水，边填坑边骂娘，有了文档就可以看文档结合代码，了解其中模块逻辑以及结构，包括哪些坑不能踩等等好处。有些公司会专门有文档工程师这个职位来专门负责整理各种文档，并且保存在服务器上。

好的文档都是程序员等人智慧的结晶，是一盏指路明灯，是一条通往光明的道路。程序员不能看说明文档等于在黑暗里摸爬滚打，有了说明文档才迎来了黎明的曙光。

说个我遇到的2个真事吧，

第一个，公司找的外包公司写项目程序，已经要交付了，发现有几个功能没做，产品经理和开发那边都找我，我一个搞运维的又不懂，只能让他们去对开发文档，我也就顺便看了看，开发文档中明确的写明怎么做，然后就让他们就重新按开发文档继续写，

另一个，由于 历史 原因业务系统处于托管状态，只有部分参考文档可用，开发那边只能按当前已有文档进行开发参考，开发那边也一直在根据现有相关文档进行开发，杯具的是这帮子不仔细看，有问题总想着我能直接给他们答案，我也只是会用而已，开发我还真搞不来，然后和他们一起看开发文档，加密算法部分给她们指出后，问题解决了。

所以我觉得，开发团队在开发中很有必要阅读开发文档，这可以避免绕圈子，也会清楚开发文档中提供的内容。

先说观点，我认为看文档没什么问题，但是“大量”这个程度很难衡量，按照需要看文档是个非常重要的事情。
需要花费时间的情况 不需要花费大量时间的情况 小结
在工作中阅读文档其实也是工作内容的一部分，而且现在大多数互联网公司都靠KPI进行考核，平时就算你把时间都用来看文档没关系，最后KPI没完成一样会被公司淘汰。所以公司不会阻拦你花费时间看文档，最多你老板会提醒你浪费这么多时间看文档而没有实际的产出会对你年终考核造成影响罢了。

题主对文档的定义不是很明确
第一个是需求说明文档
这个是在开发过程中必不可少的文档，只有清楚了开发需求，程序员高效率的开发，程序员一天的工作时间并不是都是在写代码，而是在看文档，了解需求，理清思路，只有什么都清楚了，写代码或许只要十几分钟。

再者对于一个项目新人来说不看文档了解需求，没人给你从头到尾的在讲一遍需求，你不看文档自己发挥？进入项目是和别人共同开发，你不肯能不顾及之前的代码规范。
第二个是开发文档
就拿微信开发来说，微信开发不是每个程序员必须会的东西，但是用到了怎么办，还不是去看他们的开发文档，只有将开发文档思路理清楚了，才可以进行下一步开发。
第三个是API文档
在前后端分离的开发模式中API文档是必不可少的文档。不看API不知道数据是什么样。也就是不可能顺利的和后端进行结合。

兄dei，假设你是程序员，你在写程序时，旁边会有人守着你吗？

假设你不是程序员，你在做本职工作时，旁边会有人守着你看你怎么做事吗？

答案肯定是没有的。谁会闲着招个人去监督你，看你用什么方式去完成给你的任务。

所以，其实你看不看大量文档，没有人会在乎，关键是你自己，建议自己写东西时，不要一味的复制粘贴，要有自己的想法。太依赖文档对于自己成长很不利

当然允许看文档。

要知道，随便哪个类库，都有无数的类和方法，每个方法又有若干参数，鬼知道它们都是什么意思，谁的脑子能记得那么多内容。别说是人家提供的类库，就是自己写的代码，过一段时间也不记得什么意思了。没有注释和文档，怎么看懂代码？

如果没有需求分析文档，程序员怎么理解正在开发的这个软件的基本业务流程？

如果没有架构设计文档，程序员怎么理解软件各个功能模块之间的功能与业务逻辑？

如果没有接口文档，那么多类和方法，都怎么调用，会返回什么值，难道靠猜？

……

在日常开发工作中，不仅允许看文档，还会强迫你写文档。如果你写的文档别人看不懂，别怪领导骂你不认真。文档对于软件开发的重要性是不言而喻的。

还有一个秘密告诉你，那些经常写文档的程序员，要比不写文档的程序员工资更高。

真的！！！

迎娶白富美，从会写文档开始！

这个问题要根据具体开发的功能模块来看，不过原则来说，花大量的时间看说明文档，至少给人的印象是经验不够丰富，开发能力有待提高。

具体来说，如果是普通的功能开发，技术挑战不大，这种如果还要看文档，会被认为是开发能力问题。如果是有一定的技术挑战，公司在这方面的积累比较少，开发团队也对此有共识，这种问题看文档无可厚非，当然如果能业余时间学习相关的知识，会给团队留下开发能力强的印象。对于一些前瞻性研究，公司没有任何技术积累，或者全新的技术方向，这个看说明文档是加分的，甚至可以要求公司购买相关书籍或者在线培训，当然，自己啃下来会更NB。

⑹ 刚入职的java程序员新人在公司已经看了两个礼拜的代码了

不能指望有人手把手的带你，你要自己学习，有不懂的网上都可以搜到，实在不行搭个老学员请教怎么学习，程序员没有自己学习的能力是不行的，虽然你底子不咋样，但有人发着工资养你你还不学，要怎么学呢？觉得你不行会开你的，你也不会有什么损失。我在动力节点学五个月底子比较好，没有遇到你说的情况，你要是底子实在差可以也去一下，听深圳有新校区了。

⑺ 我是新入职的java程序员快一个月了,还感觉什么都不会,怎么办，经理一天就叫我看需求，看代码

还要提一句的是，你在建立SSM的进程中，可能会常常接触到一个叫maven的东西。这个东西也是你往后作业傍边几乎是有必要要运用的东西，所以你在建立SSM的进程中，也能够趁便了解一下maven的常识。 动力节点咨询一下，现在深圳有个新校区，

⑻ IT公司的项目组入职了新的程序员，如何带好这些新员工

不少软件开发团队每年都有新的开发人员要加入，其中以初级程序员居多，要想让这些初级程序员能够快速融入开发团队并实现价值，需要从以下三个方面入手：

第一：以开发实践能力进行人员划分。 新入项目组的准程序员往往有两种情况，一种情况是刚刚走出大学校门的计算机专业毕业生，另一种情况是自主学习通过面试的非计算机专业毕业生。这两种准程序员在进入岗位之前可以根据实践能力进行人员划分，实践能力较强的可以直接安排进项目组中，而实践能力较差的准程序员则安排到实习岗位上。按照 历史 经验来看，不少实践能力较差的程序员如果直接安排到开发岗位上，往往会导致其放弃这份工作。

第二：老带新。 按照 历史 经验来看，让程序员快速成长的方式无非就是通过实际项目的锻炼，对于学习能力较强的程序员来说，如果有专人指导的情况下会很快融入到开发团队中，有的程序员在一个月之内就可以完成功能模块的开发。老带新的原则有三点，其一是软件开发团队所使用的技术结构要交代清楚；其二是软件开发过程中所使用的开发工具和开发流程要交代清楚；其三是给出具体的参考案例。

第三：安排清晰的工作任务。 对于初入项目组的开发人员来说，由于其自身的专业知识积累还比较少，在项目理解力上还有待提高，所以在安排具体开发任务的时候一定要详细，越详细越好，同时要给出明确的功能边界，防止出现不可控的事情发生，比如哪些数据是不能动的，哪些功能和资源是不能调用的等等。有的时候“无知”是最可怕的敌人，不少初级程序员进行的“删库”等操作都是在“实验”的心态下完成的。

如果有互联网、大数据、人工智能等方面的问题，或者是考研方面的问题，都可以在评论区留言！

我是程序员出身，现在也管理着一个项目，手下最多的时候也有十几号人；但是说实话，在管理方面，我还是比较欠缺的，我也一直在学习和摸索；当项目组入职了新的程序员的话，我经常会这样做：
先沟通，大方向要保持统一
每当项目组入职了新的程序员，我会第一时间和他们沟通，主要让对方快速地知晓项目的基本信息，并了解我们大的方向、观点、风格，我是希望在某些地方能和组员保持一致，例如：

制定计划
下面就要给新人制定计划了，这一点在前期很重要，否则新人就会面临无事可做的尴尬；

安排开发任务
通常，我们一两周后就会给新人安排一些开发任务，当然这个过程也是从易到难：

代码检查
对于新人，代码检查一定要做；如果是工作时间段的新人，每一行代码都检查一遍都不为过。

最后，我会给新人一些成长方面的建议，让他们觉得在这个项目中能学到东西；毕竟我没有权利给他们涨工资，只能通过这种方式留住员工了。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

建议从以下几方面考虑：

1、人员能力考查和培养。人员的能力参差不齐，需要根据岗位进行有目标的培养；

2、业务技能提升。想把工作做好，不了解业务，不理解自己做的东西，早晚要出现与预期偏差较大的情况。

3、工作态度和心态的培养。

4、尽早了解项目内容和项目团队，将人员在项目中的定位和需要的技术提前告知，告知项目计划和提示工作的难点。

5、组织一点团队活动，早点融入项目。

第一：熟悉你们开发工具、开发环境、运营环境……

第二：熟悉上下开发工序对接组别和责任人……比如开发该项目的前端、后台、测试等不同组别以及其他开发外项目组外的不同部门打交道的人员。

第三：项目说明书、整体功能、进程，所负责的分割模块……要完完全全提供出来。
每个人都是从新人成长过来的，在我工作的五年间也带过很多新人，最近刚好有个毕业生来公司实习，领导让我带，这边就分享一下我具体是怎么操作的(开发的角度):
总而言之，带新人还是比较累的，对大部分公司而言，技术要求并不是很高，所以新人真的比较难上手的不是技术，而是业务和表结构逻辑的不熟悉，作为新人，公司的打算就是从零开始培养，因此基础并不是最重要的，学习的态度才是公司看重的。

以上为个人观点，欢迎在评论中发表自己不同的观点，喜欢的加个关注，谢谢。

以十人以下的团队来说一下。首先是和员工相处好，其实这一点做到并不难，就是正常的相处，怎么愉快怎么来（当然不能坏规矩）。我做的最大尺度一次是这样：有个毕业生干着干着就哭了，一问之后知道直接原因是程序员的工作内容和自己原来想的不一样，主要原因是刚到北京体会到了巨大的压力。当时我就拉着她到对面肯德基去坐会了，点了饮料和薯条，聊了一下，顺便开导开导她，舒缓一下情绪，这事就这么解决了。其次，作为领导请安排划分好工作内容，不要频繁变更，否则影响威望值。这也是保证工作可以顺利开展的基础。安排工作时请考虑员工的能力和经验，还要考虑员工的兴趣，这点也很重要，很大程度影响积极性。

在小团队中只要工作能顺利完成了，一般问题就不会很大了。其它：可以观察一下每个人的喜好，然后看机会适度的介绍这方面的内容。比如我就专门给一个员工培训过数据结构，而她也很愿意介绍自己认识的人来工作，双赢的结果。员工做好的地方及时表扬，自己做错的地方及时承担责任，等等。总之将心比心的对待员工，小团队还是好带的。

教会徒弟，饿死师傅，等你教会他们，你就该退了，理由：你三十多，奔四了，负担大，不能加班，养不起你！中国现状，保留必要绝活，留几招吧！为养家！

先让他做点小项目，锻炼一下，把以前已经完成客户的项目拿出来给他做，练手，看看功底如何

如果功底好，则主要锻炼他的思维能力

如果功底不好则多锻炼他的技能

首先是能力要过关，之后就是交流要能顺畅，其他的问题都不是问题，只是经验和熟悉而已。

⑼ 有哪些老程序员都知道对新手很有用的经验

一说到程序员，想必大家的第一印象就是头发少，很大程度上就是因为压力大导致的，有生活压力，也有工作压力。

今天说说工作方面的压力，想必看到这个问题的小伙伴都有一个认知，就是一个项目往往比预期的要长，说不定从哪天开始就加班了，一出现BUG真的要人命。此时，考研新老选手心态的时候和经验的时候了，老程序员或许能从容应对，新手可能完全不知错所。

七、个人信息一定要保管好

这些信息包括户口档案、社保、公积金等信息，程序员新手可能跳槽比较频繁，有人甚至还换个城市工作。除了户口可能其他的信息都乱了，可能当时觉得不那么重要，但是十年、二十年后，可能会非常重要。

八、几条名言

·工作日志可以提升脑容量；

·不要先写框架再写实现，要反过来；

·重构/优化/修复Bug，不要同时做；

·简化开发流程，加快迭代速度；

·纸笔是最好的工具，其次是markdown；

·画出结果，一目了然。

·首选明文文本，二进制、加密、压缩等到时候再加；

·要学会进行清晰的命名；

·问问题前先调查，要问到点上。

·不要小看程序员