重构或专注于完成应用

您会随身重构应用程序还是专注于首先完成应用程序？重构意味着应用程序的进度会变慢。

完成应用程序将意味着您以后可能很难维护应用程序吗？

该应用程序是一个个人项目。我真的不知道如何回答“什么驱动功能和设计”，但是我想这是为了解决现有软件的低效率问题。我也喜欢最小的易用软件。因此，我要删除一些功能，并添加一些我认为会有所帮助的功能。

让它起作用。然后加快速度。最后，使其美丽。

如果您使用接口在代码（表示层，业务层和数据层）之间实现了很好的隔离，并且它不是一个整体的设计，那么重构就不会那么困难。

如果您在重构时遇到很多困难，那可能是一种代码气味-我建议您看一下Solid Principles

我认为关键是保持接口清洁。以后，只要它们之间的通信层是合理的，您就可以始终重构甚至重写模块/类/任何实现。花一些时间弄清楚以后哪些是容易更改的，哪些不是。使后者正确。

这符合TDD的精神。要编写好的测试，您需要一个好的测试接口。目前幕后的混乱程度并不重要，因为您可以稍后进行改进。

我一直在重构，尤其是使用TDD时。

1. 编写测试

2. 使测试通过

3. 重构

这将帮助您减少错误，并为成品提供更好的代码。完成后，它还将使您需要维护的代码更少。

尽早经常重构！您“节省”不执行此操作所花的时间比试图破解下一个功能并搜索过于复杂或混乱的代码中的错误要花费很多时间。

重构就像拿起房间。

如果保持工作整洁，则线性开销与算法专家所说的代码工作量O（n）成正比。假设您花费10％的时间进行重构（或保持房间整洁），那10％是给定的，并且随着时间的推移它将保持不变。

但是，如果您将脏衣服扔在角落里并继续这样做，随着混乱变得越来越复杂，您花在拾房上的时间就会增加。假设每件脏衣服都对所需的清洁时间成指数增长，那么您现在处于O（e ⁿ）的情况。

任何曾经研究过算法复杂性概念的人都会发现，某个地方有一个收支平衡点，也就是说，有最适量的脏衣服要积聚。它的多少取决于以big-O表示法丢弃的常数因子。另一个因素是您的工作价值随着时间的推移：如果您现在的工作很有价值，但是下周便宜（例如，这个星期五是这个项目的最后期限，还有另外三个），但是在那之后，您将大部分时间处于闲置状态），则该方程可能会支持不重构。

然后是复杂性临界质量。在某个时候，混乱（如果可能的话，是“严重混乱”）变得如此糟糕，以至于只烧掉整个房间并买新衣服似乎更容易。实际上，它通常不是，但是看起来是这样，而心理影响将使解决该问题变得困难十倍。

显然，如果您已经进入一个已经是巨大的多重冗余混乱的项目，那么您的选择就很有限。

TL; DR：如有疑问，请重构。在决定不这样做之前，您应该有确凿的证据。

如果您有机会添加功能或压缩错误以使销售/客户满意度得到应有的满足，请执行此操作。一旦新需求减少，您就可以与重构保持平衡。在某些时候，您必须确保正在编写人们想要的代码。在所有条件都相同的情况下，我宁愿扔掉100个小时的代码而不是扔掉1000个小时的代码。如果没人愿意的话，这就是您要做的。

真的取决于你在哪里！

需要考虑的其他事项：

您确定如何确定功能设计正确？得到用户反馈后，您是否可以再次进行重新设计？

我宁愿发布而不是重写。在确定已固定功能设计之后进行优化。

只要您确定可以在截止日期之前完成，就可以重构所有想要的东西。但是，即使存在一些不确定性，也可以更好地坚持开发，并且只有在适度的增量步骤中才可以重构。

如果您要重构的不良设计确实对您造成伤害，那么最好立即修复它，而不是创建更多依赖于此的代码。以后的重构将更加困难和昂贵。机会是您将无法再这样做。

另一方面，如果您唯一的问题是丑陋，则可能要先完成软件，因为几乎没有什么事情能胜任完成工作。

在完成应用程序时，重构将非常重要。

+ VES

1. 清晰的流程：重构将使代码更清晰，因为有时候，如果代码很少是非结构化的，那么理解一段时间后的代码流将变得困难，重构代码可能会成为一项艰巨的任务，并且可能会引入错误。

2. 提高性能：正确重构应用程序肯定会有助于提高应用程序性能。

3. 维护：最后但并非最不重要的一点是，从长远来看，维护起来会更容易。

-VE

1. 耗时：这将是更多的时间在你的进步，每一个阶段耗时。因此，可能会延迟完成。

底线

根据项目类型，您可以优先考虑代码质量或完成情况，以适应当前情况。

根据我的个人经验，我通常会先完成应用程序，但要有截止日期。完成后，您可以对其进行重构。

完成并重构它。但是，如果没有赶时间或时间框架的最后期限，我建议将其重构会很好。