业务开发编程六力

        最近三周没有写点东西，工作有点忙，组织一点小任务开发测试发布，几个人的团队基本两周左右做一个版本发布。

        其实任务很简单，我首先对需求做了详细分析，跟市场人员也做了面对面沟通确认，之后用StarUML工具进行需求分析、业务流程分析、系统分析、数据结构设计等，然后对团队进行宣讲，之后对开发人员又单独宣讲，按道理应该是板上钉钉的事，但是实际开发测试过程中出现了很多小问题，并不是想象中那么一帆风顺。

        小团队主要力量还是开发人员，因为产品人员一般设计不成问题，因为新功能也不复杂，开发人员如果把系统做好了，测试人员和运维人员就好做了，所以关键点还是开发人员。

        在开发过程中发现有几个不好的现象：

1.  极不擅长沟通，拿到任务单之后，基本上不会去和产品人员、市场人员沟通和验证自己理解的正确性，直接按自己的想法去干；
2. 不会去做任何实际的分析设计工作，想到哪里做到哪里，后面的功能和前面的能不能衔接，基本不会去思考这个整理性；
3. 关注技术细节远远大于业务流程，仅仅连接MySQL的开源库就用了好几个，如JPA、Mybatis、MybatisPlus、Mybatisflex等，这种类似的技术解决不了业务开发的本质问题，却津津有味地追求着；
4. 极不关注数据结构设计，不明白数据结构决定算法的道理，不好好考究数据表字段的设计、关联表关系设计，在Java代码里大量使用多表嵌套查询，一层又一层嵌套下去，且不说性能问题，但这个可读性就差到姥姥家去了。
5. 不关注运行日志，写不出合理恰当的日志代码，不好好做单元测试，坐等测试人员来反馈bug，返工率高，拉长了开发测试周期。

        所以看似非常简单的几个功能点，人员配备也足够，时间也足够，但是实际上并不如人意，最后不是用加班解决，就是延迟发布。业务型功能开发没有任何技术难点，用Java开发足够胜任了，所以难点全是纯技术以外的问题，而这些问题却常常是很多开发人员不屑于去关注的能力点，认为Java技术好就行了，会使用各种新技术新框架就可以傲视群雄了，业务系统开发那绝对不在话下，出了工期问题或性能bug问题，不是恼羞成怒就是死猪不怕开水烫， 要求加班解决那是一万个不情愿的，补休也愿意干。

        当然我们也有极少数开发同事，各个方面都做得不错，开发前能给出具体工时估算，工时都比较合理，然后基本上都能按工时完成开发任务提测，功能正确性和性能都不错，在公司口碑非常好。我总结发现这类极少数同事有如下六种编程能力：

        

1. 产品理解力：

        很多开发人员奉行的是：你们叫我做什么我就做什么。

        他们不知道公司有多少产品线，不关心每个产品线具体是什么，不明白当前接到的任务是哪个产品下的功能，不去想当前任务和已有功能的关联关心，没有一点整体观。

        而好的开发人员总是对公司产品业务情况了如指掌，即使不是自己开发的部分，也做到各个点上心里有数，所以他们开发的时候不会破坏已有产品功能，新老功能衔接比较自然，正常情况下你感受不到他们的优秀，工作显得自然应该，只有和那些“你们叫我做什么我就做什么”的人来比较，才显示出他们的优秀来。

        这种产品理解力，既有天生的特质，也是后天慢慢关注培养形成的，如果一直都不注重培养，混到三十五岁+都依然没有这个能力。

2. 需求分析力：

        不管是产品人员下达的任务单里的文字描述，还是产品人员提供的Axure原型界面，很多开发人员都是浅尝辄止，随便看看，然后按自己的随意理解直接开工的。危害性如下：

