過(guò)去一年中，我坐在一位資深的軟件工程師旁邊，可以仔細(xì)地觀察他是怎么工作的。我們兩人經(jīng)常共同編程，使得這項(xiàng)觀察更為容易。此外，在團(tuán)隊(duì)文化中，從背后窺探寫代碼的人并不令人反感。以下是我所學(xué)到的：

一、編寫代碼

1. 如何命名

我首先著手的是 React UI。我們有一個(gè)主要組件來(lái)放置其他所有的組件。我喜歡在代碼里加點(diǎn)幽默感，因此我想要將它命名為 GodComponent。當(dāng)進(jìn)入代碼審查環(huán)境的時(shí)候，我才明白為什么命名這么難。

在計(jì)算機(jī)科學(xué)里有兩個(gè)難題：內(nèi)存不足、命名、以及差一(off-by-one)錯(cuò)誤。 ——Leon Bambrick

我每個(gè)命名的代碼段都有隱藏含義在里面。GodComponent 是所有我不必費(fèi)心去尋找合適位置來(lái)存放那些垃圾的地方，它可以容納所有東西。如果我早早把它命名為 LayoutComponent，之后的我就會(huì)發(fā)現(xiàn)它所做的就是分配 layout，沒有狀態(tài)。

我發(fā)現(xiàn)命名好的另一個(gè)好處是：如果它看起來(lái)太長(zhǎng)了，就像 LayoutComponent 包含了很多業(yè)務(wù)邏輯層，我就知道是時(shí)候要重構(gòu)了，因?yàn)闃I(yè)務(wù)邏輯層并不屬于這里。如果是以 GodComponent 命名，這里的業(yè)務(wù)邏輯層也不會(huì)和其他有所區(qū)別。

命名你的集群?以在服務(wù)器上運(yùn)行的服務(wù)名稱來(lái)命名更好，直到用它們來(lái)運(yùn)行其他服務(wù)為止。我們最終以團(tuán)隊(duì)的名字來(lái)命名服務(wù)器。

在函數(shù)上也是同樣的道理。doEverything() 是一個(gè)糟糕的名字，會(huì)有很多難以預(yù)料的后果。如果這個(gè)函數(shù)能夠做所有事情，那么在測(cè)試函數(shù)某個(gè)特定部分時(shí)將變得非常困難。因?yàn)椴还苓@個(gè)函數(shù)有多大，你都不會(huì)覺得奇怪，畢竟這個(gè)函數(shù)應(yīng)該做所有的事情。這時(shí)候就需要改名、重構(gòu)了。

有意義的命名也有不太好的一面。如果名字的表意太強(qiáng)，結(jié)果掩蓋了一些功能上的細(xì)微差別怎么辦?例如：當(dāng)你在 SQLAlchemy 中調(diào)用 session.close() 時(shí)，這只會(huì)關(guān)閉會(huì)話但不會(huì)關(guān)閉底層數(shù)據(jù)庫(kù)的連接。

在這種情況下，可以以 x,y,z 來(lái)命名而不是 count()，close()，insertIntoDB()，這樣可防止為其賦予隱性含義并強(qiáng)制開發(fā)人員仔細(xì)檢查它所執(zhí)行的操作。

2. 歷史代碼和下一名開發(fā)者

你曾否看過(guò)一些代碼，覺得它們很奇怪?這些代碼為什么這么做呢?它們的實(shí)現(xiàn)一點(diǎn)都不合理。

我曾負(fù)責(zé)過(guò)遺留代碼庫(kù)。代碼中有諸如「當(dāng) Mohammad 發(fā)現(xiàn)情況時(shí)取消注釋代碼」這類的注釋。這是在做什么?誰(shuí)是 Mohammad?

在這里可以做下角色轉(zhuǎn)換——想象下一個(gè)人來(lái)看我的代碼，他們是否會(huì)覺得奇怪?

同行審查可以某種程度上解決代碼注釋這個(gè)問(wèn)題。這讓我想到了上下文的概念：注意我團(tuán)隊(duì)正處的上下文位置。

如果我忘記了這部分代碼，之后又回到了代碼工作上，沒有注釋的話我不能重新創(chuàng)建上下文，我可能只會(huì)想：「為什么他們要這么寫?這沒有任何意義……哦，等等，是我寫的?！?/p>

這里就是開發(fā)文檔和注釋該出現(xiàn)的地方。

3. 文檔和注釋

文檔和注釋有助于維護(hù)上下文和分享知識(shí)。

