DevOps Lessons Learned at Microsoft Engineering 筆記

原文：https://www.infoq.com/articles/devops-lessons-microsoft

筆記

組織

• 講Microsoft裡面的DevOps
• 故事描述的是Cloud & Enterprise and the Bing teams
• 以前，在一個Feature Team有三種角色：program managers, developers, and testers
• Developer與Tester在組織架構上就分開，還有一個operations team
• 我們想要減少內部溝通所需花的心力所以：
  • 結合Developer與tester->software engineer：讓一個feature能從無到有產出並能正確穩定運行
  • 把operations team的人也帶進來->service engineer
• 要做到最好的單一服務，就是需要一個可以緊密合作的團隊，寫code與測試與運營的人應該要能緊密合作。
• 最後組織的安排，把dev team與test team結合，operations team也拉進同一個大組織裡。
• 在這個大架構，接下來就分成Feture team，負責單一個解決方案，Feature，或Product
• 有專門開發運營內部工具的team
• 有開發功能的Feature team，由10~12人組成，採用自我組織，自我管理的方式
• 有4307人在Develper Division，436人在Team Service Team(指的是Visual Studio Team Service)，在Team Service Team有35個Feature Team
• 一個Feature Team有
  • 一個program manager
  • 一個engneering lead
  • 幾個software engineer
  • 幾個service engineer，他們同時支援多個team，但是都在同一個Product裡
• 另外一個改變就是，相較於之前不同組織就在不同的區域，現在同一的Feture team的人都搬到一起，所以大家不管是討論、接電話，所有有關工作的事情都可以有共同的體驗

責任

• 上述的所有改變的主要目標就是責任的改變
• software engineer與service engineer要一起搞出最好的結果
• 要有量測數據來證明團隊做得好或不好，像是test coverage或是SLA
• software engineer的責任不再只是把東西做出來，並且還要保持產品的健康
• 要Feature team的成員對客戶的問題有所洞察，如何讓客戶能很喜歡產品
• Feature team有完全的責任在產品如何設計開發測試佈署
• service enginner要更多瞭解他們運營的產品，並提供基礎架構與產品的意見，與部署運營的script or code
• Automation是Microsoft裡面軟體生命週期與快速產出價值給使用者的關鍵
• 以前像是，手動測試，環境架設，發行管理，都被自動化了
• 這樣的運作方式更靈活，也有更多機會可以失敗
• 因為都做到自動化，Dev可以自己管理Change，並且導入Feature flags，用來減低風險。
• 導入這些改變之後作者覺得有在Startup的驅動力與興奮感(?)

飛行中(!)佈署

• 從Visual Studio Team Services到OneDrive iOS App，都用Canary Release (派一隻金絲雀到礦坑裡試試有沒有毒氣)，這在VSTS team叫deployment rings。
• 團隊弄好版本後，經過自動build與test，然後發布到內部測試帳號，或早期體驗帳號，或是developer自己的機器裡。
• 現在在VSTS team的deployment ring有4個，有12個單位遍布Azure regions
• 第一個ring是有VSTS帳號的
• Feature team的lead engineer核准發布的第一個ring，因為在第一個ring的都是Feature team的人，自己先測完之後再自動化發布到其他的ring，如果有問題就自己趕快修。
• 而大部分的功能都有feature flag來控制
• 接下來是OneDrive App的例子
• OneDrive App團隊用VSTS來自動build與test，然後用HockeyApp來發布到ring上
• HockeyApp可以提供安裝，運行，Crash與使用者統計，目前是用在內部測試的ring
• 接下來就是用Apple的TestFlight來給beta tester測試
• 一旦ok了就打開feature flag正式發布給所有使用者

Idea Velocity

• 有了Continous Delivery，idea可以快速的被評估測試。
• 在Bing，任何idea都快速的被實驗測試收集統計資料，所以可以比較正確地被評估，這樣更激勵內部人員提出並實行他們的idea

​

Riot工程師分享：THE ARCHITECTURE OF THE LEAGUE CLIENT UPDATE 筆記

