1.2018-02-05：关于事物rollback-only异常：标识当前事物只回滚，但是回滚的动作需要异常触发，只有异常往上抛并且被捕捉到才会触发，如果最终没能够触发，事物又需要回滚就会报这个错，而且前面执行的都会保存到数据库
解决方式：1 某段逻辑不加事物
2 某段最终的逻辑不要抛出异常，事物没有捕捉到异常，就不会把事物标识成只回滚，但重点在于一定不能有任何地方抛出异常，这一点很难保证
3
MethodA 不加事务，所以执行到最后就不会commit，SUPPORTS和NOT_SUPPORTED都可以实现这种功能。
2) MethodD设置不共享事务，拥有自己单独的事务。验证发现，REQUIRES_NEW可以实现这种功能。
@Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class)
2.2018-02-07:关于明细：在做明细的时候，一定要细致，全面，也就是，总账记录要有，子账也要能提现，不能说通过很多关联查询能得到，那还要你记明细做什么
3.2018-03-01:关于linux任务调度：corntab 命令，corntab命令写完后要启动任务，shell脚本写完后，要把它变成可执行文件
4.2018-03-06：关于where 和 having 的区别：在查询过程中聚合语句(sum,min,max,avg,count)要比having子句优先执行.而where子句在查询过程中执行优先级别优先于聚合语句(sum,min,max,avg,count)，2 aving就是来弥补where在分组数据判断时的不足。因为where执行优先级别要快于聚合语句
5.2018-03-07:关于需求：客户很多时候并不能够一次确认准需要，随着时间，体验，需要会反复反复改动，这个过程伴随着大量成本，这个反复体验需求的过程，必须让客户尽可能的短，客户一定得有责任心，不然你就等着陪他反反复复改吧，做为甲方，我们，有义务和责任，引导客户 确认需求时要多想，多想对的，让他深刻知道反复的严重后果，让他得变得有责任心，双方都达不到一个开发的状态，就等着反复改着玩吧
6.2018-03-08:关于确认问题：一定不能不确定瞎几把乱扯淡，本来是原先的东西，扯着扯着就，扯成别的东西了（两个不清楚业务逻辑的人），而我只能听着他们扯，因为没有对错啊，扯的爽了就是那个东西了，只是需求变更了而已，说出去的话，发泄出去的情感，即使自己是理解错了，也得咽下去，改呗，谁让自己扯的爽了呢
7.2018-03-08:关于逻辑：过了很长时间，一个功能的出发点，逻辑，和细节肯定都忘的差不多了，这会别人，强行责问另一套逻辑，你会以为真的是自己错了，因为你已经忘记之前的了，而逻辑这种的东西，可以是很多种，都能解释的通，关键在于，当时确认 的是什么逻辑，什么出发点，那就是什么，，不要随便担责问，你随便的担了，那就真的是你的责任了。所以说之前，一定得搞清楚原先是什么出发点，逻辑，这个一定得保留，因为时间长了，你肯定忘记
8.2018-03-08：关于BUG:客户提出BUG的时候，往往伴随着需求改动，第一次提的需求肯定是不完善的，bug的出现，会让人集中目光和思考，这样就会产生很大新的东西，更完善的思想，就会觉得这个东西不是他要的，提的时候也就会带着他新的思想，而做为开发，这是bug就必须得改
9.2018-03-08：关于新的想法：新的想法融入已有的逻辑中，会伴随着大量的改动，可能要加很多东西，来完善这个新的想法，所以往往会发现，改动不是仅仅提的那个需求点，而客户当时想不到，开发可能也想不到，客户之后发现就觉得，开发人员理所应当的做这些东西，这个完全是开发的责任
10.2018-03-08：关于开发角度：作为开发，帮别人开发，首先考虑到的是成本，而不是是否完善，任何东西都可以无限的完善，在成本和时代水平下，开发会掌握一个度，一个功能只能做到这种程度，不是不能完善，是成本太大，这个也跟能力有关系，同样的开发时间成本，对于不同的人，做出来的东西完善程度是不一样的，但你要知道，大牛的时间成本跟萌新的时间成本同样不在一个级别，所以相对而言成本还是一致的，只会有略微差别，重点在科学的开发
11.2018-03-08：关于开发：上级跟客户确认下来得，新的需求，想法，交给基层开发人员开发，改动的东西需要开发人员承担，客户和上级确认时，考虑不周到的地方，也需要开发人员承担，做为开发拿到一个新的需求和想法，如果自己不想的很完善，那么之后出了任何问题，只能是自己的问题，要记住，你是开发，开发，开发之前你必须想的完善，如果确认下来的东西是不完善的，你直接做，责任完全在你，很多时候，萌新没经验是考虑不到那么多的，作为上级如果不考虑周全，也是担责，萌新已经不是有没有责任心的问题了，这完全是领导自己就不负责任了，作为基层开发，很多时候是很难考虑到一些方面的，有时候也只能做
12.2018-03-15:关于jrebel: 热部署引用外部工程（jar），首先 生成外部工程jrebel.xml,然后install外部工程，最后再启动想要启动的项目
13.2018-03-21:关于商场：没有好与不好，一切按规矩办事，我不欠你的，也不想对你好，但是根本不可能，既然能做成生意，特别是小公司，很多都是纽带关系，很难做，但是到最后即使再努力维持也没用，最后都是在扯皮，因为利益，没有一个标准，利益就变得不平衡，没人愿意拱手相送自己的利益，就意味着矛盾
14.2018-03-22:关于表设计：每张表每个字段的业务含义，表与表之间的关系,表设计的越严谨，越能降低程序出错的概率，这些问题在测试阶段更容易暴露
15.2018-03-23:关于脏数据:脏数据的控制级别，表结构级别（表设计唯一控制），代码级别（后台逻辑校验判断，这个不完全能保证，因为线程同步的问题），请求级别（控制请求，后台处理请求时判断），页面级别（控制按钮提交请求）
16.2018-03-26:关于垃圾数据:在测试阶段，伴随的大量bug，逻辑，需求的修改，这些修改前产生的数据都是将是垃圾数据，如果测试阶段直接用正式库，将会造成大量的维护数据，和重复测试的成本
17.2018-03-26:关于需求:如果你不能考虑周全需求会有多少影响，就意味着你给自己挖多少坑
18.2018-03-28:关于需求矛盾:矛盾最的起源，来至于平衡，矛盾的出现，因为不平衡，客户和开发者矛盾的出现，因为心里不平衡，心里不平衡，来自于各自心中的定位不同，彼此初始的定位是有差距的，如果定位相同，有的只有责任，该是谁的就是谁的，没有矛盾，矛盾因为彼此都不平衡，一开始的定位非常重要，只要有差距，肯定有矛盾，因为差距必须通过某种形式填满，客户得定位是会不断提高的，他接触的越多，时间越长，想法就越完善，内心的定位会不断变高，千万不要轻易给客户一个很高的定位，为了某种目的，一旦给了这个定位想降下来就难了
19.2018-03-28：关于非空:非空虽然能使程序不出异常，但也会隐藏程序bug，不该适用非空就不用，除非真的有逻辑需求
20.2018-03-29:关于任务：1.触发方式：某段业务在操作界面没有触发点，已有的功能逻辑中没有触发点
2.触发时间: 业务是在特定的某段时间，或者某个时间点触发
3.触发需求：统计数据，分析（某段时间，大量数据），如果是单个数据没必要
21.2018-03-29:关于objectMapper:不仅格式要对，数据类型也要一致
22.2018-03-30:关于appliation入口：如果appliation文件的路径，跟入口的架包不在一个目录下，架包是扫描不到这个文件的，也就是这个入口是失效的
22.2018-03-30:关于jdbcTamplate：还有个实现类NamedParameterJdbcTemplate，这个可以解析参数：
23.2018-04-04:关于linux crontab:1 crontab -e (如果没有会新建) 2 编辑格式内容不对，将没有办法installing new crontab 3 service crond restart 重启
24.2018-04-10:关于团队成熟: 技术成熟 1 可以降低开发周期，2 提高开发代码质量
业务成熟 1 可以大量减少需求讨论，探索，完善的时间和成本，2 可以避免重复返工（降低开发周期成本），3 可以使项目的起点完善度更高
25.2018-04-10:关于流程:需求是个方向，明确的需求是个业务流程，实现需求是个实现流程，作为开发，最终要带着业务实现流程去看需求，确认需求是否合理，完善，最终的代码实现业务流程
26.2018-04-12:关于客户需求:客户提出来的需求，大多数（不成熟客户）都是他们最直观看到，最终操作，看到的功能或页面，他们考虑不到，也不可能考虑，也不需要（初版），这些功能或画面需要多少其它功能，流程，才能最终实现他所想要的需求，流程才能走到他所能看到的画面，他所能操作的功能，
1.客户直接需求的背后，需要多少其它功能的支撑，需要多少步中间流程的扭转，这些作为看客户需求的人一定要想到，不然这些隐藏的工作，都得自己买单，客户都会觉得理所当然，因为当时确认的需求，你也很容易的保证答应了，钱也谈妥了，他就等着拿到他想要的产品了，你遗漏多少隐藏的工作量，到时就会爆发多大的矛盾，遗漏的这部分，就是你跟客户彼此心里定位和期望值的落差，不平衡就会有矛盾