如何避免重写应用程序的各个部分

我在一家公司的销售部门项目中工作。这是我的第一份专业编程工作，但是我一直在自己编码并学习多年。该项目的一部分涉及获取一些数据，并将其与输入相结合以生成图形。然后保存数据……依此类推。因此，我花了不到一天的时间为此编写了代码。第二天，我展示了我的项目主管，他喜欢它，但是“如果有的话”，并希望我在图表中添加一些内容。这对程序的外观或功能没有太大的改变，但是它极大地改变了我存储数据，处理数据等的方式。

再次，我花了一天的时间来重新组织数据库表，并基本上从头开始重写代码以支持此新请求。我又把它还给了他，同样的事情发生了。他提出了其他要求，这些要求极大地改变了我处理数据的方式。因此，我不得不再次重写它。最终，他签署了该协议，希望我不必再次重写它。

请清楚，我不是在殴打我的经理或类似的人。他是一个伟大的人，他所要求的东西并没有超出这个世界，它们与我以前所做的不相容。

我只是想知道将来是否可以做些什么来避免完全重写。我了解制作灵活的代码并且正在尝试这样做，但是我想知道我可以做些不同的做法或事情来简化此工作，因此，将来，我不会花3天时间去做一些应该吃1。

正如我所评论的那样，我有一种强烈的感觉，即要求第一次不清楚，或者您可能错过了一些重要的细节。

并非所有问题都可以通过更好的代码，最佳实践，设计模式或OOP原则来解决。如果实现是基于错误的假设或错误的前提，则它们都不会阻止您重做整个应用程序。

不要急于编码解决方案。在键入单个LOC之前，请花一些时间来澄清要求。您对需求的研究越深入，如果出现问题该怎么办。不要等到经理对您的下一个假设感到惊讶 。自己预料事情。少做运动可以大大减少意外因素。

不要害怕根据需要多次询问。有时，树木（细节）不让我们看到森林（整体图）。这是我们首先要看的森林。

明确要求后，在设计阶段就可以做出更好的决策。

最后，请记住总体情况是一个目标。实现这一目标的途径既不简单也不直接。变化将继续发生，因此要敏捷。

没有办法根据您所提供的信息知道这一点。这是您当时所需要的，它又快又脏。但是，然后有人喜欢它，并且它变得越来越复杂，所以现在您开始发现，直到复杂性开始出现，许多问题才会显现出来。有很多不同的事情可以做，这简直是压倒性的。

有一个古老的“无银弹”，这是事实。同样，没有办法知道如何使用完整的规范（或针对敏捷的更好的现行规范）以及使用好的编程原理和好的设计的能力。 程序员喜欢一遍又一遍地重写。我并不是说您一定会因为这个原因而陷入困境。

利用这次机会应用一些基本原则。您会发现它们起作用了，但随后有人会说：“哦，不，那很不好”，否则您会喜欢其他东西。您不能完全依靠公司的钱来做这一切，但是如果他们允许您有时间进行探索，请利用它作为机会。有总是一个人，有些基础，有些人，具有“最好”的方式或做事的一些“新”的方式。

您的经理很可能正确地完成了每个步骤。这不是因为他是经理，而是因为他正在考虑结果和可用性，以及可能与客户或客户要求进行过往交易的次数。

UI是很难的东西，通常，5个人有15个不同的视图。数据和数据结构以及数据分析的变化趋势往往是乘以10 :)。UI就像时尚，有些组合很酷，有些则糟糕或缺少常识。

更不用说，例如在精益生产过程中，没有什么是一成不变的。您正在经历类似迭代评估的过程，并且在每个步骤中，它都稍有改善，或者避免了错误的路径。

如此简单的答案是，根本就没有重写的东西。

迭代开发（这是您基本上所做的，尽管是一天的迭代）通常是这样的。解决方案的早期尝试通常是徒劳的，并且通过收集反馈，系统可以收敛到解决方案。我将从Craig Larman的指导材料中借用图2.2，作为他的Applied UML和Design Patterns书。

在项目开始时，您将学习如何使用明显的不稳定版本。我不同意“您必须尽早获得更多要求”的答案，因为那是瀑布式思维。的确，您应该努力从需求中获得尽可能多的收益，但是由于许多原因，不可能拥有完整而准确的需求。

这并不是说您无法减少获得反馈后必须重写的内容。经常发生的一件事是，软件的人机交互很可能会改变，因为这是第一次很难正确实现的部分。

考虑一下Microsoft Word以及其数据格式（.doc）在过去几年中的发展情况。这是因为作为问题域的文本文档并没有真正发展（页面仍然是页面，段落仍然是段落，等等）。但是，Word的用户界面发展了很多（并将继续）。用于表示或输入的代码在两个版本之间往往不稳定，因此最好不要将系统的其他部分直接耦合到它们（以防止它们被重写）。

可以将表示形式与问题的基本逻辑和数据分开的软件体系结构可以减少重写次数。之所以出现诸如Model-View分离之类的许多软件模式，是因为像您这样的人经历了许多重写，并寻求了一种更好的方法。

这听起来很佛教，但是您很幸运遭受了这些改写！如此多的人了解MVC模式或其他设计模式，却没有“忍受”模式应该避免的重写梦re。

我没有答案，只是练习。您可能需要在自己的时间做一个练习，尽管取决于您的组织，您也许可以在工作时间内获得批准。

重新设计您的第一个解决方案以完全按照其功能进行操作，但可以更轻松地添加第二个或第二个和第三个步骤。不要添加这些步骤，不要存根它们。只需创建一个满足所有原始要求但可以轻松升级以包含新功能的解决方案。对您的第二个解决方案执行相同的操作。

需求改变，这是生活中的事实。事后看来：第一个解决方案可能会有所不同，所以总编程时间会更少吗？那就是您从经验中学到的方法。

那是第一个陡峭的学习曲线。当您进行管理时，将面临第二个挑战：当用户存储了一年不希望丢弃的价值一年的数据时，您将如何应对变化的需求？

从您的故事中可以明显看出，需求和首选架构决策之间的沟通不够充分。因此，你们其中之一，或者也许两者都是不好的沟通者。

也可能是架构师，因为一些架构师在独自编程，出色的教育（通常也是独自学习）或成为公司的第一个开发人员（显然是孤独的）时，就获得了良好成就的较高地位。与团队沟通没有必要。他们继续专注于编程而不是记录设计并为团队提供支持的情况并不少见。

但是，在这种情况下，您也可以尝试通过说话更长，提出问题和做笔记来弥补。您甚至可以自己编写一个小规格，然后请架构师批准。