參考來源：http://engineering.riotgames.com/news/architecture-league-client-update

心得

看了這篇才知道可以用CEF來開發Desktop Client，Java Script統一所有前端的浪潮還在持續呀。最後講到了”datacenter in a desktop.”也蠻有趣的，Plugin架構雖然不是什麼新觀念，但卻可以很好的解決他們遇到的問題，以後遇到可以參考一下。話說回來，要寫個windows client要同時寫C++與Java Script，好像有點OOXX，不過這是因為他們不想連遠端Server的實作都改的折衷方案，畢竟Client整修失敗，就把舊的拿出去用就好，Server整修失敗，就….

筆記

• 主要就是談：the League client update，進遊戲之前的Client Application
• 原本使用Adobe AIR，使用它的RTMP協定，動畫呈現，而且還是跨「桌機」平台。遊戲推出的當下，可說是很好的解決方案，不過接下來就開始不合時代潮流，因此要做新架構
• 新架構要解決的：
  1. 用HTML5+JavaScript的解決方案，不管是在client端呈現，或是與Server溝通，還有工作流程與開發環境都比原本更有擴充性且易用。
  2. 不管是遊戲內遊戲外，玩家都可以保持連線：原本Adobe AIR的方案對PC資源使用率過大，也不支援手機。
  3. 工程師們想要有個更簡單一致的開發架構。
• 一開始想要改少一點，想說直接重用Adobe AIR的code來搞，但發覺現在已經有更多更好的方案。
• 後來選擇了 Chromium Embedded Framework (CEF) ，寫Desktop Client就像是寫網頁。對HTML 5有很好的支援，而且界面修改自訂可以更靈活。
• 決定重寫(!)，重寫很危險，但好處比壞處多就上。

Step A

• 所以Client界面主要就是Java Script
• 為了要讓Java Script與原本的Server溝通，原本Server是支援RTMP，所以他們為Java Script Client開發了一個C++原生Library，負責用RTMP與Server溝通，以及提供非同步的處理。
• 為什麼Server還是用RTMP？因為不想同時Client與Server。
• 選擇ember.js當Java Script Client框架，ember-orbit當作資料層
• 看起來架構還不賴？問題馬上出現了。
• Java Script Client變得非常複雜，裡面的元件各自處理非同步的部份，使用者的狀態也保留在Java Script Client這一層(!)，所以記憶體變得很大。
• 這個方案解決1.但是2.與3.都沒有處理好，而且Developer抱怨連連。

Step B

• 開始思考一般Web Application是怎麼做的，反正都用Java Script了，來向一般Web Application取經
• 發現少了中間層！
• 所以弄了個C++寫的micro service層，但是在本地端！
• micro service層就像是http server，按照REST的規則來提供資源存取，讓Java Script Client不要處理非同步(複雜度的主因)。
• micro service層與Java Script Client層用Web Socket溝通，micro service層與遠端Server還是用原來的RTMP溝通
• micro service層取名叫Foundation
• 弄成這個架構之後，精簡掉所有不必要的Java Script VMs，只留下Foundation，Java Script Client都只用GET
• Foundation大概佔用20MB記憶體，玩家不需要把Java Script Client砍掉才進LOL裡面！
• Foundation可以用system tray來呈現，不管玩家有沒有打開LOL都可以接觸到遊戲資訊。

Step C

• 換成新架構後，寫功能就是要寫micro service與遠端server，micro service與Java Script Client。
• 大家都改同樣的地方，互相影響。
• 需要架構上的解決方案來讓團隊協作更有效率。
• 作者自己研究了許久，決定採用Plug-in架構
• 每個Plug-in必須有自己的Semantic Versioning，還有它依賴哪個Plug-in與這個Plug-in的Semantic Versioning。
• 把架構呈現成Graph的形式，Plug-in的相依性一目了然
• 所以有front-end (FE) plugin，用Java Script，實作UI。有back-end (BE) plugin，用C++，實作資料處理與遠端Server溝通。
• 取名叫Front-end與Backend是代表這個架構模仿所謂的Client-Server架構
• 用Plug-in可以簡單開關使用者可用的功能，通常是不同區域的使用者。
• 由於之前用ember-orbit，Front-end還是可以直接操作很多資料，又增加複雜到，所以讓ember-orbit退休，資料都透過REST從back-end plugin拿，front-end plugin可以快取資料，但其他複雜資料的處理就不要在Front-end了。

