工具和工程是两个维度的东西，瀑布开发是一种怎样的体验？

菏泽炫佑科技

工具和工程是两个维度的东西，瀑布开发是一种怎样的体验？

2、产品不多，但工程性能的数量级提升却经常发生变化；

3.是一个大赛道，数据库是重中之重；

4、UI设计工具非常繁荣，商业化得很好。 发展趋势是与低代码结合；

5、开发领域的工具众多且复杂，开源和大公司面临的挑战*大。 项目管理是商业化*好的环节；

6、国外优质工具投资巨大，产品丰富且优良，而国内投资几乎为零；

7、互联网和云原生催生了持续交付的发展；

8、可观察性越来越重要，AIOps是发展方向，商业化也很成功；

9、除了运行时安全之外，开发安全越来越受到关注，软件供应链也值得关注；

10、一站式工具一定会开放，拥抱单点工具；

11、PC时代、互联网时代的工具都是外国的。 云原生时代，国内Infra团队有机会。

作者 | 张

来源 | 领取公众号（已授权）

给个定义

从2019年左右开始，这个词在软件工程领域出现的频率越来越高。 虽然这个概念早在十多年前就已存在，但真正在国内外流行起来却是近几年的事。 你说三年前，大多数人指的是 CI/CD。 两年前，一站式服务的概念开始出现，涵盖从项目管理开始的一整套。 *近又开始被提起，并且层出不穷。 如今，很少有人在这个概念上挣扎。 严格来说，是指让开发来做运维工作，但在实际应用中，这个词一般可以理解为现代软件工具和工程方法。

工具和工程是二维的东西。 我们谈论敏捷开发。 瀑布开发是一种工程方法论，与实际使用的工具无关。 您还可以使用 Excel 实现敏捷。 但在实践中，特定的工程方法往往依赖于特定的工具，例如敏捷依赖于看板。 从我们的观察来看，目前各行业软件开发团队使用的工程方法论还是有很大差异的，包括敏捷、瀑布、两轮驱动、中国式敏捷等，但所使用的工具正在逐渐趋同，并且普遍他们正在转向新的生产力工具。

我们对国内外近千种工具做了一些研究和分析，记录了一些总结与大家分享。 值得一提的是，这些工具的覆盖范围包括整个软件基础设施Infra，而不仅仅是Infra。

基础设施图

市场上有各种各样的工具。 我们需要找到一个维度来对工具进行抽象分类，并将类似的项目进行组合，以便更好地了解行业和市场。 有许多抽象的维度。 例如，根据面向客户的规模，它可能太厚，根据工具的类型，它可能太薄。 *后，我们决定根据软件工程的阶段和级别来划分，并创建了下面的地图。

这种分类的逻辑是：

*底层是云，包括AWS、腾讯云、阿里云等，还有一些资源相关的产品，比如等等。

*上面是软件设计相关的，包括UI设计和需求设计，这些都是软件的可见部分，比如Figma、Adobe等。

中间部分是实际构建软件的部分。 首先是软件开发、质量检验和交付。 这是所有生产所必需的三个步骤。 其中包括日常开发人员接触*多的IDE、代码管理、需求管理、CI。 /CD、自动化测试等

是每个软件所依赖的部分，可以理解为软件的基础，比如容器、数据库、编程语言SDK等。

*右边是 和 ，这两个块对于保证软件的正常运行至关重要，比如监控日志报警、安全扫描、入侵检测等。

这里每个色块的大小代表了我们认为该领域当前的市场空间。 我们相信，这里的区域将会随着行业的发展而发生变化。 这个分类基本上涵盖了软件工程的各个方面。 当然，一款产品可能会跨越多个色块，尤其是平台产品。 许多新产品的界限非常模糊。 例如，一个类产品会同时提供一个IDE和一些中间件。 但也有一些产品非常专注于特定领域，例如基于AI的UI自动化测试。 这就涉及到一个经常被提及的问题：一站式工具和单点工具*终的关系是什么？ 我们将在文章末尾讨论这个问题。

我们在制作这张地图的时候就深深地意识到，与美国相比，中美在这一领域的差距实在是令人尴尬。 “新创”的本土化之路任重而道远。

