软件项目总结
需求分析阶段: 1.需求人员分析需求，应该考虑到用户的真实使用场景，如果需求不切合实际，这样会导致过多的需求变更。设计开发人员应该对需求持以怀疑态度，需求三问，问清楚需求来源，问清楚需求内容，问清楚需求使用场景，如果需求人员无法解答，请需求人员找客户找客户，当然这不是针对需求细节，而是一些大方向以及需求要点。
2.需求规格说明书应该是需求人员编写，而不是开发人员自己去做，这样会导致同需求同开发。
设计阶段: 1.设计分为数据库设计和功能详细设计，数据库设计为了让每个人能会设计数据库，所以需要开发设计自己模块，但是开发自己设计的怎么样，谁都不知道，有些可能开发过程中暴露出来，有的甚至到项目后期或项目上线，后续数据库更改引发的工作量和问题都是很多。所以为了设计好数据库，首先要遵循数据库设计规范，其次有公共模块和同组其他人员去审核db设计，审核有明显问题，就得去更改，保证数据库设计尽量完整、稳定，后续尽可能不出现大的改动。
2.功能详细设计：首先功能设计开发自己有个设计蓝图和需求理解，这个需要和设计对需求人员进行反串讲，避免出现需求背离现象。详细功能设计完成后需要交给领导或者需求人员审核。
接口调试：
1.一定要注意到异常情况，刚开始调接口没有注意异常情况，导致后续出现了一些问题，所以这个异常考虑要遵守 不光自己要考虑异常，也要要求别人去考虑异常情况。
开发阶段：
1.这个阶段存在问题是最多的，一千个人眼中有一千个哈姆雷特，每个人实现代码的方式和思想都是不一样的。
2.先说代码规范，代码的缩进方式、和对齐方式没有一个统一的格式，导致代码结构层次不清晰。
3.svn提交记录没有一点注释，这样以后追述提交记录都很难。
4.有的java、js代码全篇没有一行注释，自己写的代码不光是给自己看的，其他人也会看，就算自己看懂，时间长了也不知道写的什么鬼。
5.还有类似于超长方法的，一个方法随便几百行代码（再加上没有注释），出了问题很难定位，让阅读者很难理解。
6.循环操作数据库，会导致系统性能问题，开发者的自己必须注意。
7.项目是controller、service、dao分层结构，为什么要把所有的业务逻辑写到controller，那还要service层做什么。
8.代码模块缺乏提取共性意识，有的地方每增加或者改动一个小点，都会增加一大块代码块，最终会导致整个业务类或者脚本过度复杂和臃肿，给后期维护和修改带来不少困难。
9.还有一点，实现功能不要为了实现而实现，要求要做1你就做1，殊不知根本不符
合需求。要想着这个功能是怎么来的，这个功能要解决什么问题，要实现举一反三。
10.系统中很多打印日志的地方全用的system.out,打印日志就用专门的打印方法。
11.咱们系统和外部系统对接，和硬件对接模块，很多地方都有通信，所以这些重要模块一定要尽可能多的打印日志，考虑各种情况，虽然说打印日志就多写几行代码，但是对于找到问题的根源可是太方便了。
编程规范可以通过 引入一些外部组件实行规范，比如，javaformat、jsformat、checkstyle、findbugs、codecc等。
代码编写问题必须引入代码提交审核制度，可以让同事互相审核，提交时写上审核人，如果审核不通过，不能提交。
转测试阶段：
1.测试人员应该尽可能多的覆盖测试用例，不能为了测试功能而测试，举一反三去测试，考虑正常情况外，一定要考虑异常情况。
2.测试提问题时，一些模棱两可的问题，有些自身感觉是问题，开发说不是，那就找需求或者领导，不能开发说不是问题就不是问题。
3.测试尽可能的将测试环境模拟正式环境，有些能做到的就做到，做不到的就申请，或者从现场导出数据，将测试环境当成正式环境使用。总之为了尽可能早的将问题暴露出来。
4.测试环境不符合正式环境要求的，尽可能找开发模拟，比如现场没有亮灯货架，可以让开发加个出口，弹框显示哪些亮哪些灭，将测试流程的终端和调试现场紧密结合起来。
上线前：
1.系统以及功能是做给用户的，对开发测试而言 ，用户就是需求人员。一定要得到需求人员的认可才可以上线，所以就需要需求人员将所有功能和流程全部走完，确保所做的东西是客户需要的。
2.鉴于开发人员和需求人员代沟比较大，需求人员一定要理解开发人员实现想法，请需求人员一定要有耐心去走完全流程，一些小的问题先记下来，可以不用立刻改，类似于流程或者阻塞问题必须改。
3.有些场景开发测试环境没有，必须要到生产现场调试的，一定要提前准备好生产环境，提前调试。
上线运行时：
1.现场人员一定要分清楚哪些是紧急问题、bug、优化、新需求等，这样会给开发人员留给更多时间解决紧急问题，处理问题有个优先级。
2.现场人员一定遇到问题不要谎，是问题就接反馈，不是问题新需求就一定不要接。
3.对于客户现场反馈的问题，不能用开发的方式回答用户，尽可能贴近用户的想法满足用户，或者让用户等待立刻修复，或者说用户操作失误。给用户提示一个正确的思路。