关于后端编程‘闭环’的一些思考

注：本文仅为个人后端编程开发中的一些思考，如果帮助，甚是荣幸。

1.编码curd的苦楚

当我初初接触编程的时候，战战兢兢打开记事本写下第一个HTML hello并刷新浏览器显示，那种心情激动而自豪，目前是没有了。相信80%的后端程序员都在curd的业务中反反复复，挣扎着如何避免继续curd的过程中继续curd。

对于广大后端达瓦里氏来说，编码就是对着业务编写curd相关逻辑，建个表，建个model，搞个控制这样的了，相差不大，业务复杂的来个服务类，又或者整个中间件之类。

其实写了这么多年代码，回头一看，curd是真的无法避免的，只是看谁来curd而已，业务就这些，没有必要整的过于高大上，搞的谁都看不懂，包括一年后的自己，哈哈哈。是以，每次curd时都在想，如何可以写出更加健壮的代码呢？

前辈高人很早推出了许多设计模式用于整合零散的代码结构，经典如面向对象编程OOP，（没有对象？new一个），对于流水式的，重复性的代码又加入了许多设计模式，如信手拈来的工厂模式，诸如此类，可以解决我们日常编码的80%代码量，

但是，是不是仍旧不满足啊，为啥我的代码依旧bug连连，别人（一年后的谁）一看就像一坨咖喱状的分泌物，毫无可读性？而多多查看一些框架的底层逻辑代码，为毛这么优雅，这么健（zhuang）壮（bi），其中缘由到底为何物，我也被困扰了

许久，曾经尝试过许多的编码学习路线，为此也学习了几门其他后端语言（其实就是hello），了解他们的设计思想，方法，看了为啥要这么设计，总结发现，其实还是基础知识不扎实（就是菜，没救）。全文完

 

2.提升编码能力的路线

虽然我很菜，但我心很美啊，菜不是原罪，不努力（丑）才是啊！我坚信努力就一定会有收获的，决定变化自身的编码思维，并付诸项目中，不要担心突然服务器宕机，也不要担心Redis突然就10kOps了，这都不是事。

这里提出几点个人的思路以及机会路线

1. 重新学习OOP思想（等）
2. 常用设计模式要练习到信（复制）手拈来（粘贴）
3. 编码前强迫编写代码结构文档，优先计划
4. 本文核心思想，编程的闭环
5. 不要再写垃圾代码了，你能行

为什么要重新学习oop思想呢，个人虽然是计算机专业出身的，但对于编程这座珠穆朗玛峰还是仅仅在山脚下，许多业界常常吹嘘的思想也是一知半解，只能说出个对象就是个人，我们可以new一个复用，别人一问你

个人的见解往往都是如此，答不出来其实没啥，毕竟菜是原罪，后来发现，多数都是大佬问的，希望你有个人见解就是想问问你在编程思想这块有多深入的了解而已，OOP思想要深入是需要考究自己主编语言的特点，场景，以及设计模式，

基于此给出为啥要这样设计，比如为啥有多态继承，接口，控制反转等，这些在oop中解决了哪些问题，对于项目可读性，可维护性作出了多大的贡献，诸如此类吧。

OOP复杂关系图.jpg

当然OOP的设计也是有所缺陷的，比如你可能不知道反射是啥。OOP也只是后端常用的编码思想，缺陷就是我个小弟弟能描述的了，继续：

设计模式就不说了，常用的还是得当个宝的，去搜一大推，你不搜就爱莫能助了，这里讲讲编码计划以及编写文档

很多时候写代码都是一头热的，老板->开会->需求->编码，耗时一个月编码一个小时。我们没法避免只能设计59分钟，编码一分钟了，什么你做不到？真菜-_-。

对应一个稍微大点的应用，编码前的设计可以很好的帮助你理清来龙去脉，这也是编写一个健壮代码的基础，提前设计好的方案可以协助你理清业务，从业务中来，到IDE 中出，这个过程是对需求的过程，也是写代码思路的过程，同时设计好数据库，

缓存，核心主流程，如果有足够的时间可配上伪代码，一般设计，数据库设计模型，Navicat可以编写的，Redis就直接缓存库了，流程设计直接UML设计就够了，没有必要搞过于专业的，毕竟菜，你只有一分钟编码。

至于闭环思想，略过。

 

3.编码能力提升遇到的困难

1. 困难1，无处下手

         编码能力提升的同时，你可能迫切地需要别人的认可，以至于破坏一些旧系统的代码规范也在所不惜，咱们不能操之过急（干掉漂亮），可以尝试在新项目中新模块中运用，如此反复两次以上，就吃到精髓了。

    2.困难2，有处如何下手

         保持新设计模块的独立性是非常重要的，因为初次设计经验不足必然会导致频繁修改，甚至大改，这取决编辑计划规划的完整性，所以保持模块独立性非常重要，这样可以确保你不会影响到别的地方。

  

编码过程或者说是实验过程肯定是要实战的，而实战也必然遇到困难，大的困难无非就是项目规范性问题呗，新模块开发也是项目，基础保留一致，写法保持实战是没有问题的。

 

4.编码提升的思考

这里就要讲讲编码的闭环了，闭环这概念应该产品同学的，指的是业务上，某个流程逻辑要有开始，有结束，如钱包功能，钱可以充，可以消费购物，可以退还，以及折扣等等，是一系列动作，并且可以完结。编程上也是可以借用这个概念来提升

编码的健壮性。

1.编码计划制定时，确保业务数据流向，以及最终归于何处。举例

注册账号，设计一个账号的注册流程，简单流程是：

提交账号密码->检查是否已注册->更新数据库->注册完成

但，这个流程没有涉及到插入，缓存，第三方修改，使用等，所以代码健壮性是不够的，容易二次修改导致一系列问题bug产生。

来个闭环的：

建立独立注册处理类，提供对外（内部使用等）方法，核心方法注册，拓展来源方法，拓展注册前，注册完成调用方法，拓展固定注册信息配置获取方法等，由此类统一对外服务，打包成一个黑盒，保证注册流程的闭环。

再比如常见用户类事实上可以称得上一个闭环，具备用户数据获取，获取有从缓存获取，从数据库获取，用户信息更新需更新缓存同时更新数据库，具备数据统一进，统一出的来源可以形成一个代码的闭环，没有受到外部干扰。

 

总结

个人随意瞎想的，不喜勿喷