關于軟件開發(fā)，本文認為這是所有管理者都需要知道的10件最重要的事情：

1. 軟件不是魔術

軟件不是魔術。雖然它看起來像魔術，或者是魔法，但它不是魔法。每一個元素都是由人設計的，都有其數(shù)學基礎，或者是可以用人類語言解釋的過程。

與魔術不同，軟件不是憑空變出來的。它需要設計、構建和維護。就像房子有多種系統(tǒng)一起工作(地基、結構、管道、房間、家具等等)那樣，軟件系統(tǒng)也需要許多層和子系統(tǒng)來創(chuàng)建整個系統(tǒng)。它可以設計得很好，也可以設計得很差，而且快速的設計很少能持久。

如果人們不能用語言來描述它會做什么（包括想要的結果和如何實現(xiàn)），那么計算機也無法做到。“how”被稱為算法，這并不神奇。

機器學習和其他人工智能技術也并不神奇。機器學習是基于數(shù)據(jù)的預測，而不是顯式的規(guī)則或指令。它一般是用線性代數(shù)來做的。如果有100萬張已知的香蕉照片和100萬張沒有香蕉的照片，一個訓練有素的機器學習系統(tǒng)看一張新照片，會根據(jù)它從之前的照片中學到的知識告訴你它看起來像第一組還是第二組，這不是魔術。使用機器學習根據(jù)過去的招聘決定對簡歷進行排序，即使沒有任何故意的偏見，也可能會放大經驗主義的招聘歷史。

2. 軟件永遠不會“完成”

軟件永遠不會“完成”，軟件是一個迭代的過程，在其生命周期中包含許多修訂和更新。我們的工作是創(chuàng)造一個能認識到這一點的環(huán)境。

同樣，我們從來沒有期望市場營銷和客戶獲取是“完成的”，它們也是迭代過程。在每個迭代中，隨著我們不斷地為業(yè)務交付價值，我們也不斷地學習和成長。即使已經做了一些成功的發(fā)布，我們從來沒有打算“停止”做這些事情。

如果軟件可以在一個版本中完成就好了，但這不是現(xiàn)實。需求文檔充滿了模糊性，軟件的第一個版本充滿了“哦，那是我寫的，但不是我的意思”的場景。最好的軟件能激發(fā)新的想法和功能需求，看到新的銷售管理系統(tǒng)更加高效，就會激發(fā)出更高的效率。世界在變化，競爭對手提供了新的功能，人們就有了新的想法。另外，總是有一些bug需要修復：可能是在代碼中，也可能是在構建代碼的底層軟件框架和系統(tǒng)中。某些軟件可能是完美的，但可以確信的是，隨著時間的推移，人們會發(fā)現(xiàn)它所構建的平臺存在各種漏洞。

我們的工作就是讓一個組織能夠認識到這一點。

認識到這一點的方法是建立一個有信心定期發(fā)布新版本的組織。當完全自動化測試和其他工程規(guī)范就位時，我們就建立了信心。這種信心創(chuàng)造了一種能力，可以避免過長的發(fā)布周期，而是每季度、每月甚至每周發(fā)布高質量的軟件。特定的頻率并不重要，但是信心很重要，自信能夠帶來更快的創(chuàng)新。

3.軟件開發(fā)是團隊作戰(zhàn)，沒有人能做所有事情

軟件開發(fā)是團隊作戰(zhàn)，開發(fā)人員既不是產品經理，也不是UX(用戶體驗)設計師，也不是質量工程師、分析師、安全專家、技術作家或運營工程師。組織需要所有角色。

沒有哪個管理者會建議每個銷售（sale）人員都做營銷（marketing）及PR，否則就解雇銷售團隊（因為營銷人員了解產品，也能做銷售）。營銷和銷售是相關的，但又是不同的。因此，兩者之間存在著分工。

同樣，開發(fā)團隊需要獨立的人員來收集需求、質量保證和測試、代碼編寫等等。

一個開發(fā)人員可以“做所有事情”的神話，稱為“全棧開發(fā)人員”或“10x工程師”，這一般只存在于小公司。是的，一個非常小的公司可能一個人同時做營銷和銷售，但你可能不會加入這樣的小公司。

