将付款和促销的责

raselbd223

给定代码所负责的业务领域级别的责任非常重要。示例 如果代码负责订单则让它处理订单。让我们任留给其他模块。业务领域以及它们之间的关系往往并不像看上去那么简单。我们还在较小的结构级别类方法等承担责任。如果我们尝试应用单一职责原则我们的代码将更易于测试阅读和维护。我们可以委派责任 如果我们生成的代码符合开放封闭原则则可以更轻松地进行测试或实现更改。它不会严格焊接我们的解决方案它允许我们用一种解决方案替换另一种解决方案而不会有损坏之前创建的东西的风险。

五当 侦察兵 并不总是有利可图 罗伯特书籍 研究中提到的每一种做法如果使用不当都会弊大于利。我想指出一些在我参与的项目中造成的问题多于收益的问题。 第一个是引用鲍勃叔叔的话 要像一名童子军。让露营地比你发现时更干净。 从鸟瞰角度来看这是我们每个人都应该遵循的伟大实践。但是您 电子邮件数据 需要明智地做到这一点并遵守一些附加规则。其中之一是分离由所谓的 业务功能变化的 涡轮重构 有时也称为 清理 。第二条规则如果您正在进行重大重构并且没有针对给定代码段进行测试是的实际上并没有那么不同并且很少有系统具有 ％ 的测试覆盖率请从编写它们开始。下一条规则是 每个测试一个断言 。但是请记住在测试大型企业系统时这是一种不切实际且不合逻辑的方法。



除了这个规则我们可以尝试用更 流畅 的方法结合业务知识来封装 标准 断言并创建我们自己的断言类用于测试方法。 如何在自己的代码中实现良好的实践？ 罗伯特再次编程编程再编程。 观看别人做的流媒体 视频甚至阅读最聪明的书籍和文章都不会教你如何编写干净的代码或在实际需要的地方使用各种类型的模式。 ł我们不要重新发明轮子。有许多库形式的现成解决方案其中通常包含必要的谜题元素。