谷粒商城实战笔记-编码经验积累
文章目录
- 1. 先理解需求，后写代码
- 惨痛经历
- 教训
- 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里，常量通常是
-
方便国际化：
- 如果你的应用要面向全世界，不同的语言需要用不同的文字。把这些文字都放在常量里，以后要换语言就方便多了。
-
可能更快：
- 编译器有时候会把常量直接嵌入到代码里，这样运行起来会更快一点，就像是你提前把菜切好了，做饭的时候就快多了。