基礎設施即代碼（IaC）是軟件開發(fā)中的一個令人著迷的領域。雖然作為一門學科它還相對年輕，但在其短暫的發(fā)展歷程中，它已經(jīng)經(jīng)歷了幾次具有劃時代意義的變化。我認為，它是當今軟件開發(fā)創(chuàng)新中最熱門的領域之一，參與者很多，從大型科技公司到年輕的初創(chuàng)企業(yè)，都在創(chuàng)造新的方法，如果完全實現(xiàn)，有可能徹底改變我們編寫和部署軟件的方式。

在本篇文章中，我想對IaC這一主題進行深入探討：它是什么，它能帶來什么好處，它已經(jīng)經(jīng)歷了哪些具有顛覆性的轉(zhuǎn)變，以及未來可能會發(fā)生什么樣的變化。

#01

什么是 IaC？

讓我們從解釋這個概念開始。基礎設施即代碼是一個涵蓋一系列實踐和工具的術語，旨在將應用程序開發(fā)中的嚴謹性和經(jīng)驗應用到基礎設施供應和維護的領域。

這里的“基礎設施”是故意模糊的，但我們可以把它定義為在環(huán)境中運行一個特定的應用程序所需要的一切，但這并不是應用程序本身的一部分。一些常見的例子包括：服務器、配置、網(wǎng)絡、數(shù)據(jù)庫、存儲等等。在本文后面我們還會看到更多的例子。

IaC的實踐與運行時代碼的實踐相呼應。這些實踐包括：使用源代碼控制進行版本管理、自動化測試、持續(xù)集成/持續(xù)交付（CI/CD）部署流程、快速反饋的本地開發(fā)等。

遵循IaC的實踐可以帶來以下好處：

性能：如果需要提供或更改大量基礎設施，IaC 將始終比人工手動執(zhí)行相同操作更快。

可重復性：人類在可靠地重復執(zhí)行相同任務方面往往表現(xiàn)不佳。如果我們需要重復進行一百次相同的操作，很可能會分心并在過程中出錯。IaC 不會受到這個問題的影響。

文檔化：你的 IaC 可以作為你系統(tǒng)結(jié)構的文檔。當維護系統(tǒng)的團隊規(guī)模擴大時，這就變得至關重要了 —— 你不希望依賴于部落知識，或者只有少數(shù)幾個團隊成員了解系統(tǒng)基礎設施的工作原理。最重要的是，與傳統(tǒng)文檔不同，這份文檔永遠不會過時。

審計歷史：有了 IaC，由于你對IaC的版本控制與你的應用代碼相同（有時被稱為 GitOps），它為你提供了歷史記錄，你可以查看你的基礎設施是如何隨時間變化的，如果任何變化導致問題，有辦法回滾到一個安全點。

可測試性：IaC 可以像應用程序代碼一樣進行測試。你可以對其進行單元測試、集成測試和端到端測試。

接下來，讓我們談談 IaC 工具在實踐開始以來所經(jīng)歷的主要階段。

#02

第一代：聲明式，主機配置

代表：Chef、Puppet、Ansible

第一代IaC工具都是關于主機配置的。這很有意義，因為軟件系統(tǒng)的基礎設施，在其最低的抽象層次上，由單個機器組成。因此，這個領域的第一批工具集中在配置這些機器上。

這些工具管理的基礎設施資源是 Unix 中熟悉的概念：文件、來自 Apt 或 RPM 等軟件包管理器的 users、groups、permissions、init services 等等。

下面是一個創(chuàng)建 Java 服務的 Ansible playbook 例子：

-hosts:app tasks: -name:Updateapt-get apt:update_cache=yes -name:InstallApache apt:name=apache2state=present -name:InstallLibapache-mod-jk apt:name=libapache2-mod-jkstate=present -name:InstallJava apt:name=default-jdkstate=present -name:CreateTomcatnodedirectories file:path=/etc/tomcatstate=directorymode=0777 -file:path=/etc/tomcat/serverstate=directorymode=0775 -name:DownloadTomcat7package get_url:url=http://apache.mirror.digionline.de/tomcat/tomcat-7/v7.0.92/bin/apache-tomcat-7.0.92.tar.gzdest='/etc/tomcat' -unarchive:src=/etc/tomcat/apache-tomcat-7.0.92.tar.gzdest=/etc/tomcat/servercopy=no -name:ConfiguringMod-Jk&Apache replace:dest=/etc/apache2/sites-enabled/000-default.confregexp='^'replace="JkMount/statusstatus JkMount/*loadbalancer JkMountCopyOn " -name:DownloadsampleTomcatapplication get_url:url=https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.wardest='/etc/tomcat/server/apache-tomcat-7.0.92/webapps'validate_certs=no -name:RestartApache service:name=apache2state=restarted -name:StartTomcatnodes command:nohup/etc/tomcat/server/apache-tomcat-7.0.92/bin/catalina.shstart