Step D

• 已經有了更有生產力的架構，大家可以各自做自己的Plugin不會互相影響。
• 有些人不喜歡Ember.js，想直接用HTML 5的東西。
• 有些人在別的地方已經有了現成的Web Client，想說直接搬到這個Java Script Client，這樣就不用重作一次Client，反正都是Java Script。
• 本來很堅持來這邊開發就一定要用Ember.js，後來發現，就算每個Plug-in都用Ember.js，要保持每個Plug-in的Ember.js的版本相同，也很困難，公司太多Developer了。
• 最後改成每個Plugin都可以用自己的Java Script Framwork

結論

• 最後的架構，可以讓多個團隊獨立的開發the League client update，HTML5 Front-end與C++ back-end的配合夠靈活效能也夠好。Plug-in架構不只對開發有幫助，對實際產品呈現也有幫助。
• 大部分人都很滿意！
• 回頭來看，這就是一種”datacenter in a desktop.”的架構，Atom就是如此。
• 還有HTML視覺效果，功能可以獨立更新發布還沒講。

​

微众银行基于自主可控技术的分布式架构实践

參考來源：微众银行基于自主可控技术的分布式架构实践 http://www.infoq.com/cn/presentations/webank-distributed-architecture-practice-based-on-self-controlled-technology

心得

難得看到新銀行的案例分享，新銀行就沒有過去技術的包袱，每個邏輯節點可以作所有業務，但把user分塊，也就是沒有一個資料庫有全部的資料，不同節點之間需要對方的資料就要去查詢。並且同時有Scale up與Scale out的方案，把模組切分的更獨立來架構變得靈活，用Open Source技術與同一機器環境讓運營成本比起傳統銀行少了10+倍。非常值得參考！

筆記

• 普惠金融：普惠金融體系(Financial Inclusion System)普惠金融體系是指一整套全方位為社會全體人員，尤其是金融弱勢群體提供金融服務的思路、方案和保障措施等。
• 去IOE：(去掉IBM的小型机、Oracle数据库、EMC存储设备)
• 微眾銀行WeBank，全虛擬化銀行。開發時間很短，30億資本，半年籌建。
• 選擇自主可控全分布式架構
• 分散風險的進化，目前一般銀行的架構是集中式鬆耦合，同一個業務由一個節點或是多個節點服務，但業務之間還是緊耦合，所以只要某業務所屬節點有問題，還是會造成其他業務出問題。後來進化成一個節點包所有業務，但是只服務特定客群
• 提高冗餘的進化：一般銀行多主節點，沒辦法滿足CAP。最後捨棄高性能，一主兩從，

  取CP

• 進化後：一個節點是一個邏輯概念，可以做同一客戶群的所有業務，有多台機器，一主二從架構的保持資料一致性與備份。
• 把服務分成兩大類，對客戶，對內部後台管理，所以有兩種類型節點
• 一個客戶的業務在一個節點上處理，一個節點可以處理多個客戶，一客戶一開始就指定在哪個節點，客戶創立與查詢用GNS(客戶在哪裡)來做。
• 雙向擴展
  • 橫向擴展：客戶變多加節點
  • 縱向擴展：同樣的客戶業務變多，升級機器，或是增加節點的機器數量。
• 規則：客戶變多只能用橫向，一節點五百萬就是五百萬。
• 分佈式架構平台，參考圖，業務能力、基礎能力(無狀態服務，大數據框架)、基礎資源(資料中心，虛擬機器，網路)。

  這個架構其他業務也可以參考。

