1

有哪些方法可以编写易于修改的代码？

我从经验中学到的一点是，我几乎总是需要写一个扔掉。这样，在编写实际应用程序之前，我就对所需的领域知识和程序结构有了一定的了解。

4

6 回答 6

5

一般准则是偏离的

  • 高内聚、低耦合
  • 不要重复自己
  • 识别设计模式并实现它们
  • 不要识别不存在或不需要的设计模式
  • 使用编码标准，坚持下去
  • 如有疑问，请评论应评论的所有内容：评论
  • 使用单元测试
  • 在实施之前写评论和测试，这样你就知道你想做什么
  • 当它出错时：重构，重构，重构。通过良好的测试，您可以确保没有任何问题

哦，是的：

阅读： http: //www.pragprog.com/the-pragmatic-programmer

上面的一切（我认为）和更多都在里面

于 2009-05-15T17:11:11.907 回答
1

我认为您对可修改性的强调比可读性更重要。使某些内容易于阅读并不难，但是当其他人（或您）必须根据不断变化的需求对其进行修改时，对它的理解程度的真正考验就来了。

我试图做的是假设修改是必要的，如果不是很清楚如何进行修改，请在代码中留下明确的指示以说明如何进行修改。

我假设我可能需要对代码的读者进行一些教育，以使他或她知道如何正确修改代码。这需要我的精力，也需要阅读代码的人的精力。

所以虽然我很欣赏文学编程的理念，它可以很容易地阅读和理解，但有时它更像是数学，唯一的方法就是让读者系好安全带，密切关注，再读几遍次，并确保他们理解。

于 2009-05-15T17:17:28.897 回答
1

把你的代码挂起来晾干

在分配更改 Web 界面外观的任务时，我很早就知道了这一点。代码是 C 语言，我讨厌，并被编译成 CGI 可执行文件。而且，更糟糕的是，它是建立在一个被废弃的库上的——没有更新，没有支持，而且投入了太多的工时来改变它。在框架之上是一个杂乱无章的代码网络，由各种表单和元素构建器、自定义字符串实现以及各种其他神秘的东西（非 C 程序员可以自杀）组成。

对于我所做的每一项更改，输出 HTML 都会有几个，有时是很多例外。这些异常中的每一个都需要在表单构建器中进行小的更改或改进，这要归功于该语言没有继承，因此只有函数和结构，而不是花费时间在团队中，而是经常编写这些异常。

由于缺乏经验，我被迫更改每个异常的输出，而不是在改进的表单生成器中合并更改。但是，在无效更改后数小时内搜索 15,000 行代码会导致代码烧毁，以及需要一夜睡眠才能治愈的迷雾。

始终通过 DRY-er 运行您的代码。

于 2009-05-15T17:40:12.853 回答
0

修改代码的最简单方法不是编写代码。编写伪代码不仅仅是为了算法，如果你不确定，你的代码应该如何构造。

在编写代码的同时进行设计永远不会奏效......对我来说:-)

于 2009-05-15T17:08:02.383 回答
0

这是我目前的经验：我正在（Java）使用一种可能经常更改的数据库模式（添加/删除的字段，修改的数据类型）。我的策略是解析这个模式并使用apache velocity生成代码。生成的BaseClass永远不会被程序员修改。否则，将MyClass extends BaseClass创建 a 并使用超类的“getters”和“setters”来实现此类的逻辑组件（例如 toString() ！）。

于 2009-05-15T17:16:01.757 回答
0

可读性有很大帮助：如果您做了一些不明显的事情，或者您正在走捷径，请发表评论。注释是您以后有时间可以返回和重构的地方。为所有内容使用合理的名称，以便更容易理解正在发生的事情。

不断的修订将使您从初稿转变为更好的草案，而不会丢掉（太多）工作。任何时候你从头开始重写，你都可能失去经验教训。在编写代码时，请使用重构工具来消除代表不再需要的探索领域的代码，并使显而易见的事情变得晦涩难懂。第一个减少了您需要维持的数量；第二个减少了每平方英尺的工作量。（真的，Sqft 和代码行一样有意义。）

适当地模块化并强制执行模块之间的逻辑封装和分离。您不希望对代码的任何一部分有太多依赖，否则该部分本来就更难理解。

考虑使用经过验证的真实方法而不是尖端方法。你为了可预测性放弃了一些功能。

最后，如果这是人们将在修改前后使用的代码，您需要（ed）有一个适当的 API 将您的代码与他们的代码隔离开。拥有强大的 API 可以让您在幕后进行更改，而无需提醒所有消费者。我认为有一篇关于 Coding Horror 的不错的文章。

于 2009-05-15T17:17:54.543 回答