本操作手冊的抽象層次是一臺以 Linux 為操作系統(tǒng)的單一計算機。我們聲明我們想要安裝的 Apt 軟件包，我們想要創(chuàng)建的文件（創(chuàng)建它們的方式有多種：直接在給定的路徑下創(chuàng)建目錄，從給定的 URL 下載，從存檔中提取文件，或根據(jù)正則表達式替換編輯現(xiàn)有文件），我們想要運行的系統(tǒng)服務或命令等等。 實際上，如果你稍微看一下，你會發(fā)現(xiàn)這個 playbook 與 Bash 腳本非常相似。主要的區(qū)別是，playbook 是聲明式的—— 它描述了它希望發(fā)生的事情，比如在機器上安裝給定的 Apt 軟件包。這與腳本不同，腳本包含要執(zhí)行的命令。 雖然這個區(qū)別很小，但它很重要；它使 playbook 具有冪等性，這意味著，即使它在中間某個地方失敗了（也許 tomcat。apache。org 有暫時的故障，導致從它那里的下載失敗），你可以重新啟動它，之前成功執(zhí)行的步驟會識別到這一點，并在不做任何事情的情況下通過，這通常不是 Bash 腳本的情況。

現(xiàn)在，這些工具對于推進軟件開發(fā)行業(yè)的發(fā)展起著至關重要的作用，不可忽視。但是，它們只能在單個主機層面上運行，這有巨大的局限性。這就意味著你不得不手動管理這些主機，這在很大程度上抵消了IaC所帶來的好處，或者你需要將這些工具與能夠管理主機的其他工具結(jié)合使用，比如用于本地開發(fā)的 Vagrant，或者用于管理共享環(huán)境（如生產(chǎn)環(huán)境）的 OpenStack。

舉個例子，如果你想創(chuàng)建一個經(jīng)典的三層架構，你需要創(chuàng)建三種類型的虛擬機，每種類型的虛擬機都有自己的 Ansible playbook，根據(jù)它們在架構中的角色來配置這些主機。

IaC 工具的下一階段將擺脫這種限制。

#03

第二代：聲明式，云計算

代表：CloudFormation、Terraform、Azure Resource Manager

2000 年代中期，云計算的引入是軟件開發(fā)史上的一個里程碑事件。在許多方面，我認為我們?nèi)栽谏疃认鶐淼母锩杂绊憽?/p>

突然間，主機管理的諸多問題得到了解決。你不需要運行和操作你自己的 OpenStack 集群來自動管理虛擬機；云供應商將為你處理這一切。

但更重要的是，云計算立即提高了我們設計系統(tǒng)的抽象水平。不再只是給主機分配不同的角色那么簡單。

如果你需要發(fā)布 - 訂閱資源，那么就沒有必要去配置一臺虛擬機，并在其上安裝 Apt 的 ZeroMQ 包；相反，你可以直接使用 Amazon SNS。如果你想存儲一些文件，你也不需要指定一堆主機作為你的存儲層；相反，你可以創(chuàng)建一個 S3 存儲桶。諸如此類，不一而足。

我們進入了配置管理服務的階段，而不再是將主機配置置于首要位置。由于上一代的工具被設計成只在單個主機的層面上工作，因此我們需要一種全新的方法。

為了解決這個問題，像 CloudFormation 和 Terraform 這樣的工具應運而生。它們和第一代工具一樣，都采用聲明式設計；但不同之處在于，它們操作的抽象層級不再是單一機器上的文件和軟件包，而是各種屬于不同托管服務的獨立資源，以及這些資源的屬性和它們之間的相互關系。

