克服“稍后修复”的坏习惯

发布于 2024-07-27 23:29:08 字数 443 浏览 4 评论 0原文

当我从头开始编写代码时，我有一个坏习惯，即在一个函数中快速编写所有内容，一直在想“稍后我将使其更加模块化”。然后当后来出现时，我有一个工作产品，任何修复它的尝试都意味着创建函数并必须弄清楚我需要传递什么。

情况变得更糟，因为当您的项目即将完成时，重新设计类变得极其困难。例如，我通常在开始编写代码之前做一些计划，然后当我的项目完成时，我意识到我可以使类更加模块化和/或者我可以使用继承。基本上，我认为我没有做足够的规划，也没有得到超过一层的抽象。

所以最后，我陷入了一个具有大型主函数、一个类和一些辅助函数的程序。不用说，它的可重用性不太好。

有没有人遇到过同样的问题并且有什么技巧可以克服这个问题？我想到的一件事是用伪代码编写主函数（没有太多细节，但足以看出他们需要什么对象和函数）。本质上是一种自上而下的方法。

这是一个好主意吗？还有其他建议吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

南城追梦 2024-08-03 23:29:09

我发现 TDD 红绿重构规则非常有效。

回复收藏 0 原文

夜灵血窟げ 2024-08-03 23:29:09

我的经验法则是任何超过 20 LoC 的东西都应该是干净的。 IME 每个项目都基于一些“只是概念验证”，而这些“概念验证”从来没有打算最终出现在生产代码中。不过，由于这似乎是不可避免的，因此即使是 20 行概念验证代码也应该是清晰的，因为它们最终可能成为大型项目的基础之一。

我的方法是自上而下的。我编写

while( obj = get_next_obj(data) ) {
  wibble(obj);
  fumble(obj);
  process( filter(obj) );
}

并稍后才开始编写所有这些功能。（通常它们是内联并进入未命名的命名空间。有时它们被证明是单行代码，然后我可能会在以后消除它们。）

这样我也避免了必须评论算法：函数名称足以解释。

My rule of thumb is that anything longer than 20 LoC should be clean. IME every project stands on a few "just-a-proof-of-concept"s that were never intended to end up in production code. Since this seems inevitable though, even 20 lines of proof-of-concept code should be clear, because they might end up being one of the foundations of a big project.

My approach is top-down. I write

while( obj = get_next_obj(data) ) {
  wibble(obj);
  fumble(obj);
  process( filter(obj) );
}

and only start to write all these functions later. (Usually they are inline and go into the unnamed namespace. Sometimes they turn out to be one-liners and then I might eliminate them later.)

This way I also avoid to have to comment the algorithms: The function names are explanation enough.

回复收藏 0 原文

琉璃繁缕 2024-08-03 23:29:09

您几乎已经确定了问题所在。没有足够的计划。
花一些时间分析您要开发的解决方案，将其分解为功能块，确定如何最好地实现它们，并尝试分离应用程序的各个层（UI、业务逻辑、数据访问层等））。

尽早从 OOP 角度进行思考并重构。这比一切都建成之后再做要便宜得多。

回复收藏 0 原文

玩物 2024-08-03 23:29:09

尽量少地编写 main 函数，其中几乎不包含任何内容。在大多数 GUI 程序、sdl 游戏程序、open gl 或任何具有任何类型用户界面的程序中，主要功能应该只不过是一个事件吃循环。必须如此，否则总会有很长一段时间计算机似乎没有响应，并且操作系统认为可能会关闭它，因为它没有响应消息。

一旦获得主循环，请快速锁定它，仅针对错误修复进行修改，而不是新功能。这可能最终会将问题转移到另一个函数，但无论如何，在基于事件的应用程序中拥有一个整体函数是相当困难的。您总是需要一百万个小事件处理程序。

也许你有一个单一的类。我已经这么做了。处理它的主要方法是尝试保留依赖关系的心理或物理地图，并注意哪里有……比方说，一组函数不明确依赖于任何共享状态或变量的穿孔、裂缝。类中的其他函数。在那里，您可以将该函数集群分离到一个新类中。如果它真的是一个巨大的类，并且真的很混乱，我会称之为代码味道。考虑重新设计这样一个东西，使其变得不那么庞大和相互依赖。

您可以做的另一件事是，在编码时，请注意，当一个函数增长到不再适合单个屏幕的大小时，它可能太大了，此时开始考虑如何将其分解为多个较小的功能。

回复收藏 0 原文