如何对未来修改和功能未知的应用程序进行编程？
背景
我对编程并不陌生，但在处理客户及其需求方面我却是新手。以下是我与当前客户的历史记录：我继承了一个已完成 2/3 的 PHP 应用程序，并继续使其 100% 完成，直到客户需要导致应用程序和数据库需要重写的（主要）功能。我花了两周时间起草新应用程序如何处理新的更改以及其他所需的功能，并在获得批准后再次开始构建应用程序。我现在被要求添加新版本之前未讨论过的新功能，而且它们非常重要。此外，整个应用程序有超过 300 个用户，这使得它变得更加困难。
问题
忽略客户要求提供最初未讨论过的功能这一事实。如何使我构建的应用程序具有功能证明？在完美的世界中，客户会确切地知道应用程序应该具有哪些功能，这将使我的工作变得更容易。但事实并非如此，我所说的这些主要功能是在起草应用程序时应该包含的功能，而不是在应用程序上线时包含的功能 - 尽管这个问题对于应用程序的任何未来修改或功能都是通用的。
我不喜欢告诉我的客户他请求的功能或更改非常重要，以至于我必须（再次）重写整个应用程序。然而，在写这篇文章时，我突然想到，如果不重新开始就无法添加该功能，这可能不是我的错。但这似乎几乎是他想要的任何新功能，因为有些东西已经为应用程序进行了硬编码，现在为了新功能而更改它们是行不通的。
任何有关这种情况的个人经历都会很棒 - 我希望我不是唯一处理这种情况的人，因为它可能非常令人沮丧。谢谢！
Background
I'm not new to programming, however I am when it comes to handling clients and their needs. Here's my history with my current client: I inherited a PHP application with it being 2/3 completed, continued to make it 100% completed until the client wanted (major) features that caused the application and database to need to be rewritten. I spent two weeks drafting how the new application would work with the new changes along with other needed features and after approval I started the building the application, again. I'm now being asked to add new features that were not discussed before the new build- and again, they are pretty major. Also, the whole application is live with over 300 users- making it even harder.
Question
Ignore the fact the client is asking for features not discussed originally. How do I make the applications I build feature proof? In a prefect world, the client would know exactly what features the application should have, which would make it a lot easier to do my job. But this is not the case and these major features I'm talking about are those that should have been included while drafting the application, not when the application is live- though this question is general for any future modification or feature to an application.
I don't like telling my client the feature or change he is requesting is so major that I have to rewrite the whole application (again). However, while writing this it occurred to me that it may not be my fault that the feature can't be added without starting over. But this seems to almost be any new feature he wants, as some things have been hard coded for the application and changing them now for a new feature just wont work.
Any personal experience with this situation would be great- I hope I'm not the only one dealing with this, as it can be very frustrating. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
请放心，这是一个老问题。大多数程序员都必须与每天对应用程序有新愿景的经理或决策者打交道。他们似乎不明白，自动化某件事比在高层次上描述它需要更多的工作。他们似乎也不明白，如果被告知拆除你刚刚辛辛苦苦做的东西，会损害工人的士气。
试图预测人们可能被要求重新设计软件的所有方式是一个难题。有些人建议使用挂钩，以便您可以在工作流程的任何给定步骤添加新功能，而无需拆散应用程序。但是您应该添加哪些钩子呢？如果工作流程本身需要改变怎么办？
许多软件开发人员使用诸如敏捷软件开发或极限编程 或其他迭代方法。
迭代开发的常见想法之一是您不应该尝试预测所有未来的变化。当然，您预期的一些变化将会发生，但其中许多变化也很可能不会发生，因此您为预测可能发生的变化所做的工作都是白费力气。
所以你应该只编写今天需要的软件。随着情况的变化，您将不得不重写其中一些内容，但这是正常且不可避免的。而且很可能大部分都不会改变，所以设计越简单越好。我们的假设是，通过只关注当前的需求，您可以充分减少总体工作量，从而获得净胜利。
当然，他们还说，当变化发生时，你应该优雅地应对变化，并通过经常与客户（或经理）沟通来减少时间损失。在这种情况下，模型和原型是有用的工具。
另外，不要害怕如实告诉你的经理你需要多长时间来重新设计软件以满足他的描述。您可以通过提出一些妥协方案来提供帮助。例如，通常他要求的单个功能就是您需要重新架构的原因，否则更改会小得多。因此，公开讨论这个问题，并进行对话，看看是否有另一种方法可以解决相同的需求，而无需做那么多工作。如果他能够更快、更便宜地满足这一需求，这也应该符合他的利益。
但最终，你可能会面对一位完全愚蠢的经理。在这种情况下，再多的谈判或改进你的方法也无济于事。不要为那些持续不尊重你、你的时间和你的工作成果的人工作。不要让它们左右你或让你因为内疚而长时间工作。
另请阅读这篇幽默文章，它可能反映了您的情况：如果架构师必须像程序员一样工作 。
Be assured that this is an old problem. Most programmers have had to deal with some manager or decision-maker who has a new vision for the app every day. They don't seem to understand that it takes a lot more work to automate something than it takes to describe it at a high level. They also don't seem to understand that it takes a toll on the morale of their workers to be told to tear down something you just worked hard on.
It's a hard problem to try to anticipate all the ways one could be asked to redesign software. Some people have suggested hooks so that you can add new functionality at any given step of the workflow, without having to tear apart the application. But which hooks should you add? And what if the workflow itself needs to change?
Many software developers use methods like Agile Software Development or Extreme Programming or other iterative methodologies.
One of the common ideas of iterative development is that you shouldn't try to anticipate all future change. Some of the changes you anticipated will happen of course, but it's just as likely that many of them will not, so the work you put in to anticipate possible changes is wasted effort.
So you should just write the software that is needed today. You will have to rewrite some of it as things change, but that's normal and unavoidable. And it's likely that most of it will not change, so the simpler design is better. The assumption is that by focusing just on the current requirements, you reduce the overall work enough so that it's a net win.
Of course they also say that you should respond gracefully to change when it does happen, and mitigate lost time by communicating with the client (or manager) frequently. Mock-ups and prototypes are useful tools in this case.
Also don't be afraid to tell your manager truthfully how long it is going to take you to redesign the software to meet his description. You can help by proposing some compromises. For example, often a single feature that he asked for is the reason you need to rearchitect, and otherwise the changes would be a lot more minor. So talk openly about this, and have a dialogue to see if there's another way to solve the same need without so much work. It should be in his interest too, if he can get that need met more quickly and less expensively.
Eventually, though, you might face a manager who is completely senseless. No amount of negotiation or improving your methodologies can help in this case. Don't work for someone who is persistently disrespectful of you and your time and the product of your work. And don't let them walk all over you or guilt-trip you into working long hours.
Also read this humor piece, which probably mirrors your situation: If Architects Had to Work Like Programmers.
钩子。
使某些东西可扩展的最佳方法是使其具有许多明确记录的附加代码插入点。为了适应新功能而对原始程序进行的修改越少越好。这个想法背后有“扩展”、“附加组件”、“模块”等等——这样人们就可以改进你的程序，而根本不需要接触它的源代码。
Hooks.
The best way to make something extensible is to make it have many clearly-documented insertion points for additional code. The less the original program has to be modified to accomodate a new feature, the better. This idea is behind "extensions", "add-ons", "modules", whatever - make it so that someone can improve your program without having to touch its source code at all.
由于 PHP 支持 OOP，并且我的教育从一开始就是 OOP，所以我建议您像手背一样学习面向对象的设计模式。另外，经常思考“接口代码”。首先，架构的设置方式与相关代码的可维护性有很大关系。您也许可以不理会该应用程序，从头开始重新设计它，然后完全更换系统。这使得处理 300 个用户比一次更新小部分更容易。
设计模式：http://en.wikipedia.org/wiki/Design_pattern
Since PHP supports OOP and my schooling has been OOP from the start, I would suggest that you learn Object Oriented design patterns like the back of your hand. Also, think "code to an interface" a lot. The way the architecture is set up in the first place has a lot to do with the maintainability of the code in question. You may be able to leave the application alone and redesign it from the ground up then swap the system in its entirety. This makes dealing with 300 users easier than updating small parts at a time.
Design patterns: http://en.wikipedia.org/wiki/Design_pattern
根据需要，可以使用“插件”应用程序模型。
Depending of the needs, a "plug-in" application model could be used.
你永远不可能做出完全面向未来的东西。制定规范是有原因的……以便能够遵守。尽管我会说客户是否愿意为每个主要版本付费，但这是他们的特权。
You can't ever make something completely future-proof. Specs are drawn out for a reason...so that they can be adhered to. Although I would say if the client wants to pay money for each major release, that's their prerogative.
尝试提前计划稍后可能添加的功能，并使用可以包含这些功能而无需完全重写的设计。不过，最初的复杂性和以后轻松添加内容的能力之间显然需要权衡。
使事物模块化和松散耦合也有帮助。如果您有一个具有相当明确定义的 API 的组件，那么很容易完全替换其实现，而无需触及使用它的大部分或任何代码。
Try to plan ahead for features that might be added later on, and use a design that can encompass those features without a complete re-write. There's obviously a trade-off between initial complexity and the ability to easily add stuff later, though.
Making things modular and loosely coupled also helps. If you have a component with a fairly well defined API it's easy to replace its implementation entirely without touching much or any of the code that's using it.
对主要新功能进行反编码几乎是不可能的。然而，在某些地方，计划的灵活性总是一个好主意。最重要的是，保持数据库接口抽象和表字段可扩展是有意义的。使用活动记录或表数据网关或类似方案通常很容易，有时简单的 $fieldnames[$table]=[a,b,c] 可能就足够了。
其次，当然，尝试在挂钩或插件上构建核心应用程序。不过，这同样只有助于扩展，而不有助于重大更改。
如果您有现有用户并重新设计了一个实时系统，那么它可能有助于实现数据库视图（甚至版本化？），保留旧应用程序并在扩展存储方案上构建新版本。但实际上，很难根据一般描述进行评估。
Anticicoding major new features is hardly possible. There are however a few spots where planned flexibility is always a good idea. Foremost it makes sense to keep the database interface abstract and table fields extensible. It's often easy with active record or table data gateway or similar schemes, sometimes a simple $fieldnames[$table]=[a,b,c] might suffice.
Second of course, try to build the core application upon hooks or plugins. Though, that again only helps for extensions, not major changes.
If you have existing users and rework a live system, it might help to implement database views (even versioned?), keep the old application and build the new version on an extended storage scheme. But really, that's difficult to asses on a generic description.
我想到了两个概念：“你不会需要它”和“保持简单，愚蠢”。也就是说，根据我的经验，为未来的功能进行编码是创建糟糕代码的陷阱，但无论如何，未来都会有所不同。但也许这只是我。
Two concepts come to my mind: "you ain't gonna need it" and "keep it simple, stupid". I.e., coding for future features, in my experience, is a trap for creating terrible code, and then the future comes differently anyway. But maybe that's just me.