• 所有節點不共享網路、服務器、數據庫存儲。
• 選擇開源技術與低端服務器，才能做到。
• 組件都很簡單，一個組件只做簡單的一件事，後續管理才會簡單
• TDSQL：腾讯云金融级数据库CDB for TDSQL （Cloud DataBase for Tecent Distribute
  SQL）是一个适用于OLTP场景且与MySQL 5.5 、5.6兼容的分布式关系型数据库。
• OLTP：所謂線上交易處理(OLTP)，其英文全名為On-Line Transaction Processing，是傳統關聯式資料庫(Relational Database)之主要應用，係指基礎性的日常事務處理，故算是面對交易的處理系統。

  我理解是即時支援Transation

• 100+ x86伺服器，用簡單同一的機器，作邏輯分資源模塊。
• 有網關來限流，讓資料百分百不遺失
• 通常對於效能的取捨就是性能，需要性能就加機器。
• 用硬體作Message Queue管理。對於100bytes的message可以做到每秒3500萬筆，確保送達模式就每秒10萬筆

  嚇死人，用硬體作Message Queue第一次聽到

• 用硬體作Message Queue，就沒辦法加上更多邏輯的實作，反而讓各功能component變得簡單。
• 全部都用open source
• 一般銀行一個帳戶20~100元/年，微眾一個帳戶5~3元/年

  省很大！

• 去IOE，讓大象瘦身可以跳舞。性能無限擴展(!)

​

筆記：Akka Streams: Streaming Data Transformation à la Carte

http://www.infoq.com/presentations/akka-streams?utm_source=infoq

心得

這位Viktor Klang講話方式與外型都很像我前同事XD，現在Akka除了可以提供不用管Thread的執行模型之外，還有Akka Stream可以提供處理資料的模型。其實我對Akka沒很熟啦，不過因為後來都是在寫Backend的關係，所以對Backend處理架構有興趣。看起來Akka Stream除了提供原本基於Actor的好處之外，還提供了對資料流更高階更有效率的抽象化架構，像是Source, Flow, Sink這樣的概念，以前在做M$的DirectShow就有接觸了，不過那個只是單機視訊播放。這個是處理數千數萬的資料流，應用的等級差很大。最後帶到Reactive Stream的概念，那個Dynamic Push-Pull Model看來真的是蠻屌，但應該還在發展中。話說現在typesafe也要改名成lightblend了，看來他們公司搞的技術都頗有看頭，希望他們Live long and Prosper！

筆記

簡介Akka

• Akka: Simple message-oriented programming model for build reactive applications.
• 會用Scala demo因為可以顯示比較完整(!)
• 不需要考慮Share state, memory visibility, threads, locks, concurrent collections, thread notifications.
• 高CPU使用率, 低延遲, 高輸出, 有彈性
• Supervisor hierarchy可以讓application有彈性
  • 有個root actor當supervisor，管控其下的child actor，有問題就換掉，做得慢supervisor就找其他actor幫忙。

    這種是製造業思維，被敏捷洗腦的我聽了有點OOXX，不過Akka處理message就是製造業沒錯啦…

• Akka的計算單位稱為Actor
• Actor有address, mailbox, current behavior, local storage
• Actor週期性的送出message
• 每個Actor有一個Parent，由Parent處理該Actor失敗的情境
• 每個Actor有1..N個child Actor
• 沒做事的Actor不會佔用CPU時間
• 一個Actor一次只處理一個message，避免Concurrent issue
• 一個Actor佔用450 byte，所以一台機器可以有百萬個Actor(!)
• Akka Cluster可以有2500個node，所以如果都是10G RAM以上的機器，可以有到兆等級的Actor(!)

  Akka Stream

• 有誰敢說自己Multi Thread的實作100%正確呢？就算有Test，Multi Thread這件事本質上就是容易錯，我們有一定要用這個作業系統特性嗎？
• 如果有更簡單的方式，是否可以不用Thread
• Akka Stream特性：
  • immutable，Actor處理方式讓各個資料流不互相干擾
  • reuseable，有Immutable就很容易可以做到
  • composable，既然可以reuse，就可以很容易組合
  • coordinated，Actor的Supvisor架構
  • asynchronus，Actor是message driven，可以做到非同步
  • transformations，提供各種不同的Transformation方式來處理Flow
