确定语言/框架/技术是否“面向未来”

我是PHP开发人员，最近我开始使用CodeIgniter。看来，每当我搜索与CodeIgniter相关的内容时，博客文章以及通常不是'09或'10的内容，都让我开始思考，CodeIgniter是否仍然有意义，并且将来还会有用吗？是否有其他框架正在取代它？

其他语言和框架也是如此。您什么时候放弃学习某些语言或框架？有什么简单的方法可以找到正在出现的值得收集的东西？

这不是一门精确的科学，因此不要期望能够确定地预测超过5年的技术前景。

但我会寻找以下所有内容：

• 已安装的基础 -更大的已安装基础意味着许多公司会竞相投资于该技术及其维护，这意味着需要开发人员来使用该技术。随后出现正周期。例如，像Java之前的COBOL一样，Java不会消失很长时间。
• 广泛的行业支持 -是否有多个知名行业参与者支持该技术？只有一个坚定的支持者是一个警告信号-只需更改策略即可随时将其丢弃或搁置一旁。
• 开源 -事实证明，主要的开源产品长期以来都是非常好的选择（例如，查看Linux，Apache，Red Hat，JBoss和Eclipse...。）。另一方面，专有产品有些受单个供应商的追捧，您可能会面临停产/价格上涨/试图强迫其迁移到“下一件大事”的风险。
• 品质 -高质量的产品寿命更长，因为人们希望使用它们而不是转向其他产品。相反，质量更好的产品将很快被废弃。
• 创新 -技术是否朝着创新的前沿发展？如果是这样，它可能会在更具创新性的公司和用户中获得采用和支持。这最终将开始成为主流（例如，我会说像Scala和Clojure这样的新语言属于此类）
• 社区 -是否存在围绕技术的积极，开放，务实，奉献，乐于助人的社区？这些是最终将保证未来的人。

没有办法知道是否有什么可以证明未来的发展，我宁愿专注于这项技术是否可以帮助我解决今天遇到的问题。当某种语言或框架无法解决您的问题时，您将放弃学习某种语言或框架。

参与代表您正在做的事情的社区，您可以很好地了解即将发生的事情，但是即使那样，我还是愿意花时间用最好的工具来完成工作，而不是什么很热门或我认为最热门的一个。从现在开始的一两年。

无法确定性地确定某事是否可以证明未来。您可以得出的最接近的信息是确定围绕特定语言或框架的活动级别-如果开发人员的活动很多，通常是一个很好的信号，表明该语言/框架正在逐渐流行并且可以在一段时间内可行。反之则表示兴奋程度较小，并且（通过开发人员论坛）获得支持的难度可能更大。

只要您选择的语言/框架能够解决您要解决的问题，就无需担心将来的问题，除非您显然正在与一种濒死的技术合作。技术不断变化-您可以做的一件事就是跟踪行业趋势。如本主题所述，学习新的编程语言/框架可以帮助您紧跟潮流，并为您提供不断评估新工具的机会。

“耐未来性”既涉及意志力和固执，也涉及更务实的关注。

一个极端的例子就是这个。从40年代末开始，Sparkle Filters仍在运行IBM 402计算机作为其会计系统。这是一台使用电子插件板而不是“文件”进行编程的机器。

我个人曾在一家公司工作过，该公司仍然在专门设计用于运行数十年的专用仪器中维护基于MS-DOS的计算机。直到1997年，我什至取消了可操作的PDP。

我想说的是，如果您的公司像Sparkle Filters一样受到计算机历史博物馆的访问，那将表明您（或您的祖先）已经成功地“验证了”该系统！

我可以回答某项特定技术是否可以满足未来需求-答案几乎肯定是没有，因为您没有为此花费时间。

为了使这个问题易于回答，您将需要在需求中添加更多细节。例如：

• 我们在说什么时间范围-1年，3年，5年以上？
• 采摘5年后不在的东西的成本是多少？
• 通过选择不太“安全”的选择，您将获得什么好处，而好处是否超过了风险？

语言/框架/技术的选择实际上是项目风险管理的一部分。与所有风险一样，您将需要考虑多种因素（我试图将其保持简短），然后采取措施将其降低到适合当前情况的水平。