不要用自己的興趣去挑戰(zhàn)別人吃飯的專業(yè)。一個小孩“擅長Facebook”并不意味著他或她會成為下一個扎克伯格；一個小孩對工程學很感興趣并不意味著他或她可以能夠使用微積分；一個小孩能夠自己做了一個網站并不意味著這個網站每小時可以處理數(shù)十億的金融交易。

4. 設計不是外觀，而是工作原理

史蒂夫·喬布斯有句名言：”設計不只是外表和感覺。設計就是工作原理。“ UX設計師不會坐下來決定菜單的顏色，或者決定按鈕是圓形還是方形，他們決定工作流和交互是什么。

用戶會看到一個有三個選項的屏幕，還是一個屏幕只顯示一個選項？這個設計決定需要心理學、對用戶的同理心，以及測試、測試、再測試。

UX設計的最大挑戰(zhàn)之一是，一旦你熟悉了系統(tǒng)，就失去了預測新用戶的能力。設計該系統(tǒng)的人在預測新用戶的需求時將自動被取消資格。UX可能很漂亮、優(yōu)雅，可以與一件藝術品相媲美，但是請UX設計師將背景更改為帆船的圖片是沒有幫助的。

我們的工作是信任測試數(shù)據(jù)而不是主觀臆測，創(chuàng)建一個環(huán)境，在產品發(fā)布之前計劃進行多次修訂，并期望在產品發(fā)布之后進行進一步的改進。不要將UX設計人員與圖形設計人員混淆。讓UX計師設計公司節(jié)日賀卡和讓技術作家寫公司通訊是一樣的失禮行為，這些是不同的技能。

5. 安全是每個人的責任

不管知不知道，無論愿不愿意，我們都是從事安全行業(yè)的。所有軟件都有安全需求和潛在的安全漏洞。開發(fā)軟件所涉及的系統(tǒng)也有安全需求和漏洞。雖然防火墻和入侵檢測等安全的基礎設施組件是必要的，但它們還不夠：還必須使用內置的安全控制來設計、實現(xiàn)和維護軟件平臺。安全既是好的技術，也是好的流程。

如果認為我們不是被攻擊的目標，那就錯了。所有的計算機系統(tǒng)都是被攻擊的目標，因為攻擊不僅是為了其中的信息，而僅僅是它是一臺計算機這樣的一個事實。例如，一個沒有價值信息的系統(tǒng)是網絡攻擊目標，因為它可以被用來轉發(fā)對其他計算機的攻擊，或挖掘比特幣，或存儲他人的盜版視頻。

安全不是打開/關閉這樣按鈕，有許多灰色地帶。安全性最好從一開始考慮。事后的亡羊補牢是昂貴的，而且往往是無效的。我們不會先造一艘船，然后再“添加”一種讓它漂浮的功能。同樣，也無法先構建一個系統(tǒng)，然后按下“具有安全性”按鈕就安全了。

安全是關于風險和對風險的容忍度。對兩個節(jié)點之間的通信進行加密并不能保證它的安全性，但它提高了安全性，只有超級算力才有可能破解密碼。在一個領域降低風險對其他領域沒有幫助。保護網絡并不能防止物理安全問題。一個人撐開一扇門，其他人就能偷走你的備份磁帶。

正如吉恩·斯帕福德(Gene Spafford)的一句名言：”唯一真正安全的系統(tǒng)，是一個關了電、澆鑄在混凝土里、由全副武裝的警衛(wèi)把守在絕緣房間里的系統(tǒng)——即便如此，我還是心存疑慮。“

遵守NIST CSF(國家標準與技術網絡安全框架學會)、PCI DSS(支付卡行業(yè)數(shù)據(jù)安全標準)和SOC 2(服務組織控制報告)等安全標準可以量化風險，如果做得合適，還可以降低風險。這些標準并不能保證絕對安全，絕對安全是不存在的。更重要的是，它們?yōu)槿绾呜撠熑蔚貞獙蛨蟾娌豢杀苊獾陌踩┒刺峁┝酥笇А?/SPAN>誠實、直率、公開是良好的建議。

