CRM的dev(总结)--多思考，先实现，再优化！

时间辗转，难忘当年!
当我上上个月的最后一天走进这家公司，熟悉环境项目什么的，过了几天，开始着手做项目，刚开始本来是让我做一个模板生成的项目，让我熟悉FreeMarker，后来由于CRM这个项目比较紧急，就让我转战开发CRM客户关系系统的项目，刚拿到手的这个项目，在我眼中的无非也就是一些增删改查的套路和流水线似的坦克大战····等到开发的时候，才会发现有时候，如此轻蔑地态度，必然会让自己吃上不小的亏，虽然现在已经开发完成了整个项目的前端，后台，测试，临近上线，回过头来，再看个把月前的自己，真的很有感触·····
给我最大的三个感触：
1）任何项目，任何公司领导分配下来的活，先别管这个项目是多么的简单，又或者你是如此这般的轻蔑和不屑，再或者你非常牛逼，都懒得写这种类型的，可以，但是咱话得敞开了，装逼需要本钱！不用考虑这个那个乱七八糟的，一句话：先尽己所能的着手思考和熟悉你要做的是什么项目，做的是什么事情，知道自己要干什么，怎么干，干多久，在你下手开始搬砖之前，请认真的问问自己，考虑好了嘛？想清楚了嘛？如果连这一点都无法确认的话，请不要轻易去动手，因为，真的可能会吐血而亡，这里我说的是你的领头老大BOSS，被你气的吐血而亡，因为很可能会因为考虑不周到，最后变成返工，重写的悲剧····悲惨世界的悲，楚乔传电视剧的剧，不写几个比较潮的东西，你们还以为我是深山老林里出来的老衲，我靠，我屌丝嘛？好吧，我承认，我有点！我也是·····醉了··
小生感想–PS to U：万事开头难，不妨多想想···
2)很多时候当你因为错综复杂的业务逻辑抓破脑袋，眉头紧锁的时候，不妨多看看流程图，甚至可以自己用笔画一些步骤的流程，切身的体会一下每一个步骤的必要性和不可或缺的某些条件，绘图可以帮助自己更好的理解清楚业务的执行流程和顺序，同时，最好能够对业务的一整套可以有自己的梳理思维，你可以用汉字，用符号，用绘图等等你能想到的方式去尽可能的帮你诠释和理解，最终的目的只有一个：认识深刻
小生感想–PS to U：漫漫人生路，何苦逻辑多···
3）别管项目需要怎样的优雅和端庄，都是大老爷们，当然也有一些漂漂姐姐是程序员哈，爱怎么美化怎么美化，我们需要去做的，先不是考虑如何能把他做的尽善尽美，而是重点考虑怎样在自己理解业务场景和背景的情况下更好的去实现功能点，永远都是先实现功能点，然后再考虑优化的事情，当然一些基本的规范在开发的时候还是要遵守的，你可以理解为潜规则···但是你得考虑好Java可是航空母舰，潜的深，理解的才透彻···
小生感想–PS to U: 力拔山兮气盖世，功能点后美顽石···
本次的开发，中间遇到了很多的问题，一方面自己对问题的认识和考虑不周，理解不透彻，有一些细节的东西没有考虑周全，再者就是一些业务逻辑的处理，还有的是一些平常中需要努力去养成的好习惯和一些努力去改掉的坏毛病，关于CRM场景的一些问题，现在列表如下，如果各位看官以后遇到或者有一些新奇的想法随时欢迎前来赐教：
1）手机号脱敏后保存的特殊校验；
2）新增和更新时下拉框赋予不同的选项；
3）查看，新增，编辑，查询，申请，审核等等按钮之间数据的干扰和入侵，互相影响，例如：点完查看，再点编辑，显示错误数据等等；
4）新增时候，下拉框的选项单个，并且制度状态，不可编辑，以及只读状态的获取；
5）多条件组合查询，下拉框和时间框的选择以及值的获取；
6）前，后端当前登录用户的获取；
7）实体类中需要某些特殊字段，不存库，用来显示，此外，需要自己去赋予特殊业务场景的值；
8）金额的校验以及大小的限制和格式化；
9）列表页的每一行增设单选按钮并且每一行特定情况下的背景色改变；
10）数据库存储的用户id以及各种状态对应的数字1,2,3,4，需要在列表显示，查看，增加，编辑，审核的时候显示成对应的中文
11）引用对象由于中文转换，修改了原有的值，需要的处理；
12）人工选择和人工操作的按钮，前端怎么点击，后端怎么写，不需要特定的判定条件，只需要和前端保持一致；
13）新增，更新之前的字段查重；
14）后端对象在前端的调用；
15）新增和编辑功能保存时的调用区分；
········································
等等等等···················一系列的问题吧，有的真的不难，有的没有考虑到，有的的确不知道怎么去做，但是问朋友，问同事，百度，自己想，琢磨···等等一千种一万中的方式，搞出来结果是次要的，弄清楚为什么这样做才是自己真的学会了很多！
PS：感谢所有帮过我的人，今天多留一份汗，明天少说一句求人的话！
加油↖(^ω^)↗，小生！！！
谢谢各位看官！