• Linear transformation
  • Source
  • Sink
• Non-linear transformation
  • Fan in
  • Fan out
• Non-linear transformation：可以建構Graph，拿來做Protocol
• 擴展
  • Akka TCP stream
  • Akka Http
  • Reactive Stream Inter op
  • …其他
• Materialization具體化
  • Akka Stream把what與how分離
  • Source/Flow/Sink的DSL可以建立藍圖
  • ActorFlowMaterializer把藍圖用Actor執行
• Demo: 定義Source, Flow, Sink形成資料流處理的管道
• Klang’s Conjecture: “If you cannot solve a problem without programming; you cannot solve a problem with programming.”

  本日學到的名言

• 比較Push與Pull的特性，主要就是Push沒辦法處理Drop，Pull會有多的Overhead
• 比較Push&Pull與Supply＆Demand
• 2-way在Publisher與Subscriber
• 如果我們的Data Flow可以同時有Push與Pull?
  • 當Subscriber比較快就用Push
  • 當Publisher比較快就用Pull
  • 自動切換Push與Pull->Dynamic push-pull
  • 當可以有批次的Demand，就可以有批次的動作，設計者決定要累積多少的Demand才發出信號進行動作。
• 帶出Reactive Stream，可以完成以上的model
• 推廣時間：
  • https://github.com/typesafehub/activator-akka-stream-scala
  • https://github.com/reactive-streams/reactive-streams-jvm

​

筆記：Easier, Better, Faster, Safer Deployment with Docker and Immutable Containers

http://www.infoq.com/presentations/immutable-servers-docker?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3

心得

這篇也算是Docker官方業配文？這位法國來的Jerome Petazzoni講英文我意外蠻好懂的。所謂Immutable這個概念最常就是拿人體的細胞來比。聽起來是很有說服力啦。基本上這樣子的Deploy方式就很像修車模組化整批換掉，而且軟體是虛擬的，完全不會有什麼零件製造品質問題或是什麼物理性問題。而這個架構可以強迫設計者把Storage與Service分開，讓Service成為真正的Stateless，而Data與Service分開的速度部份，我覺得也不用擔心，現在幾乎所有雲端Solution都有Storage Service了，怕延遲就是要用In Mem Cache。我最驚豔的是，有side kick container這種東東呀！裝個Container在正在運作的Container旁邊就可以偷看網路與其它東西…Docker真的是越來越成熟了！不過缺點就是，幾乎什麼都要寫code，想要完成這樣子的架構就是要寫一堆configuration！然後就有比較高的學習曲線，然後就要引進版本管理機制，然後就要管理這些東西的複雜度，然後就要找更厲害的Engineer才能把東西搞好搞大！這樣其實對我們來講是好事啦！在IT界總有新觀念可學習，新東西可以玩~

筆記

Never change what’t on a server

• 不要裝新的packages
• 不要upgrade原來的packages
• 不要移除或down grade原來的packages
• 就算有安全性問題！
• 不要編輯configuraiton files
• 不要更新application的code!

如何upgrade

• 起一個全新的Server然後測試過沒問題之後換掉舊的

  那新舊Server可以同時存在，寫DB怎辦？這可能又是一個只新增欄位與換Data Model才能解決的問題

• 避免server confiugration drift導致難以維護的結果。

  導入Immutable Server的佈署概念

• 一陣子就重新換Servers
• 維護Golden image，所有的Server都用這個image佈署

  缺點

  小修改很可怕

• 小修改就要把整個Server群的image換掉
  • create image要時間
  • 重新啟用同數量的server要時間
  • 把舊的Server的Request導到新的也要時間
• 解法：
  • 全部都自動化
  • 用中間image減少編譯時間

    很難Debug

