如何使用未知的未来修改和功能对应用程序进行编程？

Question

背景

我不是编程的新手，但是我在处理客户及其需求方面。这是我与当前客户的历史：我继承了一个PHP应用程序，它已经完成了2/3，继续完成100％，直到客户想要（主要）功能导致应用程序和数据库需要重写。我花了两周的时间来起草新应用程序如何与新的更改以及其他所需功能一起工作，并在批准之后再次开始构建应用程序。我现在被要求添加在新版本之前未讨论的新功能 - 而且它们非常重要。此外，整个应用程序现在有超过300个用户 - 使其更难。

问题

忽略客户端要求最初未讨论的功能的事实。如何制作我构建的应用程序功能证明？在一个完美的世界中，客户端会确切地知道应用程序应该具有哪些功能，这将使我的工作变得更加容易。但事实并非如此，我所说的这些主要功能是在起草应用程序时应该包含的功能，而不是在应用程序处于活动状态时 - 尽管这个问题对于应用程序的任何未来修改或功能都是通用的。 / p>

我不喜欢告诉我的客户他要求的功能或更改是如此重要，以至于我必须重写整个应用程序（再次）。然而，在写这篇文章的时候，我想到，如果没有重新启动就无法添加该功能可能不是我的错。但这似乎几乎是他想要的任何新功能，因为有些东西已被硬编码用于应用程序并且现在更改它们以便新功能无法正常工作。

任何有关这种情况的个人经验都会很棒 - 我希望我不是唯一一个处理这种情况的人，因为它可能非常令人沮丧。谢谢！

Answer 1

请放心，这是一个老问题。大多数程序员不得不与每天对应用程序有新视野的经理或决策者打交道。他们似乎并不明白，自动化某些东西需要花费更多的工作，而不是高水平地描述它。他们似乎也不明白，要告诉他们拆除你刚才努力工作的东西，会影响他们工人的士气。

尝试预测可以要求重新设计软件的所有方法是一个难题。有些人建议使用钩子，以便您可以在工作流程的任何给定步骤添加新功能，而无需拆除应用程序。但是你应该添加哪些钩子？如果工作流本身需要改变怎么办？

许多软件开发人员使用Agile Software Development或Extreme Programming等方法或其他迭代方法。

迭代开发的一个常见想法是，您不应该试图预测未来的所有变化。您预期的一些更改当然会发生，但它们很多都不会发生，因此您为预测可能的更改所付出的工作是浪费精力。

所以你应该编写今天所需的软件。当事情发生变化时，你将不得不重写其中的一部分，但这是正常的，不可避免的。并且它的大部分可能不会改变，因此更简单的设计更好。我们的假设是，只关注当前的需求，就可以减少整体工作量，从而获得净胜利。

当然，他们还说你应该优雅地做出反应，以便在事情发生时做出改变，并通过经常与客户（或经理）沟通来减少浪费的时间。在这种情况下，模型和原型是有用的工具。 另外，不要害怕真实地告诉您的经理需要多长时间才能重新设计软件以满足他的描述。您可以通过提出一些妥协来提供帮助。例如，他要求的单一功能通常是您需要重新架构的原因，否则更改将会更加轻微。因此，请公开谈论这个问题，并进行对话，看看是否有另一种方法可以在没有这么多工作的情况下解决相同的需求。如果他能够更快，更便宜地满足这种需求，那么这也符合他的利益。

但是，最终，你可能会面对一个毫无意义的经理。在这种情况下，无论是协商还是改进方法都无济于事。不要为那些一直不尊重你，你的时间和工作成果的人工作。不要让他们走遍你或者内疚 - 让你长时间工作。

另请阅读这篇幽默作品，这可能反映了您的情况：If Architects Had to Work Like Programmers。

Answer 2

钩。

制作可扩展内容的最佳方法是使其具有许多明确记录的插入点以用于其他代码。原始程序必须修改以适应新功能越少越好。这个想法背后是“扩展”，“附加组件”，“模块”等等 - 让人们可以改进你的程序，而不必触及它的源代码。

Answer 3

由于PHP支持OOP，我的学校教育从一开始就是OOP，我建议你学习面向对象的设计模式，比如你的手背。另外，想一下“代码到界面”很多。首先建立体系结构的方式与所讨论的代码的可维护性有很大关系。您可以单独离开应用程序并从头开始重新设计它，然后完整地交换系统。这使得处理300个用户比一次更新小部件更容易。

设计模式：http://en.wikipedia.org/wiki/Design_pattern

Answer 4

根据需要，可以使用“插件”应用程序模型。

Answer 5

你永远不可能做出完全面向未来的事情。规范是出于某种原因而制定的......因此可以遵守这些规范。虽然我会说如果客户想要为每个主要版本付钱，那就是他们的特权。

Answer 6

尝试提前计划可能稍后添加的功能，并使用可以包含这些功能而无需完全重写的设计。不过，显然需要在初始复杂性和稍后轻松添加内容的能力之间进行权衡。

使模块化和松散耦合也有帮助。如果你有一个具有相当明确定义的API的组件，那么很容易完全替换它的实现，而不会触及使用它的很多或任何代码。

Answer 7

难以预测主要新功能。然而，有一些地方计划的灵活性总是一个好主意。最重要的是保持数据库接口抽象和表字段可扩展。使用活动记录或表数据网关或类似方案通常很容易，有时简单的$ fieldnames [$ table] = [a，b，c]就足够了。

当然，第二，尝试在钩子或插件上构建核心应用程序。虽然，这只会有助于扩展，而不是重大变化。

如果您有现有用户并重新加工实时系统，那么实现数据库视图（甚至版本化？），保留旧应用程序并在扩展存储方案上构建新版本可能会有所帮助。但实际上，很难对通用描述进行评估。

Answer 8

我想到了两个概念：“你不会需要它”和“保持简单，愚蠢”。即，根据我的经验，对未来功能进行编码是创建可怕代码的陷阱，然后未来会有所不同。但也许那就是我。