我，1 倍開發(fā)者，有 20 條軟件工程的經(jīng)驗法則

作者 | Mickey Muldoon

譯者 | 孫薇

出品 | CSDN（ID:CSDNnews）

我并非一個10倍的開發(fā)者（10倍開發(fā)者指的是在其領(lǐng)域，所產(chǎn)生的成果是其他同事的十倍），從撥號時代以來，我從未建過網(wǎng)站，大學(xué)畢業(yè)沒幾年我就選擇了編程，因為對于政府和政治這些東西我并不擅長，導(dǎo)致事業(yè)一度陷入僵局。

因此，大約5年中我一直在朝九晚五地寫代碼，那段時間我還養(yǎng)著3個孩子，剛開始編程時2個才出生，1個2歲。所以，我不是那種通宵達旦、周末無休的程序員，我還得照顧家人。

大約一年前，我開始為自己的首個開源項目投入貢獻，那是我的第一個副業(yè)項目，一個會議網(wǎng)站。

我從未完整地讀過一本軟件工程相關(guān)的書籍。

總而言之，我只是一個1倍開發(fā)者，所做的事情也只夠讓我體面地混過去而已。

作為一個1倍開發(fā)者，我大量使用了常規(guī)知識，對于軟件工程我沒太多有趣的新東西可說。

總的來說，我還沒抽出時間大量從事工作以外的內(nèi)容，或者在副業(yè)上再多花些時間，或者真正廣泛地讀些東西，或者大幅超越自己。我在主業(yè)和副業(yè)上都難以抽出更多時間。

但我感覺到了自己的雄心，想要成為一個1.1倍的開發(fā)者，也在嘗試找到辦法來實現(xiàn)。

這陣子我的空閑時間多了一些，由于新冠疫情和隔離，導(dǎo)致我雖在休假卻無處可去，孩子們也因為疫情而只能休著“春假”在家學(xué)習(xí)，于是就有了本文。

因此我打算以如下方式將我的軟件工程學(xué)知識作以闡述：

1. 寫下我關(guān)于某些軟件工程學(xué)話題的愚見；

2. 將我的想法分享給更聰明的人，請求大家猛烈地批評指正；

3. 基于第二點更新；

4. 嘗試找出方法，以查找軟件工程相關(guān)的信息，或者基于新項目的反饋，并根據(jù)優(yōu)先級將有用的信息排序，并與第一點相結(jié)合。

事不宜遲，以下就是我關(guān)于1倍開發(fā)者的經(jīng)驗法則。

規(guī)則本元

規(guī)則1：規(guī)則是個好東西

根據(jù)我的觀察，人類天生就在尋求非理性、不一致性和權(quán)威主義的模式，也就是說，一般而言大多數(shù)人會不自覺傾向于將目標(biāo)設(shè)定為令領(lǐng)導(dǎo)者滿意的方式，復(fù)制周邊人的做法，并遵循某些已有的模式。在一個復(fù)雜的世界里，保持理性和一致性非常困難。因此，直接完成“領(lǐng)導(dǎo)指派的任務(wù)”或者“同事都在做的事情”就成了簡便的選擇。

在許多情況下，這條策略能很好地服務(wù)于人，而且確實有助于建立“團隊一致性”。但是，如果你的目標(biāo)真的很外延——比“團隊一致性”要求更高，涉及到完成團隊外部的目標(biāo)時，嘗試保持理性和一致性就非常有價值了。

我認(rèn)為，經(jīng)驗法則（或者你想換個說法，改叫原則）有助于提供一些保護、一些框架、一些支架，讓人們得以擺脫默認(rèn)思維模式。它們有助于增強某種程度的邏輯一致性；在存在許多相互競爭的優(yōu)先事項和價值觀時，有助于將重點集中在會話上；當(dāng)你在無休止的選項中嘗試找到?jīng)Q策方案時，有助于提供一種更加明確和周全的便捷方案。

我在亞馬遜工作，這家公司以存在一套普適原則而聞名，這些原則在招聘時，在艱難決策時，在評估權(quán)衡時都會體現(xiàn)。而且我認(rèn)為，這些原則的存在對亞馬遜是好事，并非由于它們包含任何天才性的特殊之處，而僅僅是因為擁有這些原則總比退回到盲從領(lǐng)導(dǎo)者更好。

思考很困難，決策也很難，有周全的規(guī)則來指導(dǎo)決策有助于我們做得更好。

以上這些的意思是：下面列出的經(jīng)驗法則與亞馬遜的并不完全相同，大多只是在我思考這些主題時，跳到腦海里的經(jīng)驗法則而已。