• 沒裝tcpdump或iptables怎辦
• log怎麼導出去
• 解法：把需要用的工具裝進去image裡面
• 解法：把log導到外面。

  存資料

• Immutable沒辦法存資料
• 解法：不要存在Server上，存在其他Storage，Amazon RDS
• 解法：存在外部系統

  導入Immutable Container也就是Docker

• Create docker image可以有snapshot，所以小修改要create image更快。
• 換Image後啟動速度比一般VM快非常多！完全不能比！
• 可以重使用原本在Host作業系統上的資料，或是用Data Volume Container。
• Container之間可以分享：
  • 目錄，像是Log
  • 網路，可以用B Container來看到A Container的Traffic！這種叫做side kick container
• 執行Service的Container完全可以是Read only

​

筆記：Microservices and the Art of Taming the Dependency Hell Monster

InfoQ辦的2015 QCon，裡面的Session都很不錯呢！這次看的是：

Microservices and the Art of Taming the Dependency Hell Monster

http://www.infoq.com/presentations/microservices-dependencies?utm_source=infoq&utm_medium=email&utm_campaign=03112016Seg3

心得

Gilt是在歐洲美國都很有名的線上購物網站，尤其是折扣商品的銷售很猛，雖然我沒買過啦。看他們完全導入Micro Service的數量很驚人，而DB的選擇方式也是相當多元，基本上就是歷史因素以及各取所長。還有就是在Gilt裡，Play+Scala幾乎都是主流了！聽了這場，我覺得學Functional還是應該學Scala啦！裡面講到的Dependecy問題非常有感覺。只要軟體複雜度到一個程度，一定會出現這種問題，還好他們已經先把戰略佈置成Micro Service的形式了。各各擊破比起所有Application或Service大一統簡單。但Micro Service要能減緩Dependency Hell還是要靠REST Service，裡面提出的策略非常有用。就算是想用Remote API Call，這場Session也派的上用場。把Document當成一個產品，放到軟體生產流程裡面成為一個不可或缺的環節，這樣可以完全避免掉Document更新跟不上實作的問題！

筆記

• Gilt從Ruby+Memchache->PostgreSQL to Play+Scala->MicroService+Scala->Legacy Service->PostgreSQL
• Micro Service 156+個，Application Service 5~9個。
• User service, 百萬user，10000 request 1秒，用mongo db(CP)存，有consistency
  • 用Remote API呼叫，回傳Future！可以這樣用喔？
• Catalog Service, 取所有product，5000 request 1秒，用postgreSQL(CA)，百萬product
• Inventory Service，檢查庫存，與其他domain隔開，10000 request 1秒，用hbase(CP)，每天更新一次庫存，需要保證不會多賣。
• Cart Service：處理購物車，處理量較小，用dynamoDB，用了7年，可選consistency。
• 從2008~2015年，每個Service的發展速度都不同，所使用的library演進也不同，但是都透過Http提供服務
• 看起來戰略規劃得很好，但是隨著產品越做越複雜，直接面對User的Application Service也變得複雜，需要包含user service, catalog service, inventory service, cart service等等在一個頁面呈現，結果就是，要把幾乎所有的client library包含進來。
• 接下來就是
  • 開發application service變得很慢
  • 只要一點小變化就做一個新的client library->因為不想包含太多
  • 做custom API避免包含太多client library
  • 大量相同架構的程式碼，因為想避免client libary dependency
  • Code的品質變差，讓開發變慢
  • 最後就會真正在產品上看到錯誤：java.lang.NoSuchMethodError，哈哈
• 怎麼辦？從Open Source借鏡
• http://www.apidoc.me/ 自動產生document

API design must be First Class

• protocol buffer, api doc就是一種契約，尤其是可作完就丟的micro service，這樣的靈活度就是來自於訂立良好的契約。
• 這樣的方式就是”Schema First Design”，Server Client就看資料是什麼就怎麼處理。而不要關心其他實作細節。

  這看來有點不敏捷…不過Gilt的code base已經累積很多，不是說改就改，而以micro service的形式，還是可以把改動的影響範圍縮到最少，並且也有可能以敏捷的方式開發。

