编码建议

 

1. 避免一个接口一个方法
1. 接口太多，难以维护
2. 需要以服务为边界，不要以数据库模型来定义边界
2. 对于给出提示的废弃的方法，不要使用，应找出替代方法
3. 不要使用using (var context = new FileManagerEntities())
1. 无法mock数据，不易单元测试
2. 应从工厂中取数据
4. 赋值优化
1. CopyTo（）
2. 类的继承
5. 避免硬编码，多用抽象的方法、服务来实现
6. 异常处理，catch中return需要慎之又慎
1. 除非对代码没什么影响，可以return
2. 否则，最好throw出去，给最外层处理
7. 面向微服务的方法
8. 参数传递函数的方法，需要谨慎
1. 对内使用，可以用此方法
2. 对外使用，需尽力避免

 

1. 所有类、接口、属性，均需注释，用于生成API的说明文档
2. 所有js均不能设置为全局，需要封装成对象，防止页面js与引用js产生冲突
3. Json返回必须为对象，不要将其序列化为字符串：不易测试和封装
4. 需要考虑用户使用习惯。对于查询和导出两个功能，如果查询次数远大于导出次数，则导出可以使用查询的代码，第二次查询：如果查询数据太多，而将查询数据放在隐藏域，太占用空间；反之，如果查询次数基本等于导出次数，则可以将查询数据放在隐藏域，避免查询占用时间过大。
5. 对用产品需求的任何变化，必须要找产品确认，不可擅自改动。对于任何与原先情况不同的改变，需要给出充分的理由
6. 完成一项产品需求，需要给出意见：如何实现可以有更高的效率，更好的UI交互……
7. 对于任何重复的劳动，需要想办法简化，一定避免重复劳动，多动脑筋
8. 对于任何脚本的实现，都需要记录并给予规范的命名，迟早会用的到，避免重复劳动

 

1. 需求文档
1. 判定产品人员类别：偏市场or偏产品
1. 偏市场的产品，需要自己花时间理清思路，然后开始写代码
2. 对于需求文档，需要自己总结确认
3. 问清楚需求对应的业务逻辑，了解整个业务流程，有助于构造好的产品
2. 单元测试
1. 保证覆盖率
2. 保证所有方法都是可测试的
3. 对业务逻辑、业务流的可测试性

 

1. 参数设计为类：参数灵活、可复用、易修改
2. 命名规范：
1. 大小写
2. 实际意义的命名
3. 类间赋值
1. 参数大多相同的，用基类表示，并CopyTo（）
4. 注释
1. Tool工具生成类时，需要添加注释
2. SeeAlse来规避重复注释
5. 查找问题
1. 先日志，避免代码查找
6. 编码习惯
1. 内存释放：using、try catch final中释放
2. Request方法的入口，参数检查
7. 尽量避免警告信息；否则，给出必要的理由