程序员如何独当一面

转载自： http://blog.csdn.net/lwpoor123/article/details/79354767

今天和大家分享一下，程序员如何独挡一面这个话题，这是一个很大的话题，我把他分成三部分来谈：

一、需求转换的能力或者叫理解需求的能力；

二、分配时间的能力；

三、开发质量的问题；

我为什么把时间分配优先级放到代码质量的前面呢，原因有两个：

1.如果时间把控的好，及时功能有点问题，也是有时间来修复，相反及时程序代码质量再高，到了完成的时间节点没有完成，那就是灾难性的。

2.代码质量是通过时间的积累，技术的沉淀，修复成本越来越低，提升空间越来越小的因素；而时间规划却是和人的行为习惯挂钩不好去改正的一个点，比如你让一个拖延症的人变的行动迅速，是一个相对艰难的事情。

所以，我觉的合理分配时间的能力的权重要>开发质量的问题。

在开始之前，先给大家看一下思维导向图：

一、需求转换的能力

需求转换的核心就两个字“沟通”，开发成本最大的浪费是需求浪费，这分为两方面，一方面需求方，无效需求或者需求变动带来的研发成本浪费，另一方面是需求方和研发方需求传递不一致的浪费，简单来说就是没有充分沟通，导致研发所做的功能和需要方需要的功能不一致，导致返工的现象。第一点是我们作为研发不能把控的，我们能做好的就是在需求传递的过程中，保证需求的有效性和完整性。

那么具体要怎么做呢，可以通过以下几点：

1.开发前需求沟通，最理想的沟通方式：产品提供需求文档 => 研发人员先过一遍，记录有疑问的需求点 => 产品和研发讨论需求，把所有的需求都过一遍，有疑问的点重点沟通 => 研发人员用产品能听懂的话，大概的描述一下重点讨论的需求和实现方式 => 产品确认无误，启动开发流程。

2.开发中沟通，或者是开发前模拟程序实现流程的时候，如果有未谈到的需求或者有异议的需求，及时和产品沟通之后在开始做编码。

3.测试阶段，给需求方演示程序，最后一遍对接核对需求。

如果能保证以上三点，基本上在需求转换的工程中已经算一个合格的程序员了。

二、分配时间的能力

做软件开发的一般情况下都是，以功能（或叫结果）为导向，以时间为衡量标准的一项严谨的工种。所有“时间概念”在软件开发中发挥着无疑比喻的重量。

在说合理分配时间之前，我想有必要先说一下，程序开发的生命周期，在很多人眼里，程序开发有啥周期，做完不就完事了吗？其实这是小作坊的思维方式，对于一个合格的软件公司或者大一点的软件公司来说，即使到了开发实施的这一步，也分为5步：软件设计，思考最优实现方式 => 撸码 => 测试阶段 => 修复完善 => 交付，完成开发。

一般来说，对我个人而言软件设计，思考最优实现方式要占用30%的时间，撸码占用50%，测试和完善20%，当然，这个不能一概而论，对于新书来说思考的时间短点，关键点在留够测试和完善的时间，测试和完善的时间越长，项目的成功几率就越大；对于大咖来说思考的时间更长，因为代码质量过硬，所有测试和完善的时间可以相对分少一点。

如果你能认识到小作坊和生产线的区别，就能合理的安排时间，尽量提前完成开发，进入测试和完善的阶段，才是关键。

影响时间规划的还有另一个原因，项目冲突，比如你再做B项目，突然测试人员找你说你的A项目有一个xx问题，这个时候，你就要平衡一下优先级，原则上来说，是先处理优先级高的问题，但一定要把控的是尽量不影响自己的B项目计划开发进度。如果实现迷茫可找你的领导来权衡，让他做决定，这一点很重要，一定不能忽略。

三、开发质量的能力

这一点是最后一点，也是最偏重技术的一点，那么怎么去衡量开发质量的，我把它分为三个元素：

1.基本的评判标准，功能可以正常使用；

2.可读性高，利用他人和自己阅读、修改，降低维护成本；

3.模块化程度高，提高扩展性，降低维护成本，提高开发效率。

综上所属，写个正在奋斗的你一点小小的建议：提高自己主观能动性，调整自己心态，以主人翁的心态，积极的面对工作。你在认同公司的同时，公司才能认同你！