正如李在《如何構(gòu)建好軟件》中所說(shuō)，「軟件的主要價(jià)值不是編寫它的代碼，而是編寫它的人所積累的知識(shí)。」

比如說(shuō)，我們有個(gè)似乎沒有人用過(guò)的、面向隨機(jī)客戶端的 API 終端。因?yàn)檫@些原因，我就應(yīng)該把它刪除嗎?畢竟這是一個(gè)技術(shù)累贅。

如果說(shuō)，在某個(gè)特定國(guó)家，有 10 名記者會(huì)一年一次將他們的報(bào)道發(fā)送到這個(gè)終端，怎么辦?你如何測(cè)試它?如果沒有開發(fā)文檔(那時(shí)就沒有)就不能測(cè)試。所以我們沒有測(cè)試。我們刪除了那個(gè)終端。過(guò)了幾個(gè)月后，到了一年中發(fā)送的時(shí)間，因?yàn)檫@個(gè)終端已經(jīng)不存在了，10 名記者也就無(wú)法發(fā)送這 10 份重要報(bào)告。

雖然熟悉產(chǎn)品的人已經(jīng)離開了團(tuán)隊(duì)，但是現(xiàn)在代碼中有注釋解釋終端的作用。

據(jù)我所知，文檔是每個(gè)團(tuán)隊(duì)都在努力的東西。不僅僅是代碼的文檔，還有關(guān)于代碼的流程。

4. 自信地刪掉垃圾代碼

我過(guò)去很不喜歡刪除垃圾代碼或過(guò)時(shí)的代碼。我認(rèn)為過(guò)去寫的代碼都是神圣的。我的想法是：「他們寫這些代碼的時(shí)候肯定有一些想法?！惯@是傳統(tǒng)和文化與第一性原則之間的碰撞，與刪除一年一次的終端發(fā)生的事相同。我在那里學(xué)到了詳細(xì)的一課。

我嘗試基于已有代碼進(jìn)行工作，但是資深工程師會(huì)嘗試解決掉它——全部刪除。一個(gè)永遠(yuǎn)無(wú)法到達(dá)的 if 聲明?一個(gè)不應(yīng)該調(diào)用的函數(shù)?是的，都消失了。

至于我呢?我只會(huì)把我的函數(shù)寫在最上面。我沒有減少這些技術(shù)累贅，反而增加了代碼的復(fù)雜程度，以及誤導(dǎo)別人的可能。下一個(gè)人將事情拼湊起來(lái)會(huì)更困難。

現(xiàn)在我受到的啟發(fā)是：有一些代碼你可能不理解，也有一些代碼你知道永遠(yuǎn)不會(huì)用。刪除那些你永遠(yuǎn)都不會(huì)用的代碼，小心那些你不理解的代碼。

5. 代碼審查

代碼審查對(duì)學(xué)習(xí)來(lái)說(shuō)非常有用。這是你寫代碼和其他人寫代碼時(shí)進(jìn)行的外部反饋循環(huán)。

兩種實(shí)現(xiàn)有什么區(qū)別呢?一種方法比另一種好嗎?每次代碼審查時(shí)我都問(wèn)自己：「他們?yōu)槭裁催@樣做?「。每當(dāng)我找不到合適的答案時(shí)，我就會(huì)去和他們談?wù)劇?/p>

在第一個(gè)月后，我開始在同事的代碼中找到錯(cuò)誤(就像他們對(duì)我代碼做的一樣)。同行審查對(duì)我來(lái)說(shuō)變得更有趣了——這是我期待的游戲——一個(gè)提高我代碼意識(shí)的游戲。

我的啟發(fā)是：在理解代碼如何實(shí)現(xiàn)前不要批準(zhǔn)它。

二、測(cè)試

我非常喜歡測(cè)試，以至于如果沒有測(cè)試就將代碼寫入代碼庫(kù)我會(huì)感到非常不舒服。

如果整個(gè)應(yīng)用程序只做一件事(就像我所有的學(xué)校項(xiàng)目)，那么手動(dòng)測(cè)試是可以的。但是如果該應(yīng)用程序可完成 100 種不同的功能，那該怎么辦呢?我不想花半個(gè)小時(shí)來(lái)測(cè)試所有的功能，何況有時(shí)候還會(huì)忘記一些需要測(cè)試的地方。

所以就出現(xiàn)了自動(dòng)化測(cè)試。