我们跳过底部的云部分，因为云部分与大多数公司无关。 这个底层基础设施和电信运营商类似，注定只是少数大公司的业务。 我们先来看这一部分。

目前重点关注的产品不多（我这里一般指的是运行程序的程序，也是程序的一种），和整个技术体系的发展阶段有关。 事实上，工程性能的数量级提升往往是通过变化来实现的，比如当年Java带来的变化，以及*近容器化带来的变化。 下一个可预见的变化是。 虽然已经存在很多年了，但是发展并不顺利。 原因是程序结构与新的运行环境不匹配，所以我认为要想发展就必须从程序结构的改变开始。 目前有一些公司在朝这个方向努力，比如，，以及新成立的创业公司Koyeb。 这里的新事物都是比较小众的，因为它们的适用性有限，解决了*终的效率，但是无法解决大规模应用的问题。

另一种是相对兼容现有的应用结构，提供更好的工具来帮助开发和管理运行环境，典型的比如k8s，也有一些非常大的初创公司，比如。 我们可以将这些产品视为新时代。 这个领域的产品很多，而且新产品不断涌现，是对现在云的很好的补充。

中间件

说实话，在我职业生涯的早期很多年我都不明白什么是中间件，尽管我的**份正式工作是在.net的中间件部门。 这个概念在不同时期往往有不同的含义。 *早的中间件可能指的是JBoss之类的服务器软件，后来还包括消息队列EJB之类的。 我觉得理解中间件的概念比较好：所有不是程序本身但是程序运行所必需的软件，比如数据库、缓存、队列、网关等。中间件可以直接提供给你云供应商，但你必须自己编写程序。

中间件种类很多，这里有很多上市公司和初创公司。 这是一条超级大的赛道。 我看了一下基本上可以分为sum和sum，因为数据库真的是中间件皇冠上的明珠，它是如此的美丽。 这里不一定是传统意义上的数据库，而是与数据存储和处理相关的任何东西。 其他还有太多诸如、、、等等，都很大。

它比较小，但是类别很多，比如对象存储MinIO、服务网格Solo.io、消息队列、API网关Kong等。

链接：需求设计和UI设计

事实上，软件工程中的很多概念都是借鉴于传统制造业的。 本质是生产东西，一个是实体的，一个是虚拟的，但是流程和管理方面有很多值得借鉴的地方。 所有的生产无非就是设计、制造、质检和交货。 我们先来看看设计方面。

软件设计分为需求设计和UI设计（当然还有架构设计、数据库设计等，我们认为是开发阶段）。 这里的需求需要与Jira等传统项目管理软件中的需求区分开来。 Jira 中的需求可视为已确定并进入开发流程。 事实上，业务运营过程中的很多需求是不确定的，可能来自IM、电子邮件、口头等，这些需求需要经过产品经理的充分评估和改进后才能进入开发流程。 这些需求也缺乏结构化的组织。 所以我们可以把这里的需求设计理解为生产研究和业务连接的地方。 专注于这个领域的产品确实不多。 可能是痛点不够明显，也可能是被其他工具替代了，比如文档、Excel、Jira等，虽然不够完美，但也还不够痛。 有一些产品做得很好，例如 Aha.io 等。

UI设计的工具相当多，比如老牌的Adobe系列，新星Figma等等。 这个领域有很多细分领域，比如产品原型、Proto.io、快速UI设计、通用线框工具Miro等。这里的发展趋势是逐渐与低代码融合，*终可能会发展成一种状态设计为代码。 所有这些工具确实降低了门槛，让更多的人可以上手，但真正专业的设计师仍然需要能够控制细节的工具，所以Figma这样的工具更受专业群体的欢迎。

*复杂的领域

