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

• 原文連接：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小時前」)。時間的準確性已不復存在，但它讓個人用戶工做變得簡單得多。

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

結論

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

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