如何编程一个未知的未来修改和功能的应用程序?

请放心,这是一个老问题。大多数程序员每天都要和一些对应用程序有新见解的经理或决策者打交道。他们似乎不明白,自动化一件事情比在高层次上描述它需要更多的工作。他们似乎也不明白,让他们的员工拆除你刚刚努力工作过的东西会对他们的士气产生影响。

这是一个很难预测的问题,所有的方式可以要求一个人重新设计软件。有些人建议使用钩子,这样您就可以在工作流的任何给定步骤添加新功能,而不必拆开应用程序。但是你应该加哪些钩子呢?如果工作流本身需要改变呢?

Agile Software Development 或 Extreme Programming 或其他迭代方法。

迭代开发的一个常见想法是,您不应该试图预测所有未来的变化。当然,你所预期的一些变化会发生,但它们中的许多也很可能不会发生,所以你所投入的工作 可能的 改变是白费力气。

当然,他们也说,当发生变化时,你应该优雅地做出反应,并通过与客户(或经理)频繁沟通来减少损失的时间。在这种情况下,实体模型和原型是有用的工具。

不过,最终你可能会遇到一个完全没有头脑的经理。在这种情况下,再多的谈判或改进方法也无济于事。不要为一个总是不尊重你、不尊重你的时间和你工作成果的人工作。不要让他们在你身上走来走去,也不要因为内疚而耽误你长时间工作。

If Architects Had to Work Like Programmers .

钩子。

使某些内容可扩展的最佳方法是使其具有许多明确记录的插入点,以供附加代码使用。为了适应一个新的特性,原来的程序修改得越少越好。这个想法是在“扩展”,“附加组件”,“模块”,无论什么-使它,以便有人可以改进您的程序,而不必接触它的源代码。

由于PHP支持OOP,而且我的学校从一开始就是OOP,所以我建议您像学习手背一样学习面向对象的设计模式。另外,要经常考虑“代码到接口”。架构的设置方式首先与所讨论的代码的可维护性有很大关系。您可以将应用程序放在一边,从头开始重新设计它,然后交换整个系统。这使得处理300个用户比一次更新小部件更容易。

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

你不可能做出完全经得起未来考验的东西。制定规范是有原因的……这样才能遵守。虽然我想说如果客户想为每一个主要版本付费,那是他们的特权。

试着提前计划那些

使事物模块化和松散耦合也有帮助。如果您有一个具有相当好定义的API的组件,那么可以很容易地完全替换它的实现,而无需触及使用它的大部分或任何代码。

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

当然,第二,尝试在钩子或插件上构建核心应用程序。不过,这同样只对扩展有所帮助,而不是重大变化。

如果您有现有用户,并且对实时系统进行了返工,那么实现数据库视图(甚至是版本控制?),保留旧应用程序并在扩展存储方案上构建新版本可能会有所帮助。但事实上,这很难用一般的描述来评估。