发展占据了整个地图*大的面积。 这个区域东西*多，也*复杂。 毕竟这是你和人交往*多的地方。 这里*大的部分叫，包括需求管理、bug管理、进度管理、测量等。已经开发出Jira、Asana等产品，而且都是非常大的上市公司。 这个领域新产品不断涌现，比如Code，但都是比较垂直的。 值得一提的是，有很多团队使用更通用的管理工具来实现相同的目的，例如，甚至。 管理是一个非常多样化的需求，因此这个领域开满了鲜花。 我们观察到，中美两国在这一领域的需求存在巨大差异。 外需更偏向于个人效率，内需更偏向于管理效率。 从全球范围来看，我们还没有看到任何可以挑战Jira的产品。 基本上，Jira的插件能力可以满足大部分场景的需求。 然而国内Jira面临着巨大的挑战，不仅仅是因为国外的产品政策。 确实，国外的产品在满足用户的“管理”需求方面做得还不够，比如支持瀑布模型混合的中国式敏捷，以及业务需求的管理等。

这里的第二个主要发展领域是，俗称的装配线，它也是借用自制造业。 这里指的是写完代码之后涉及到的工具，而不只是像这样的CI。 这里的典型代表是它的两个主要产品是代码仓库和CI，占据了大部分位置。 这个领域极其复杂，但在商业化方面做得好的并不多。 其中大多数是小工具，甚至是开源工具。 在这个领域做产品会面临开源*大的挑战，因为程序员喜欢在这里造轮子。 可以集成各种单点工具，例如代码扫描Sonar、代码审查、代码搜索等。 还有一些比较垂直的工具，专注于某一类应用，比如移动端构建、移动端开发Ionic、服务器端镜像构建等。

我们来谈谈低代码。 实际上我不太相信低代码的故事。 详细分析可以阅读《低代码开发是未来吗？》 》。 但无论如何，模块化的低代码业务功能在某些垂直场景下确实很有价值。 事实上，我们认为好的低代码产品往往都是垂直场景的。 老牌的低代码产品比如等等，微软等各大厂商也都有自己的低代码产品。 其他低代码产品大致可以分为两类。 一是流程自动化，比如Tray。 另一类是快速开发工具，例如，。 严格来说，Excel可以认为是一种低代码工具。 总的来说，我认为低代码是为了提高现有模式重复创建的效率，而不是解决从0到1的创建效率问题。

开发真正的价值在于从0到1的创造，这需要专业的开发工具IDE。 IDE是严格意义上的工具，即程序员使用的“锤子”。 每个人的喜好不同工具和工程是两个维度的东西，瀑布开发是一种怎样的体验？，不同的工种对锤子的要求也不同。 IDE是一个非常非常重要的工具，但是真正商业化的并不多。 造成这种情况的原因有两个，一是开源，二是大公司的垄断。 也许是因为IDE太重要了。 如果每个开发者都必须付费才能使用，将会极大地限制人类的创造力。 因此，很多产品都是开源的，比如它的各种衍生品，还有微软的。 还有一些大公司垄断的产品，比如XCode，也是免费的。 目前只有独立IDE厂商做得比较好，但也有传言说他们会被收购。

做出一款好的IDE的门槛其实非常高，因为它是与程序员互动*多的产品，所有细节都必须完善才能获得青睐。 遗憾的是，国内至今还没有像样的IDE产品。 各大云厂商生产的产品都是基于开源内核的，没有任何核心技术。 而且这个品类本身的定位也很尴尬，缺乏场景。 作为创造力的核心，IDE工具可以是免费的。 只要上下游生态能够蓬勃发展，效益就会更大。 这也是各大厂商愿意在这里进行战略性损失的原因。 说到这里，我们就来回忆一下曾经的IDE工具之王吧。

在制作这张 Infra Map 之前，我从未想过 API 会被划分为一个单独的类别。 这类产品看上去存在感并不强，但我错了。 只是国内使用的产品很少，国外很多产品已经很成熟了。 国外信息化发展早，生态系统开放。 API已成为各类产品互联的标配。 自然，API太多就需要管理，于是就出现了这样的产品。 很多大公司也提供API全生命周期产品如、、Tibco等。 该领域几乎没有开源产品。 大概只有大公司才会使用这样的产品，而且很容易圈钱。 我们相信API将变得越来越重要，数字世界将变得越来越丰富，沟通和交流将依赖API。

