好的开发人员需要具备的那些素质

1、积极，主动性

这个其实比较重要，如果说技术实力不强，有些东西没用过，这些其实都不是问题，只要主动的去学习，主动的去发现问题，跟进问题，其实很多技术类的问题都不是问题了。这个放在第一位的素质。

 

2、有风险提前抛出来

做项目肯定有风险，没有风险项目也就没有挑战了。如果仅仅靠项目经理去把控，一来项目经理没有那么多精力，二来每个人的视野有限制，这两个原因导致可能考虑不全，而这个时候，就需要每个开发同学能够主动的发现风险，并提出规避方案，如果没有规避方案，那提出来也行。

 

3、区分主次，合理规划

对于系统中的功能进行核心/非核心、主流程/非主流程、高优先级/低优先级的划分。优先完成出核心、主流程、高优先级的部分。避免铺地毯式的一步一步的逐步推进。

 

4、新的想法打算用在项目中的，自己提前搞demo验证过

有些同学，包括我自己，都会尝试一些新东西，例如新框架，新的工具等。但是有个前提，不要在项目开始或者进行中的时候才考虑用新东西试一下，项目一般都是有时间限制要求的。之前有同事说想在项目中用XX框架，这时候一般会考虑之前有没有搞过，如果搞过，那就放心去用好了，如果没搞过，在项目来临的时候，最好不要用。项目一般有预研阶段，这个时候，如果有新的想法，可以尝试做一些例子。为啥要这样呢？因为新东西有学习成本，这个倒是其次，有些新东西有坑在里面，因为这个世界没有银弹的方案。

 

5、主动承担没人负责的模块

有些模块的划分，可能没法划分到具体的人，因为可能是两个模块衔接的，这时候，如果时间允许，建议开发同学主动的承担一些没人负责的模块。例如两个模块的衔接、整体页面的安全方案考虑、单元测试的集成、持续集成等。

 

6、自己负责的部分完成之后帮助其他同事

这个和上一个重复了？没有。刚才的那个是没人负责的，这个是其他同事的，项目内部人员的技术素质可能是参差不齐的，有些东西可能熟悉的人几个小时就能搞定，有的可能需要一天时间，这个时候，如果你熟悉一个模块，而另外一个同事不熟悉，你就可以帮助一下了。

 

7、代码注释充分

由于我们参与的大多是业务项目，有个特点就是复杂。这时候，就需要有充分的注释，当然是非常必要的环节才加。至于一看就能懂的，那就没有必要添加了。

 

8、代码自测充分，高质量的完成自己负责的模块

这个必须提一下，开发同学代码编写好了之后，需要提交给测试同学进行测试，有时候测试还分几轮。这时候，bug的情况体现了代码的质量，而质量的保证，除了经验和代码review之外，还需要自己完成一些自测的事情。尤其是主流程必须有，还有就是自己觉得一些边界的条件下。有人说着不是浪费时间吗？时间上这个是节省时间，自测充分之后，后续bug就少，返工就少，讨论问题就少，省了很多时间的。

 

9、畅通的沟通氛围

项目中有各个角色，沟通必不可少，为啥说要自己创造一个好的沟通氛围呢？因为你需要找别人讨论问题，别人也需要找你讨论问题，如果沟通态度和语气啥的有问题，就会给彼此构建一个屏障，而这个屏障会导致大家沟通不是很顺畅，最终可能就导致一个问题大家理解的不一致。讨论过程中，注重沟通的方式，要做到对事不对人。

 

10、重构

重构！重构！重构！重要的事前说三遍。写代码就像写文章，不是一蹴而就的。需要反复的修改和重构。当你发现代码重复、类结构不合理的时候，或者自我对代码感觉不太好的时候，就去重构。技术人员需要一些代码洁癖

 

11、编码前充分设计

编码前宁可多花时间进行方案的详细设计，千万不要一接到需求就进行编码。提前进行详细设计，会缩短编码的时间，也会降低bug的发生。变写变想，反而会降低开发效率，还很有可能在临近功能写完时，进行二次修改。

 

12、学会换位思考

•一个项目是需要多方协作的，例如需要业务、开发、测试、产品、UED等，那不同的人必然会有不同的想法，因为大家的知识积累以及经验积累肯定不一样，在大家想法不一致的时候，可以更多的是做个换位思考，先理解对方的观点，了解这个观点背后的原因，然后再来反观自己的想法，相信之后的争吵肯定会少很多，同时在互相理解的基础上，做事情的默契和结果也会有很大的提升；

•在协助中多一些换位思考，多站在对方的角度思考和理解问题，最后大家在协作中能够实现共赢；

•开发功能之前站在用户的角度去思考，假如你作为业务用户，你对这个功能会有什么样的需求。

 

13、责任心

这个放在最后，其实并不是说排名在最后，这个我认为也是很重要的，试想一个没有责任性的人写出来的代码，别人能信得过吗。写代码前要进行深度的思考。写完后要对自己的代码进行充分的测试。上线前需要反复确认自己的代码有没有问题