作為軟體工程師你應該知道的100件事 - Harish

構建軟體：

• (1)過早最佳化是萬惡之源。不要低估這個說法。
• (2) 您很少需要從頭開始構建某些東西。幾乎每個用例都有庫和依賴項。所以握住你的鍵盤，不要重新發明輪子。
• (3) 瞭解問題的範圍是您在找到解決方案之前需要做的第一步。我們錯過了第一步而直接跳入解決方案是很常見的。
• (4) 不要太完美主義者。首先，讓它工作，然後讓它乾淨。軟體交付始終具有最高優先順序。
• (5) 糟糕的程式設計師擔心程式碼。優秀的程式設計師擔心資料結構及其關係。- 萊納斯·託瓦茲
• (6) 使用程式碼註釋來解釋你為什麼要做某事，而不是你在做什麼。不要過度描述並在程式碼註釋中開始寫小說。
• (7) 擁有有意義的錯誤日誌可以節省大量除錯問題的時間。在錯誤訊息中提供所有相關資訊，而不是僅僅說“函式 X 中發生錯誤！”。並且永遠不要記錄任何敏感或個人資訊。
• (8) 100% 行/分支覆蓋率並不意味著您的程式碼沒有錯誤。編寫測試以涵蓋所有功能需求，而不是涵蓋行/分支。
• (9) 如果你正在修復一個bug，寫一個相應的測試用例，這樣以後就不會發生了。錯誤的發生通常是由於錯誤假設，為所有這些錯誤假設編寫測試用例將使應用程式更加健壯。
• (10) 當有人閱讀你的程式碼時，他們不應該需要記住超過 7 件事來理解它。嗯，因為在我們的短期記憶中，我們的大腦一次不能儲存超過 7 件東西。這也是許多程式碼 linter 在函式中警告超過 7 個引數的原因之一。
• (11) 不要僅僅因為有人要求你做某事就以特定的方式做某事，明白為什麼，如果你不相信，那就挑戰現狀。
• (12) 解決問題是每個工程師應該真正擅長的最重要的技能。您的組織存在很多問題。開始解決它們，不是所有的都能解決，甚至20%都解決不了。但是在嘗試解決的過程中，您會學到很多東西。

設計系統：

• (13) 最好的系統設計通常是最簡單的。保持簡單愚蠢！(KISS)
• (14) 設計模式和最佳實踐並不是適用於任何地方的魔法藥水。優秀的工程師知道最佳實踐，但高階工程師知道何時打破最佳實踐。
• (15) 理解抽象。程式碼中不必要的複雜性通常是由於抽象不佳而引入的。
• (16) 一個系統的強弱取決於它的最弱點。聚焦瓶頸。
• (17) 離主要源頭的步驟越多，一切都變得越腐敗。儘量減少中間步驟，這適用於技術和非技術環境。
• (18) 沒有完美的解決方案，只有權衡。列出優點和缺點，以及做出正確權衡的要求。
• (19) 您在專案中引入的每項技術都伴隨著風險。衡量風險並制定減輕風險的計劃。不要在沒有救生衣的情況下跳入大海。
• (20) 避免過早的抽象。解決您現在遇到的問題，僅此而已。當您看到類似的問題出現並且您看到一種模式出現時，那麼您應該考慮圍繞它構建抽象。
• (21) “構建軟體設計有兩種方法：一種方法是簡單到沒有明顯缺陷，另一種方法是複雜到沒有明顯缺陷。第一種方法是困難得多。簡單很難。” - 託尼·霍爾。
• (22) 不要太偏向於語言或框架，如果你喜歡某種語言，就不要一直崇拜它，不要開始到處使用它。如果你討厭它，也不要一直抱怨它。每種語言或框架都是為特定用例設計的。作為工程師，您的工作是為用例選擇正確的工具。
• (23) 如果當你弄清楚某些東西是如何工作的時候，你已經忘記了為什麼部分，那麼程式碼中有很多不必要的抽象和複雜性需要清理。
• (24) 複雜性一旦累積，就很難消除。不要認為您當前的更改引入的一點點複雜性沒什麼大不了的。如果每個開發人員都遵循相同的方法，那麼複雜性會呈指數級累積。
• (25) 如果您決定重寫元件/服務，請務必重新考慮您的決定。閱讀程式碼比編寫程式碼更難，這就是為什麼“我應該重寫它！” 在軟體開發中很常見。
• (26) 不要猶豫挑戰你的高階工程師或架構師提出的設計，有時你的設計會更好。提出有效的令人信服的觀點並客觀地進行比較。只是不要因為過於自信的混蛋而把這帶到極端。
• (27) 大多數情況下，靜態型別語言比動態型別語言要好，儘管靜態型別系統會帶來開銷。這就解釋了為什麼 TypeScript 是最受歡迎的語言之一。