这里开发的*后一个类别是 Hub。 为什么会有这种单独的分类？ 因为。 我们将其视为一种工具、社区还是资源？ 虽然具有工具属性，但在企业级应用中效果更好。 但在开源社区和开发者影响力方面无人能比。 创作的过程避免不了借用，而Hub就是各种可以借用的资源。 除了代码之外，还有 等提供的API Hubs 提供了可以参考的应用架构。

保护区

如何保证软件产品的质量是一个令人头疼的问题。 我们可以依靠自动检测工具或手动测试。 首先我们看一下Test，它是测试工具。 这是一个很大的类别，大多数质量保证投资都放在这个领域。 让我震惊的是，国外在测试工具上真的花了很多钱。 难怪国外产品质量好，而国内产品基本还是靠人。 测试工具有很多细分，比如一些相对成熟的领域：

测试工具有一个趋势是基于AI，包括通过历史测试数据生成新的测试代码，或者通过可视化分析来测试UI，比如Test.ai等。当我看这个领域时，确实是这样。超出我的想象。 感觉就像我发现了宝藏。 没想到老外的测试工具这么先进。 这些工具的场景非常清晰，商业化也不错。

除了测试工具之外，测试管理也很重要。 顾名思义，测试管理就是对测试用例、测试计划、测试结果等进行管理，形成结构化数据、输出报告等，诸如此类。管理工具相对较少。 这里比较有趣的一家公司叫Test ，它引入了一种更加数据化的连接上下游的测试管理理念，值得学习。

有了工具和管理，剩下的就是人了。 到目前为止，测试仍然是一项需要人工参与的工作，因此有一些测试服务公司承接外包测试，也可能通过众包的方式来完成，例如。

的演变

软件交付由入库和交付两部分组成。 过去我们对于可交付软件的仓储比较随意，基本上都是直接放在文件系统中。 随着软件工程的深入，我们发现软件存储也很有讲究，包括权限、安全扫描、跨网传输等。因此，这一类别诞生了，典型的代表是JFrog和开源的Nexus。 该领域门槛不高，替代方案较多，因此深度涉足该领域的企业并不多。 唯一一家上市公司JFrog的市值也不高。

*早的软件交付是通过物理介质，80年代出生的人可能都有过购买软件光盘的经历。 随着BS应用的兴起，软件分发已经变得基于互联网，软件交付变成了更新服务器上的代码的问题。 因此就有了持续交付的概念。 几乎所有的互联网和移动互联网应用都涉及到持续发布的问题，因此这个领域诞生了很多商业工具，比如。 过去，应用架构多种多样，交付工具也多种多样。 许多团队构建了自己的发布工具。 随着云、微服务、云的兴起，应用架构开始融合，交付工具也趋于统一，出现了很多新兴的发布工具，比如. 例如，还有一些工具专注于灰度发布的能力。

越来越重要

事实上，可观察性一直存在，但在过去并没有那么重要，因为大多数单体应用程序或客户端应用程序架构简单，问题很容易排查。 *直观的可观察工具是任务管理器。 您可以看到正在运行的软件消耗了多少CPU和内存。 如果系统卡住了，直接杀掉消耗*大的进程即可。 只是云时代，微服务架构让软件变得非常复杂。 一个问题涉及N个微服务，可能涉及N台服务器。 发现问题就变得非常困难，所以可观察性就显得尤为重要。 这个领域存在很多问题。 优秀的商业软件，如。

可观察性由几个要素组成：监控、记录、报警和跟踪。 其中，只有日志有单独的商业工具，例如，其他的基本都集成为一个工具。 以前这个领域基本都是自己用开源产品搭建的，，，，，但是真正集成这些产品并不容易，这涉及到海量数据的处理。 所以这个领域有很多商业公司，除了其他还有，等等。所有这些工具只有一个目的——帮助你在出现问题的时候快速定位问题。

仅仅定位问题还不够。 *好完全自动解决问题。 这就是 AIOps。 虽然我觉得让机器来做运算是危险的，但是这个领域也有很多大型商业公司，比如，，。 总的来说，可观测性是一个有前景的市场。 软件吞噬世界。 如果软件不可控，后果将不堪设想。

*重要的事情 -

