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

1. 軟件不是魔術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 設(shè)計不是外觀，而是工作原理

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

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

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

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

5. 安全是每個人的責(zé)任

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

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

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

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

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

遵守NIST CSF(國家標(biāo)準(zhǔn)與技術(shù)網(wǎng)絡(luò)安全框架學(xué)會)、PCI DSS(支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn))和SOC 2(服務(wù)組織控制報告)等安全標(biāo)準(zhǔn)可以量化風(fēng)險，如果做得合適，還可以降低風(fēng)險。這些標(biāo)準(zhǔn)并不能保證絕對安全，絕對安全是不存在的。更重要的是，它們?yōu)槿绾呜?fù)責(zé)任地應(yīng)對和報告不可避免的安全漏洞提供了指導(dǎo)。誠實、直率、公開是良好的建議。

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

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

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

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

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

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

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

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

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

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

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

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

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

8. 技術(shù)債很討厭，但不可避免

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但是，一個成功的產(chǎn)品是業(yè)務(wù)需求和運維需求的權(quán)衡結(jié)果。

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

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

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

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

結(jié)論

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

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

作者：Thomas A. Limoncelli