其他提示：

• (28) 最佳化您的程式碼以提高可理解性。無聊冗長的 20 行程式碼總是比巧妙編寫的單行程式碼要好。
• (29) 新手與他們編寫的程式碼建立情感聯絡是很常見的。但在敏捷環境中，需求和程式碼不斷變化。習慣於修改和刪除舊程式碼。
• (30) 為任何問題想出不止一種解決方案。試圖找到多種解決方案會迫使您以不同的方式思考，一旦您有了不同的解決方案，您就可以透過選擇正確的權衡來做出決定。
• (31) 你處理的模組越多，你獲得的領域知識就越多。您擁有的領域知識越多，您需要加入的會議就越多。您加入的會議越多，您編寫的程式碼就越少。透過記錄和共享領域知識來打破鏈條，這樣您就不是唯一的聯絡點。我知道說比實施它容易。
• (32) 當你被某個問題困在某個問題上很長時間沒有任何進展時，重新表述這個問題或向某人解釋這個問題，這在大多數情況下都很有效。為什麼你認為rubber duck除錯如此受歡迎。
• (33) 您不需要了解整個程式碼庫才可以開始處理它。瞭解架構和生命週期，並開始使用您的模組。不要浪費你的時間去試圖理解每個類。
• (34) 程式碼是負債而不是資產。您擁有的程式碼越多，就越需要閱讀、理解、測試和維護。最好的程式碼是沒有程式碼。
• (35) 瞭解如何在 StackOverflow 上釋出問題。您很少需要釋出問題，但這是一項有用的技能，當您在文件和使用者有限的庫/框架上工作時，它會派上用場。
• (36) 如果您在其他模組中偶然發現您沒有處理的問題或錯誤，請通知相應的開發人員，或在 scrum 中提及。請不要說：我不對其他模組負責。
• (37) 您編寫的函式應該具有零/最小的副作用。這使得該功能可以輕鬆且獨立地進行測試。
• (38) 看在上帝的份上，請不要編寫自己的日期格式/解析函式。每種程式語言都有許多流行的日期庫，只需使用它們即可。日期和時區比您想象的要複雜得多。

安全：

• (39) 每個開發人員都應該知道如何編寫安全程式碼。編寫具有糟糕設計/抽象的程式碼是可以的，但編寫具有安全漏洞的程式碼絕對不行。閱讀OWASP Top 10文件以開始使用。
• (40) 當您想快速格式化或驗證某些 JSON/XML/YAML 資料時，不要使用線上格式化程式或驗證程式。特別是如果您正在處理一些機密的生產資料，則對任何線上工具都是嚴格禁止的。請改用任何本地編輯器或命令列工具。不要冒險將您公司的資料洩露到某個隨機站點。（推薦工具：Cyber​​Chef - 下載離線使用）
• (41) 永遠，永遠不要在你的程式碼庫中推送任何敏感資訊。在提交和推送之前，請務必仔細檢查您的程式碼是否包含電子郵件地址、電話號碼、密碼、身份驗證令牌、私鑰等。
• (42) 始終驗證和清理使用者輸入。永遠不要假設或期望使用者會以正確的格式傳送某些輸入。並且在驗證時總是更喜歡白名單而不是黑名單。

拉取請求：

• (43) 猜猜看！您還可以在拉取請求評論中給予讚美。我們在複習的時候總是專注於不好的部分，小小的讚賞可以給你的同行帶來微笑。下次試試。
• (44) 將閱讀拉取請求和理解其他開發人員的評論作為日常實踐，以獲得對功能和編碼標準的不同觀點。
• (45) 程式碼格式和其他標準應該自動化。使用程式碼格式化程式和 linter 構建您的專案開發管道，以便整個程式碼庫保持一致和乾淨。請停止在公關評論中爭論標籤與空格的問題！
• (46) 建立簡短的拉取請求。如果您正在處理多個功能，請將它們分成多個 PR。並且給審稿人足夠的審稿時間，不要在部署前一小時建立PR。

學習：