生產(chǎn)力及學(xué)習(xí)

規(guī)則2：我學(xué)到的大多東西在其情境之外都沒什么用處

有時候我會聽人說起，IQ測試唯一衡量的只是“你在參加IQ測試時的表現(xiàn)”。我認(rèn)同這個說法，并同意大多數(shù)知識都是高度情境相關(guān)的。從大學(xué)開始，我從事了大約7份不同的“真正工作”，每份都有不同的職務(wù)頭銜。在亞馬遜，我做過兩個完全不同的產(chǎn)品和行業(yè)。

我發(fā)現(xiàn)，我在一份工作中學(xué)到的大多知識（差不多90%）對下一份來說都是沒用的，即便是在同一個職業(yè)領(lǐng)域中。倒并非完全無用——另外的10%可能是非常重要的10%，比如如何更好地處理電子郵件，或者如何應(yīng)對辦公室政治。但當(dāng)我開始下一份工作時，我所學(xué)到的大多知識仍然全都是“一次性的”，與特定公司的運作方式相關(guān)的特定知識。

亞馬遜可能是個極端案例，因為這里的開發(fā)者花了大量時間來掌握公司的內(nèi)部工具和商業(yè)概念，這些在別的公司完全見不到。或許我在某種程度上也被這些感染了，我知道其他開發(fā)者有著不同的經(jīng)驗，他們所掌握的特定技術(shù)和技能實際上可以從一份工作遷移到下一份。

在學(xué)校時（我的確花了幾年時間工作），事實上大多知識都是不可轉(zhuǎn)移的。在某個領(lǐng)域?qū)W到的東西，對其他領(lǐng)域并無幫助。

因此，我任性地傾向于這樣的想法：如果我今天90%的工作對于下一份工作沒什么用，就應(yīng)該減掉那90%（例如：專注于可以通用的想法、系統(tǒng)、抽象概念和技術(shù)），只是別太在意那90%（就像我之前那樣），或者找到一份我愿意犧牲掉那90%時間的工作，因為我覺得選擇這份工作的原因很重要，或者給的工資很豐厚。

這條規(guī)則可能更局限于我個人，因為我已經(jīng)換了一堆職業(yè)。對其他人來說，他們可以將技能從一份工作帶到下一份。

規(guī)則3：將“學(xué)習(xí)時間”集中在復(fù)合上

復(fù)合是個很重要的概念，在復(fù)利中、摩爾定律中隨處可見。它是關(guān)于良性循環(huán)的概念。因此在我有限的空閑時間里，我認(rèn)為需專注于可能引發(fā)良性循環(huán)的東西。

良好的起點之一就是掌握快速打字的技能。在過去兩個月中，我在keybr.com網(wǎng)站上花了些時間有條理地學(xué)習(xí)如何打字更快，這讓我能夠在相同時間里寫更多內(nèi)容，交流更多東西，完成更多工作，因為我在計算機上做什么都更快了。

建立持久的關(guān)系也是一項復(fù)合活動，因為你可以接觸更多有助于你快速完成工作的人員。

消化媒體（書籍、博客等）并非天然的復(fù)合過程。唯有當(dāng)你有某些方法想要反饋、消化，或?qū)F(xiàn)有的知識與想法相融合時（比如本文中一些有價值的內(nèi)容），作為讀者，除非立即積極“處理”這些內(nèi)容，否則很可能無法從中受益。

編程語言

這部分很有可能會充分暴露我的無知。

規(guī)則4：何時選用Java或C

Java是大型企業(yè)應(yīng)用的理想之選，很難想象諸如亞馬遜這樣的企業(yè)使用其他語言。這是因為Java有庫及社區(qū)的深層支持，且靜態(tài)類型使得處理大公司內(nèi)部天文數(shù)字級別的數(shù)據(jù)模型變得更加容易。

我將C#視為微軟公司所推出的Java替代版，因此，如果我需要利用Java的某些優(yōu)勢，但又使用到了微軟的生態(tài)系統(tǒng)，就會使用C#。

規(guī)則5：何時選用Python或Ruby

Python和Ruby對我來說非常相似。兩者都是腳本語言，且都是動態(tài)類型，似乎是00年代最偉大的東西了。在速度比易讀性或debug更重要時，可以選用它們。其次，針對機器學(xué)習(xí)或者人工智能應(yīng)用程序，選用Python。

當(dāng)使用Python時，應(yīng)當(dāng)啟用類型提示會讓情況更加清晰。