• 定義REST API就要遵守REST的語意

Backward and Forward Compatibility

• 向前相容，新增欄位只能是Optional或是有Default Value
• 向前相容， 不要Rename！如果真的有需要的話，導入新的Data Model並且提供Migration機制。
• 向後相容，小心使用Enum，像是他們用Scala定義Enum時會一定要有個Undefined，把處理未知enum的責任交給Micro Service開發者，而不是由不知道實作的Micro Service使用者負責。

Accurate Documentation

• 他們發現唯一可以讓Document精確的方式就是在Software Process裡使用Document。
• 用Sematic Versioning，X.Y.Z，當API有不向後相容時，X請進版！

Generated client libraries

• 有爭議，但他們覺得有用
• 為了避免寫重複的code，例如發http request，組json
• 有了Data Schema，API doc，是可以產出Client libary
• 最小dependency，頂多是包含處理http與處理json的library
• 為有用到的語言產一個，例如Ruby client library，Play client library等等
• 產出來的client library只要有通過自動測試，使用者就可以拿去用！
• 使用者可以從client libary選擇他要用的版本。

​

無「暇」的程式碼 - 嘴砲篇

話說最近正在讀《無瑕的程式碼》這本書，所以一直擺在手邊，三不五十就會瞄這本經典鉅作一下，不過最近眼花常會看錯書名...

當程式寫出來，功能完整，沒啥bug，自我感覺天下無敵的那一瞬間，就會看成「無敵」的程式碼

當不小心打開Open Source的專案原始碼時，一堆看不懂的程式碼在眼前，老鼠怎麼捲都捲不完，眼花撩亂的那一瞬間，就會看成「無窮」的程式碼

當看到某些函式訂了參數，傳進去卻沒用到，咒罵這分明是脫褲子放屁的那一瞬間，就會看成「無用」的程式碼

當看到某些大師的程式碼，想說來重構一下，以證明自己比大師更厲害，卻發覺完全沒地方下手，體會到大師果然厲害的那瞬間，就會看成「無缺」的程式碼

當看到某些程式碼模組交互呼叫，糾纏不清，你濃我濃時，想修個bug卻不知從何下手時，就會看成「無縫」的程式碼

當看到某些程式碼根本只是隨便寫寫，完全不考慮後續維護，魔術數字四散各地，變數名稱與流程邏輯完全對不上，改起來簡直想要跳樓，就會看成「無恥」的程式碼

當bug截止時間將到，知道錯誤在這段，卻完全沒有idea要怎麼改，就會看成「無望」的程式碼

當一直寫一樣的東西，絲毫沒有變化，感覺悶的要死時，就會看成「無趣」的程式碼

當看到某些程式碼內含一堆架構，實際上架構根本就沒做到什麼重要的事，完全是一個熱臉貼冷屁股的那一瞬間，就會看成「無感」的程式碼。

當程式碼架構設計的好，還貼心的附上完整的測試案例，要新增功能，要修bug都是一塊蛋糕，照著架構改好跑跑測試就搞定，感覺人生輕鬆愉快的那一瞬間，就會看成「無痛」的程式碼。

當看到好不容易重構後變得比較簡單的程式碼，一次又一次被加個阿紗布魯，天邊飛來的一朵邏輯的那一瞬間，就會看成「無力」的程式碼

當花了十年參透大師寫的那一行程式碼背後所隱含的大宇宙的奧秘的那一瞬間，就會看成「無極」的程式碼。

軟體進步到現在，開發測試部署全部都可以用程式碼控制，四輪傳動系統、行車主動安全系統，物聯網，OOXX什麼東西都會有程式碼存在，當我想到2XXX年還是有一堆人要寫程式碼的那一瞬間，就會看成「無限」的程式碼。

以上純屬嘴砲，我只是想表達這本書的中文標題，真的意義深遠...