作者 |?Allen Helton

責編 | 唐小引

出品 | CSDN（ID：CSDNnews）

以下為譯文：

今天是我 30 歲生日。

雖然對我 20 多年來的生活已經感到很滿意，但是我更期待未來十年可能發生的變化。

為了慶祝這個重要的里程碑，我想和大家分享我的職業生涯中總結的軟件開發相關的 30 條有價值的經驗。

1. 抓住每一個學習新東西的機會

我不確定是否還有一個行業的發展速度能夠比軟件行業更快。新的方法和模式不斷涌現，管理服務每天也都在改進。你要抓住每一個學習新東西的機會，不斷豐富自己的技能棧。

2. 意見分歧成就創新

要和那些與你意見不同的人呆在一起。如果你的團隊都贊同你的意見，你的思想會變得越發狹隘。別人對你的質疑不僅可以幫助你完善自己的方案，還可以激發你想出創新性的觀點。

3. 不要帶有個人色彩

如果你的代碼反復修改最終測試五次都沒通過或者在最終的 sprint 評審中你的方案不被認可，你會怎樣？我們都是團隊的一員，有著相同的目標: 我們要盡自己所能開發出最棒的軟件。

4. 自動化

每次你讓一個人完成一項任務，都有可能出錯。但是機器不會忘記清單上的事項。機器會以同樣的方式一遍又一遍地執行同樣的任務。自動化從身份驗證 測試到 部署策略的所有工作。

5. 擁抱失敗

你永遠不會比現在知道的更少。如果你嘗試構建一個新的軟件，但是失敗得很慘，那也沒關系！下一次你嘗試的時候，你就會知道什么是不該做的了。我們可以從失敗中積累經驗，提高技能。

6. 用戶體驗就是一切

客戶不會因為后端編寫的好而購買你的軟件，用戶體驗才是你產品的賣點。他們之所以會買它，認可它，是因為它以一種直觀和有效的方式解決了他們的問題。

7. 小步快跑

在構建軟件時，你的目標應該是讓某些東西能夠正常工作并盡可能快的展現給用戶。一般來說，人們很難憑空給出所有的想法。但是他們可以告訴你如何把你所擁有的變成他們所需要的解決方案。

8. 不要循規蹈矩

不要認為 “我們這樣做是因為我們總是這樣做”是理所當然的。做某事是因為就該這么做，而不是因為這么做自己最熟。如果你從不嘗試去做不同的事情，你就很難改變。

9. 使用單一責任原則

汽車開起來真的很好。但是如果你讓一輛車飛起來，你就會犧牲它的一些駕駛能力。它也許可以同時做到這兩點，但它永遠不可能將任何一點做的很棒。你的代碼也是這樣的，保持專注，做好一件事。

10. 代碼調試被高估了

如果你遵循單一責任原則，那么你的代碼應該只關注某一個功能。如果它的功能非常聚焦，出現問題也會非常容易定位。沒有比控制臺日志和一些單元測試更快定位問題的了。

前面已經給出了 10 條建議，下面的建議可能會有些爭議。

11. 編程語言的選擇很重要

當開始一個新項目時，想想你要解決的問題。Python 適合大數據處理。JavaScript 適合普通的網頁開發。世界上有這么多種語言都有其存在的原因，你要選擇最能解決問題的語言。

12. 實踐出真知

如果你想學習一些新的東西，無論是編程語言，新的架構模式，還是技術棧，動手實踐將極大地提高你的理解能力。在你實踐之前，理論只是理論。此外，你還可以與他人分享你學到的東西。

13. 你永遠不會知道一切

直到進入開發階段，你可能才發現更好的方法。你可以在開發階段再對其進行改進。技術變化飛快，昨天能夠解決問題的最佳方法可能今天已經不再是最佳選項。

14. 暫時用不到就不要寫

這聽起來可能顯而易見，但是并非所有人都可以做得到。誰要求你要加那個配置的？沒有人啊？那就硬編碼。如果你暫時不需要就先不要去寫。先完成最基本功能然后再去迭代。

15. 評審和回顧很重要

在敏捷開發中，你在 sprint 結束時要進行 sprint 評審和回顧。如果你的回顧工作做得好, 你和你的團隊的效率就會提高。你將會和他們保持一致，能夠更快地行動，并且擁有無與倫比的團隊友誼。

16. 80 / 20

當你發布你的最終產品時，你可能會失望地發現你的消費者并沒有用到你開發的所有功能。事實上，他們會找到一小部分功能(大約 20%) 使用(80%的時間)。只有 20% 的時間，使用其他 80% 的功能。因此，請把你的注意力放在優化解決業務問題的功能上。

17. 優秀的架構師能為復雜問題提供復雜的解決方案

有些問題比其他問題更難解決。如果你有一個好的軟件架構師，他們會設計一個復雜的解決方案來解決這個復雜的問題。

18. 但是偉大的架構師可以為復雜的問題給出簡單的解決方案