• 错做：完全或部分理解错误；
• 漏做：没认真分析，少做了功能；
• 多做：有时想多了，多做了功能，客户根本就不要的；

        所谓过犹不及，少做多做都不恰当；而那些注重需求分析的同事，总是细细阅读产品描述的文字，细细琢磨产品原型图和备注文字，分析清楚每一句话真正的功能含义，分析清楚背后的含义和隐藏的需求，然后和产品人员一一确认自己的分析结果，总是正确和准确理解了客户的真实需求，自然就没有什么返工现象了。

        优秀的开发人员总是舍得在需求分析上下功夫，打开心扉去主动和产品人员和市场人员交流想法，保证在动手写代码之前对需求点理解透彻了。

        在敏捷开发时代，提倡快速试错，但是对做企业业务系统开发的，这个快速试错常常演化为不懂脑子蛮干，敏捷开发不是马虎做需求分析的借口，敏捷开发没有说不需要认真做需求分析。

        没有良好的需求分析能力和习惯，编码技术越好，真是做多错多，危害性更大。

3. 系统设计力：

        敏捷开发成为很多开发人员偷懒的借口，不做系统设计，不写任何文档，所谓的一切都在代码中，代码变化太快了，系统设计文档是跟不上形势的，所以不用做了，直接想到哪里做到哪里。

        前面我讲到用UML2.0十三张图进行需求分析和系统设计，我们不用做得太细，也不用每次使用全十三张图，恰当使用其中一张或几张图来表达系统设计即可，比如常常我们从大粒度来设计系统，用组件图、部署图、包图、类图、时序图、活动图来设计，基本都解决绝大部分问题了。

        系统设计本来就比较难，如果平时不抓住机会训练自己思维能力，这种能力和习惯是很难培养的。

4. 沟通协调力：

        在上面产品理解和需求分析过程中，最大的恶是自以为是，认为自己一看就理解，然后急急忙忙就开工，然后提测到测试组才发现错做、少做、多做，测试组打回返工，这根本就不是任何技术难题导致的问题，开发人员根本就不认为是自己的错，这才更可恶。

        如果你认为产品人员的描述有问题，或者难以实现，或者存在性能问题，你要第一时间去和产品人员沟通，表达自己对问题的理解想法，尽量去说服产品人员甚至市场人员或客户，所谓有事好商量，但不能不声不响地改了别人的设计细节，这个就是不尊重产品人员。

        有意识地打开心扉，主动去跟相关人员沟通，包括产品人员、市场人员、客户或用户等，所谓利益干系人，产品功能提出者由于知识上局限，可能部分理解错了，可能提出的功能实现上对现有系统性能会出现重大问题，或者需求本身就不合适，这些都需要我们积极去沟通协调，让事情走向一个正确的方向上去。

5. 数据设计力：

        就是数据结构设计能力，特别是数据库表的设计能力，俗话说数据结构决定算法，好的数据结构能解决很多业务流程问题，少写很多业务逻辑代码，性能上还表现不错。

        网上有很多关于表设计的原理原则，怎么设计主键、外键、索引、唯一性索引、1对1关系、1对N关系、N对N关系、字段冗余等等，没有经验的开发人员最好整理这些知识并反复琢磨，在企业级业务系统开发，和Oracle、MySQL或SQLServer打交道太多了。

        除了表结构设计以外，还有代码内存中的数据结构设计，其它存储系统设计等，这些都要关注重视，做好每一次数据结构设计。

6. 测试验证力： 

        很多开发人员都是很喜欢写代码，不喜欢测试自己的功能点，至少不重视这个问题，常常把bug留给测试人员，发现之后打回重做，反复拉锯浪费了两个部门的时间。

        有时我们开发的功能，不是提供给前端界面的API接口，而是后台进行数据处理的，实时流式计算或批量计算，我们怎么验证其正确性，这个问题讲起来容易，要争论时开发人员必定讲的头头是道，现实中我碰到多起开发人员一直无法证明自己程序在线上到底是正确还是错误，市场部门和运维部门一次次质疑数据的正确性，但是就是无法证明到底是怎样的，浪费了一批人的时间，关系也搞得很不好。

        特别对这些没有界面、日夜运行、实时不停处理数据的程序，怎么验证其正确性，有时不是测试人员能全面验证的，至少手工不好验证，构造几亿数据都是一个麻烦事，开发人员怎么证明验证自己的程序，有时可能的预先设计一个工具来验证才方便。

        开发人员要有这个意识，要有这个能力，在之后的测试和运维工作中才能比较轻松，没有那么多质疑的问题出现。