程序
前端
前端 预申请和索赔单共同功能封装
多文件上传功能
单选功能的使用
前端表单使用下标循环的问题
后端
事件监听 有效的减少了循环注入的问题
JWS有比较规范的开发
前期针对bug修复提交代码次数较多，改进测试方法后，尽量减少了代码提交次数。
项目开发层级分明（VO,DTO,QO)，学到了分层的好处
项目分层很方便
JOB的使用，让定时任务分离出来
标签注释 （非空标签使用，可以不用自己写代码判断 添加/修改/删除 都可以自己定义）
统一记录操作信息，这个很方便
后端字段可读性 可理解性
权限，SQL不能有多个WHERE
龙哥代码太高端，疯狂吐槽
使用体验 有些冗余
接口复用性不高，重复接口太多了
代码还需要更加简洁化，有些乱
项目日志 需要增加重要的步骤
测试
测试bug重复率的问题
项目实践紧，开发交出的代码质量没有那么高，SIT经常被BLOCK住，进而引起测试时间更加压缩，测试质量受到影响
bug修复后的回测理论上应该把bug和其相关联的业务都回测一下，保证没有次生bug的出现，但还是时间问题只对bug本身功能回测，没有发现次生的bug
项目管理过程
发版时，经常会覆盖掉之前的代码
前期沟通不够充分，需要多对开发测试培训
测试开发还需要提高自己的技术水平
前后端沟通上还是有比较多的冲突，开始没沟通好，导致后期的联调耽误时间
后端完成接口后，希望可以先发出来，空接口也可以，让前端可以提前进入
开发一些基本IT意识欠缺（比如一个entity的增删改查）
有一些说过多次的问题，没有根本的解决方法，比如操作页面后的刷新（copy代码也要copy完整）
开发测试leader在开发过程中的沟通不够，导致偏差，每个Sprint是否可以详细解析，开发和测试中应该注意的问题
项目周期不能再压缩了
项目实践紧迫的情况下，项目计划做的很合理，并且严格按照计划执行，没有大的delay
团队成员各司其职，合作顺畅，相处融洽，基本都是遇到问题共同解决，很少有推诿甩锅的情况->管理氛围好
对于涉及文档中未明确的小需求变更，没有清晰的变更流程，出现了产品直接让开发改但测试不知情的情况，改完未经过测试，改好的功能实现了，但是引起的其他问题未被发现。
测试直接让开发改代码，产品不知道，之后发现不符合正常业务需求，或关联业务没有考虑彻底，造成返工和回滚等<br>（发现问题->共同讨论找到方案->产品更新文档->通知项目群->实施）
用禅道进行沟通，提高了工作效率，每个人清晰清楚自己的任务，沟通效率提高
产品
需求界线不明确（工时部分），说不定还有需要修改的部分
需求沟通时 没有沟通明确 各方面对需求的认识有问题
问题反馈的回应有待改进，有时候讨论好的东西 过段时间就石沉大海了。
前期需求做的很彻底，整个过程中没有出现很大的需求改动或某个功能不合理推倒重来的情况
接到需求时，要多考虑需求的可拓展性以及对其他功能的影响。
与测试和开发人员多沟通，大家集思广益，提出自己在开发和测试过程中遇到的问题，对需求进行优化
对于原型以及文档，及时更新和下载，避免因为使用旧版本，而引发的无效工作<br>
需求讲解时，需求，开发以及测试人员同时在场，确保理解需求，及时提出觉得不合理的地方，避免因需求传递而导致的需求理解错误。<br>
针对提出的需求变更和优化，及时做好文档记录，避免后期无法追溯问题
改进措施
前端
优化框架组件，对开发人员友好，对于通用的功能需要提炼
下标使用可以在页面初始化时，用find 找到具体的Index，避免使用Magic Number<br>另外，也可以增加组件的使用，将一个页面上不同部分划分为不同组件
可以使用Mock技术，这样不需要等后台即可做前端页面的测试
后端
开设一些主流技术的讲课，提供资料，熟悉主流代码风格，避免写出一些晦涩难懂的代码
定义代码规范（可以参考阿里Java开发手册，只是多数人没读过罢了）
使用Sonar等代码检查工具（项目时间紧的情况下 不适用）
权限 可以通过优化代码的方法来适应不同的场景，等AM优化完毕，看是否可以应用到GWS之上
代码的优化需要依靠个人的研发习惯，可以看一些参考书：《代码整洁之道》
测试
灵活运用禅道搜索功能，将问题的标题和描述写的足够清晰，每次出现问题，先寻找关键字，看是否有已经发生过的问题，避免重复开同样的bug
测试需要制定一个用例与用例之间的关联，通过项目过程的问题，发现哪些用例可能会同时出现问题，测试的时候就可以测到关联的问题了。
需要通过定期的自动化测试 来发现回归错误。
项目管理过程
需求讨论时，BA，开发，测试需要一起进行。
前后端的沟通需要定义一些默认的规则，这样可以有效的减少不必要的沟通成本
高质量的原型，可以有效的减少不必要的沟通成本和返工成本
需求和开发的改动需要通知到所有人
项目周期紧迫的情况下，在成本一定的情况下，可以适当缩减项目范围
