本文轉載自公眾號“讀芯術”(ID：AI_Discovery)

我從事自由網絡的開發工作已經有將近20年的時間，回首過往的工作經歷，我比較大的感受就是：這四個習慣，要是能早點兒養成就好了。

[[330478]]

深層自動化

你一直擅長運營單人商店，并且能將很多細節和流程牢記在心。該客戶的部署有15個步驟，每月執行一次，每次運行最多花費5分鐘。

你要與同事討論該問題，明確需構建的所有功能和需修復的所有故障，有一個問題將反復出現：自動化僅花費你幾分鐘的時間且每隔一定時間段執行一次，這種操作真的值得嗎?

只需要5分鐘的時間即可手動執行該過程，頻率為每月/次。而將該手工過程自動化需要花費3個小時。自動化操作也許會將運行進程所需時間間從5分鐘減少到3分鐘。

這里的關鍵在于：由于流程實現了自動化，運行此流程的人員可能不再是你本人。

月收益不僅僅是2分鐘。你的5分鐘可以精簡為0分鐘，因為流程自動化了這三分鐘的事可能會交給別人來做。事實上，其他的任何人都可以執行此任務。關鍵時刻，團隊中有3分鐘空閑時間的任何成員都可以去運行該自動化流程。

不必親力親為。如果實現了深層次自動化，其他成員可以分擔此項任務以便讓專注。

廣泛測試

由于擅長記憶所有細節，你知道構建新功能時需調整的每個小開關和切換按鈕，確保沒有通過添加新代碼損害其他功能。

然而，你始終確信沒有遺忘什么嗎?要是其他人添加了代碼呢?他們是否需要了解各個開關和切換鍵?每當別人整合新代碼時，你可能還是會忐忑不安。

測試是增強自信的過程——即確信自己添加的新代碼不會破壞任何舊代碼;讓開發者有信心部署好代碼而無需午夜醒來并焦慮思考：“天哪，如果用戶在刪除付款方式后(而非事前)單擊該按鈕，他們將獲得500元。我需要馬上還原程序。”

編寫測試代碼確實有點耗時，其效果可能不如執行代碼。但是，編寫測試代碼能讓頭腦保持清醒。測試代碼的編寫過程可以讓開發者重點關注代碼的性能要求。然后，再去執行具體任務。

測試為開發者提供空間——讓開發者大腦有足夠的空間專注于代碼重構及改進，因為開發者不再需要忐忑追蹤所有開關和切換鍵以維護重構過程。測試會幫助開發者完成追蹤任務，你有了足夠的空間去重構代碼。

除此之外，深層自動化與廣泛測試的組合是重要加分項：深層自動化+廣泛測試 =深層自動化測試。使用自動化測試，任何人都可以貢獻自己的代碼并運行測試。你可以充滿自信地進行構建、調整并進行演示和交付。

傳授知識

程序員會遇到很多具體的編碼問題，并在網絡上尋找處理方案。這樣不一定能找到解決之道。你可以在一些第三方文檔中閑逛，調試不同的設置，創造性地思考問題，然后問題就得到解決了。

解決了自己的問題可不算結束。想想那些即將面對你剛剛經歷過的問題的程序員們，花時間和精力解決了這個小問題后，請不要浪費專業知識。

筆者建議向他人傳授所學知識。KentC.Dodds稱之為“增加價值影響”，SWYX稱之為“公共學習”。無論是撰寫教程文章、博客文章，還是堆棧溢出問題的答案，程序員都需要明白這點：讓他人受益，不要掠奪知識。

你自己也會從中受益。準備傳授知識時，無論是實際的演示文稿，文章還是主題帖子，你都會比初次學習時更好地掌握解決方案。你將更加深入地理解問題所在，優化初始解決方案并了解如何與初學者交流深層次、低層次概念。

你將發現并為各種難題設計出色的解決方案。這就是為客戶服務的工作內容，這也是在特定代碼段中的任務。花些時間“增加你的價值影響力”——用授人以漁的方式分享自己的發現。你能幫助別人成為專家。同時你自己也將成為專家中的一員。

讓他人參與

回想大學校園做團隊項目時，我們都知道自己寫的代碼水平很低，甚至不清楚自己在做什么，調試實際上只是在攪動代碼行以保護某些內容不受損。

作為一名獨立的自由職業者，你可以看到代碼的完整內容。而且很大程度上，所有的代碼也許只被你一人瀏覽過。這或許會讓你感到害怕和不安。

這種恐懼和危機感阻礙了你向他人求助并組建團隊的腳步。原因在于你永遠不會覺得自己的代碼已經接近完美，能讓其他程序員印象深刻。

恐懼和不安會限制程序員的發展。嚴重情況下，你與他人合作學習的機會、你脫離獨立項目并為團隊案例盡心盡力的機會、你成長的機會等，都會受到影響。

筆者建議程序員養成讓他人積極參與的習慣。請其他程序員查看一下你的代碼，接受并希望那些審閱者會注意到你代碼糟糕透頂的事實。悅納自己的不足，然后從中成長。順便說一句，他人的代碼可能也有糟糕的部分。

另外，當程序員開始踐行此操作時，會自言自語：“特里，我想給你演示我已構建的這個模塊，但是再給我最多3天的時間，我需要清理一下數據。”

無需這樣。所有代碼都存在改進空間，永遠不會完美地完成檢查任務。程序員總是想要擁有更多的時間來準備。只需擁有代碼現在的樣子即可，然后，請他人來參與審查吧。

更早更頻繁地接納他人的意見，你的代碼才能逐漸得到完善。在編碼時，程序員會對自身代碼有一定預期，明白是哪些編碼習慣或不足讓審閱者感到尷尬或給予差評。

代碼永遠不會完美，不要等到代碼完美無缺的那一天，才尋求他人的觀點來閱覽代碼并給出反饋，那一天永遠不會到來。

編程的道路算得上是蜿蜒曲折，但如果能做到以上四點，我不敢說你會走得更快，但一定會更清醒明確。