当然，我会提供一个更具体的例子来说明这两个原则的重要性及其背后的惨痛经历。
1. 先理解需求，后写代码
惨痛经历
几年前，我所在的团队负责为开发一个在线预订系统。
项目启动之初，我们急于展示成果，没有充分理解客户的具体需求就开始了编码工作。我们认为只需要实现基本的预订功能即可，比如让用户选择日期、时间、人数等，并能够发送预订请求销售公司。
然而，当我们将初步版本展示给客户时，客户提出了一系列我们未曾预料到的需求。比如，他们需要一个会员系统来积累积分；还需要根据不同的时间段设定不同的预订规则；另外，还需要有一个功能来处理取消预订的情况，同时要通知其他等待预订该时段的顾客。
由于我们没有在一开始就彻底理解这些需求，导致后期需要进行大量的重构工作。这不仅延误了项目的交付时间，还增加了额外的成本。据估计，因为前期的需求理解不足，我们额外花费了大约两周的时间来弥补这一失误，而原本这些时间可以用来优化用户体验或其他特性。
教训
- 深入沟通：在项目开始时，应该花更多的时间与客户进行深入沟通，确保理解每一个细节。
- 需求文档：制定一份详细的需求文档，并让所有相关人员签字确认，以确保每个人都对项目有相同的理解。
- 持续迭代：即使在项目初期，也应该采用敏捷开发的方法，持续迭代并获得客户的反馈，以便及时调整方向。
2. 前后端都要校验
惨痛经历
在另一个项目中，我们需要为一家集团开发一个营销管理系统。我们决定在前端实现数据校验，以提供即时反馈给用户。然而，我们忽略了后端的数据校验。
结果，尽管前端能够阻止大多数错误的用户输入，但仍有一些恶意用户找到了绕过前端校验的方法，向我们的服务器发送了非法数据。这些数据包括超长字符串、特殊字符序列以及其他不符合规定的内容，导致我们的数据库出现了问题，甚至引发了几次服务中断。
我们不得不紧急修复这些问题，并加强后端的数据校验机制。这次经历让我们意识到，仅仅依赖前端校验是不够的，必须在后端也进行严格的校验。
教训
- 前端校验：在前端实现即时校验，以提供良好的用户体验，但应视为第一道防线。
- 后端校验：在后端实现严格的校验逻辑，确保数据的一致性和安全性。
- 数据过滤：使用参数过滤器和验证器来确保所有传入的数据都是合法的，并且符合预期的格式。
- 安全防护：增加安全措施，如SQL注入防护和XSS攻击防护等，以保护系统免受攻击。
3，避免使用JOIN查询以提高性能
有一个开发中需要遵循的原则：避免使用JOIN查询以提高性能。
在数据库查询中，JOIN操作可能导致性能问题，尤其是涉及多表关联时。JOIN操作会增加查询复杂度，可能导致大量的磁盘I/O操作和CPU计算开销，尤其是在处理大数据量时。此外，JOIN查询还可能因索引失效而进一步降低查询效率，尤其是在没有适当索引支持的情况下。因此，减少JOIN操作是提高查询性能的有效手段之一。
