如何以一种减少完全返工的可能性的方式实现代码

Question

我有一件工作被丢弃，因为一个很小的规格变化，结果证明没有正确的规格。如果它是在项目开始时完成的，那么大部分工作都是would have never have been needed in the first place。

有什么好的技巧/设计原则可以防止这些事情发生？

或者为了减少在实现过程中实现功能请求或设计更改所需的代码返工数量？

Answer 1

模块化。编写能很好地完成工作的小块代码。然而，这仅仅是个开始。它通常是一个大的因素组合，导致代码如此糟糕，以至于需要完全返工。从高度不稳定的需求，糟糕的设计，缺乏代码所有权的一切，清单不胜枚举。

除了其他人带来的东西:交流。

你和客户，你和管理层，你和其他开发人员，你和你的QA部门之间的沟通，每个人之间的沟通是关键。确保管理层了解合理的时间框架，并确保您和客户都确切地了解您的建筑是什么。

Answer 2

花时间与你为之构建产品的客户保持畅通的沟通。制定里程碑并设置时间，以便在每个里程碑向客户显示项目。即使当你展示一个里程碑时，客户对它感到完全失望，你也可以划掉你已经拥有的东西，从上一个里程碑重新开始。正如Csunwold所说的，这也要求你的工作是建立在彼此独立工作的模块中。

点数...

1. 保持开放，对产品的进展保持开放和诚实
2. 愿意每天根据客户的需求、业务和产品变化的规格进行更改。

Answer 3

软件需求发生了变化，除了与客户进行更频繁的交互之外，人们对此无能为力。

然而，人们可以构建在面对变化时更健壮的代码。它不会使您避免丢弃满足无人再需要的需求的代码，但它可以减少此类更改的影响。

例如，只要这一点适用，就使用接口而不是类(或在您的语言中等效的类)，并避免向接口添加操作，除非您绝对确定需要它们。通过这种方式构建程序，您不太可能依赖特定实现的知识，也不太可能实现不需要的东西。

这种方法的另一个优点是，您可以轻松地将一个实现替换为另一个实现。例如，有时为原型编写最愚蠢(在效率上)但最快的编写和测试实现是值得的，只有当原型是产品的基础并且性能确实很重要时，才会用更智能的东西来替换它。我发现这是一种非常有效的方法，可以避免过早优化，从而丢弃东西。