与生活中的大多数事物一样，风险最低的活动实际上可能不是最佳选择。

简而言之，与您将在项目的预期寿命期间获得的收益相比，您准备承受多少不确定性。

您对未来的展望时间越长，确定的可能性就越小。例如，如果您只担心接下来的两年，您的选择将比挑选未来十年需要解决的事情容易得多（并给您留下更多选择）。

我要说这是不可能的，有很多因素。可能出错的事情包括：

• 时尚。人们失去了兴趣，将注意力转向了新的漂亮平台。Perl在2000年左右几乎垄断了Web应用程序。现在几乎没有提及。
• 供应商的市场份额。大约在2000年之前，尽管C ++ / Sun Solaris在3000年之前还是不错的。
• 公司Shenanigans。几年前，我会选择Java作为未来的证明平台。有了ORACLE对API等的版权保护，我想将会转向其他语言框架，我只是希望知道哪个框架。
• 路的尽头。我正在考虑像Visual Basic这样的东西，在经历了一段悠久而光荣的历史之后，就无法再扩展以适应软件开发中的最新思想。
• 失败者获胜。PHP（我喜欢）永远不会也永远不会赢得开发人员的选美比赛，但是它已经成为毫无争议的网络之王。当我在2004年首次编写php时，我永远都不会将它作为Web开发的通用语言来支持。
• 丑小鸭。无需更改单个语法或添加单个API的Java脚本，突然就摆脱了原始的脚本语言，这种动画语言的恼人旗帜将其添加到WEB 2.0的核心部分。

最后，没关系。CodeIgniter为您工作，并提供您想要的东西。您所做的任何事情都不会停止工作，因为博客帖子过旧或发布速度降低了。因此，我的建议是使用现在有效的方法，并应对将来的情况。

一个PHP框架Symfony在其站点上对此做了完美的解释。

选择正确框架的10条标准

您正在进步，这是一件好事！您已经知道您将使用框架来开发站点或应用程序。但是哪一个呢？这是可以用来避免出错的清单：

1.人口和社区规模

框架越广为人知和认可，它将越“活”，不断发展和完善：新想法，插件的数量和质量等。

2.哲学

这是框架的实质：这是确保框架满足您的需求的基本标准。由专业人员根据自己的需求开发的工具显然可以满足其他专业人员的需求。

3，可持续发展

在选择框架之前，请确保在整个过程中它都能跟上您的发展。这简化了应用程序的维护和升级。

4.支持

另一个不容忽视的标准是轻松找到问题的答案并获得帮助。确定可用的支持：来自发布者。来自社区（邮件列表，IRC等）？来自服务公司（开发，支持，培训）？

5，技术

为了避免陷入迷宫中，总是最好选择一种可互操作的解决方案；一种在开发（设计模式）方面尊重最佳实践的方法

6，安全性

任何应用程序都可能容易受到攻击。为了将风险降到最低，总是最好选择能够确保安全功能的框架（例如XSS管理）。

7，文件

评估有关框架的现有文献的性质，数量和质量是绝对必要的：有据可查的工具既易于使用，又可升级。

8，许可证

许可证之所以重要，仅仅是因为它们会对您的应用程序产生重大影响。例如，使用GPL许可框架开发的应用程序必须服从GPL。另一方面，对于MIT许可的框架而言并非如此。

9.市场上的资源可用性

也许您希望在开发阶段或从长期来看，有一个技术团队为您服务，以进行维护和升级。换句话说，请确保所使用的工具所需的技能在公开市场上可用。

10.尝试一下！

那是关键！不要对在互联网上阅读评论，评论和谣言好坏感到满意。通过对其进行测试，您将可以下定决心，并确保完全满意该工具。

关键是耐心。忍耐，忍耐，忍耐。无法肯定地预测未来。（我什至必须写那个吗？）但是，如果您将新技术投入几年并观察其被采用的方式，那么您将很好地了解它是否会扎根并适合长期项目/长期投资。

因此，当NextNewThing（tm）出现时，请随意加入潮流……只是在头几年没有任何重要意义。

