阶段小结

前言

这段时间疯狂的赶项目，难得找到一点空闲时间将最近的积累总结一下。希望以后能记住项目中间的这些教训。

一 . 需求变化

1. 因为在该领域没有大型项目的案例，且商业模式的不成熟，进而产生了大量的需求变动，这些不能在项目中后期再考虑 ，这些东西在项目设计初期就考虑进去是至关重要的。

2. 因为需求变动而导致的数据库变动是其中最让人头疼的问题。
   所以有以下几点可以考虑：

   ( 1 ) tinyint :
   当tinyint 长度设置为1的时候，在实体类中是可以用boolean型去接受，所以我们常用来作为true/false的存储字段。
   但是如果后期需求变动，就可能导致大面积的boolean型被转成String类型，这样会无端的造成工作量。
   解决思路 :
   如果是流程，我们可以考虑用int 或者 varchar ，通常考虑用1 ，2 ，3 等数字来作为数据，这样有利于用> < = 等判断流程 。例如 ：状态 > 5就足够判断所有5之前的流程 。

   ( 2 ) 主键的设置 :
   处于数据的弹性和可扩展型，我们之前在尽量避免使用自增主键，但是后期发现因为这一个条件导致出现了多个联合主键或者不必要的字段，得不偿失
   解决思路 :
   对于唯一性的数据，用自增主键是合适的，但是该自增主键可以根据情况不作为外键来使用，这样可以避免因为数据的变化而出现脏数据的情况 。

3. 因为需求变动而导致的代码频繁重构的问题
   重构从来就不是问题，每次重构都能让我的代码更精炼 ， 但是频繁的重构+业务的繁重会导致重构的代码出现越写越差得惨剧。
   之前就出现过 ， 需求更改又急需上线 ， 导致加班加点的修改代码 ， 但是后期发现因为这些改出来的代码导致新业务难以整合，代码复用率低 ， 代码结构混乱 ，注释混乱等一系列问题 。

   解决思路 :
   （ 1 ）预留 ：
   要预留出后面代码的空间 ， 这些可以采用抽象类和接口等思路 ，对于一些可能变换的逻辑 ， 将其作为一个单独的模块划分出来，不能影响到整体业务的流程 。
   （ 2 ）优化 与 复制的处理：
   不能投机取巧 ，选择直接复制而不是优化复用之前的代码。对于复用数极多的代码，要尽量优化 ， 选择复制的话可能出现要复制无数次 而 更改又需要更改无数次的惨剧 。 对于业务线不同的代码 ， 又不可以偷懒直接用同一个流程 ， 重写一个流程会给后面的修改带来极大的好处 。
   （ 3 ）不要为了赶而赶代码：
   这是一个原则性问题 ， 之前因为业务和性格，又单独复负责一个大型模块 ，持续了两个月996的生活 ，不仅代码质量差了 ， 身体也跟着差了 ， 形成了一种恶性循环 。现在看来，这种原则应该坚持，对效率的影响是非常大的 。 人手不足就应该补充，而不是一个人去硬抗 。

二 . 对于框架的选择

1. 这是一个很尴尬的问题，因为用的框架类似于一个外壳 ， 里面的插件是自定义添加的，这就导致了不可控的现象，我们能控制自己的代码，但是我们不能控制别人插件的代码 ， 修改源码这种事情通常是吃力不讨好，所以选择插件要注意看更新时间，更新频繁的才应该优先考虑。

n总结

未完待续。。。。。
东西很多，零零散散。
这段时间会陆陆续续总结出来。