例如，這里有一個 CloudFormation 模板，定義了一個由 SQS 隊列觸發(fā)的 AWS Lambda 函數(shù)：

AWSTemplateFormatVersion:2010-09-09 Resources: LambdaFunction: Type:AWS::Function Properties: Code: S3Bucket:my-source-bucket S3Key:lambda/my-java-app.zip Handler:example.Handler Role:!GetAttLambdaExecutionRole.Arn Runtime:java17 Timeout:60 MemorySize:512 MyQueue: Type:AWS::Queue Properties: VisibilityTimeout:120 LambdaFunctionEventSourceMapping: Type:AWS::EventSourceMapping Properties: BatchSize:10 Enabled:true EventSourceArn:!GetAttMyQueue.Arn FunctionName:!GetAttLambdaFunction.Arn LambdaExecutionRole: Type:AWS::Role Properties: AssumeRolePolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Principal: Service: -lambda.amazonaws.com Action: -sts:AssumeRole Policies: -PolicyName:allowLambdaLogs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -logs:* Resource:arnlogs*:* -PolicyName:allowSqs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -sqs:ReceiveMessage -sqs:DeleteMessage -sqs:GetQueueAttributes -sqs:ChangeMessageVisibility Resource:!GetAttMyQueue.Arn

這個 CloudFormation 模板與我們之前看到的 Ansible playbook 差別很大。它并未提及任何文件、程序包或初始化服務；而是使用了托管服務的語言。我們配置的資源類型是AWS::Function和AWS::Queue。我們并未定義這些服務將在何處運行，也未定義如何配置這些主機 ——我們所關心的是，云供應商所提供的托管服務能否被正確使用。

然而，它與 Ansible 的共同點在于其聲明性質(zhì)。我們不需要編寫對 SQS API 的調(diào)用來創(chuàng)建一個隊列 —— 我們只需要聲明我們需要一個隊列，并將 VisibilityTimeout 屬性設置為 120，部署引擎（在這個例子中是 CloudFormation）會負責確定需要調(diào)用哪些 AWS API 來實現(xiàn)這個目標。如果我們后來決定修改隊列（比如我們想將超時時間設為 240，而不是 120），或者完全刪除它，我們只需修改模板，引擎便會自動找出需要的 API 調(diào)用來更新或者刪除隊列。

這些工具是 IaC 發(fā)展過程中的一個巨大的里程碑，這大大提升了前一代的抽象水平。然而，它們也存在一些缺陷。

第一個問題是，為了實現(xiàn)其聲明性質(zhì)，這些工具使用了自定義的 DSL（領域特定語言），例如，在 CloudFormation 中，這種語言可能是 JSON 或 YAML 格式。這就意味著所有的通用編程語言功能，比如變量、函數(shù)、循環(huán)、if 語句、類等，在這種 DSL 中都無法使用。因此，沒有簡單的辦法來減少重復代碼。

舉個例子，如果我們想要在我們的應用中配置不止一個，而是三個具有相同設置的隊列，我們無法簡單地編寫一個循環(huán)來執(zhí)行三次；我們必須把相同的定義復制和粘貼三次，這并不理想。同時，這也意味著我們無法將模板劃分為邏輯單元；我們無法將一部分資源指定為存儲層，另一部分資源指定為前端層等。所有的資源都屬于一個扁平的命名空間。

這些工具的另一個問題是，雖然它們肯定比第一代的主機配置更高級，但它們?nèi)匀恍枰阍敿氈付ㄔ谙到y(tǒng)中使用的所有資源的所有細節(jié)。例如，你可能已經(jīng)注意到，在上面的模板示例中，除了我們主要關注的 Lambda 和 SQS 資源，我們還有事件映射和 IAM 資源。這是連接 SQS 和 Lambda 所需的 “粘合劑”，而正確配置這些“粘合劑”資源并非易事。

舉例來說，你需要向執(zhí)行函數(shù)的 IAM 角色授予一組非常特定的權限（sqs:ReceiveMessage、sqs:DeleteMessage、sqs:GetQueueAttributes 和 sqs:ChangeMessageVisibility），才能成功地從特定隊列觸發(fā)它。

