编码建议
- 避免一个接口一个方法
- 接口太多,难以维护
- 需要以服务为边界,不要以数据库模型来定义边界
- 对于给出提示的废弃的方法,不要使用,应找出替代方法
- 不要使用using (var context = new FileManagerEntities())
- 无法mock数据,不易单元测试
- 应从工厂中取数据
- 赋值优化
- CopyTo()
- 类的继承
- 避免硬编码,多用抽象的方法、服务来实现
- 异常处理,catch中return需要慎之又慎
- 除非对代码没什么影响,可以return
- 否则,最好throw出去,给最外层处理
- 面向微服务的方法
- 参数传递函数的方法,需要谨慎
- 对内使用,可以用此方法
- 对外使用,需尽力避免
- 所有类、接口、属性,均需注释,用于生成API的说明文档
- 所有js均不能设置为全局,需要封装成对象,防止页面js与引用js产生冲突
- Json返回必须为对象,不要将其序列化为字符串:不易测试和封装
- 需要考虑用户使用习惯。对于查询和导出两个功能,如果查询次数远大于导出次数,则导出可以使用查询的代码,第二次查询:如果查询数据太多,而将查询数据放在隐藏域,太占用空间;反之,如果查询次数基本等于导出次数,则可以将查询数据放在隐藏域,避免查询占用时间过大。
- 对用产品需求的任何变化,必须要找产品确认,不可擅自改动。对于任何与原先情况不同的改变,需要给出充分的理由
- 完成一项产品需求,需要给出意见:如何实现可以有更高的效率,更好的UI交互……
- 对于任何重复的劳动,需要想办法简化,一定避免重复劳动,多动脑筋
- 对于任何脚本的实现,都需要记录并给予规范的命名,迟早会用的到,避免重复劳动
- 需求文档
- 判定产品人员类别:偏市场or偏产品
- 偏市场的产品,需要自己花时间理清思路,然后开始写代码
- 对于需求文档,需要自己总结确认
- 问清楚需求对应的业务逻辑,了解整个业务流程,有助于构造好的产品
- 单元测试
- 保证覆盖率
- 保证所有方法都是可测试的
- 对业务逻辑、业务流的可测试性
- 参数设计为类:参数灵活、可复用、易修改
- 命名规范:
- 大小写
- 实际意义的命名
- 类间赋值
- 参数大多相同的,用基类表示,并CopyTo()
- 注释
- Tool工具生成类时,需要添加注释
- SeeAlse来规避重复注释
- 查找问题
- 先日志,避免代码查找
- 编码习惯
- 内存释放:using、try catch final中释放
- Request方法的入口,参数检查
- 尽量避免警告信息;否则,给出必要的理由
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 没有源码,如何修改代码逻辑?
· NetPad:一个.NET开源、跨平台的C#编辑器
· 面试官:你是如何进行SQL调优的?