• (47) 作為一名程式設計師，你應該從根本上享受學習和探索。如果你不喜歡它們，你應該認真考慮其他職業選擇。
• (48) 你不需要學習進入市場的每一種技術。隨時瞭解趨勢，但在需要時學習和使用它們。
• (49) 從一個剛畢業的大學實習生那裡也能學到很多東西。永遠不要將您的學習範圍僅限於擔任更高職位的人。
• (50) 閱讀您使用的不同開源專案的原始碼，以瞭解和學習乾淨的程式碼實踐和程式碼組織。
• (51) 學習某些技術的最好方法是自己構建一個高度簡化的版本。( https://github.com/danistefanovic/build-your-own-x )
• (52) 幾天之內學一門語言很容易。但瞭解其生態系統需要數月或數年的時間。
• (53) 探索不同的程式語言以理解不同的正規化。瞭解不同的程式設計正規化將幫助您為您的用例選擇正確的語言。
• (54) 學習 Git。不只是 git pull 和 git commit，瞭解所有高階概念。無論您使用何種技術，git 都將保持普遍。
• (55) 鑑於大多數開發人員的工作都集中在網路/網路程式設計上。瞭解網路系統中的底層協議很有幫助：HTTP、HTTPS、SSL/TLS、DNS、SMTP、IPv4、IPv6 等。
• (56) 擁有良好的 CSS 專業知識將使您看起來像個巫師！如果您是一名全棧 Web 開發人員，花幾天時間掌握 CSS 將節省“我不知道自己在做什麼”的時間。
• (57) 吸引人的 UI 設計比強大的系統架構更容易給人們留下深刻印象（顯然不是指領域專家）。因此，當您進行概念驗證時，擁有良好的設計技能會派上用場。（只是不要透過在 HTML 中硬編碼所有內容來濫用它）

生產率：

• (58) 建立細粒度的子任務來跟蹤您的進度，尤其是當您正在處理一項巨大的任務時。很難描述檢查某事完成後的幸福感，這反過來又會激勵你保持正軌。
• (59) 不要試圖同時處理多項任務。專注於一項任務並儘量減少上下文切換。上下文切換的成本高於您的預期。
• (60) 改進和自定義您的工作流程（IDE、除錯工具、生產力工具、CI/CD），以便您可以更快地迭代。迭代越快，失敗的速度就越快。你失敗得越快，你學得就越快。
• (61) 花時間在自動化日常任務上。如果你做的事情不止兩次，那就寫一個工具讓它第三次自動化。同時，不要浪費數小時/數天來自動化一項幾乎不需要幾分鐘的簡單任務。找到正確的平衡點！
• (62) 用資料夾和標籤組織您的工作郵件（個人郵件也是如此）。每天組織郵件的小努力將幫助您在需要時快速找到重要的文件或對話。
• (63) <Esc> + :q! + 退出 Vi 編輯器！認真地說，學習基本的 Vi 繫結，即使 Vi 不是您的預設編輯器，您也可以在幾乎所有可用的文字編輯器中使用 Vi 繫結，相信我，在那之後您的工作效率會飆升。
• (64) 文件技能在這個行業中被嚴重低估。學習如何編寫設計文件、更改提案等。開始使用筆記工具來組織和記錄幾乎所有內容 - 媽媽、個人目標、職業目標、隨機想法、書籍摘要，等等。（推薦工具：Notion）
• (65) 在對您的任務進行估算時，請始終保留一些緩衝時間。你永遠不知道在一個未開發的洞穴中會遇到什麼怪物。
• (66) 最好聽器樂或lo-fi 節拍或平靜的聲音，而不是帶歌詞的音樂。就我個人而言，我覺得我在器樂方面更有效率，而且科學也支援它並不奇怪。

自己：

• (67) 立即在辦公桌前調整您的身體姿勢！
• (68) 工作之餘有不同的愛好是好事。僅僅因為您是開發人員，您就不需要 24x7 編碼。
• (69) 善待每一個人！時刻保持冷靜！最重要的是，要謙虛！
• (70) 記得定期休息。不要燒壞自己。
• (71) 投資於良好的工作站設定。鑑於您大部分時間都在辦公桌前度過（尤其是在這些遠端工作日期間）。在高質量的產品上多花幾分錢是值得的。
• (72) 閱讀不同的認知偏差。它不僅會幫助您做出更好的個人決策，還會幫助您做出更好的技術決策。
• (73) 在你的職業生涯早期就開始投資。瞭解複利的力量，相信我，它很神奇。同時不要過度儲蓄，當你不享受現在的時候，儲蓄一切又有什麼意義呢？就是這樣，沒有更多的財務建議。

人際關係：

• (74) 人際交往能力與您的技術技能一樣重要。練習指導、公開演講、領導專案等。開發人員不需要遵循社交無能的刻板印象。
• (75) 不是每個人都會有和你一樣的動機。永遠不要指望別人會因為你這樣做而對任何話題感到興奮和表現出興趣。不同的人對不同的動機做出反應。
• (76) 不要用你的同事（實際上是任何人）不知道的東西來判斷他們。
• (77) 學習如何推銷自己。您可能在很多方面都非常熟練，但如果您沒有在正確的平臺上展示這些技能，那麼沒有人會欣賞它。
• (78) 幫助周圍的人變得更好。教授或分享您學到的東西。對你所學的東西進行教學或寫作會讓你更好地理解它。
• (79) 永遠不要猶豫說“我不知道”。你可能是一個很好的騙子，但我們的大腦在發現某人是否在撒謊或假裝方面是驚人的。更糟糕的是，偽造會導致更高的期望。
• (80) 你的團隊中總會有一位搖滾明星開發者，他幾乎可以解決任何問題。不要被他們的技能嚇倒，而是閱讀他們的拉取請求，進行技術聊天，並定期從他們那裡獲得反饋以提高自己。
• (81) 你很有可能在工作中遇到你的BFF。不要向同事敞開心扉。（請自行決定是否採納此建議）

溝通：

• (82) 一直在聽，我再說一遍：聽！
• (83) 開會沒有什麼要說的也沒關係，不要亂說話，浪費別人的時間。
• (84) 不要只用 Hi/Hello/Good Morning! 給別人 IM，然後等待他們的回覆。給他們你為什麼 ping 的原因。沒有人只想聽到你的問候或祝福。https://www.nohello.com/
• (85) 在解釋您的設計時，儘可能使用圖表。一張圖片勝過千言萬語。它也可用於記錄。（推薦工具：draw.io）
• (86) 在向某人解釋某些設計或概念時，減少行話的使用。並非每個人都熟悉所有技術術語。以適當的平衡使用它們。
• (87) 提出一個你認為微不足道或愚蠢的問題，你不應該感到羞恥。
• (88) 如果您想在幾分鐘內完成工作，請致電。如果你想在幾個小時內完成工作，那麼 IM。如果你永遠不想完成工作，那麼電子郵件（人們在 2021 年仍然使用電子郵件嗎？）。
• (89) 當你就某個問題向某人尋求幫助時，不要只是四處說“嘿 X 不起作用，你能幫幫我嗎？”，而是說“嘿，當我執行 X 時，我正面臨錯誤Y，我已經研究並嘗試瞭解決方案 Z，但它似乎也不起作用，你能幫我解決這個問題嗎？”。在接受別人的幫助之前做你的研究，請不要因為你的程式碼中的一些錯字而浪費別人的時間，認真！
• (90) 不要成為腳踏車棚效應的犧牲品。在會議或討論中，將複雜/關鍵專案置於瑣碎專案之上。

職業：

• (91) 做自己不喜歡的事情是可以的，但做自己討厭的事情是不可接受的。
• (92) 在職業生涯早期，將學習和機會置於薪酬、福利等之上。在學習率高的活動或工作上投入更多時間。學習化合物，你必須儘早開始才能獲得它的好處。
• (93) 你在工作中的純粹動機應該是為團隊和專案增加價值，而不是為了給任何人留下更高的薪水或升職。如果處理好前者，後者只是副產品。
• (94) 花時間在簡歷上並始終保持最新狀態。建議擁有一個描述您的專案和經驗的作品集網站。
• (95) 你解決的問題越是模糊不清，你的角色就越高。適應不確定性和模糊性。
• (96) 每六個月問自己這些問題：
  
  • 我是否正在學習新技能並拓寬我的專業領域？
  • 我是否在組織中產生影響？
  • 我的技能和經驗是否足夠好？
  
  如果你的答案都是否定的，那麼你必須考慮更換公司或團隊。如果你已經在現在的公司工作了 2-3 年以上，並且你的答案都是肯定的，那麼你仍然應該考慮換公司，或者至少對它持開放態度。除非你一直在尋找，否則你永遠不會知道你錯過了什麼。
• (97) 如果仔細觀察，程式設計與寫作非常相似。程式語言類似於人類語言，程式設計師類似於作家/詩人。任何人都可以成為作家，但要成為一名優秀的作家需要付出很多努力和時間。
• (98) 定期與您的經理進行一對一交流並尋求反饋。不要等到您的年度審查才突然出現驚喜。
• (99) 如果你的經理不對你的失敗負責，並沒有責怪你，那麼你在他們手下工作是在冒著個人和職業發展的風險。
• (100) 年的經驗只是一個數字。有時您會發現初級工程師比高階工程師更熟練。不要誤會我的意思，經驗教給你的不僅僅是技能，所以是的，工作經驗很重要，但這不是唯一的因素。