從某種程度上來說，這是一個非常低級的問題；然而，由于 DSL 中缺乏抽象工具，我們實際上沒有任何工具可以隱藏這些實現(xiàn)細節(jié)。所以，每次你需要創(chuàng)建一個由 SQS 隊列觸發(fā)的新 Lambda 函數(shù)，你別無選擇，只能復制包含這四個權限的代碼段。因此，這些模板往往會很快變得冗長，并包含大量重復內(nèi)容。

#04

第三代：命令式，云計算

代表：AWS CDK、Pulumi、SST

例如，讓我們看看相當于上述 CloudFormation 模板的云開發(fā)工具包程序（在這個例子中我將使用 TypeScript，但任何其他 CDK 支持的語言看起來都非常相似）：

第二代工具的所有缺陷都可以追溯到它們使用了一種自定義的 DSL，這種語言缺乏我們在使用通用編程語言時習慣的抽象工具，如變量、函數(shù)、循環(huán)、類、方法等。

因此，第三代IaC工具的主要思想非常簡單：如果通用編程語言已經(jīng)具備了這些功能，那么我們?yōu)槭裁床皇褂盟鼈儊矶x基礎設施，而要使用自定義的 JSON 或 YAML DSL？

例如，讓我們看看相當于上述 CloudFormation 模板的云開發(fā)工具包程序（在這個例子中我將使用 TypeScript，但任何其他 CDK 支持的語言看起來都非常相似）：

classLambdaStackextendscdk.Stack{ constructor(scope:cdk.Construct,id:string,props?:cdk.StackProps){ super(scope,id,props); constfunc=newlambda.Function(this,'Function',{ code:lambda.Code.fromBucket( s3.Bucket.fromBucketName(this,'CodeBucket','my-source-bucket'), 'lambda/my-java-app.zip'), handler:'example.Handler', runtime:lambda.Runtime.JAVA_17, }); constqueue=newsqs.Queue(this,'Queue',{ visibilityTimeout:cdk.Duration.minutes(2), }); func.addEventSource(newlambda_events.SqsEventSource(queue)); } } constapp=newcdk.App(); newLambdaStack(app,'LambdaStack');

這個 CDK 代碼的第一個有趣之處在于，它比其對應的 CloudFormation 模板要短得多 —— 大約 20 行 TypeScript，而 YAML 大約有 60 行，所以大概是 3 比 1 的比例。這是一個非常簡單的例子；當你的基礎設施越來越復雜時，這個比例就會越來越大 —— 我見過有些情況下比例高達 30 比 1。

其次，CDK 代碼的級別比 CloudFormation 模板要高得多。請注意，如何從隊列中觸發(fā)函數(shù)的細節(jié)被 addEventSource() 方法和 SqsEventSource 類優(yōu)雅地封裝了起來。這兩個 API 都是類型安全的 —— 你不能錯誤地將一個 SNS 主題傳遞給 SqsEventSource，因為編譯器不允許這樣。

還請注意，我們不必在代碼中的任何地方提到 IAM —— CDK 為我們處理了所有這些細節(jié)，所以我們不必知道需要哪 4 個確切的權限來允許一個函數(shù)被隊列觸發(fā)。

所有這些都是因為高級編程語言允許我們構建抽象概念。我可以把一段重復的或復雜的代碼，放在一個類或函數(shù)中，并為我的項目提供一個干凈、簡單的 API，這個 API 巧妙地封裝了所有混亂的實現(xiàn)細節(jié)，就像 CDK 團隊創(chuàng)建和維護的 SqsEventSource 類那樣。

如果這是其他項目可能受益的東西，我可以把我的抽象概念打包成它所使用的編程語言的庫，并通過我的語言的包管理器分發(fā)出去，比如 JavaScript/TypeScript 的 npmjs.com，或 Java 的 Maven Central，這樣其他人就可以依賴它，就像我們分發(fā)應用程序代碼的庫一樣。我甚至可以把它添加到 constructs.dev 的可用開源 CDK 庫目錄中，這樣就更容易找到它。

#05

第四代：Infrastructure from Code

代表：Wing、Dark、Eventual、Ampt、Klotho

雖然第三代 IaC 工具是一個巨大的飛躍，使云計算更容易被使用（我在這里可能有偏見，因為我是 AWS 的 CDK 團隊的前成員，但我認為這種說法很接近事實），但它們?nèi)匀挥懈倪M的空間。

