如何成為更好的軟體開發人員

銀河1號發表於2019-01-13

今天，我想分享一些關於軟體開發人員如何提高他們的專業技能並在工作中變得更好的想法。這裡提出的主題是通用的，並不是特定於任何技術堆疊。就此而言，其中大部分都不是特定於IT的。這些是關於如何發展您的個人特徵，改善與同事和客戶的協作以及推進您作為軟體開發人員的職業生涯的一般建議。

本文中的一些內容是主觀的，反映了我的個人經歷，而其他內容已被其他人採用併成功使用。

理解端到端的過程

許多開發人員認為軟體開發完全是關於編碼的，而其他一切只是讓人討厭並浪費寶貴時間的人。這不能遠離真相。在您編寫一個軟體程式碼之前，它會經歷一個從模糊的想法轉變為精心設計的解決方案的過程，以便實施。在您將最新的更改推送到Git之後，軟體正在進行測試，部署，監控，分析和改進。編碼只是該過程的眾多步驟之一。

那麼為什麼會這樣呢？通常，特別是在大型組織中工作時，專案的不同階段由不同的團隊甚至部門處理。這一切都始於收集需求的業務分析師。然後將要求移交給為開發人員生成模型的設計人員。開發人員編寫程式碼並將結果提供給QA工程師。如果一切正常，則會將工件傳送給將其交付給終端使用者的運營團隊。該過程被視為一組離散步驟而沒有任何反饋。由於各部門之間缺乏溝通，他們的代表往往不瞭解他人的目標，這會導致誤解，甚至衝突。

通常，軟體開發過程被視為一組沒有反饋的離散步驟。

對於現在的許多人來說，這聽起來有點過分誇張。隨著敏捷方法的興起，越來越多的公司從這種僵化的方式轉向由混合專業人士組成的小型團隊。但即便如此，我們也看到人們並沒有真正去了解別人的工作。您經常對設計師感到煩惱，因為他們希望您實現一個過於耗時的自定義核取方塊？反之亦然，受到批評，因為你忘了使用正確的字型。

只要關注他人的工作，就可以克服很多這些差異。與您的設計師坐下來解釋他，實現自定義核取方塊需要一段時間，並且有一個庫可以提供您可以重複使用的不同類似的核取方塊。作為回報，學習排版的基礎知識並理解為什麼選擇正確的字型會產生影響。對經理，業務分析師，QA工程師，支援和營銷專家持同樣的態度。引用T. Huxley：

嘗試學習關於某事的一切事物。

通過向每個人學習，您將能夠預測他們的需求，縮短反饋迴圈並實現更頻繁的交付。此外，它將贏得所有其他人的愛和尊重。

瞭解客戶的需求

您需要了解有關客戶的一件重要事情：他們不瞭解您正在做的大部分事情。敏捷，函數語言程式設計或非關係型資料庫對他們來說都是黑暗的。即使那些密切關注你的工作並且真正感興趣的人仍然大部分都處於黑暗中。這有幾個後果。

與軟體開發人員交談時，大多數客戶都會面對。

為他們招聘軟體開發人員需要一定程度的信任。人們往往因為不理解他們需要付出很多錢而感到不舒服。記得上次你走進一個不熟悉的汽車維修服務，並不確定你是否可以信任他們的乘車？那麼，你的客戶有同樣的感覺。除了沒有汽車，只有一大堆抽象的非有形概念應該以某種方式實現產品和收入。與新客戶合作時，獲得他們的信任非常重要。確保他們瞭解您的操作方式，並以更小但頻繁的迭代次數提供結果。通過這種方式，他們可以看到您的工作進度，評估中間結果並提供反饋。

通常，客戶傾向於提出自己的解決方案而不是分享他們的問題。由於他們對您的能力知之甚少，因此他們的解決方案經常被誤判，低估或過於雄心勃勃。還記得Henry Ford引用的舊（也可能是虛構的）：

如果我問過人們他們想要什麼，他們會說更快的馬。

有時候邀請他們退後一步討論他們想要解決的問題，而不是順其自然而且默默地實現客戶想要的任何東西。結合他們的領域知識和技術專長，您可能會找到更好的解決方案。

請記住，並非所有人都喜歡對他們的想法提出質疑，而這種策略要求您有一些機智並激發客戶眼中的信心。您還需要離開自己的舒適區並沉浸在自己的業務中，以便能夠理解問題並提出更好的解決方案。如果您正在複雜的行業（如金融或醫療保健）工作，這可能具有挑戰性。但如果你把它拉下來一次，那麼下次客戶會以更開放的心態返回時很可能。

為工作挑選合適的工具

如果你擁有的只是一把錘子，那麼一切看起來都像釘子。