写了这么多，终于到了*后一篇，安全。 在传统意义上，安全通常指的是运行时安全，因为这是存储生产数据和与客户打交道的地方。 因此，企业投入大量资金来保证生产系统的安全运行，包括防火墙、流程监控等。这个领域有很多成熟的工具，比如、、、等。这些工具从各个方面保证应用的安全，包括网络、容器、云主机等。这一领域的安全传统上是“运维”关注的问题。

开发安全的另一个领域*近受到越来越多的关注，它解决与软件开发相关的安全问题。 基本上可以分为几类，静态安全（SAST）、动态安全（DAST）、软件组件分析（SCA）、交互式安全（IAST）和运行时应用程序保护（RASP）。 由于制造商一般不会只生产一种类型的安全产品，而且往往会跨越多种产品，因此我不会单独列出它们。 这里既有老牌厂商如、、、，也有一些新星、Snyk、、等，安防产品要实现核心竞争力的门槛相当高。 如果仅仅依赖公共漏洞数据库进行扫描，那就太同质化了。 因此，好的安全产品一定是在性能、易用性、有效性、甚至独特性方面。 亮点在分析能力等方面。

还有另一类安全称为“软件供应链安全”。 虽然供应链安全*近被频繁提及，但它也被当作一个盒子，把所有东西都装在里面。 但我认为严格意义上的供应链安全与上述两种安全不同。 供应链安全的核心解决的是可信问题，即保证软件不被篡改。 运行时安全和开发安全解决错误和漏洞。 当然，供应链安全也可以归入发展安全的一部分。 毕竟这也是发展过程中的事情。

还有一个领域叫做安全管理，它与测试管理类似。 该类别的产品不多。 主要解决审计、合规管理、风险管理、风险评估等一些问题。

一站式工具与点工具

看了这么多工具，我们发现老外其实很卷毛，随便一个带点肉的赛道都有很多人围观。 幸运的是，国外市场很大。 毕竟，这是一个全球市场。 企业越多，越有利于市场繁荣和创新。 但国内对Infra大赛道的投入其实还不够。 上述工具每个类别都有一些国内标杆，但无论是数量还是质量都存在巨大差距。 具体的我就不一一列举了，大家可以互相鼓励。

那么国内这么多ToB厂商的程序员每天加班在做什么呢？ 外国人在造轮子，我们在包轮子。 国内企业喜欢进行自研。 到目前为止，公司产研团队使用的工具大部分都是自建的。 典型的方法是使用开源工具，然后获取破解的 Jira，或者更好的是，自己构建一个控制台，然后神奇地修改它。 查看开源工具会让这些工具看起来像是“一站式商店”。 这种被美其名曰“自研”的做法，浪费了大量的工程人力。 想象一下，中国有多少这样的团队。 另一方面，国内商务工具市场十分惨淡，无人做，形成恶性循环。

“一站式”是一个在中国特别流行的概念（外国人的产品似乎总是强调All in One），可能是因为中国人喜欢一站式购物。 我们也注重一站式的理念，但我们越来越觉得不可能包办一切。 细分领域那么多，每个领域都有上市公司。 一家公司如何能做到这一切？ 所以一站式解决方案*终一定要走向开放平台，这也是我们的发展方向。 说实话，一站式并没有太多的技术创新。 它基本上是管理的演变，而管理又是不规范的重灾区，所以它不是一门好生意。 市场上的一站式产品应该不多，几个就够了。 单点工具要充分发挥，在各个细分领域细化，创新才能萌芽。

在制作Infra Map的过程中，该领域的发现确实突破了我们现有的知识。 该行业的外资规模巨大。 国内团队一直享受着国外研发成果自动化软件开发，从PC时代到互联网时代都是如此。 幸运的是，我们看到在当前的云原生时代，国内的Infra团队开始崭露头角。 只有研究历史，才能洞察未来。 希望我们的贡献能够帮助到更多的国内团队。 相信工具会随着生产力的提高而不断改变，机会永远存在。

结尾

《新程序员001-004》全面上线，对话世界级大师，报道中国IT行业创新创造

成就一亿技术人

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等