一個有才華的人才能降低復雜解決方案的復雜性，并將其轉化為每個人都可以使用的東西。他們把問題的主要部分放在自己身上，并提出了一個簡單的解決方案，這個方案掩蓋了困難任務。例如，一位偉大的架構師設計了亞馬遜的“一鍵購買”按鈕。他們完全可以將所有復雜性隱藏到一個按鈕的背后。

19. 1x，10x，100x

如果你發現正在編寫的代碼存在問題，請立即修復它，此時花費的代價最小。但是如果你讓 QA 去查找 bug 并上報，這將需要 10 倍的代價。你需要分析師的努力，再加上你再次熟悉它并解決它的努力， 如果 bug 進入這個階段，需要 100 倍的努力才能修復。你可以讓用戶進行上報問題，然后使用任何必須的流程來修復問題，然后進行測試和部署。

20. 故事和隱喻是關鍵

如果你想以最簡單的方式解釋你的軟件是如何工作的，那就講一個故事。人們通過將自己熟悉的事物聯系起來，與故事和隱喻產生聯系。他們會理解你想要傳達的信息，并且能夠將這些信息傳達給其他人。

21. 一個健壯的、文檔詳盡的 API 物超所值

現在，軟件是持續集成的。我怎樣才能把這項服務與那項服務聯系起來？答案就是通過 APIs。如果你構建的 API 具有豐富的功能集并且有詳細的文檔說明，那就太棒了。開放 APIs 是當今的標準，你應該嘗試構建它們。

22. 面試官更關心你的問題解決能力，而不是你的編程理論知識

當我面試某人的時候，我會回答一些理論上的問題，但是我大部分時間都在試圖了解你的大腦是如何工作的。如果編程是你的日常工作，你會花一整天的時間想出問題的解決方案ーー而不是寫什么多態性。

23. 80 / 20（再次出現）

大約花費 20% 的時間完成 80% 的工作，剩下的 80% 的時間完成最后的 20% 的工作。想象一下正在建造的房子。在第一個月，你會看到一塊從草地到地基、腳手架和房間的土地。從那時起，事情就像蝸牛一樣慢了下來。軟件也是一樣。大部分的時間將花費在不那么重要的階段。

24. 之前做過

開發人員開玩笑說，他們從來沒有寫過一行原創代碼。老實說，這可能是真的。模式的存在是有原因的。你軟件獨一無二的原因是解決業務問題的方式。不要因為標新立異而提出一個新的模式。可以嘗試使用一些行之有效的方法，把更多精力放在提高用戶體驗上來。

25. 良師益友至關重要

無論你是剛剛開始自己的職業生涯，還是已經工作了 4、5 年的老手。肯定有人做過你要做的事情，你可以尋求他們的幫助。通常情況下，他們很樂意幫忙。

26. 一切都在代碼中

計算機會完全按照你說的去做。他們沒有自己的思想。你的代碼不能工作，是因為你寫的就那樣。出現問題代碼中總會有答案，需要你自己去尋找。

27. 軟件是一個環

當時我并不在場，但顯然云開發幾乎和大型機開發一模一樣。現在的工具更好了。方法論也是循環的。我們曾經熱衷于瀑布式開發，然后進入了敏捷開發，但是 瀑布式開發似乎又卷土重來了。也許今后 10 年將帶給我們一個改進的工具包和過程，就像我們 20 年前所做的那樣。

28. 存儲空間被淘汰，計算機開始流行

過去，所有的成本優化策略都圍繞著節省磁盤空間而展開。使用所有的計算機，你可以占用盡可能少的存儲空間。但是今天，情況發生了翻天覆地的變化。存儲成本幾乎為零，計算價格也在上漲。花時間優化代碼的處理 ，盡可能地存儲所有東西。

29. 數據之美

大數據是非常重要的。它為機器學習提供動力，為我們的工作過程提供參考，并闡明趨勢。現在數據存儲如此廉價，沒有理由不將我們想要存的都存儲起來。人們喜歡圖表、圖形和趨勢。用數據為決策者提供參考。

30. 最好的工具是你的團隊

如果你想要進行創新，建立一個強大的團隊。一個相互信任的團隊可以完成工作，相互挑戰，在個人層面上建立聯系。建立一種致力于相互了解的文化將是你是否成功的最終決定因素。作為一個領導者，把你的努力投入到你的團隊中。

總結

大概就是以上這些內容。

到目前為止，我在軟件行業經歷了職業生涯的很多巨變，我很高興看到自己的觀點在未來 10 年內會發生怎樣的變化。

你還有其他的經驗教訓想要分享嗎? 歡迎留言評論。

英文：Software Solutions and Technologies to Counter the Coronavirus Pandemic30 Things I Learned About Software Before I Turned 30

鏈接：https://medium.com/better-programming/30-things-i-learned-about-software-before-i-turned-30-f7c90c3068d5

作者：Allen Helton

譯者：明明如月，知名互聯網公司 Java 高級開發工程師，CSDN 博客專家。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的30 岁程序员：关于编程，我终于想清楚这 30 件事了！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。