[譯] 獨自開發時一些良好的工程實踐

• 原文連結：Good Engineering Practices while Working Solo
• 原文作者：Shalvah
• 譯者：Alisa

當你不得不獨自面對開發工作的時候，你是如何充分利用這一點的呢?

大多數開發者是作為團隊的一員來進行開發工作。然而，在我們職業生涯的某個階段，我們都會(或將會)經歷獨自工作。雖然很多產品開發都需要能夠管理或與團隊的其他成員一起工作，但在獨自工作時養成良好的實踐也同樣重要。

關於“獨自工作”的簡單介紹

Solo通常是指獨自做某事。但是在這裡我們指的是在非正式的、非結構化的環境中由一小部分人所做的任何事情。可能只有你，或者你和其他一些人。例如包括:

• 一個開源專案，如包或庫
• 一款個人產品，可以是商業的，也可以是免費的
• 為客戶提供的自由職業

這裡的共同之處在於，沒有像在公司那樣的既定規則。

我為什麼要為我的工程實踐而煩惱呢?

以下是它們重要的幾個原因：

你會成為你團隊的財富。

讓我們考慮一下當你加入一個團隊時可能出現的情況:

• 你加入一個遵循你習慣的開發實踐的團隊。太棒了！這意味著你將從第一天就準備好為團隊做出貢獻。
• 你加入了一個遵循一系列不同實踐的團隊。如果你已經掌握了良好工程實踐的一般概念，那麼你應該不會花太長時間來適應它，並且你很快就會變得高效。
• 你加入的團隊沒有遵循任何好的實踐(哦，不！)在這種情況下，根據團隊的不同，你可能能夠運用你的知識並改進他們的流程。否則...也許只能離開。

不管怎樣，這都是雙贏。

你會成為一名更好的開發人員

軟體工程不僅僅是編碼。將產品從概念引入到釋出過程中涉及到很多活動的部分，然後讓它繼續執行下去。反覆灌輸最佳實踐將幫助你保持正軌，避免受挫。

如果你熱愛程式設計(就像我一樣)，那麼在開發新東西時，總有一種誘惑會讓你馬上開始編寫程式碼。但隨著時間的推移，我發現，在保持獨自工作的靈活性的同時，適當地建立某種結構，可以幫助我避免前進道路上的許多障礙。

讓我們考慮其中一些好的實踐。

遵循工作流

工作流是將你頭腦中的想法轉化成成品所涉及的一系列步驟。你的工作流程應該包括以下內容:

• 當決定更改時，我要遵循什麼流程來實現它?
• 我如何向終端使用者交付該產品的新版本?
• 我如何跟蹤對該產品所做的更改?
• 我如何跟蹤這個產品的缺陷、問題和未來計劃?

為什麼？ 在沒有定義工作流的情況下,完成工作似乎更快(“只需編寫程式碼並推送到master分支”)，但是隨著專案復變得越來越複雜，你會發現對工作流有明確的定義可以更容易地確定需要做什麼，並且專注於它。在團隊中工作時，工作流成為幫助每個成員提高生產力的管道。

你可以做什麼：

• 使用issues(問題) (GitHub、Gitlab、BitBucket或任何託管你程式碼的地方)。Issues幫助你跟蹤缺陷、功能請求和對專案的主要更改。此外，寫下一個問題的標題和描述會迫使你在頭腦中清晰地表達你的想法，並準確地定義問題是什麼以及解決方案應該包括什麼。通過新增Trello和GitHub Projects等專案管理工具，你還可以更進一步。

• 使用pull requests(拉取請求)。許多開發者在獨自開發時更喜歡直接把程式碼推到master。然而，通過pull requests進行更改有很多好處。這樣操作更容易看到新功能或bug修復中涉及的所有更改，以及合併時它們如何影響程式碼庫。此外，當pull requests與issues同時出現時，可以更容易地觀察專案是如何演變的，而不必閱讀程式碼就能找出問題所在。