Mikeras的回答很不错。我会补充说，面向未来确实是一种安全或风险管理。它往往需要你放弃一定的便利和成本/效率优势，现在以避免出现问题以后。我已经开发了将近面向未来的技术已有一段时间了。有某些模式可以提供帮助。这是一些。

1. 数据应以开放格式存储，以便以后提取或转换。奇数文件格式通常是一大锁定技术和陷阱领域。另外，相对于诸如XML或Word 97格式之类的复杂废话，更喜欢诸如CSV，ASN.1或JSON之类的简单方法。想法是，将自己自己放入解析器非常简单，并且低级格式解析器可在您的应用程序中重复使用。

2. 理想的应用应该有供应商和技术中立的接口内置到他们，再加上精确的描述是什么，他们做的。您应该设计一些东西，在其中可以更改或放弃实现而不破坏任何内容。另外，如果您的调用过程或处理数据的方法可跨平台使用，则迁移到新平台也很容易。因此，接口是最重要的正确方法。接口实现方法越简单，越快，越开放越好。

3. 堆栈应该是完全开源的，可以自由修改。从这个角度来看，GPL，LGPL，BSD，MIT等许可证都可以。这个想法是，如果社区开始濒临死亡，那么可能需要将堆栈移至新的[hardware / OS / protocol / etc]。您需要执行此操作的代码。

4. 堆栈的设计应具有高度模块化的特点，每一部分都可以被一个人理解。这样一来，新组就可以更轻松地进行维护。即使将运行时的最低级别考虑在内，很好地分解出库和编译器，如果需要移植，也可以带来巨大的回报。通常，只有一部分可以移植，并且所有旧代码都可以使用。

5. 您的应用应以模块化方式制作，该方式应考虑平台细节，以最大程度地减少该领域的返工。如果可能，它也有助于将功能构造为输入/处理/输出块。这可以帮助分析端口将受到的影响（通常在无尘室方法中进行正确性分析）。最低风险方法平台的明智之选是使用最低通用标准，这些通用特性由一个界面（该界面可让您使用）普遍支持，从而进一步减少了移植。（我说过你会失去一些东西...）

6. 动态键入，类型推断或其他灵活的键入方法会有所帮助。新平台的端口可能会更改基本类型的定义。在内部进行强类型输入的语言意味着您不必担心这些东西。

7. 保持并发模型简单。事件驱动的消息通过清晰的界面传递，可移植到...基本上所有内容。还有协程。您只想避免容易出现错误和可移植性问题的路由。

8. 查看Mozilla和Apache的可移植运行时。它们通过某些接口和实现选择排除了许多平台特定的问题。他们可以提示您担心什么，以及为许多问题提供良好的解决方案。

完美的例子：Tcl。我知道，很多人讨厌它，而我很少自己使用它。但是，Tcl是一种非常容易理解，实施（12条主要规则）和编码的语言。它体积小，速度快，与Web服务器集成，嵌入本机应用程序，已移植到大量内容中，具有某些安全功能，自80年代问世以来就定期进行更新。您或我可以立即使用核心语言实现整个TCL运行时。如果我们必须移植标准库，它将比移植.NET或Java容易。并且为此编写了很多有用的代码。它早在Java小型应用程序也针对的“移动代理”热潮中就已用于网络技术中。例如，OpenACS Web框架可追溯到1998年，服务器版本早于该版本。

其他示例：BASIC，COBOL和LISP（方案或CL）。这些语言都可以追溯到50或60年代。它们足够简单，可以简化理解，实施和机械翻译。但是，您可以与他们一起构建有用的东西。COBOL仍然支持世界上大多数事务处理，已经进行了几次更新，甚至可以在.NET上运行。如今，旧的QBasic / QuickBASIC应用程序仍可在现代平台上使用开放/免费工具运行，并可以将其移植到更好的工具，例如GAMBAS或RealBASIC。LISP编码器自然会将其系统模块化和功能化，从而简化了移植。在过去的几十年中，已经有不计其数的实施方案，无论是开放式还是商业化的。

因此，界面，开放性，简单性，模块化和与平台无关的体系结构/设计/编码。这些将为您提供所需的面向未来的解决方案。无论如何，大多数时候。