OOP编码实践应该总是为时而准备?

我倾向于在短时间内做很多项目,并且有很多代码将永远不会被再次使用,所以总是有压力/诱惑.我一直坚持的一个规则是封装/松散耦合,所以我有很多小班,而不是一个巨人神班.但还有什么不应该妥协的?

更新 – 感谢伟大的回应.许多人都提出了单元测试,但我认为这不是真正适合我所做的UI编码.可用性/用户验收测试似乎非常重要.要重申,我在谈论不可能的最后期限项目的最低编码标准.

不是OOP,但是在短期和长期都有帮助的做法是干,不要重复你自己.请勿使用复制/粘贴继承.
相关文章
相关标签/搜索