規(guī)則6：何時使用硬核語言

在我看來：Go、Rust、Haskell、Erlang、Clojure、Kotlin和Scala都是更為硬核的語言，其中我只用Kotlin發(fā)布過生產(chǎn)代碼。

但假設(shè)一下的話，如果要構(gòu)建全新的Web服務(wù)，我也許會用Go/Rust語言，因為延遲和性能在這種情況下比社區(qū)和庫的支持更加重要。當(dāng)我需要非常優(yōu)雅或數(shù)學(xué)化的功能方法，卻又無需大量的業(yè)務(wù)邏輯時，也許會選用Haskell或Erlang。至于Clojure，該何時使用我就不知道了，在我看來，如果我開始了解和喜歡Lisp之后，可能會用到它。我知道Clojure是一種可編譯為JVM字節(jié)碼的功能范例，但在這種情況下，我更傾向于使用Kotlin。因為Kotlin支持Java，對Intellij也有很好的支持。Scala也是一樣，我可能首先會用Kotlin。

規(guī)則7：怎樣使用Javascript

我寫過的代碼中，最糟的便是Javascript的。當(dāng)時，我正為亞馬遜開發(fā)移動購物體驗，我的團隊對JS框架知之甚少。因此我們換成了vanilla JQuery。起初非常簡單，但之后我們有很多前端需求，很快管理前端狀態(tài)完全成為了噩夢，想想看，組件消失又重現(xiàn)，而我們不知道原因，因此只能在控制臺上注銷掉所有的變量。

因此我是諸多體驗極差的人之一，但我認(rèn)為，這主要得歸咎于我們自己?，F(xiàn)在數(shù)年過去了，我的JS準(zhǔn)則是：

1. 改用Typescript，讓情況更清晰；

2. 嘗試將更多邏輯塞入服務(wù)器端，如果前端不是太復(fù)雜，我會考慮類似Phoenix之類的框架，將所有內(nèi)容全部丟到服務(wù)器端；

3. 如果需要前端交互性，使用類似Vue或React之類的框架；

4. 不要跳過單元測試。

規(guī)則8：何時使用C或C\++

我感覺：不是我們選擇了C語言，而是它選擇了你。有大量的應(yīng)用程序——操作系統(tǒng)、語言設(shè)計、低級編程和硬件都必須使用C語言。

C\++則很有趣，對于諸如機器人技術(shù)、視頻游戲和高頻交易這樣的應(yīng)用來說，它極為有用。無垃圾回收功能對性能帶來的收益，讓它更優(yōu)于Java。

規(guī)則9：如果想要測試服務(wù)器變更卻不重建，請使用PHP或Hack

由于安全因素，亞馬遜禁止使用PHP，但至少到2020年為止，其改進版Hack還在Facebook和Slack公司的后端上使用。

在此之前我從未考慮過何時應(yīng)該使用PHP或Hack，也許是因為它們在亞馬遜是一種禁忌。我知道Slack和Wikipedia都在使用這兩種語言，Slack聲稱，它的編程環(huán)境極為開發(fā)者友好，例如，無需重啟本地服務(wù)器就可查看變更，并web原生支持并發(fā)。

技術(shù)

規(guī)則10：何時使用無服務(wù)器函數(shù)

當(dāng)有一個相對較小且較為簡單的模塊代碼需要偶爾運行時，我會選用無服務(wù)器函數(shù)。

規(guī)則11：選用哪種數(shù)據(jù)庫技術(shù)

當(dāng)需要臨時查詢以及/或者需要ACID及事務(wù)支持時，請選擇SQL，否則請選擇no-SQL。盡管noSQL在處理事務(wù)方面，PostgreSQL（我對AWS Aurora的風(fēng)格很熟悉）在可用性、可伸縮性和持久性方面表現(xiàn)都在改善，但傳統(tǒng)上來說，noSQL更有優(yōu)勢。

測試

規(guī)則12：何時編寫單元測試

只要缺陷的預(yù)期值并非微不足道，我都會嘗試編寫單元測試。預(yù)期值算法：“缺陷的可能性\*缺陷的成本”。由于無法真正精確計算出這些值，這算是一種逃避策略。但至少就我編寫的代碼和通常拿到的需求而言，缺陷造成高昂損失的可能性總會發(fā)生。

但是，每段代碼都應(yīng)當(dāng)有個細(xì)致的單元測試，以證明代碼是以可測試的方式所編寫的，這一點非常重要。

不過，我并不認(rèn)為需要囊括每行每段代碼，除非你無法信任自己（或別人）在預(yù)期值方面的評估結(jié)果，那也可以采用這種策略。

