一次设计开发的认识

20年10月的时候有朋友联系我，想要邀请我一起开发一个系统，主要采用分布式，微信小程序，web页面，数据库使用mysql和redis，一次保存持久化数据，一个作为缓存保存一些高频率使用和不需要持久化的数据。

系统不复杂但是开发过程中确各种问题频发。之前我做的系统都是比较规矩的，现有整体的系统概述文档，然后业务流程图，业务说明文档，然后是数据库E-R图，之后才开始具体的开发 。这些前期工作完成后整个系统的样机基本呈现在脑海里了。而这次开发的程序应为前期描述的简单，觉得就没必要整那些复杂的流程了，直接列了一下大概的功能块就开始干了。

后端技术主要使用springboot，springcloud，mysql，redis，分布式系统方便以后加其他功能块以及以后流量大了方便解决等问题，整体来说分布式优点多多，缺点就是相对单体架构代码上更麻烦了。

说说主要遇到了那些问题

第一用户登录问题，一开始我设计了一个用户表，商家，用户和管理员的信息都在这一个表中，其实这么做没啥问题，但我前期的登录注册写完后那个朋友非要说不清晰要吧三者信息分开，分开就分开吗，也有好处，但是这样之前的代码就要调整，用户相关的通用功能都需要三份，工作量一下增加三倍，而且这也导致和我预想中的开发流程不一致需要一个调整，也的亏是前期，要是其他功能写了很多后，那基本设计到用户信息的地方都有修改。总的来说就是我们之间前期意见没统一了，没有以前做业务分析。

第二个就是支付问题，这个是我的原因，第一次写支付相关的功能，坑比较多，前期相关技术积累调研不够，导致一个支付的功能卡了一周才完成。

第三就是争吵了，基本每次负责市场的朋友了解一些相似软件的功能后就想加进去，尤其是已有功能很多想调整，导致进度缓慢工作量加大，有些架构上的问题他觉得不理解就想指点，导致很多争吵，中途有一次差点放弃这个项目。

第四订单流程问题，也是规划调用不足的引起的，最开始的订单状态设计了6个，都是开发的时候临时想的需要那些状态才加上的，但做着做着就发现状态不够要加新的状态，导致前期订单业务这块及其混乱，也是耗时最长的地方，一个订单折腾了一个半月，最后状态数订单下15个。

在一个就是由于一开始没做设计，开发过程中有些地方没预留下扩展空间，后期一些功能的添加修改稿对之前代码大多进行了重构。

ridis与mysql数据一致性问题

认识

开发一个程序前一定先做好调研在开始，了解需要做什么，前期要做到那个程度，需要那些技术。

然后要做一个业务功能罗列分析，尽可能避免中途添加业务模块的情况。

沟通，一定要和相关人员沟通好，沟通我感觉才是做一个系统做重要的部分，让他们在开发前尽可能提出意见，然后讨论将合理的都加入到设计中。意见一定做到统一。

程序功能之间尽可能依赖关系小，尤其底层的功能块。

业务流程图也要有，我能不可能清晰的记住系统每一个业务具体情况，尤其是做个功能多了以后，这个时候有流程图才能在加功能的时候快速的知道往哪加，需要那些信息。