技术周期_技术选择中的元周期-CSDN博客

技术周期

自1950年代以来，我一直在为QCon Beijing做主题演讲，并研究技术趋势和选择。

我在IT中看到的有趣的紧张关系之一是“正确完成”和“快速完成”之间的紧张关系。

大多数企业/业务IT都在制定良好的业务决策。做出这些决定的商人需要的信息大部分都是正确的，而不是准确的。是的，IT的某些部分处理围绕金钱的交易，犯了1分钱的错误是不可接受的，但是我们对企业IT所做的绝大部分工作是帮助商人做出明智的选择。

我的QCon演讲将围绕由IBM //和VisiCalc淘汰的IBM 360/370上的大型，制度化的IT的崛起。

但是我看到这种事情一遍又一遍地出现。

您有大型重要的“必须正确”的IT项目，有50％的时间失败了，而没有失败的项目，其余的75％是迟到的或与原始范围有实质性差异。

另一方面，您拥有业务人员可以在电子表格中完成的工作，这是几个开发人员可以使用今年版本的Delphi / PowerBuilder / VB / JSP / Apex在几周内“完成”的项目。

有趣的是，看到了以上两种方法的周期。有了“必须有正确的”项目……当它们失败或严重落后于计划时，“快速完成”队伍就会出现，而且，很快就可以完成。我有一个朋友，他在一家大银行工作，并且在进入大型C ++ / CORBA项目的过程中取得了巨大的成就，这些项目按计划进行了1-4个月，由3个人组成的团队完成了90％的功能。

孤立地快速完成项目似乎是一个更好的选择。但是，当您进行大量的砍伐和烧伤，完成项目所需的一切工作时，总的来说，它们是无法维护的，并且无法轻松地从最初部署的手动配置机器上迁移。其症状是Windows XP不会消失，因为XP机器上运行着数百万个无法移动的项目。从更广泛的角度来看，如果您的数据库中有数百个表，这些表大多是引用岛，那么您会过于激进地完成“快速入门”。

我的想法

经过近40年的观察，……并参加了苹果// //作为一个高中生，开发了廉价，快速的软件，其硬件和软件的总成本低于研究问题并提出估算框架所需的成本在FEMA的DEC微型计算机上做这件事，这是我的第一个付费演出……这就是我的想法。

您绝对需要一组可以信任的坚如磐石的核心基础架构。事实的来源必须是可信赖的，可维护的，设计良好的，记录良好的，可测试的和经过测试的，以及我们从传统的集中式高成本，运行缓慢的IT部门看到的所有其他信息。它们成本高昂且运行缓慢，以换取构建非常灵活，可维护且可预测的系统。

但是那些坚如磐石的系统需要公开非常简单的数据和API，以使其可以快速构建一次性的系统。快速构建的系统可能是基于电子表格的，也可能是基于JavaScript的，等等。它们是要被丢弃的项目……尽管实际上，它们成为数十年来困扰着组织的行尸走肉。

精明的IT高管将为这两种系统分配资源，并在两者之间取得平衡。如果一个项目打算被整个公司/客户群的一小部分使用，则可以快速执行该项目并维护其可维护性，以“在规格发生重大变化时廉价地重新编写”。小型项目不应相交/相互依赖。他们通常不应彼此共享数据库表。应该将它们隔离开来，以便他们可以更改，破坏，迁移，而不必担心只有一个人知道并且两年前该人离开了公司的依赖……或者更糟的是，某个人的头上有太多依赖，劫持公司人质。

不符合上述标准的项目应放在缓慢且充满过程的路线上，因为这些项目比个人要大，并且随着时间的推移会对组织产生影响。可预测性和可维护性的成本超过了开发和速度成本。

上述折衷没有公式，只是一条裤子……或者我只是一个a脚的经理，无法阐明一套可靠的规则。

避免“昨天的技术”问题

要记住的一件事是技术选择。无论大型项目还是小型项目，都必须采用合理的早期主流技术。

在这两种情况下，在系统生命周期开始时，选择早期主流采用的技术都意味着这些技术将在项目的整个生命周期内不断增长，在某些情况下将超过20年。

在上个千年中，选择Java / JSP作为快速项目的公司是一个不错的选择。 Java / JSP是早期的主流，并在中小型项目中取代了VB和PowerBuilder。但是，今天的选择（或Java / Play！或类似的东西）将是一个糟糕的选择。另一方面，“快速执行”项目JavaScript / Node很有意义。是的，服务器端JavaScript开发人员今天比Java / JSP开发人员更昂贵，但是几年后成本将与其他主流技术保持一致。有关价格趋势，请看15年前的Java / JSP开发人员和8年前（今天）的Ruby / Rails开发人员。

对于大型IT项目，没有多少明确的选择。我认为这是微服务变得流行的原因之一。没有人能为大型IT项目找到合适的语言/框架组合，因此，这些项目已脱钩，技术选择也被放弃。可悲的是，这意味着大型项目中真理的来源减少了……但是我离题了。