浅谈下自己业务开发的总结（java）

一.背景原因

之前自己在业务的开发中，基本的做法都是：1.从大脑里面过一下，这个业务或者是不是能够实现。2.若技术上没有问题，那么就开始画个流程图–哪里开始，大致做了什么，然后结束退出。3.逻辑评估下，没问题，马上就开始编码。4.编完码用检测工具一看，长了就缩减下，不规范就调整下。5.测试下，没有大bug就谢天谢天。
但是后期需求来了，或者要做优化处理的时候。就会发现----不敢动代码！哪怕是一个小小的变量都小心翼翼，更别说要加处理逻辑。那简直就是二次开发，有时候要重新通读很多代码。虽然这样小心，但是修改完仍是会或多或少地发现不少bug…甚至还在生产环境中才检测出来的都有。

二.是我代码写的不规范吗？

有可能！毕竟规范这个词是个含糊的词。可以说你有你的规范，他有他的。我按他的规范可能就不太满足你的规范。当然，这个影响应该还是有限的。所以，我代码写的不规范，应该是其中一个原因，但绝不是唯一的原因。

三.假如我代码比较规范了，那么为什么还是会被骂？

可能不是别人，就是自己骂自己。这是我写代码？这是什么东西啊？我当时明明觉得以及很“规矩”，而且基本无从修改了啊！为什么还是这样难以维护和二次开发啊？
显然，我个人看到自己写的代码就是这样。我承认自己代码写的差，逻辑能力不强。但是我对自己的要求还是比较严格的。所以每次加逻辑总会把以前的代码修改很多。渐渐地，我觉得，是我的表达不够规范，逻辑不够清晰。

四.写在这里，对自己的反思与总结

以前觉得系统的架构对代码逻辑的影响是非常大的。后来接触完几个层次后发现：系统架构应该是对业务更清晰的分层。基本来说，当业务逻辑细分到原子方法时。系统架构对业务的影响是相当小的，或者说是能够乐观控制的。很多时候，系统架构的设计初衷是为了方便业务开发----当然前提是你了解了系统架构。

五.怎么来开发一个业务？

1.搭好系统的架构，了解系统的性能
2.给系统分好层
以上两点基本等于瞎说。因为太空泛

3.业务描述
其实这部分很重要。相当于算法描述。用自然语言描述你的业务，然后清晰地理顺整个思路。而且由于是自然语言，大部分内容是可以和运维、产品等沟通的。可以对完善逻辑起到一定的作用

4.流程图
流程图就是把每一个步骤写出来。怎么来划分步骤呢？或者说不同的人做事情应该有不同的步骤，怎么定义"步骤"这个词呢？那么我就给自己规定：一个“步骤”，对应3中算法描述的一“步”，也对应代码中的一个“方法”。那这样开发流程就一一对应起来了

5.伪代码
伪代码。就是一个“步骤”所对应的一个方法的具体“接口”：包括详细的方法名、入参、出参、异常。

6.代码注释
将“步骤”添加到主流程中对应的方法调用上；将业务描述添加到对应的方法实现上。至此，整个过程就比严密的串联起来了

7.检查实现方法是否逻辑严密
细节的地方自然是飞空判断、逻辑判断等以及异常抛出检查。

8.异常处理
首先是异常的编号机制，其实应该是严密的；再者对应的提示、处理办法等应该也要配备