如何以减少完全返工可能性的方式实现代码[已关闭]

模块化。制作能够很好地完成工作的小代码块。然而,这只是开始。它通常是一个大的因素组合,导致代码非常糟糕,需要完全返工。从高度不稳定的需求,糟糕的设计,缺乏代码所有权,等等。

再加上其他人提出的:沟通。
您与客户、您与管理层、您与其他开发人员、您与QA部门之间的沟通,每个人之间的沟通都是关键。确保管理层了解合理的时间框架,并确保您和客户都准确了解您的建筑是什么。

点。。。

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

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

然而,人们可以构建在变化面前更加健壮的代码。它不会使您免于抛出满足不再有人需要的需求的代码,但它可以减少此类更改的影响。

这种方法的另一个优点是,您可以轻松地将一个实现替换为另一个实现。例如,为原型编写和测试实现时,有时效率最低但速度最快,并且只有在原型是产品的基础且性能真正重要时,才最终用更智能的东西来取代它,这是值得的。我发现这是一种非常有效的方法,可以避免过早的优化,从而扔掉一些东西。

正如已经说过的那样,模块化是答案。但这可能是一个很难在实践中使用的答案。 我建议将重点放在:

• 能够很好地完成预定义任务的小型库

我不知道你的应用程序是否是UI密集型的;这会使模块化变得更加困难。它通常仍然值得付出努力,但如果不值得,那么就假设它不久就会被扔掉,并遵循冰山原则,即90%的工作与UI无关,因此更容易保持模块化。

最后,我推荐安德鲁·亨特(andrew hunt)和戴夫·托马斯(dave thomas)的《务实的程序员》(the Practical programmer),这本书有很多技巧。我个人最喜欢的是干的--“不要重复你自己”--任何说同样的东西两次的代码。

• 小迭代

• 反复

• 迭代之间的测试

基本假设 ,并且不要深入到需要花费大量时间才能扔掉的东西上。

在这里查看其他答案时,我注意到每个人都在提到下一个项目要做什么。

不过,有一件事似乎遗漏了,那就是进行一次清理,找出规范不同步的原因。根据客户的实际需求。

我只是担心,如果你不这样做,无论你采取什么方法来实施你的下一个项目,如果你仍然在实际需求和规范之间存在不匹配。对于你的下一个项目,那么你将再次处于相同的情况。

但至少如果你知道原因,你可以尝试帮助减少再次发生的可能性。

不要敲敲其他答案所说的,那里有一些很棒的东西,但请从发生的事情中学习,这样你就不会被迫重复。

干杯

如果您正在为相机编写软件,您可以假设下一个版本也将进行视频、立体声视频或3d激光扫描,并包括所有这些功能的所有挂钩,或者你可以编写一个多功能的可扩展宇航员架构,它可以处理下一个摄像头,包括喷气式发动机,但它将花费大量资金、资源和性能,因此你最好不要这样做。

在新角色中完全重写新功能并不总是一个坏主意。

正如csunwold所说,模块化代码非常重要。这样写的话,如果有一件容易出错,它就不会弄脏系统的其他部分。通过这种方式,您可以调试单个buggy部分,同时可以安全地依赖其余部分。

除此之外,文档是关键。如果您的代码被整洁而清晰地注释,那么将来对您或任何正在调试的人来说,重新编写代码将非常容易。

使用源代码管理也会有帮助。如果您发现一段代码不能正常工作,那么总是有机会恢复到以前的健壮迭代。

虽然它不直接适用于您的示例,但在编写代码时,我会尽力留意未来软件的发展。

基本上,我试图预测软件的发展方向, 关键的是,我抵制住了实施任何我能想象到的事情的诱惑。我所追求的只是让API和接口在不实现这些功能的情况下支持可能的未来,希望这些“可能的场景”能帮助我找到一个更好、更经得起未来考验的接口。

当然,这并不总是有效的。