通常只學習單一技術的開發人員會將其應用於遇到的每個問題。不出所料，這種方法導致次優結果。相反，在解決新問題時，請暫停並思考您所使用的工具是否真的適合此類工作。如果您有疑問，請稍微調查一下，然後列出一些可能更好的替代方案。為了更容易，編譯一個問題列表並逐個評估不同的選項。每個評估的問題可能不同，但它可以沿著以下方式進行：

它必須支援哪些平臺或裝置？
什麼是非功能性要求，例如效能或記憶體使用情況？
購買許可證是一種選擇，還是需要免費或開源的東西？
該解決方案是否提供了開箱即用的所有功能，或者您需要自己編寫一些東西嗎？
您是否有任何其他限制，例如公司政策，法律考慮或團隊中缺乏專家？

回答這些問題可以幫助您構建頭腦中的選項，並將其縮小到候選人名單。

Experiment Safely

那麼如果你認識的東西都不適合你的情況並且你想嘗試一些新東西會發生什麼呢？你沒有經歷某事的這一事實並不意味著它是不可能的。這只是意味著您需要考慮一些額外的事情：

你有足夠的時間準備嗎？如果專案的時間表沒有壓力，您可以在開始實施之前儘可能多地學習，並在整個過程中學習其餘部分。或者至少採用“fake it till you make it“接近並說服客戶，你知道你在做什麼。
確定首先需要測試的內容。 Take the “fail fast“在完成實驗之前，”接近並確定您需要評估的關鍵事項。懷疑係統的效能？構建一個最小的原型並執行負載測試。不確定特定庫或與外部服務整合？單獨實現，然後構建其餘部分。

請記住，走這條路仍然對您和您的客戶都有風險，他們需要了解風險和潛在的好處。畢竟，從長遠來看，為期兩週的調查可能會節省數月的工作，這聽起來很不錯。即使實驗失敗，你也只會失去兩週。您對客戶的信任度越高，他們就越可能同意這樣的事情。

建立在巨人的肩膀上

IT人員通常有兩個共同特徵：我們有創造力，我們喜歡我們的工作。這聽起來像是一件好事，但它帶來了一個尷尬的副作用：我們傾向於為之前已經解決的問題提出我們自己的解決方案。因此，每當我們面臨選擇是使用框架，庫或服務還是自己實現它時，我們傾向於選擇後者。這就把我們帶到了重新發明輪子的徒勞之旅。導致這種情況的一些常見誤解是：

自己實施一些東西比學習第三方解決方案更容易。雖然這可能是一個完全正確的理由，但重要的是不要過度簡化手頭的任務。通常情況下，開始時似乎很簡單，但隨著進步而變得更加困難。最終，您最終可能會花費大量時間來處理有人可能為您處理的錯誤和邊緣情況。
這個解決方案比我需要的更多。除非有特殊原因導致這是一件壞事，例如增加生成的工件的大小，增加潛在的漏洞或大大減慢構建速度，這通常不是一件壞事。您最終可能會在以後需要它。另一方面，新增整個庫只使用一個函式可能是一種矯枉過正。
我們可以做得更好。儘管有一些成功的專案以這些詞開頭，但通常情況並非如此。質量第三方解決方案由具有解決此特定問題的經驗和資源的團隊維護。要與他們競爭，您需要能夠進行更多投資。大多數專案既沒有資源也沒有必要這樣做。
程式碼所有權和長期維護將成為一個問題。有些人擔心，如果你使用第三方解決方案，你可能會因為某種原因而在某些時候放棄或無法使用該專案。產品鎖定的風險是真實的，您應該考慮可能的緩解策略。如果它是一個開源專案，您是否有可能自行分叉並維護？或者，如果它是一個專有專案，更換它需要多少錢？基於這些輸入，您可以有意識地決定是否值得冒風險。

通過重新實現來學習

這個故事還有另一面。重新實現一些東西實際上是一種很好的學習方式。雖然為生產專案編寫自己的框架幾乎總是一個壞主意，但將其建立為學習練習可能非常有價值。有什麼更好的方法可以通過解決同樣的問題來熟悉它解決的問題。不要太深入兔子洞，簡化粗略的實施將足以讓你瞭解情況。

當你在這裡時，不要回避窺視類似專案的來源。研究開源專案的程式碼將使您從更多經驗豐富的開發人員的經驗中受益。

研究你的工作方式

不僅在技術方面，而且在方法論方面努力改進。就像正確設計和優化的軟體一樣，完善的工作流程將使您能夠以更少的工作量和壓力工作，同時產生更好的結果。建立一個有效和高效的工作流程並非易事，而且有很多關於這一主題的書籍和材料。但首先，請考慮以下幾個方面進行改進：

