Diego PH on Unsplash
美國勞工統計局預測，到2020年，軟件開發工作的職位將比僅在美國就職的申請人多140萬。
當您瞭解到2018年全球有2300萬軟件開發人員時，該統計數字甚至更令人驚訝
這些數字意味著兩件事：
· 良好的軟件開發實踐是必須的
· 關於"良好的開發實踐"是什麼樣的，有很多意見，而要瀏覽這些意見可能是具有挑戰性的
但是，在技術領域中也有一些人經常以訪談，博客和書籍的形式（例如，Martin Fowler或Kent Beck）分享他們對軟件開發的意見，這些意見在軟件世界中常常被認為是有價值的。 。
其中之一是Tripwire的創始人兼長期首席技術官Gene Kim。 Kim的著作廣為人知，他的職業生涯對軟件開發實踐的重要性產生了深遠的影響。 許多人熟悉他所寫或合著的書：《鳳凰計劃》，《 DevOps手冊》，《加速》，並高興地看到他最新發行的《獨角獸計劃》。
Phoenix項目的重點是軟件開發的DevOps /基礎架構方面，而Unicorn項目則跟隨技術主管和架構師Maxine，她試圖在其開發團隊中應對不斷變化的需求和外部依賴項帶來的挑戰。 在Phoenix中，"三種方式"和"四種工作類型"描述了重要的概念，許多人今天使用這些概念來幫助定義DevOps。
在本文中，我想分享一些吉恩·金（Gene Kim）最好的作品的主要收穫。
鳳凰計劃的要點：
鳳凰項目以小說的形式寫成，小說由人物和故事情節組成，遵循IT經理Bill的想法，試圖應對更快發展的期望以及許多團隊在溝通和依賴性方面的挑戰。 它說明了" DevOps"運動如何通過遵循運動的基本原理（稱為"三種方式"）來改造團隊。
三種方式：
1.流動原理
將IT視為價值流。 幾乎就像工廠生產線一樣，其中每個組件都為生產線增加了價值，並期望僅需完成一次
- · 工作僅朝一個方向流動-下游
- · 缺陷永遠不會傳遞到下游
- · 我們應該一直在努力改善流程
2.反饋原則
用作衡量流增加的價值的方法
- · 上游反饋迴路應該到位
- · 反饋循環應儘可能短，這意味著對添加/更改的快速反饋
3.持續學習與實驗原理
描述軟件組織的文化和環境
- · 通過練習尋求掌握東西
- · 從成功和失敗中學習
- · 促進實驗，而不要擔心實驗和失敗的可能性。
The Three Ways as an image
四種工作類型：
- · 業務項目-這些是您的涉眾要求您為客戶做的項目
- · 內部項目-例如，將從本地託管的數據中心遷移到雲提供商
- · 運營變更-可能類似於部署新功能
- · 計劃外的工作-計劃中的故障，錯誤或突然更改，需要立即採取行動。
加速的要點：
作為《 DevOps狀況報告》中一項研究的結果，該報告是由世界各地各種規模的公司進行的一項調查，Accelerate發佈了四個關鍵指標，研究人員確定這四個指標是低，中，高績效之間的唯一區別 團隊：
四個關鍵指標：
- · 變更的前置時間-客戶或利益相關者提出請求，與該請求作為代碼進入生產之間的時間間隔
- · 部署頻率-將變更部署到生產的頻率
- · 平均恢復時間-從發現的故障中恢復需要多長時間
- · 變更失敗百分比-您的變更百分比導致系統中的錯誤，失敗或錯誤
低，中和高績效團隊之間的度量標準劃分如下，最左邊的列是高績效團隊：
The Four Key Metrics for High, Medium, and Low performing teams
Phoenix Project和Accelerate幫助建立了一個基礎，許多團隊仍在努力適應這一基礎，軟件開發團隊可以在此基礎上衡量其生產率和效率，同時直接瞭解他們在這些領域如何改進。
獨角獸計劃的收穫：
隨著"獨角獸項目"的發佈，Gene Kim擴展了他對軟件開發的想法，以確定他認為是當今影響工程和業務的最重要挑戰。 他將這些挑戰歸結為"五個理想"。 與《鳳凰計劃》相似，這本書是一本小說，具有不同的故事和場景，以說明這些學習情況並確認DevOps運動作為快速安全地交付軟件的重要性。
五個理想：
1.局部性和簡單性
這與開發團隊可以在一個或多個位置進行本地代碼更改，而不會影響或需要各種其他團隊和其他位置的程度有關。 我們都知道，無需別人幫助我們，或為我們提供某些東西就可以自己做事更容易。 需要多個團隊的協作來部署或開發新功能，只會因溝通不暢而導致延誤和潛在挑戰。
為了使它起作用，我們需要簡單性，這意味著產品或軟件本身的各個部分與其他部分之間是鬆散耦合的，並且在其實現和基礎結構中應儘可能簡化。
2.專注，流動與快樂
開發人員的日常工作和工作方式直接影響開發人員的效率。 當開發人員可以專注於編寫代碼而沒有延遲或依賴時，它會產生一種流動感，從而帶來快樂。 從書中：
"我們的工作是否充滿無聊，並等待其他人代表我們完成工作？ 我們是否盲目地對整個小部分進行研究，只在部署過程中看到一切都炸燬，導致消防，懲罰和倦怠時才看到我們的工作成果？ 還是我們以小批量（理想情況下為單件生產）工作，從而獲得對我們工作的快速而持續的反饋？ "
3.改善日常工作
這個理想與技術債務和架構直接相關。 世界上最大的公司（通常稱為FANG：Facebook，Amazon，Netflix，Google等）之所以如此成功和穩定，是因為他們做出了有意識的決定來擺脫現有的技術債務。 微軟以一種文化著稱，這種文化說，如果開發人員在功能開發或提高開發人員生產率之間做出選擇，那麼選擇應該始終是開發人員生產率。 這本書的一句名言：
"亞馬遜可能會在六年內花費超過10億美元重新配置其所有內部服務，以使彼此分離。"
4.心理安全
正如《 DevOps狀態報告》和Google Aristotle Project所顯示的那樣，團隊成員可以放心地從錯誤中吸取教訓，並承擔風險，這對於團隊的效率至關重要。 這是因為團隊需要能夠談論他們所遇到的問題並感到安全，因為需要預防才能解決問題，這需要誠實和無畏。
5.以客戶為中心
顧名思義，這種理想使我們想起團隊正在開發，或從事的工作是否對客戶真正重要（他們是否願意為此付出代價？）還是僅僅是為我們自身職能帶來價值的事情？ Silo？ 如果我們的日常行為無法為客戶提供價值，那麼也許我們應該在其他方面開展工作。
這本書中我最喜歡的一些報價：
Hoare原則："有兩種編寫代碼的方法：編寫代碼如此簡單，其中顯然沒有錯誤；編寫代碼如此複雜，以至於其中沒有明顯的錯誤。"
"懲罰性失敗和"攻擊信使"只會使人們掩蓋錯誤，最終，所有對創新的渴望都將被徹底撲滅。"
"創建軟件應該是一種協作和對話式的努力—個人需要相互交流才能為客戶創造新的知識和價值。"
"技術債務是您下次要進行更改時的感受。"
這三本書幫助設計了一個模板或示例，開發團隊在進行項目並試圖提高效率時可以遵循這些模板或示例，許多最大，最成功的軟件公司已經在使用這些思想。 我期待這個傢伙寫的下一本書。
你怎麼看？ 他錯過了什麼嗎？
(本文翻譯自Tylor Borgeson的文章《How to develop Software like a CTO》，參考：https://medium.com/swlh/software-development-practices-as-recommended-by-gene-kim-c6f6e952309f)
閱讀更多 聞數起舞 的文章
