文章目录
- [1. 先理解需求,后写代码](#1. 先理解需求,后写代码)
- [2. 前后端都要校验](#2. 前后端都要校验)
- 3,避免使用JOIN查询以提高性能
- 4,用常量类代替魔法数字
1. 先理解需求,后写代码
惨痛经历
几年前,我所在的团队负责为开发一个在线预订系统。
项目启动之初,我们急于展示成果,没有充分理解客户的具体需求就开始了编码工作。我们认为只需要实现基本的预订功能即可,比如让用户选择日期、时间、人数等,并能够发送预订请求销售公司。
然而,当我们将初步版本展示给客户时,客户提出了一系列我们未曾预料到的需求。比如,他们需要一个会员系统来积累积分;还需要根据不同的时间段设定不同的预订规则;另外,还需要有一个功能来处理取消预订的情况,同时要通知其他等待预订该时段的顾客。
由于我们没有在一开始就彻底理解这些需求,导致后期需要进行大量的重构工作。这不仅延误了项目的交付时间,还增加了额外的成本。据估计,因为前期的需求理解不足,我们额外花费了大约两周的时间来弥补这一失误,而原本这些时间可以用来优化用户体验或其他特性。
教训
- 深入沟通:在项目开始时,应该花更多的时间与客户进行深入沟通,确保理解每一个细节。
- 需求文档:制定一份详细的需求文档,并让所有相关人员签字确认,以确保每个人都对项目有相同的理解。
- 持续迭代:即使在项目初期,也应该采用敏捷开发的方法,持续迭代并获得客户的反馈,以便及时调整方向。
2. 前后端都要校验
惨痛经历
在另一个项目中,我们需要为一家集团开发一个营销管理系统。我们决定在前端实现数据校验,以提供即时反馈给用户。然而,我们忽略了后端的数据校验。
结果,尽管前端能够阻止大多数错误的用户输入,但仍有一些恶意用户找到了绕过前端校验的方法,向我们的服务器发送了非法数据。这些数据包括超长字符串、特殊字符序列以及其他不符合规定的内容,导致我们的数据库出现了问题,甚至引发了几次服务中断。
我们不得不紧急修复这些问题,并加强后端的数据校验机制。这次经历让我们意识到,仅仅依赖前端校验是不够的,必须在后端也进行严格的校验。
教训
- 前端校验:在前端实现即时校验,以提供良好的用户体验,但应视为第一道防线。
- 后端校验:在后端实现严格的校验逻辑,确保数据的一致性和安全性。
- 数据过滤:使用参数过滤器和验证器来确保所有传入的数据都是合法的,并且符合预期的格式。
- 安全防护:增加安全措施,如SQL注入防护和XSS攻击防护等,以保护系统免受攻击。
3,避免使用JOIN查询以提高性能
有一个开发中需要遵循的原则:避免使用JOIN查询以提高性能。
在数据库查询中,JOIN操作可能导致性能问题,尤其是涉及多表关联时。JOIN操作会增加查询复杂度,可能导致大量的磁盘I/O操作和CPU计算开销,尤其是在处理大数据量时。此外,JOIN查询还可能因索引失效而进一步降低查询效率,尤其是在没有适当索引支持的情况下。因此,减少JOIN操作是提高查询性能的有效手段之一。
4,用常量类代替魔法数字
把代码中的常量抽取到常量类中,是一个非常有用的编码经验,避免把字面量硬编码在代码中。
-
让代码更整洁:
- 把所有的常量都放在一个地方,就像把所有的调料都放在调料盒里一样,找起来方便,也显得更整洁。
-
避免手滑:
- 如果你直接在代码里写一些固定的值,比如
"success"
或者10
,万一打错字或者数字,可能要花好长时间才能找到错在哪。用常量类就不用担心这个问题了。
- 如果你直接在代码里写一些固定的值,比如
-
容易改错:
- 如果你有一天突然想把
"success"
改成"ok"
,你只需要在一个地方改,不用满世界去找。这就像是你只需要改一个地方的地址,而不是给每个人发信通知他们你的新地址。
- 如果你有一天突然想把
-
编译器帮你把关:
- 如果你用的是常量,编译器会在你写错的时候提醒你。就像是有个严格的老师在旁边盯着,让你不容易犯错。
-
让代码更好懂:
- 比如说,你用
"SUCCESS"
或者"ERROR"
这样的词,别人一看就知道你是啥意思,不像1
和0
那样让人摸不着头脑。
- 比如说,你用
-
防止误操作:
- 在Java里,常量通常是
public static final
的,这意味着一旦设定就不能再改。这就像是给你的钱存进银行,不会被偷走。
- 在Java里,常量通常是
-
方便国际化:
- 如果你的应用要面向全世界,不同的语言需要用不同的文字。把这些文字都放在常量里,以后要换语言就方便多了。
-
可能更快:
- 编译器有时候会把常量直接嵌入到代码里,这样运行起来会更快一点,就像是你提前把菜切好了,做饭的时候就快多了。