他們的第一個缺點是，它們在很大程度上是在單個云服務的層面上運作的。因此，雖然他們使使用 Lambda 或 SQS 變得很容易，但你仍然需要知道這些服務是什么，以及為什么你會考慮使用它們。

現(xiàn)在是云計算時代，我們已經(jīng)看到每個供應商提供的服務數(shù)量激增。僅 AWS 就有 200 多種。在如此多樣化的選擇中，選擇適合自己要求的服務變得越來越難。我應該在 AWS Lambda、AWS EKS 或 AWS AppRunner 上運行我的容器嗎？我應該使用 Google Cloud Functions 還是 Google Cloud Run？在什么情況下，這一個比那一個更適合？

大多數(shù)開發(fā)人員對每個云計算供應商的產(chǎn)品沒有特別詳細的了解，特別是由于這些產(chǎn)品往往經(jīng)常變化，新的服務（或現(xiàn)有服務的新功能）不斷推出，舊的服務被淘汰。但他們確實對系統(tǒng)設計的基本原理有很好的理解。

因此，他們知道他們需要一個無狀態(tài)的 HTTP 服務，在負載均衡器后面進行水平擴展，一個 NoSQL 文檔存儲，一個緩存層，一個靜態(tài)網(wǎng)站前端，等等。第三代的工具對他們來說太低級了；理想情況下，他們希望用這些高級別的系統(tǒng)架構術語來描述他們的基礎設施，然后將如何在給定的云供應商上最好地實現(xiàn)這種架構的細節(jié)委托給他們的 IaC 工具。

第三代工具的第二個缺點是，它們將IaC與應用程序代碼完全分開。例如，在上面的 CDK 的例子中，Lambda 函數(shù)的代碼與它的基礎設施定義完全脫節(jié)。而且，雖然 CDK 有資產(chǎn)的概念，允許這兩種類型的代碼在同一個版本控制倉庫中存在，但它們?nèi)匀徊荒芟嗷印哪撤N意義上說，這就是重復 —— 我的應用程序代碼使用了 SQS 隊列，這對我的IaC提出了一個隱含的要求，即正確配置該隊列。

但是，就像所有的重復和隱含要求一樣，當雙方意外地不同步時（例如，如果我從我的基礎設施代碼中刪除了隊列，但忘記更新我的應用程序代碼以不再使用它），這可能會導致問題，而且在我部署我的更改之前，我的語言的編譯器并不能幫助我捕獲這些錯誤，可能會引發(fā)問題。

第四代 IaC 工具的目標是解決上述兩個問題。它們的主要理念是，在云計算時代，基礎設施代碼和應用程序代碼之間的區(qū)別已經(jīng)變得沒有太大意義。因為兩者都在使用托管服務的語言，我在應用程序代碼中想使用的任何資源，都需要在我的基礎設施代碼中存在，就像我們在 Lambda 和 SQS 的例子中看到的一樣。

因此，這些工具將兩者統(tǒng)一起來。它們不再是獨立的基礎設施和應用程序代碼，而是消除了前者，只保留了應用程序代碼，而基礎設施則完全來自應用程序代碼。由于這個原因，這種方法被稱為 Infrastructure from Code，而不是 Infrastructure as Code。

讓我們來看看 IfC 工具的兩個例子。

Eventual

第一個是 Eventual，一個 TypeScript 庫，它定義了現(xiàn)代云應用的幾個通用構建模塊：Service、API、Workflow、Task、Event 以及其他一些東西。你可以從這些通用構件中創(chuàng)建一個任意復雜的應用程序，把它們組合在一起，就像樂高積木一樣。

Eventual 部署引擎知道如何將這些構建模塊轉(zhuǎn)換為 AWS 資源，如 Lambda 函數(shù)、API 網(wǎng)關、StepFunction 狀態(tài)機、EventBridge 規(guī)則等。這種轉(zhuǎn)換的細節(jié)被庫的抽象所隱藏，因此，作為它的用戶，你無需關心這些細節(jié) —— 你只需使用所提供的構件模塊，部署由庫處理。

下面是一個簡單的例子，顯示 Event、Subscription、Task、Workflow 和 API：

