忠告1

代碼不僅僅是用來運行的。代碼也是跨團隊交流的一種方式，是向他人描述問題解決方案的一種方式。良好的代碼可讀性不是那么容易做到的，但它是編寫代碼的基本部分。這涉及到清晰地分解代碼，選擇恰當的自解釋變量名，插入注釋來描述任何隱含的內容。

忠告2

不要渴望你的 pull request 能為你贏得多少名聲，而要多關注你的 pull request 能為你的用戶和社區做些什么。要不惜一切代價避免“功利性的貢獻”。如果你提交的功能對產品的意圖沒有明顯的幫助，就不要添加任何功能。

忠告3

品味也適用于代碼。品味是一種受約束的滿足過程，這種滿足是由對簡單的渴望所約束的。保持對簡單性的偏愛。

忠告4

要學會說“不”——僅僅因為有人要求做某個特性，并不意味著你就應該這么做。每個特性都有一個超出初始實現的成本：維護成本、文檔成本和用戶的認知成本。我們要時刻提醒自己：我們真的應該這樣做嗎? 通常，答案是否定的。

忠告5

當你準備答應實現一個新用例時，請記住，僅從字面意思理解實現用戶的需求通常不是最佳選擇。用戶關注的僅僅是他們自己的特定用例，你必須從整個項目的角度出發，兼顧整體性和原則性。通常，正確的做法是擴展現有的特性。

忠告6

不斷進行持續集成，并以完整的單元測試覆蓋為目標。確保你處在一個可以自信地編寫代碼的環境中；如果不是這樣，那么你需要從構建正確的基礎設施開始。

忠告7

事先不做好計劃也是可以的。嘗試一下，看看結果如何。盡早恢復錯誤的選擇。當然前提是確保你的環境可以達到這樣的目的。

忠告8

好的軟件使困難的事情變得簡單。問題一開始看起來很困難，并不意味著解決方案必須很復雜或者很難操作。工程師經常使用反射式的解決方案，這會在有更簡單解決方案 (雖然可能不太明顯) 的情況下，帶來不必要的復雜性 (我們可以使用 ML! 我們可以嘗試構建一個應用程序! 我們可以使用區塊鏈!)。在編寫任何代碼之前，請確保你所選擇的解決方案不能變得更簡單。做任何事情都要有本源思維。

忠告9

避免隱式規則。應該明確說明你自己開發的隱式規則，并與他人共享。當你發現自己提出了一個重復的、準算法的工作流時，你應該設法將它標準化到一個文檔中，以便其他團隊成員能夠從此經驗中獲益。此外，你應該在軟件中嘗試自動化任何可以自動化的工作流 (例如，正確性檢查)。

忠告10

在設計過程中應該考慮你選擇方案的總體影響，而不僅僅是你希望關注的那些方面——比如收入或成長性。除了你正在監視的度量之外，你的軟件對其用戶、對世界的總體影響是什么? 是否存在超過價值主張的不良副作用? 在保持軟件可用性的同時，你能做些什么來解決這些問題呢?

IT技術分享社區

個人博客網站：https://programmerblog.xyz

文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠程辦公：常用的遠程協助軟件，你都知道嗎？51單片機程序下載、ISP及串口基礎知識硬件：斷路器、接觸器、繼電器基礎知識

總結

以上是生活随笔為你收集整理的程序人生：给年轻程序员关于开发过程的10条忠告的全部內容，希望文章能夠幫你解決所遇到的問題。

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