團隊和專案管理方法。由於我們大多數人都是團隊合作，因此採用一種可以改善協作併為每個人建立共同工作節奏的流程非常重要。軟體開發中的敏捷運動催生了許多廣泛採用的方法，例如Scrum or Kanban。它們有助於組織整體工作結構，但不包括所有內容。還有其他方法可以幫助您進行估算，確定問題的優先順序，改善溝通等。您需要確定您正在努力解決的領域，並尋找有助於解決困難的最佳實踐。
Personal processes.像管絃樂隊一樣，有效的團隊必須具有相同的節奏，但這並不意味著每個人都必須以相同的方式工作。每個人都有自己的偏好，應該以提高工作效率的方式工作。例如，許多人不喜歡在編碼時被打擾幾個小時，但我個人喜歡短時間工作一兩小時，中斷之間（不太嚴格的版本）pomodoro technique）。我也不喜歡在家工作，以避免與家庭有關的分心，更喜歡在辦公室或咖啡館工作。找出適合您的方法並堅持下去，同時確保您的習慣不會給其他團隊成員帶來麻煩。
工程實踐。許多實踐都存在於技術和方法之間的邊界上，並側重於改進實際的開發過程。例如，test-driven development and behavior-driven development幫助保持程式碼庫的良好結構和測試。Code reviews有助於減少程式碼中的缺陷，並在團隊中傳播知識。Continuous integration and continuous delivery確保更簡單，更安全的部署過程。將這些實踐與其他組織方法結合使用可獲得最佳結果。

請記住，沒有適用於所有人的流程，您需要在自己的環境中進行試用。此外，請確保您完全理解該過程並正確實施。向已經完成整個過程並從他們的經驗中受益的團隊尋求建議。不要忽視有助於您採用流程的軟體和材料工具。獲得真正的看板和現代化的持續交付平臺。採用新工藝需要付出努力，甚至可能導致短期的生產力損失。給它一些時間，然後評估事情是否有所改善。

Remove obstacles

在解決障礙時必須另外說一點。忽視可能看起來不重要但實際上可能對你的工作產生毒害的小滋擾是一個常見的錯誤。您的產品設計師是否坐在單獨的房間或建築物內？這意味著需要花費更多的努力才能過來並進行對話，有些事情將不會被討論。寫新測試難嗎？然後很多東西都不會被測試。

這些東西中沒有一個本身特別危險，但它們往往堆積起來並造成嚴重後果。令人討厭的是，你經常不會注意到它們，直到它已經太晚了。特別是當有更嚴重的危險需要解決時。記住有關的寓言boiling frog and the notion of creeping normality.

保持警惕，並在他們找到你之前在他們的根源上對抗這些事情。

專注於基礎知識

IT是一個極其快節奏的行業。每週都有新工具進入市場。我已經提到了臭名昭著的“JavaScript fatigue“我上一篇文章中的綜合症。許多開發人員都受到壓力，並被迫在每個新專案中重新評估他們的JS技術堆疊，這讓他們瘋狂。事實上，始終站在邊緣可能具有挑戰性，但有一些想法可以使它更容易。

首先，關注基本面。儘管新技術經常出現，但新的基本概念卻很少見。在學習新知識時，請確保您瞭解導致此實現的基本思想。很可能，這些想法也用於其他專案，一旦你遇到類似的東西，你就會更容易掌握它。例如，現代JavaScript UI框架基於元件，一旦您瞭解瞭如何使用React構建面向元件的應用程式，就可以在使用Angular時使用此體驗。以類似的方式，Redux的想法進入Angular，而Angular的反應式狀態管理是作為MobX實現的。

花一些時間熟悉有關軟體開發中常見模式主題的經典書籍，如“Enterprise Integration Patterns“由Gregor Hohpe和Bobby Woolf，著名的”Design Patterns: Elements of Reusable Object-Oriented Software“四人幫或Martin Fowler的不同作品。儘管書中描述的一些內容可能已經過時，但您可以使用它們來了解模式如何演變到今天。

其次，不要急於瞭解那裡的每一件新事物。我知道很有可能會關注Hacker News上出現的每一件新事物，但很多事情只是噪音。相反，請留意社群中已經存在一段時間的事情，並且已經超越了初步討論的炒作。不要屈服FOMO。如果你至少注意一些正在發生的事情，那麼沒有重要的事情會被忽視。

Bonus Tips

我們在本文中已經討論過很多內容，但在結束之前還有一些我想強調的要點。這些小技巧更多地關注你的個人特質而不是專業特徵，但我仍然認為它們對你的工作生活有很大的影響。

Share the knowledge

通常人們認為囤積寶貴的知識會使它們成為不可或缺的。在你的團隊中有這樣的人會讓你接觸到“bus factor“如果這樣的人要離開這個專案，你可能會陷入困境。如果您是這些人中的一員，請考慮除了讓您不可或缺之外，您的專業知識也會使您無法駕馭和“不可取消”。您可能會錯過組織中的其他職業機會，因為您擔任此職位。相反，與同事分享知識，如果可能的話，將您的部分工作委託給他們，並使用此協作在他們的工作之上構建更多的東西。