我倾向于在很短的期限内做很多项目，并且有很多永远不会再次使用的代码，所以总是有压力/诱惑去偷工减料。我一直坚持的一条规则是封装/松耦合，所以我有很多小类，而不是一个大神类。但还有什么我不应该妥协的呢？
更新- 感谢您的好评。很多人都建议进行单元测试，但我认为这并不适合我所做的那种 UI 编码。可用性/用户接受度测试似乎很重要。重申一下，我说的是不可能的截止日期项目的编码标准的最低限度。
Iain
问问题
1275 次
19 回答
19
不是 OOP，而是一种对短期和长期都有帮助的做法是 DRY，不要重复自己。不要使用复制/粘贴继承。
于 2008-11-24T14:19:46.247 回答
13
不是 OOP 实践，而是常识；-)。
如果你赶时间，必须写一个 hack。总是添加一条带有原因的评论。因此，您可以追溯它并在以后制定一个好的解决方案。
如果你从来没有时间回来，你总是有评论，所以你知道为什么现在选择解决方案。
于 2008-11-24T14:21:53.120 回答
9
使用源代码控制。
无论设置需要多长时间（秒..），它总能让您的生活更轻松！（仍然与 OOP 无关）。
于 2008-11-24T14:38:58.453 回答
8
命名。在压力下，您将编写糟糕的代码，您将没有时间记录甚至评论。尽可能明确地命名变量、方法和类几乎不需要额外的时间，并且在你必须修复它时会让混乱变得可读。从 OOP 的角度来看，对类使用名词和对方法使用动词自然有助于封装和模块化。
于 2008-11-24T15:31:41.593 回答
7
单元测试 - 帮助你在晚上睡觉:-)
于 2008-11-24T14:28:29.270 回答
5
这是相当明显的（我希望如此），但至少我总是确保我的公共界面尽可能正确。类的内部总是可以在以后重构。
于 2008-11-24T14:34:17.637 回答
3
没有具有可变公共变量的公共类（类似结构）。
在不知不觉中，您在整个代码中都引用了这个公共变量，而当您决定该字段是计算字段并且其中必须包含一些逻辑的那一天......重构变得混乱。
如果那一天在您的发布日期之前，它会变得更加混乱。
于 2008-11-24T14:21:42.390 回答
3
想想在某些时候必须阅读和理解代码的人（甚至可能是你未来的自己）。
于 2008-11-24T14:59:03.030 回答
2
和其他人一样，没有那么多的 OOP 实践，而是适用于 OOP 的编码实践。
- 单元测试，单元测试，单元测试。已定义的单元测试习惯于让人们专注于任务，而不是在对象之间漫无目的地“徘徊”。
- 在编写生产代码之前，定义和记录所有分层信息（命名空间、包、文件夹结构等）。这有助于充实对象关系并暴露与对象关系相关的假设中的缺陷。
- 在编写生产代码之前定义并记录所有适用的接口。如果由主管或架构师完成，这种做法还可以帮助更多初级开发人员继续完成任务。
可能还有无数其他“应该”，但如果我必须选择我的前三名，那就是名单。
编辑以回应评论： 这正是您需要预先做这些事情的原因。所有这些类型的做法使持续维护变得更容易。当您在项目启动时承担更多风险时，您将花费越来越多的时间来维护代码的可能性就越大。诚然，前期成本更高，但建立在坚实的基础上是值得的。您的障碍是缺乏时间（即必须维护其他应用程序）还是来自更高层的决定？我不得不与这两条战线进行斗争才能采用这些做法，而且这种情况并不令人愉快。
于 2008-11-24T14:59:42.220 回答
2
单一责任主体的应用。有效地应用这一原则会产生很多积极的外部性。
于 2008-11-24T17:31:42.100 回答
2
当然，一切都应该经过单元测试、精心设计、注释、检查到源代码控制并且没有错误。但生活不是这样的。
我的个人排名是这样的：
- 使用源代码管理并实际编写提交评论。这样一来，如果您想知道“我写这篇文章时到底是怎么想的”，您就有了一点点文档。
- 编写干净的代码或文档。干净、编写良好的代码应该需要很少的文档，因为它的含义可以通过阅读来掌握。黑客有很多不同。写下你为什么这样做，你做了什么，如果你有时间/知识/动机/……做对的话，你想做什么
- 单元测试。是的，它排在第三位。不是因为它不重要，而是因为如果你没有其他两个至少完成一半，它就没用了。编写单元测试是另一个级别的文档，你的代码应该做什么（等等）。
- 在添加内容之前进行重构。这听起来像是一个典型的“但我们没有时间”的观点。但与其中许多要点一样，它通常节省的时间多于成本。至少如果你至少有一些经验的话。
我知道已经提到了很多，但由于这是一个相当主观的问题，我想添加我的排名。
于 2008-11-24T18:39:53.617 回答
1
就像其他人都建议这些建议并非特定于 OOP 一样：
确保您注释您的代码并使用合理命名的变量。如果你不得不回顾你编写的快速而肮脏的代码，你应该能够很容易地理解它。我遵循的一般规则是；如果你删除了所有代码，只剩下注释，你应该仍然能够理解程序流程。
黑客攻击通常很复杂且不直观，所以一些好的评论是必不可少的。
我还建议，如果您通常必须在紧迫的期限内工作，请根据您最常见的任务为自己建立一个代码库。这将允许您在每次有项目时“加入点”而不是重新发明轮子。
问候，
博士后
于 2008-11-24T15:36:22.737 回答
1
[在此处插入样板文件非 OOP 特定警告]
关注点分离，单元测试，以及如果某件事太复杂，它可能还没有完全正确地概念化的感觉。
UML 草图：这已经澄清并节省了很多次浪费的精力。图片很棒不是吗？:)
真的在考虑 is-a's 和 has-a's。第一次做到这一点非常重要。
于 2008-11-24T17:12:44.837 回答
1
无论公司想要多快，我几乎总是尽我所能编写代码。
我发现它不需要更长的时间，而且通常可以节省很多时间，即使在短期内也是如此。
我不记得曾经写过代码并且再也看不到它，我总是通过它来测试和调试它，即使在那些少数通过实践中，例如重构以保持我的代码干燥，文档（对某些人来说）度），关注点分离和凝聚力似乎都可以节省时间。
这包括创建比大多数人更多的小类（每个类一个问题，请），并且经常将初始化数据提取到外部文件（或数组）中并为该数据编写小解析器......有时甚至编写小 GUI 而不是编辑数据手。
编码本身非常快速和容易，调试某人在“压力之下”时写的废话是一直需要的！
于 2008-11-24T17:16:49.413 回答
1
在我目前的项目将近一年的时间里，我终于建立了一个自动构建，它将任何新的提交推送到测试服务器，伙计，我希望我在第一天就做到了。我早期犯的最大错误就是变黑了。对于每个功能、增强功能、错误修复等，在我让任何人看到产品之前，我都有一个“只有一个更多”的糟糕案例，并且它实际上螺旋式进入了六个月的周期。如果每一个合理的变化都被自动推出，我会更难隐藏，而且我会在利益相关者的参与方面更加正确。
于 2008-11-24T18:23:27.877 回答
1
回到你几天/几周前写的代码，花 20 分钟检查你自己的代码。随着时间的推移，您将能够确定您的“即兴”代码是否组织得足够好，可以用于未来的维护工作。当你在那里时，寻找重构和重命名的机会。
我有时会发现我一开始为函数选择的名称并不完全适合最终形式的函数。使用重构工具，您可以在名称被广泛使用之前轻松更改名称。
于 2008-11-24T18:45:14.773 回答
1
我总是花时间实践的实际 OOP 实践是单一职责原则，因为在项目“上线”后，正确重构代码变得非常困难。
通过坚持这个原则，我发现如果我编写的代码无法满足功能或非功能需求，我很容易被重用、替换或重写。当您最终得到具有多种职责的类时，其中一些可能满足要求，一些可能不满足要求，并且整体可能完全不清楚。
这些类的维护压力很大，因为您永远不确定您的“修复”会破坏什么。
于 2008-11-25T10:50:39.227 回答
0
对于这种特殊情况（截止日期短，并且有很多代码永远不会再次使用），我建议您注意将一些脚本引擎嵌入到您的 OOP 代码中。
于 2008-11-24T14:53:05.070 回答
0
学习“随用随重构”。主要从“提取方法”的角度来看。当你开始编写一个顺序代码块时，花几秒钟的时间来决定这个块是否可以作为一个可重用的方法独立使用，如果可以，立即创建该方法。我推荐它甚至用于一次性项目（特别是如果您可以稍后返回并将这些方法编译到您的个人工具箱 API 中）。没过多久，你几乎不假思索地做这件事。
希望你已经这样做了，我正在向合唱团布道。
于 2008-11-24T18:22:34.167 回答