您应该始终抽出时间进行哪些OOP编码实践？
我倾向于在很短的期限内完成很多项目，并且有很多代码永远不会被使用，所以总是有压力/诱惑去抄近路。我一直坚持的一条规则是封装/松耦合，因此我有很多小类，而不是一个巨大的类。但还有什么我永远不能妥协的呢您应该始终抽出时间进行哪些OOP编码实践？,oop,rad,Oop,Rad,我倾向于在很短的期限内完成很多项目，并且有很多代码永远不会被使用，所以总是有压力/诱惑去抄近路。我一直坚持的一条规则是封装/松耦合，因此我有很多小类，而不是一个巨大的类。但还有什么我永远不能妥协的呢 更新-感谢您的大力响应。很多人都建议进行单元测试，但我认为这并不适合我所做的UI编码。可用性/用户接受测试似乎非常重要。重申一下，我指的是不可能在最后期限内完成的项目的最低编码标准。不是面向对象的，但短期和长期都有帮助的实践是枯燥的，不要重复你自己。不要使用复制/粘贴继承。没有带有可变公共变量（类似
更新-感谢您的大力响应。很多人都建议进行单元测试，但我认为这并不适合我所做的UI编码。可用性/用户接受测试似乎非常重要。重申一下，我指的是不可能在最后期限内完成的项目的最低编码标准。不是面向对象的，但短期和长期都有帮助的实践是枯燥的，不要重复你自己。不要使用复制/粘贴继承。没有带有可变公共变量（类似结构）的公共类 在你知道它之前，你在你的代码中引用了这个公共变量，当你决定这个字段是一个计算字段并且里面必须有一些逻辑的时候。。。重构变得一团糟
如果那一天在你的发布日期之前，它会变得更混乱。不是OOP实践，而是常识；-） 如果你赶时间，必须写一篇文章。始终添加一条带有原因的评论。因此，您可以追溯它，并在以后制定一个好的解决方案
如果你从来没有时间回来，你总是会有评论，这样你就知道为什么选择了现在的解决方案。单元测试-帮助你晚上睡觉：-）这很明显（我希望如此），但至少我总是确保我的公共界面尽可能正确。类的内部可以在以后进行重构。使用源代码管理
无论设置需要多长时间（秒），它都会让您的生活更轻松！（仍然与OOP无关）。对于这种特殊情况（期限短，并且有很多代码将永远不再使用），我建议您注意在OOP代码中嵌入一些脚本引擎 想想那些在某个时候必须阅读和理解代码的人（甚至可能是你未来的自己）。和其他人一样，没有太多的OOP实践，也没有太多适用于OOP的编码实践
这正是你需要提前做这些事情的原因。所有这些做法都使持续维护变得更容易。当您在项目启动时承担更多风险时，您就越有可能花费越来越多的时间来维护代码。当然，有更大的前期成本，但建立在坚实的基础上为自己付出代价。您的障碍是缺少时间（即必须维护其他应用程序）还是上级的决定？我不得不在这两个方面进行斗争，才能采取这种做法，而且这不是一个令人愉快的局面。。在压力下，你会写出可怕的代码，你没有时间去记录甚至评论。尽可能显式地命名变量、方法和类几乎不需要额外的时间，并且当您必须修复它时，将使混乱变得可读。从OOP的角度来看，使用名词表示类，动词表示方法自然有助于封装和模块化 就像所有人都建议的那样，这些建议并不特定于OOP： 确保注释代码并使用合理命名的变量。如果您必须回顾您编写的快速而肮脏的代码，那么您应该能够轻松地理解它。我遵循的一般规则是：；如果您删除了所有代码，只留下注释，那么您应该仍然能够理解程序流程 黑客通常是复杂的，不直观的，所以一些好的评论是必不可少的 我还建议，如果你通常不得不在紧迫的截止日期前工作，那么根据你最常见的任务为自己建立一个代码库。这将允许你“连接点”，而不是每次你有一个项目时重新发明轮子 问候,
Docta[在此插入样板文件，而不是OOP特定的警告]
- 关注点分离、单元测试，以及如果某件事情太复杂，可能还没有完全正确地概念化的感觉
- UML草图：这已经澄清并节省了多次浪费的精力。照片很棒，不是吗？：）
- 真的在想is-a和has-a。第一次做对是非常重要的