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

模块化。编写能很好地完成工作的小块代码。然而,这仅仅是开始。导致代码如此糟糕的因素通常有很多,需要彻底返工。从高度不稳定的需求、糟糕的设计、缺乏代码所有权,等等。

补充一下其他人提出的问题:沟通。
你和客户、你和管理层、你和其他开发人员、你和你的质量保证部门之间的沟通,每个人之间的沟通都是关键。确保管理层了解合理的时间框架,并确保您和客户都确切地了解您的建筑是什么。

花点时间与你构建产品的客户保持沟通。制定里程碑,并设定在每个里程碑向客户展示项目的时间。即使当你展示一个里程碑时,客户对它完全失望,你也可以从头开始。这也要求你的工作构建在相互独立的块中,正如Csunwold所说。

点。..

3. 愿意每天根据客户的业务需求和产品规格进行更改。

我建议重点关注:

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

首先编写接口是实现这两个目标的好方法(使用用于依赖关系的接口)。接下来,在编写代码之前,针对接口编写测试,通常会突出显示非模块化的设计选择。

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

最后,我推荐安德鲁·亨特和戴夫·托马斯的《实用程序员》,因为它充满了技巧。我个人最喜欢的是DRY——“不要重复自己”——任何说同一件事两次闻起来的代码。

• 经常迭代

• 尽快得到一个简单的工作产品,这样客户就可以提供意见。

东西会被扔掉,所以要适当地编写代码

你好,

不过,似乎缺少的一件事是进行清洗,以找出规格不同步的原因。根据客户的实际需求。

这可能是沟通不畅或客户需求蔓延等简单问题。

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

希望这能帮到你

干杯,

有时重写是最好的解决方案!
如果你正在为相机编写软件,你可以假设下一个版本也会做视频、立体视频或3d激光扫描,并包括所有这些功能的所有钩子,或者你可以编写一个多功能的可扩展宇航员架构,它可以应对下一个相机,包括喷气发动机——但它会花费太多的金钱、资源和性能,你最好不要这样做。

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

正如csunwold所说,模块化代码非常重要。这样写,如果一个部分容易出错,它就不会弄乱系统的其他部分。这样,您可以调试一个有缺陷的部分,同时能够安全地依赖其余部分。

除此之外,文档是关键。如果你的代码有整洁清晰的注释,那么将来重新编写它对你或碰巧调试的人来说都会变得非常容易。

使用源代码管理也会有所帮助。如果你发现一段代码不能正常工作,总有机会恢复到过去的健壮迭代。

虽然它并不直接适用于你的例子,但在编写代码时,我会注意如何看到软件在未来的发展。

但是 批判性地说,我抵制住了实施任何我能想象到的事情的诱惑。我所追求的只是在不实现这些功能的情况下,让API和接口支持可能的未来,希望这些“可能的场景”能帮助我设计出一个更好、更经得起未来考验的接口。