規(guī)則13：何時編寫集成測試

我對集成測試的定義是：當(dāng)你調(diào)用不屬于自己的代碼時所使用的測試（而不是模擬）。

當(dāng)我對不屬于自己的代碼不夠信任時，都會嘗試編寫一個集成測試，尤其當(dāng)這些代碼有可能在我未知的情況下執(zhí)行更改時。

規(guī)則14：何時編寫端到端測試

我將端到端測試定義為產(chǎn)品模擬完整“用戶會話”的測試——這里的用戶可能是嘗試對我的代碼進行多次迭代，以完成某項工作的人類或者另一臺計算機。這通常是規(guī)則12中所定義集成測試的超級集合。

1. 當(dāng)我對產(chǎn)品的運作原理并不完全了解，也無法對變更進行完整的單元測試，希望能確定該產(chǎn)品的可運行性時，更像是“煙霧測試”；

2. 當(dāng)我需要回歸測試用例，以便在將來的重構(gòu)中驗證功能時；

3. 當(dāng)結(jié)果難以提前預(yù)知，比如進行復(fù)雜的計算時，我想測試一些代碼對其影響。

情況1應(yīng)當(dāng)避免，但情況2和3很難真正避免掉。

DevOps

規(guī)則15：何時安排專門的支持工程師

在亞馬遜，默認(rèn)情況下，你對自己的代碼提供支持，因此如果你的某個系統(tǒng)出現(xiàn)了嚴(yán)重故障，你某個同事將會被派遣，并預(yù)期以通宵達旦的方式工作至問題解決。

可能很殘酷。但在亞馬遜公司（比如我現(xiàn)在的團隊），當(dāng)然還包括其他公司，會聘請專門的網(wǎng)站可靠性工程師（SRE）在正常的工作時間之外，在線解決生產(chǎn)環(huán)境中的嚴(yán)重問題。

在多年對付此類問題（并在我的團隊內(nèi)推動大家解決此類問題）之后，我逐漸相信：作為程序員，如果在非工作時間，有可能出現(xiàn)你無法控制的風(fēng)險，那么你應(yīng)當(dāng)始終提倡有專職的SRE來解決問題。一個很好的案例：如果你繼承了某人的代碼，就可以解決現(xiàn)有的缺陷。

找到身處其他時區(qū)、通過訓(xùn)練足以支持你系統(tǒng)的人員往往并不困難，只需有資金支付即可。團隊中的工程師需要共同努力，將這一觀點傳達給管理層。

安全性

規(guī)則16：如果你將所有的IT安全性問題推給信息安全部門（InfoSec），他們將對你提出嚴(yán)苛的規(guī)則

信息安全是一項艱苦的工作，博弈論想要生效，就會步入難以避免地過度謹(jǐn)慎小心。因此我認(rèn)為，如果你至少能完成某些自己的安全保障工作，就能避免嚴(yán)厲限制的沖擊。

一個很好的例子就是亞馬遜內(nèi)部wiki的遷移失敗經(jīng)驗。早在2015年，亞馬遜的信息安全團隊就禁用了PHP。我們內(nèi)部wiki使用的MediaWiki就是以PHP編寫的，而內(nèi)部wiki團隊并沒有質(zhì)疑這個決定（盡管Facebook、WordPress、Slack公司都在使用PHP，F(xiàn)acebook還構(gòu)建了清理過的Hacklang用以替代），而是執(zhí)行了信息安全團隊的建議。他們使用基于Java的替代品（Xwiki）來替換MediaWiki，最終使得相關(guān)團隊用超過4個自然年的時間替代了24個開發(fā)年的產(chǎn)品，還不包括這次遷移對其他團隊工作的中斷——鑒于頁面需要不斷增加已遷移和未遷移項目。如果他們拒絕了PHP禁令，或者自己針對Hack進行一些研究，可能就會避免這場災(zāi)難。

設(shè)計與白板

規(guī)則17：讓設(shè)計會話關(guān)乎輸入，而非批準(zhǔn)

很多會議的目的在于獲得批準(zhǔn)或者獲得同意，除非萬不得已，這種情況應(yīng)當(dāng)避免。你不需要獲批，而是需要做出自己的決策，或者確定該從他人那里獲得何種程度的許可。

與之不同，設(shè)計會議或?qū)υ拺?yīng)當(dāng)是關(guān)于信息獲取以及回答問題的。

項目管理

規(guī)則18：評估更多用于施壓而非項目策劃