軟件，如果不管它，就像面包一樣變得陳舊。我們的工作是平衡安全妄想與現(xiàn)實，并適當預算時間和資源。

6. feature大小并不能預測開發(fā)時間

feature大小(用戶感知到的)與創(chuàng)建feature所需的時間完全無關。小feature可能需要幾天或幾年的時間，大feature(用戶感知到的)也可能需要幾天或幾年的時間。

我們的工作是創(chuàng)建并支持一個軟件開發(fā)過程，該過程接受這個事實，并且不是拍腦袋評估工程量。工作量評估本身可能需要令人驚訝的很長時間。

鼓勵通過溝通來解決工作量評估的問題。工程師可能會給出一個令人驚訝的很長時間的工作估算，但是也會提出對需求進行更改，從而大大縮短時間。記住工作量評估要包括測試、培訓、部署和意外的假期（例如病假）。

在沒有與工程部門協(xié)商工作量的情況下，永遠不要承諾某個feature。這并不是我們在公司的權力標志，這需要的是一個專業(yè)流程，在這個流程中，開發(fā)人員的請求得到認真對待，評估工作量，并按時交付(或出于誠實的原因延期)。

7. 偉大來自于成千上萬的小進步

偉大來自于在很長一段時間內所做的成千上萬，也許是數(shù)百萬的小進步（變更）。如果變更的效果都被測量是負面的，那么變更將被回滾。

谷歌也不是一天建成的。谷歌的搜索引擎是數(shù)百萬個人改進的結果。搜索質量小組每周開會一次，工程師們走上講臺，提出他們的修改建議。他們展示了在模擬的環(huán)境中會有多大的改進，委員會進行辯論并投票表決。幾周后，將對測量結果進行評審，并決定保留或回滾更改。

谷歌搜索是迭代開發(fā)戰(zhàn)勝“數(shù)據(jù)大爆炸”思維的勝利。誰都不可能在一開始做出一個好的搜索引擎。只有在好萊塢電影中，一個聰明的極客才會想出一個驚人的新點子，并且第一次就能完美地實現(xiàn)它。在現(xiàn)實世界中，一夜成名需要數(shù)年的時間。

無論試圖實現(xiàn)的目標是一個為客戶提供更好服務的系統(tǒng)，還是一個更高效、錯誤更少的系統(tǒng)，還是一個運行更順暢的系統(tǒng)，都是如此。

我們的工作是要求系統(tǒng)的設計能夠容易擁抱新的變化，并定義相關的KPI(關鍵性能指標)，這些KPI可以在更改之前和之后方便地進行度量。最重要的是，必須有一個流程來檢查結果，并決定保留或回滾變更。回滾不應被視為失敗或受到懲罰。從每次回滾中學到的與在每次保留的更改中學到的一樣有價值。

托馬斯·愛迪生聲稱在發(fā)明燈泡的過程中測試了1000根燈絲。當一位記者問他：”失敗1000次是什么感受？“他回答說：”我沒有失敗1000次。燈泡是一項有1000個步驟的發(fā)明。”

8. 技術債很討厭，但不可避免

技術債務是將來需要做的工作，因為我們現(xiàn)在選擇了一個更簡單的解決方案，而不是使用一個需要更長時間的更好解決方案。任何合理規(guī)模的軟件項目都有技術債務。技術債務讓所有的進步都變得更慢，越忽視它，它就越像滾雪球一樣越滾越大。

有金融背景的管理者聽到“債務”時，會認為這是一種未來會有回報的投資。技術債務恰恰相反，它是有毒和痛苦的，并且是一個定時炸彈。

1972年，F(xiàn)ram為它的濾油器做了一個電視廣告，在廣告中，一位汽車機械師解釋說，一位顧客為了節(jié)省4美元而不更換濾油器，后來，這位顧客不得不花200美元更換一個昂貴的主軸承。汽車機械師總結說：“你可以現(xiàn)在付給我錢，也可以以后付。”

