最近刚完成了一个团队项目，虽然这次项目是建立在另外一个项目的基础上去实施，本身没有涉及到很多的设计方面的东西，但是这次项目也让我学到了很多东西，于是和另一个项目组的同学进行了总结，发现了很多需要改进的地方。
首先这次给我最深刻的教训是，项目预发布的时候，安全检查不通过，原因是存在XSS和CSRF漏洞。
这次项目是采用我们自己开发的一个框架去搭建，在过滤上只是做到了对输出的过滤，对输入的数据控制需要自己按照业务也控制，而这次我们用的框架的版本是老版的框架，并没有部署上输出的过滤，被检测出来，所以这个XSS问题，我们通过升级框架来完成对输出过滤的部署。而关于CSRF漏洞，我们是做了一层一次令牌控制，用户每次登陆都产生唯一令牌来做校验。关于这次的安全问题，我们总结如下：
A、安全意识还是很欠缺，当然这个的原因是因为时间很紧迫，根本没有时间给我们细细规划项目，考虑各个环节，但是我也觉得这个不可忽视的一个原因，是因为我们经历的项目还是太少了，还是需要不断的锻炼，积累经验。
B、项目的时间紧迫这个是一个客观因素，作为程序员的我们解决不了（可悲的，本来我觉得项目的时间作为程序员是最有发言权的，可惜现在确实产品给定时间，要我们赶工完成-_-|||），抛弃这个客观因素不说，我们还是需要挤出点时间去对项目做一个整理的梳理，不能只是埋头敲代码赶工。
其次，有关项目业务处理从层的错误码统一。
这个项目涉及到另外个团队提供的API使用，但是我们发现，在使用的时候他们会返回一套含有错误码的信息，虽然我们不能统一掉所有团队的错误码机制，但是我们总结，在自己的项目中，有必要去维护这么一份错误码。很多时候（包括我们目前完成的项目）在业务层返回的数据信息一般都是true或是flase,这在视图层或是第三方使用的时候就非常的不好用，不能明确返回的false到底是什么地方返回的false（特别是当一个方法中有多处返回false的时候，就尤为明显），这就造成调试代码的时候也很痛苦，如果我们设置了错误码，那么使用者就能很容易的直到是什么地方出错了，一般一个错误码代表一种错误信息。而对于像这种使用第三方API的编码方式，我们更倾向于将第三方的API调用结果进行封装，也输出一套自己的错误码，这样就不会受到第三方API的影响。关于错误码机制的问题，我也觉得很有必要去做一次统一，这样不但调试的时候方便，使用的时候也会大大减少成本。
第三，前台JS的封装统一。
目前来说前台的Js都是比较分散的，自己写自己的，对于js这块应该做一层通用方法的封装。同时出一份统一的编码格式及规范文档，对于一个团队开发来说，有规矩才能成方圆。
最后，代码检查这块，这块还是相当有必要，自己要对自己的代码负责，同时作为项目的一分子，也要对项目的质量负责，就算没有时间进行代码评审，自己还是不能放松。如果条件允许的情况下，我更希望是能写出单元测试，进行测试。