我認(rèn)為測(cè)試是一種文檔，是對(duì)代碼假設(shè)的文檔。測(cè)試會(huì)告訴我(或我之前的人)他們預(yù)想代碼是如何工作的，以及他們預(yù)期哪里會(huì)出錯(cuò)。

所以，當(dāng)寫測(cè)試時(shí)，我會(huì)記?。?/p>

• 記錄如何使用測(cè)試時(shí)用到的類/函數(shù)/系統(tǒng)。
• 記錄我所想到的會(huì)出錯(cuò)的地方。

在大多數(shù)情況下，以上的結(jié)論是在我在測(cè)試而不是實(shí)現(xiàn)的過(guò)程中想到的。

以下是我在 Google 衛(wèi)生間小休時(shí)學(xué)到的例子：

• 我在 #2 中遺漏了一些東西，那里是 bug 出現(xiàn)的地方;
• 所以每當(dāng)發(fā)現(xiàn) bug 時(shí)，確保修復(fù) bug 的代碼也有相應(yīng)的測(cè)試(稱為回歸測(cè)試)，用于記錄信息：這里可能出現(xiàn)另一種錯(cuò)誤。

僅僅編寫這些測(cè)試并不能提高我代碼的質(zhì)量，而編寫代碼卻可以。但是我從閱讀測(cè)試代碼中獲得了寫更好代碼的直覺。

但是，并不只有這一種測(cè)試，這就是為什么有部署環(huán)境測(cè)試的原因。

你可以有完美的測(cè)試單元，但是如果沒有系統(tǒng)測(cè)試，就會(huì)出現(xiàn)以下的情況：

[[275640]]

這同樣適用于已經(jīng)測(cè)試好的代碼：如果你機(jī)器上沒有你需要的庫(kù)，你會(huì)崩潰。

為了測(cè)試你需要：

• 有一臺(tái)你用于開發(fā)的機(jī)器;
• 有一臺(tái)你用于測(cè)試的機(jī)器;
• 最后，有一臺(tái)你部署的機(jī)器(請(qǐng)不要用與開發(fā)程序使用同一臺(tái))。

如果測(cè)試和部署機(jī)器之間的環(huán)境不匹配，你就遇到麻煩了。所以這里就出現(xiàn)了部署環(huán)境。

• 我們先有本地開發(fā)環(huán)境，在我的機(jī)器上是 docker;
• 然后有服務(wù)器上的開發(fā)環(huán)境，機(jī)器上安裝了一系列的庫(kù)(和開發(fā)工具)，我們?cè)诎惭b了代碼的機(jī)器上進(jìn)行開發(fā)。其他相關(guān)依賴的測(cè)試都可以在這里進(jìn)行;
• 接下來(lái)是 beta/stage 環(huán)境，它與生產(chǎn)環(huán)境完全一樣;
• 最后是生產(chǎn)環(huán)境，它是代碼運(yùn)行和服務(wù)于實(shí)際客戶的機(jī)器上的環(huán)境。

這里的想法是嘗試捕獲單元和系統(tǒng)測(cè)試無(wú)法捕獲的錯(cuò)誤。例如，請(qǐng)求系統(tǒng)和響應(yīng)系統(tǒng)之間的 API 不匹配。個(gè)人項(xiàng)目與小公司的情況大不一樣。不是每個(gè)人都有資源來(lái)搭建自己的設(shè)備。然而，這個(gè)想法仍適用于像 AWS 和 AZURE 這樣的云供應(yīng)商。

你可以為開發(fā)和生產(chǎn)設(shè)置分開的集群。AWS ECS 使用 docker 鏡像來(lái)部署，所以即使跨環(huán)境事情也會(huì)相對(duì)平穩(wěn)。棘手的一點(diǎn)是其他 AWS 服務(wù)之間的集成。你是否可以在正確的環(huán)境中調(diào)用正確的終端呢?

你甚至可以更進(jìn)一步：下載其他 AWS 服務(wù)的備用容器鏡像并使用 docker-compose 來(lái)配置本地完整的環(huán)境。它會(huì)加速反饋循環(huán)。

三、設(shè)計(jì)

為什么我要將設(shè)計(jì)放到寫代碼和測(cè)試的后面呢?設(shè)計(jì)本應(yīng)該在第一位，但是如果我沒有在環(huán)境中寫代碼和測(cè)試，我可能會(huì)不擅長(zhǎng)設(shè)計(jì)一個(gè)遵循環(huán)境特性的系統(tǒng)。

在設(shè)計(jì)系統(tǒng)時(shí)，有很多事情需要考慮：