我曾擔(dān)任過開發(fā)者及嘗試發(fā)布產(chǎn)品的產(chǎn)品經(jīng)理兩種角色，一直以來，我需要參與很多的評估會議。

人們常說，評估是用于計劃的，是為了搞清楚某項工作所需要花費的時間，以便大家能夠據(jù)之安排自己的工作。

.在我為期五年的產(chǎn)品發(fā)布經(jīng)驗中，回憶起來僅有一個項目是達到這個目標(biāo)的——那是一個非常簡單的安卓應(yīng)用，沒有外部依賴關(guān)系，技術(shù)上并不復(fù)雜，只有一個本地mySQL數(shù)據(jù)庫，以及一些視圖。在這個特定案例中，由于未知因素極少，評估非常準(zhǔn)確，我們可以正確預(yù)期工作的完成時間，誤差在1-2天之內(nèi)。由于我們的期限定得非常嚴(yán)格，這次評估起到了很大作用。

這也是唯一一個我參與的項目里，可以正確量化速度，并正確推進里程碑的項目。

在其他所有項目中，評估的主要目的是施加壓力：適時拋出類似“你說過只用5天”這樣的對話，從而逼迫開發(fā)者更快更努力，同時也花費更多時間迅速完成工作，以免以后再遇到這樣的對話。

我不反對有壓力，但我認(rèn)為，我們需要正確認(rèn)識到：這才是評估的主要目的。

規(guī)則19：明確嚴(yán)格期限、軟性期限、內(nèi)部期限和預(yù)期完成日期之間的區(qū)別

嚴(yán)格期限：如果錯過將對企業(yè)造成嚴(yán)重的不利影響。

軟性期限：如果錯過會令某些人看起來會很差勁。

內(nèi)部期限：這是團隊的內(nèi)部目標(biāo)，不會影響到團隊外部的任何人。

預(yù)期完成日期：這是團隊針對當(dāng)下情況所評估的工作完成時間。

我見過很多將這些期限搞混的痛苦經(jīng)歷。任何時候，如果你拿到一個期限，請確認(rèn)是其中的哪一個。當(dāng)然，通常情況下，我們需要保證按時達成內(nèi)部期限的工作，以確保在嚴(yán)格期限之前完工。但需要指出：讓內(nèi)部期限以嚴(yán)格期限的形式體現(xiàn)時，會對開發(fā)者造成壓力，讓他們延長工作時間。

需要牢記的另外一點：如果某個工程師給出一個預(yù)期時間，而其他人將其定義成嚴(yán)格期限（這種情況時有發(fā)生），這種做法是錯誤的。

規(guī)則20：當(dāng)某人談及敏捷時，請推進看板方法而不是Scrum

當(dāng)某人討論我們在做敏捷開發(fā)時，對我意味著每兩周一次團隊內(nèi)部會議，僅此而已。

然后某些人可能會迷失在敏捷開發(fā)的兩種風(fēng)格：看板方法和Scrum里。在我看來，Scrum意味著“在那兩周之內(nèi)你需要完成特定的任務(wù)”；而看板則意味著“在兩周之內(nèi)完成你能完成的所有任務(wù)”。如果你不清楚所在團隊遵循的風(fēng)格是哪種，應(yīng)當(dāng)明確討論，然后推進看板方法?？紤]到評估的難度（見規(guī)則18），Scrum很容易導(dǎo)致在那兩周時間里，你需要被迫加班以完成相應(yīng)的工作。

原文鏈接：

https://muldoon.cloud/programming/2020/04/17/programming-rules-thumb.html

本文為CSDN翻譯文章。

1.2020年第5期《單片機與嵌入式系統(tǒng)應(yīng)用》電子刊新鮮出爐！

2.為什么星鏈和5G是互補共榮，互相不能替代的兩個大項目？

3.嵌入式系統(tǒng)：大數(shù)據(jù)和行業(yè)應(yīng)用之間的橋梁

4.ARM的免費IP戰(zhàn)略，能否撼動RISC-V的根基？

5.解讀工信部25號文：蜂窩網(wǎng)包打物聯(lián)網(wǎng)，LoRa真要涼涼了？

6.說說兩個冷門卻又不冷門的預(yù)處理指令#pragma和#error！

免責(zé)聲明：本文系網(wǎng)絡(luò)轉(zhuǎn)載，版權(quán)歸原作者所有。如涉及作品版權(quán)問題，請與我們聯(lián)系，我們將根據(jù)您提供的版權(quán)證明材料確認(rèn)版權(quán)并支付稿酬或者刪除內(nèi)容。