有一個軟件項目，其中有一個子系統(tǒng)與供應商通信。最初系統(tǒng)只與一個供應商通信，所以非常簡單。然后又接了一個，然后另一個。有些功能必須實現(xiàn)三次，每個供應商一次，這是不可持續(xù)的。當要求支持第四個供應商時，開發(fā)人員表示反對。是的，他們可以在大約一個月的時間里把它移植上去，但是軟件架構開始吱吱作響，就像颶風中的老房子一樣。這些權宜之計積累了大量的技術債務。

開發(fā)人員的建議是花兩個月的時間重構供應商架構，使其成為一個插件系統(tǒng)。然后，新的供應商可以在一周內而不是一個月內支持接入。

管理者們并不高興。為什么下一個供應商需要兩個多月的時間來支持，而之前的供應商是在一個月內支持的呢?花兩個月的時間來償還技術債務將使未來的支持更快，代碼更穩(wěn)定，并使添加新feature更容易。很難衡量確切的好處。

“你可以現(xiàn)在付給我，也可以以后再付給我"。

我們的工作是分期償還技術債務。失控的技術債務降低了添加其他feature的能力，并導致軟件系統(tǒng)不穩(wěn)定。償還技術債務應該與業(yè)務目標掛鉤，類似于非功能需求。

9. 軟件不會自己運行（軟件需要運維）

雖然供應商和開發(fā)人員可能會試圖告訴你不同的情況，但是軟件并不會自己運行。任何基于軟件的系統(tǒng)（特別是網站和web應用程序）都需要運維人員和運維流程。否則，軟件就像一本合上的書，必須有人打開它，管理它，以及照顧它的需求。

運維比軟件開發(fā)本身更重要。代碼只寫一次，但運行可能會是數(shù)百萬次。因此，粗略地衡量一下，運維的重要性是否要高出幾百萬倍呢？

我們的工作就是期望運維成為任何軟件系統(tǒng)的一部分。它必須像其他任何項目一樣被計劃、預算、管理和有效地運行。

運維功能(通常稱為非功能需求)對用戶是不可見的，除非作為二級需求。數(shù)據(jù)備份是非功能需求中一個很好的例子。沒有用戶請求數(shù)據(jù)備份，但是，用戶確實要求恢復已刪除的數(shù)據(jù)。遺憾的是，沒有備份就沒有恢復。恢復是功能需求，備份是一種運維（非功能）需求。

讓軟件服務易于維護或高效運行的功能需求從來不會被用戶提出來。然而，他們確實享受著一個低成本、高可靠的系統(tǒng)所帶來的好處。客戶會離開那些不靠譜的網站，再也不會回來。

持續(xù)改進的需求不僅包括新功能需求，還應該包括新的非功能性需求。因此，我們的工作不僅是為客戶提出的功能需求分配資源，還要為運維需求分配資源。在兩種相互競爭的需求之間取得平衡是困難的。

但是，一個成功的產品是業(yè)務需求和運維需求的權衡結果。

10. 復雜的系統(tǒng)需要DevOps才能良好運行

復雜的系統(tǒng)最好通過DevOps進行改進。DevOps有很多定義，但是DevOps通?？醋魇峭ㄟ^快速迭代加速交付價值(feature、bug修復、流程改進等等)。要做到這一點，每個相關人員都必須參與。也就是說，他們必須跨職能團隊進行協(xié)作。DevOps這個名字來自于移除開發(fā)人員和運維(IT)之間的隔閡，這對于實現(xiàn)快速的發(fā)布是絕對必要的。然而，優(yōu)秀的DevOps環(huán)境將其擴展到跨所有職能團隊的端到端工作。

DevOps被誤解為開發(fā)人員來做運維。這種“構建它，運行它”的策略是跨職能團隊工作（消除隔閡）的一種方法，但它不是唯一的方法。

一個復雜的系統(tǒng)需要三件事：良好的流程、所有相關人員的良好溝通以及嘗試新事物的能力。

結論

軟件正在吞噬世界。本文總結了軟件以及軟件工程的10個箴言，希望管理者及相關從業(yè)者理解其重要性并從中受益。

原文：https://queue.acm.org/detail.cfm?id=3325792

作者：Thomas A. Limoncelli