• 使用編號(hào)是多少?
• 有多少用戶?預(yù)期增長(zhǎng)是多少?(即需要使用多少數(shù)據(jù)行)
• 未來(lái)可能出現(xiàn)的問(wèn)題是什么?

我需要把它轉(zhuǎn)成一個(gè)名為「需求收集」的合理清單。這個(gè)過(guò)程有點(diǎn)與靈活性的原則相悖——在開始系統(tǒng)開發(fā)之前，你可以設(shè)計(jì)多少部分呢?但是這是一種平衡——你需要選擇什么時(shí)候做什么。當(dāng)然僅僅收集需求并不是所有需要考慮的事情。我認(rèn)為，在設(shè)計(jì)中包含了開發(fā)的過(guò)程也是值得去做的。例如：

• 本地開發(fā)如何運(yùn)作?
• 怎么打包和部署?
• 如何進(jìn)行端對(duì)端的測(cè)試?
• 怎么對(duì)新的服務(wù)進(jìn)行壓力測(cè)試?
• 怎么管理機(jī)密信息?
• CI/CD 集成?

我們最近為 BNEF 開發(fā)了一個(gè)新的搜索系統(tǒng)。做這件事真的很棒。我開始設(shè)計(jì)本地開發(fā)，學(xué)習(xí) DPKG(打包和部署)和試圖解決部署機(jī)密信息的問(wèn)題。

誰(shuí)會(huì)想到對(duì)產(chǎn)品中的機(jī)密信息進(jìn)行部署會(huì)變得如此棘手呢?

• 你不能將這些信息存到代碼中，因?yàn)檫@樣任何人都能看得到。
• 把它們作為環(huán)境變量?這是一個(gè)好主意。但你怎么把它們放在那里?(每次機(jī)器啟動(dòng)時(shí)訪問(wèn) PROD 機(jī)器來(lái)填充環(huán)境變量是一件痛苦的事情)
• 部署為機(jī)密文件?文件從哪里來(lái)呢?怎么進(jìn)行填充呢?

而且我們不想進(jìn)行手動(dòng)操作。

最后我們使用了一個(gè)有角色訪問(wèn)控制的數(shù)據(jù)庫(kù)(只有我們的機(jī)器可以與數(shù)據(jù)庫(kù)對(duì)話)。我們的代碼在啟動(dòng)時(shí)從這個(gè)數(shù)據(jù)庫(kù)中獲取秘密數(shù)據(jù)。這個(gè)能在開發(fā)、測(cè)試和產(chǎn)品之間很好地復(fù)制——在各自的數(shù)據(jù)庫(kù)中都有機(jī)密。

同樣的，對(duì)于像 AWS 這樣的云供應(yīng)商，這可能非常不同。你不必考慮太多機(jī)密。獲取你角色賬戶，在用戶界面中輸入機(jī)密數(shù)據(jù)，在需要的時(shí)候你的代碼會(huì)找到它們。它簡(jiǎn)化了很多時(shí)間，這非常酷，而我很高興有經(jīng)驗(yàn)領(lǐng)會(huì)這種簡(jiǎn)易性。

設(shè)計(jì)時(shí)考慮維護(hù)需求：

設(shè)計(jì)系統(tǒng)是件令人興奮的事。維護(hù)系統(tǒng)呢?就沒那么有趣了。

我在維護(hù)過(guò)程中遇到了這個(gè)問(wèn)題：系統(tǒng)為什么會(huì)降級(jí)，以及如何降級(jí)?

有兩個(gè)原因可以解答為什么系統(tǒng)也會(huì)有降級(jí)的時(shí)候：

• 首先，系統(tǒng)不應(yīng)當(dāng)舍棄舊的東西，而是在已有的基礎(chǔ)上增加更多功能。系統(tǒng)更新傾向于增加而不是刪除。
• 其次，帶著最終目標(biāo)來(lái)設(shè)計(jì)。一個(gè)進(jìn)化到做不該做的事情的系統(tǒng)和一個(gè)從零來(lái)設(shè)計(jì)做同樣事情的系統(tǒng)一樣，沒有用。這是一種系統(tǒng)的倒退。因此需要對(duì)系統(tǒng)進(jìn)行降級(jí)。

現(xiàn)在我知道至少三種降低降級(jí)機(jī)率的方法：