• 複查你的程式碼。 這聽起來可能很奇怪，但是你應該像檢查其他人編寫的程式碼那樣檢查自己的程式碼。有些人建議做一個PR，離開幾分鐘或幾個小時，然後在合併或更新之前再回來檢視程式碼。==程式碼複查，脫離你的IDE，讓你用(某種程度上)新鮮的眼光看你的程式碼，幫助你發現錯誤和識別你忘掉的東西。程式碼複查還會迫使你質疑自己。為什麼我要用這種方式實現呢?會出什麼問題呢?還有更好的辦法嗎?==

• 保持有意義的Git歷史。 嘗試像在團隊中那樣提交程式碼——要避免一次提交大量程式碼，保持提交集中，提交資訊有意義。與程式碼評審一樣，編寫描述性提交資訊會迫使你放慢速度。我在這次提交中想要達到什麼目的？我是怎麼做到的呢？

在某些情況下，你可以允許自己違反規則。例如，您可能會決定，對於實在很小的問題修復(例如糾正一個錯別字)，直接推到master也是是可以的，以避免拖慢進度。

編寫可重用的元件和模組

思考要遵循DRY、SOLID、FIRST的原則。用更小的、封裝的、可重用的元件來構建軟體。使用像Bit這樣的工具來建立你最喜歡的構建塊的集合，並保持更新。最終你將能更快地構建更好的軟體。

編寫文件

呃，文件。許多人都知道，很少有人會寫，喜歡它的人更少。在經歷了興奮的編碼過程之後，編寫文件通常是一件困難的事情。我該怎麼用文字抓住程式碼的所有複雜之處?

為什麼？ 人類是不可靠的。我們會遺忘，我們會有生病的時候，或者我們會離開一個專案。文件能確保知識不受某一個人的束縛。文件還可以幫助開發人員全面瞭解專案並保持專注。

你可以做什麼：

• 要清楚你不是在寫書。 文件不是要寫成文學著作。沒有人給你打分。不要試圖去解釋所有的東西。保持簡潔明瞭。有時候你只需要羅列幾個要點就足夠了。
• 編碼前做記錄。 記錄產品的介面-它將如何從外部開始運作。它將作為規範，在構建軟體的過程中給你一些指引。
• 編碼後做記錄。 再次強調，寫作時要像一個旁觀者一樣。什麼是重要的？你需要知道什麼才能使用它(或貢獻它)？在開發過程中，規範可能會發生變化，因此在編碼完成後，檢查一下編碼前所寫的文件，是否仍然是正確的非常重要。
• 編碼時做記錄。 這主要適用於用程式碼編寫文件。有很多關於程式碼文件化的文章，所以我不會詳細討論這個問題。
• 劃分單元來工作。 以上所有的原則都適用於劃分單元。例如，一個單元可以是一個函式、一個類、一個新功能、行為的改變、一個模組或整個產品。如果記錄一件工作看起來非常困難，那麼嘗試將它分解成更小的單元(或者，在單元的基礎上再往上提升層次)。

溝通

溝通主要適用於與小團隊或為客戶提供服務。

為什麼？ 透明度關係到責任。當你知道你必須向某人報告你的交易時(無論是你的同事還是你的老闆)，這有助於你保持專注。這也是許多公司召開站立會議的原因之一。

另一個原因是，當團隊中的成員遇到問題時，可以通過與客戶或其它團隊成員溝通得到輕鬆解決。我已經記不清有多少次我沮喪地大喊，“我的更改沒有顯示出來”，結果另一個團隊成員告訴我，“哦，我想我做的一些修改，可能導致了你的修改無效”。

你可以做什麼：

• 當你遇到無法預料的困難時，要讓你的團隊和客戶知曉。
• 定期向客戶彙報專案進展情況。不過，儘量不要太技術化。
• 當計劃有變化時，要讓你的團隊知道。
• 消除溝通的障礙，這樣每個人都能容易地知道其他人在做什麼。找到並使用最適合你們的工具——WhatsApp、電子郵件、Slack等等。

本質上，保持反饋環節的活力。它消除了相關的各方之間的許多摩擦。

監控

為什麼？ 總會有一些事情會出錯的。部署可能會失敗，人會犯錯，異常可能會被丟擲，流程會被打破。重要的是要做好監控的準備，以便您能夠更好地處理這些故障。監控是反饋環節的另一部分;它阻止你在不知道產品實際效能的情況下，在象牙塔中進行構建。