import{event,subscription,task,workflow,command}from"@eventual/core"; //defineanEvent exportinterfaceHelloEvent{ message:string; } exportconsthelloEvent=event("HelloEvent"); //getnotifiedeachtimetheeventisemitted exportconstonHelloEvent=subscription("onHelloEvent",{ events:[helloEvent], },async(event)=>{ console.log("receivedevent:",event); }); //aTaskthatformatsthereceivedmessage exportconsthelloTask=task("helloTask",async(name:string)=>{ return`hello${name}`; }); //anexampleWorkflowthatusestheaboveTask exportconsthelloWorkflow=workflow("helloWorkflow",async(name:string)=>{ //calltheTasktoformatthemessage constmessage=awaithelloTask(name); //emitanEvent,passingitsomedata awaithelloEvent.emit({ message, }); returnmessage; }); //createaRESTAPIforPOST/hello exportconsthello=command("hello",async(name:string)=>{ //triggertheaboveWorkflow const{executionId}=awaithelloWorkflow.startExecution({ input:name, }); return{executionId}; });

Wing

另一種方法是創(chuàng)建一個全新的通用編程語言，該語言不僅僅在單臺機器上執(zhí)行，而是從一開始就設計成在云上分布式運行。Wing 就是由 Monada 公司創(chuàng)建的一種這樣的語言，該公司的聯(lián)合創(chuàng)始人是 AWS CDK 的創(chuàng)建者 Elad Ben-Israel。

Wing 通過引入執(zhí)行階段的概念成功地將基礎設施代碼和應用程序代碼合并在一起。默認情況下，Preflight 對應于 “構建時間”，在這個階段執(zhí)行基礎設施代碼；Inflight 對應于“運行時間”，應用程序代碼在云上運行。

通過 Wing 編譯器實現(xiàn)的復雜的引用機制，Inflight 代碼可以使用 Preflight 代碼中定義的對象。然而，Inflight 階段不能創(chuàng)建新的 Preflight 對象，只能使用這些對象明確標有修飾符的特定 API Inflight。Wing 編譯器會確保你的程序遵守這些規(guī)則，所以如果你試圖破壞這些規(guī)則，它就會編譯失敗，并為你快速提供關于應用程序正確性的反饋。

因此，我們上面看到的那個由隊列觸發(fā)的無服務器函數(shù)的例子，在 Wing 中看起來會是下面這樣的：

bringcloud; letqueue=newcloud.Queue(timeout:2m); letbucket=newcloud.Bucket(); queue.addConsumer(inflight(item:str):str=>{ //getanitemfromthebucketwiththenameequaltothemessage letobject=bucket.get(item); //dosomethingwith'object'... });

這段代碼相當高級 —— 我們甚至沒有在任何地方明確提到無服務器函數(shù)資源，我們只是在一個匿名函數(shù)中寫了我們的應用代碼，用 Inflight 修改器進行了注釋。該匿名函數(shù)被部署在無服務器函數(shù)中，并在云上執(zhí)行（或在 Wing 附帶的本地模擬器中執(zhí)行，以提供快速開發(fā)體驗）。

還要注意的是，我們不能在應用代碼中錯誤地使用錯誤的資源。例如，錯誤地使用 SNS 主題而不是 SQS 隊列，因為在 Preflight 的代碼中沒有定義 Topic 對象，所以我們沒有辦法在 Inflight 的代碼中引用它。同樣，你也不能在 Preflight 的代碼中使用 bucket.get() 方法，因為那是一個 Inflight 的專用 API。這樣一來，語言本身就可以防止我們犯很多錯誤，如果基礎設施和應用代碼是分開的，這些錯誤就不會被發(fā)現(xiàn)。

如果你想了解更多關于 Infrastructure from Code 的新趨勢，我推薦這篇來自 Ala Shiban 的文章，他是這個領域另一個工具 Klotho 的聯(lián)合創(chuàng)始人。

https://klo.dev/state-of-infrastructure-from-code-2023

#06

總結(jié)

這就是 IaC 領域的歷史和最新發(fā)展。我認為這值得密切關注，因為它是當今軟件工程中最熱門的領域之一，甚至在一些產(chǎn)品中還將最新的人工智能進展納入其中，比如 EventualAI 和 Pulumi Insights。

我相信，在不久的將來，這個領域?qū)楷F(xiàn)出許多新的方法，這些方法將對我們編寫和發(fā)布軟件的方式產(chǎn)生深遠的影響。