• 將業(yè)務(wù)邏輯和基礎(chǔ)設(shè)施分開：通常是對(duì)基礎(chǔ)設(shè)施降級(jí)——當(dāng)使用量增加、框架過(guò)時(shí)、出現(xiàn)零日漏洞等情況下;
• 圍繞系統(tǒng)維護(hù)建立流程。對(duì)舊的和新的組件都使用相同的更新。這可以防止組件之間出現(xiàn)差異，保持整個(gè)代碼「現(xiàn)代化」;
• 確保一直修剪你不想要的/舊的東西。

四、部署

將功能進(jìn)行捆綁部署還是逐個(gè)部署呢?如果答案是將功能捆綁在一起，則會(huì)出現(xiàn)問(wèn)題。

接下來(lái)要問(wèn)的問(wèn)題是：為什么想要把功能進(jìn)行捆綁呢?

• 部署是否花費(fèi)過(guò)多時(shí)間?
• 代碼審查是否容易進(jìn)行?

不管是什么原因，這是需要修復(fù)的流程瓶頸。

捆綁功能部署至少有兩個(gè)問(wèn)題：

• 如果一個(gè)功能中有 bug，將妨礙另一個(gè)功能執(zhí)行;
• 增加整體出錯(cuò)的風(fēng)險(xiǎn)。

然后，無(wú)論你選擇什么部署過(guò)程，你總是希望你的機(jī)器像一頭牛而不是像寵物一樣。它們并不珍貴。你知道每臺(tái)機(jī)器上運(yùn)行的是什么，以及如何在死機(jī)的情況下重新創(chuàng)建它們。當(dāng)一臺(tái)機(jī)器死機(jī)時(shí)，你不會(huì)心煩意亂，你只需要啟動(dòng)一臺(tái)新機(jī)器。你像牛一樣放養(yǎng)它們，而不是像寵物一樣養(yǎng)著他們。

五、程序出錯(cuò)的時(shí)候

當(dāng)事情出錯(cuò)時(shí)，而且一定會(huì)有出問(wèn)題的時(shí)候，黃金法則是將對(duì)客戶的影響最小化。

當(dāng)事情出了差錯(cuò)，我自然傾向于趕快解決 bug。事實(shí)證明，這并不是最理想的解決方案。與其修復(fù)哪里錯(cuò)了，即使只是「修改一行」，所做的第一件事應(yīng)該是回滾版本?；氐街暗墓ぷ鳡顟B(tài)，這是讓客戶恢復(fù)工作最快的方法。

過(guò)了這個(gè)時(shí)候，才應(yīng)該看看哪里出了問(wèn)題并修復(fù)那些 bug。

在你的集群中出現(xiàn)一臺(tái)「垮掉」的機(jī)器也應(yīng)當(dāng)是同樣的做法——在試圖找出機(jī)器出了什么問(wèn)題之前，先把它停了，并標(biāo)記它不可用。

首先找 bug 這種本能會(huì)引導(dǎo)我走上解決 bug 的漫長(zhǎng)旅途，反而偏離了讓客戶先恢復(fù)工作這一理想的目標(biāo)狀態(tài)。有時(shí)候，我覺得它沒有工作的原因是因?yàn)閷懙拇a有問(wèn)題，而仔細(xì)閱讀每一行代碼后會(huì)陷入混亂，像是一種深度優(yōu)先搜索。

之后，我的啟發(fā)是，首先開始廣度優(yōu)先搜索，然后再深度優(yōu)先搜索，去除最頂端的節(jié)點(diǎn)。能否用已有的資源確認(rèn)：

• 機(jī)器啟動(dòng)了嗎?
• 是否安裝了正確的代碼?
• 配置是否正確?
• <代碼特定配置>，像代碼中的路由是否正確?
• 模式版本是否正確?
• 然后進(jìn)入代碼。

在某次出錯(cuò)的問(wèn)題上，我們以為機(jī)器上沒有正確安裝 nginx，但結(jié)果是配置被設(shè)置為了 false。

當(dāng)然，我不需要總是這樣做。有時(shí)候錯(cuò)誤信息已經(jīng)足以減少需要搜索代碼的區(qū)域。而且當(dāng)我無(wú)法解決這個(gè)問(wèn)題時(shí)，我嘗試并持續(xù)修改代碼以將問(wèn)題降到最低。修改的次數(shù)越少，我就能越快地處理實(shí)際問(wèn)題。

