你应该总是抽出什么OOP编码实践？

Question

我倾向于在很短的期限内做很多项目,并且有很多代码永远不会再次使用,所以总是有压力/诱惑偷工减料.我总是坚持的一个规则是封装/松耦合,所以我有很多小班而不是一个巨大的上帝班.但我还有什么不妥协的呢？

更新 - 感谢您的好评.很多人都建议进行单元测试,但我认为这并不适合我所做的UI编码.可用性/用户验收测试似乎非常重要.重申一下,我在谈论针对不可能的截止日期项目的编码标准的BARE MINIMUM.

Answer 1

不是OOP,但是在短期和长期都有帮助的做法是DRY,不要重复自己.不要使用复制/粘贴继承.

Answer 2

不是OOP练习,而是常识;-).

如果你赶时间,不得不写一个黑客.总是添加一条评论原因.所以你可以追溯它,以后再做一个好的解决方案.

如果你没有时间回来,你总是有评论,所以你知道,为什么现在选择解决方案.

Answer 3

使用Source控件.

无论设置多长时间(秒......),它都会让您的生活更轻松!(仍然不是与OOP有关).

Answer 4

命名.在压力下你会写出可怕的代码,你没有时间记录甚至评论.尽可能明确地命名变量,方法和类几乎不需要额外的时间,并且在必须修复它时会使可读性变得可读.从OOP的角度来看,使用名词和动词来表示方法自然有助于封装和模块化.

Answer 5

单元测试 - 帮助你晚上睡觉:-)

Answer 6

这是相当明显的(我希望),但至少我总是确保我的公共接口尽可能正确.类的内部结构总是可以在以后重构.