你可以做什麼

• 記錄日誌和指標。 不必羞於在必要的地方console.log()。記錄得資訊多總比太少好。但是，一定要避免讓不必要的細節汙染日誌，以便能更容易地進行篩選。
• 要知道日誌的位置，並建立一個系統以便於檢視。 這可以是像SSHing到伺服器跟蹤日誌檔案這樣基本的操作，也可以是像將日誌傳送到ELK堆疊這樣高階的操作。但重要的是，當你呼叫console.log()(或其他用於記錄日誌的方法)時，你要知道在哪裡查詢這些日誌。
• 不要吞下錯誤。 雖然你的應用程式應該是可復原的(在出現錯誤時能夠恢復)，但記錄你沒有預料到的錯誤是個好主意。例如，如果你正在呼叫一個API來獲取使用者建立的內容(例如tweet)，那你應該做好需要處理404 Not Found的準備。但是來自API的另外的意外錯誤，你應該記錄。我曾經遇到過這樣的情況，因為我沒有記錄這些錯誤，我不知道我已經超出了訪問的速率限制，導致我的應用程式被列入了訪問API的黑名單。
• 檢查你捕獲的日誌和指標。 這可以是手動的，也可以是自動的。我曾經遇到過這樣的情況:我實現了一個“簡單的”修復，然後部署了它，接著繼續我的愉快之旅，但後來我才意識到它沒起作用。從那時起，我開始在部署之後一段時間內監控應用程式日誌，以驗證事情是否如預期的那樣進行。

監控策略可以採用不同的形式，從簡單的控制檯輸出日誌、文字檔案到第三方應用(如Sentry、Bugsnag和Elastic APM)。選擇一個適合你的來使用吧。

觀察和迭代

這是一個最佳實踐，也是所有其他實踐的指南。沒有適合所有人的通用公式。人們習慣於不同的工作流、監控策略、文件樣式等等。這就是為什麼保持觀察和迭代是如此重要。

你看到了，但你沒有觀察。區別很明顯。
-夏洛克·福爾摩斯，波希米亞的醜聞

觀察包括批判性地觀察行為或表現。通過觀察，你將所見與所知聯絡起來，並從中推理出事實。當獨自工作時，你通常無法從高階案例研究和A/B測試中獲益，因此你可以從“非正式”來源(如人們的評論、問題報告和日誌)中獲取線索。

觀察之後就是迭代。迭代是針對觀察結果對產品進行改進，然後再進行觀察，以此類推。觀察之後，下一件事是得出結論，然後實施它們。但這還沒有結束。

一個示例場景：我有一個應用程式，它顯示專案列表和它們的建立時間。但時間是UTC時間，所以對於很多使用我的應用的人來說，顯示的時間是錯誤的，這經常讓他們感到困惑。

我決定通過顯示“UTC”來解決這個問題(例如，顯示“5:30 pm UTC”)。這個方法很有效，而且不容易混淆。但我最終意識到，我為什麼要讓使用者自己轉換到當地時區呢？因此我將其更改為將顯示的時間轉換為使用者的時區。這樣好多了。

在與使用我應用的使用者交談之後，我意識到對他們來說最重要的事情是大致地知道一個條目存在的時間，而沒必要是確切的時間。為了響應這個觀察結果，我做出了一個更新，將所有時間更改為相對時間(“5分鐘前”、“2小時前”)。時間的準確性已不復存在，但它讓我的使用者工作變得簡單得多。

這也適用於你的內部流程。這些指導方針都不是一成不變的。在選擇實踐時，重要的是觀察哪些有效，哪些無效，並以此為基礎進行迭代。不斷做出改變，直到找到適合自己的。

結論

理想情況下，在結構化的產品開發環境中，有許多不同的專門的角色起著重要作用，從產品所有者到開發人員。當你獨自工作時，重要的是你要意識到，你正在填補許多(也可能是所有)這些角色，所以可以按照自己的意願來行事。最好利用這種自由來創造一個讓你更有效率的結構。這可能需要一點額外的時間和精力，但我向你保證這是值得的！

感謝您的閱讀，請隨意評論和提問！