但是我現(xiàn)在還是會(huì)記錄花了 1 個(gè)多小時(shí)來(lái)解決的 bug：遺漏了什么?這通常是一些我忘記檢查的愚蠢錯(cuò)誤，比如像設(shè)置路由、確保模式版本和服務(wù)版本匹配等。這是熟悉使用的技術(shù)堆棧的另一步，而且只有經(jīng)驗(yàn)會(huì)告訴我為什么系統(tǒng)無(wú)法運(yùn)行。

六、監(jiān)控

這是我以前從未想過(guò)去做的事。說(shuō)句公道話，在全職編碼之前，我從沒維護(hù)過(guò)系統(tǒng)。我只是搭建它們，使用 1 個(gè)星期后然后進(jìn)行下一項(xiàng)工作。

有兩個(gè)系統(tǒng)，一個(gè)有良好的監(jiān)控，另一個(gè)并不那么好。我逐漸非常喜歡監(jiān)控。如果我不知道 bug 在哪我就不能修改錯(cuò)誤。其中一種最糟糕的感覺是從客戶那里知道有 bug。

「我做了什么?!我甚至不知道我的系統(tǒng)出了什么問(wèn)題?」

我認(rèn)為監(jiān)控由 3 個(gè)部分組成——日志、衡量標(biāo)準(zhǔn)和警報(bào)。

1. 日志

以代碼中進(jìn)行日記記錄就像人寫日志一樣，是一個(gè)進(jìn)化的過(guò)程。

你要找到你可能需要監(jiān)控的東西，日志記錄下來(lái)，運(yùn)行系統(tǒng)。一段時(shí)間后，你會(huì)發(fā)現(xiàn)你沒有足夠信息來(lái)解決的 bug。這是增強(qiáng)日志記錄的好時(shí)機(jī)——你的代碼少了些什么?

我想你會(huì)憑直覺地知道什么東西很重要需要記錄，但是在我們的服務(wù)器中我和資深軟件工程師所記錄的東西有很多不同。我認(rèn)為只要請(qǐng)求-相應(yīng)日志就足夠了，但是他會(huì)有更多的記錄內(nèi)容，比如查詢執(zhí)行時(shí)間、代碼進(jìn)行的一些特定的內(nèi)部調(diào)用，以及何時(shí)轉(zhuǎn)儲(chǔ)日志。一切都已經(jīng)解決了。

幾乎不可能在沒有日志的情況下進(jìn)行調(diào)試——如果你不知道系統(tǒng)的狀態(tài)，你怎么重新創(chuàng)建它呢?

2. 衡量標(biāo)準(zhǔn)和驚爆

衡量標(biāo)準(zhǔn)可以源于日志，也可以獨(dú)立于日志(例如向 AWS CloudWatch 和 Grafana 發(fā)送時(shí)間)。你可以決定你的衡量指標(biāo)并在代碼運(yùn)行時(shí)發(fā)送數(shù)字。

警報(bào)是把所有東西整合到一個(gè)的強(qiáng)大監(jiān)控系統(tǒng)的粘合劑。如果一個(gè)衡量標(biāo)準(zhǔn)是當(dāng)前產(chǎn)品中運(yùn)行的機(jī)器數(shù)量，當(dāng)這個(gè)數(shù)字降到 50% 時(shí)，這是一個(gè)很好的警報(bào)——你知道有什么出錯(cuò)了。

失敗計(jì)數(shù)高于某個(gè)閾值時(shí)?是的，又一個(gè)警報(bào)。

這里暗示了另一個(gè)需要養(yǎng)成的習(xí)慣。當(dāng)你修復(fù) bug 時(shí)，你不僅僅關(guān)注如何修復(fù) bug，而是你為什么不早點(diǎn)發(fā)現(xiàn)它呢?是否有布置警報(bào)?如何能夠更好地監(jiān)控來(lái)避免類似的問(wèn)題?

我還不知道如何監(jiān)控 UI。即使吧組件測(cè)試到位，也還不足以了解出錯(cuò)的情況。這些錯(cuò)誤通常是由客戶來(lái)告訴我們的——這看起來(lái)不太對(duì)勁。

七、總結(jié)

在過(guò)去的一年里，我學(xué)到了很多東西。當(dāng)我對(duì)這篇文章進(jìn)行回顧時(shí)，我能夠更好地體會(huì)到我的成長(zhǎng)。希望你也可以從這里得到一些東西!

原文鏈接：https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html#when-things-go-wrong

【本文是51CTO專欄機(jī)構(gòu)“機(jī)器之心”的原創(chuàng)譯文，微信公眾號(hào)“機(jī)器之心( id: almosthuman2014)”】 

戳這里，看該作者更多好文