代码实际上应该具有多大的可扩展性？
我刚刚开始一份新工作，我的新老板和我谈论的事情之一就是代码的寿命。
我一直在编码以使我的代码具有无限的可扩展性和适应性。我认为如果将来有人要更改我的代码，那么应该很容易做到。
但我从来没有真正清楚地知道那应该是多远的未来。
所以我的新老板告诉我不要为未来 3 年后的任何事情编写代码，他的理由是技术变化、程序过期等。
起初我有点吃惊，认为他是一份糟糕的工作，但时间越长，我认为我对这个概念越感兴趣。
对于您应该在多远的未来进行编码，还有其他人有意见吗？
I've just started a new job and one of the things my new boss talked to me about was code longevity.
I've always coded to make my code infinently extensible and adaptable. I figured that if someone was going to change my code in the future then it should be easy to do.
But I never really had a clear idea on how far into the future that should be.
So my new boss told me not to bother coding for anything more that 3 years into the future and his reasoning was that technology changes, programs expire etc.
At first I was kinda taken aback and thought he was a whack job but the longer I think about it the more I'm warming to the concept.
Does anyone else have an opinion on how far into the future you should code to?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
实现的困难判断之一是可扩展性如何。作为老板，当我给某人分配一个 2 小时的任务，三天后他们仍在处理它时，我真的很恼火，因为他们认为它应该更具可扩展性，因此他们将条目添加到配置文件中，将列添加到表中，并且更改 4 或 5 个其他对象来适应这一点，现在安装文档已过时，部署脚本必须更改，测试人员必须花一两天时间尝试所有组合和排列，以便我们知道代码是甚至工作。但当其他人通过对所有内容（甚至是发送到的电子邮件地址）进行硬编码，将两小时的任务变成半小时的任务时，我也感到非常恼火，并且不理解团队其他成员何时抱怨。
如果有一个简单而严格的规则，那么每个人在第一次编译代码的那天就可以成为高级程序员。这需要经验和判断，这可能是您将获得的最重要的判断。你知道如何获得良好的判断力吗？经验。你知道如何获得经验吗？判断力不好。
One of the hard piece of judgement to achieve is how extensible to be. As the boss, I am really irritated when I assign someone a 2 hour task and three days later they're still working on it, because they decided it should be more extensible so they added entries to the config file and columns to tables and had to change 4 or 5 other objects to accomodate that and now the install doc is out of date and the deploy script has to change and the tester has to put in a day or two trying all the combinations and permutations so we can know that code is even working. But I am also really irritated when someone else given that two hour task turns it into a half hour task by hard coding everything, even the email address it sends to, and doesn't understand when the rest of the team complains.
If there was a simple hard and fast rule, everyone could be a senior programmer the day they first compile some code. It takes experience and judgement and it's probably the most important judgement you will acquire. And you know how you get good judgement? Experience. And you know how you get experience? Bad judgement.
您应该按照规范进行编码，不多也不少。如果规范规定了 30 年，那么您的编码期限为 30 年。如果规范给出了3个月的规定，则同样适用。
但请记住，您也应该为自己的理智而编写代码。您创建的所有代码都应该实现 3 件事：
代码可替换 - 在我看来，这只是一个很好的实践。您的代码可替换性越强，您编写的代码就越好。这提供了一种相反的情况 - 你的代码越可替换，你自己就越有价值。
高效的代码 - 重用、重用、重用。
You should code to the specifications, nothing more, nothing less. If the specifications make provisions for 30 years, you code for 30 years. If the specification gives provisions for 3 months, the same applies.
Just remember though, you also should code for your own sanity. All the code you create should achieve 3 things:
Code to be replaceable - This is just good practice in my opinion. The more replaceable you are in your coding, the better code you produce. This provides a bit of a reverse situation - the more replaceable you make your code, the more valuable you make yourself.
Code to be productive - Reuse, reuse, reuse.
如果您确实想要一个持久的计划，请努力确保您的日期可以处理过去的2038 （这就是下一个“Y2K”）。
抛开日期不谈，如何准确地为从现在起一年后而不是从现在起十年后编写代码？您要么编写可维护的代码，要么不编写；您无法准确指定更改“过期”之前的时间。
我想有人可能会争辩说，他们的语言的下一个标准将弃用方法
Foo，但如果一个方法将被弃用，那实际上更多的是代码质量和可维护性，而不是为未来编写代码日期。If you really want a long lasting program, shoot for making sure that your dates can handle past 2038 (that's the next "Y2K").
Dates aside, how does one exactly code for one year from now as opposed to ten years from now? You either write maintainable code or you don't; you can't exactly specify how long until your change "expires".
I suppose one could argue that the next standard of their language will deprecate method
Foo, but if a method is going to be deprecated, that's really more a thing of code quality and maintainability than it is coding for future dates.好好编码，只关注下一个可交付成果。编写良好的代码是无限可重构/可扩展的，无论是否考虑到这一点。本来应该可扩展的编写糟糕的代码很少在实践中得到应用。
Code well, and look only to the next deliverable. Well-written code is infinitely refactorable/extensible whether written with this in mind or not. Poorly written code that is meant to be extensible rarely is in practice.
每当我编码一些东西时，我都会问自己……
需要吗？如果你不需要它，那你为什么要编码呢？
我发现它有助于防止我添加不必要的代码。不必要的代码是一种消耗。它需要远离其他活动的时间。它增加了代码大小和复杂性。它为项目添加了$$$——特别是如果代码库必须经过认证过程。
Whenever I am coding something, I ask myself ...
Is it needed? If you don't need it, then why are you coding it?
I find it helps keep me from adding unnecessary code. Unnecessary code is a drain. It takes time away from other activities. It adds to the code size and complexity. It adds $$$ to the project--especially if the code base has to go through a certification process.
如果您严格遵循敏捷方法，那么您应该只针对当前问题进行编码。这也称为 YAGNI（你不需要它）原则。
这个想法是，您不知道即将发生什么，因此尝试为其编码是没有意义的。
然而，我认为这不是特别明智的做法。
即使您处于敏捷环境中，您也知道您希望代码能够执行多次迭代，因此应该对此进行编码。
虽然程序确实会过期并且技术会发生变化，但如果您正在编写“杀手级”应用程序，那么它的存在时间将远远超过 3 年。
If you are following Agile methodologies to the letter then you should be just coding for the current problem. This is also known as the YAGNI (You Ain't Gonna Need It) principle.
The idea is that you don't know what's coming round the corner so there's no point in trying to code for it.
However, I don't think that this is particularly sensible approach.
Even if you are in an Agile environment you have an idea of what you want the code to be able to do several iterations down the line and therefore should code to that.
While programs do expire and technologies change if you're writing that "killer" app it will be around for a lot longer than 3 years.
在设计代码时，您应该记住扩展代码或可能需要新功能的可能方式，并且应该努力使其足够模块化，以便可以添加新功能。如果在某个点上，一个决定将使其更加灵活或可扩展，而另一个决定将使其更加严格，如果变得更加灵活几乎没有成本或没有成本，那么这样做是有意义的。但是，如果更灵活的路线的成本很高，那么就不要这样做。除非您确定需要该功能并且成本合理，否则您不应该疯狂地尝试添加此类功能；如果你这样做，你很可能会白花钱。
When designing your code, you should keep in mind possible ways that it might be extended or new functionality might be demanded of it, and you should strive to make it sufficiently modular that adding new functionality is possible. If there is a point where one decision will make it more flexible or extensible while another decision will make it more rigid, if there is little to no cost at being more flexible, then it makes sense to go with that. However, if the cost of the more flexibile route is significant, then don't do it. Unless you know for certain that you will need that feature and that the costs are justified, you should not go crazy in trying to add such functionality; if you do, you'll most likely spend a lot for nothing.