这完全取决于公司文化。我在一些团队中工作过，每个小决定都掌握在产品负责人（PO）手中，我也在一些团队中工作过，软件工程师是受尊重的专业人士，能够自己做出技术决策。我发现第二种方式能更快地创造出高质量的软件。另外，我不确定你所说的额外努力是什么意思？created_at、updated_at或软删除是大多数正确框架的一部分。在Spring中，你只需要一个注解，我在主要项目中使用过这些，实现成本只有几秒钟，到目前为止在多年的开发中没有维护成本。至少这些字段是已经解决的问题。
源讨论YAGRI：你将会读到它原帖 156 条评论 · 导入时统计这些决策不应该仅由编写后端代码的人来做出。 它们需要向产品负责人汇报，由他们来决定。可能确实有理由不存储某些数据。而且所有这些都会增加复杂性，更多可能出错的地方。 如果产品负责人想要开始跟踪每一次更改以及是谁做的，这将完全改变你的数据库需求。 所以要正确地进行这次讨论。然后决定是否不值得，不要添加任何你‘可能’需要的‘额外’字段，或者决定值得，彻底地进行规格设计，并说明完成它需要多少额外的时间和努力，作为一项完整功能。但不要以某种半成品的‘临时’方式来‘帮忙’给未来的程序员，他们可能不得不将其删除。 在个人项目中，你可以随心所欲。但在专业项目中，这些事情需要进行规格设计并加以考虑。…
完整原文把你的经验，加入这段讨论。
更好一点的做法是假设使用软删除，并告诉他们这就是删除的方式——如果存在硬删除的硬性要求，他们会告诉你的。 这个假设的未来程序员就是两周后的你。
完整原文但如果这不是一个技术决策呢？如果围绕数据保留存在法律影响，而你并不需要了解这些呢？ 我曾参与过一些团队，由于开发人员做出了重大假设，结果发现这些假设是错误的，不得不完全扔掉并重新构建功能，因为他们没有与产品负责人确认。因为他们假设这只是一个“技术决策”，或者他们假设自己了解客户需求，尽管从未真正询问过客户。 当然，这并不意味着在编写每一行代码时都要与产品负责人确认。但决定哪些信息存储在数据库中，你进行的事件跟踪级别，删除是硬删除还是软删除——这些都有巨大的产品影响，可能还有法律影响。 而且这需要额外的努力。现在你必须为所有这些事情编写测试。时间戳是否正确...…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。