Rails 模型命名：修复或保持原样
这与其说是一个技术问题，不如说是一个哲学问题。
我花了大约 40 个小时来开发一个新的 Rails 应用程序。它与零售相关，早期我选择“项目”这个名称来描述单个可供销售的产品。
随着时间的推移，我逐渐意识到这是一个错误——“物品”这个词太笼统了，而“产品”也许是更好的选择。
因此，我现在面临的决定是，在使用这个选择不当的名称构建更多模型之前，我是否重构/重命名我的模型、ERB 代码和表，或者我是否保持原样，节省一些时间并继续前进？我担心它反复选择后者会导致我在其他项目中看到的荒谬的技术债务，但我也认为这可能是一种过早优化的形式。
想法？
This is more of a philosophical question than a technical one.
I'm about 40 hours into working on a new Rails app. It's retail-related, and early on I chose the name "item" to describe a single available product for sale.
As time has gone on it's become obvious to me this was a mistake - the word "item" is too generic, and "product" perhaps would have been a better choice.
So the decision I'm faced with now is, do I refactor / rename my models, ERB code and tables before I build more with this somewhat poorly chosen name, or do I just leave it as-is, save some time and move on? I worry that it's choosing the latter repeatedly that results in the ridiculous technical debt I've seen on other projects, but I also think this might be a form of premature optimization.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于大中型项目来说，命名约定是绝对必要的。我想说的是，进去重构一切，使命名尽可能具体。随着新功能的引入，通用标识符很快就会失控（我曾经参与过一个项目，该项目有一个名为
UserReportReportReportParameters的类）。你越快完成这件事，痛苦就会越少。
编辑：我可能应该补充一点，如果由于截止日期或任何其他限制而无法做到这一点，请坚持使用当前的命名架构，直到您有时间立即重构所有内容。我坚信糟糕的命名约定比混合命名约定更好。
Naming convention is absolutely necessary for mid-to-large projects. I would say go in and refactor everything to make the naming as specific as possible. Generic identifiers will quickly get out of hand as new functionality gets introduced (I was once on a project that had a class named
UserReportReportReportParameters).The quicker you get this done, the less painful it will be.
Edit: I should probably add that if this is impossible due to deadlines or any other constraints, to stick to the current naming schema until you have time to refactor everything at once. I'm of the firm opinion that a bad naming convention is better than a mixed naming convention.