優秀的程序員都有的十條特征，你中了幾條？
原創
最后编辑：李晓琳 于 2020-10-15 15:25:38
1336次查看
本篇目錄
之前的文章給大家分享的都是DevOps、自動化測試、新技術趨勢等前沿知識和技術，實際上目前能完全掌握這些新技術的開發、測試人員都是少數，畢竟大多是人還是專注于自身工作，用于提升、學習新技術的時間較少，而很多新趨勢也並未成熟應用到行業。因此，不必爲此焦慮，極速變化中總有一些不變，堅守那些基礎的不變的能力，並以積極的心態擁抱變化，才是持續而穩定的成長路徑。本期分享一些不依賴于新技術、但作爲程序員都可遵循的原則，請根據自身情況取舍、實施。
目前主流項目管理軟件中，往往內置任務分解和更新功能。如在 禅道項目管理軟件內，開發負責人進行系統分析，拆解成相對獨立的任務並指派給個人，而開發人員可以在自己的頁面清晰地看到任務數量及剩余工時，完成後進度將同步更新，這種持續的正向反饋會帶來極大的成就感。
如果代碼的形式不適合進行簡易擴展，那麽它將是開發人員的地獄。因此，爲了避免出現這種情況，需要始終在代碼中尋找可以改進的地方。如果你自己做不到，那就向團隊尋求幫助。
敲代碼前先手寫代碼
在實際將解決方案轉換爲代碼之前，要養成手寫算法/僞代碼的習慣。手寫還可以幫助你在將代碼移至計算機之前規劃代碼。寫出需要的函數和類、以及它們如何交互，可以在之後節省大量時間。盡管要比直接敲代碼更耗時間，但這種規範會讓你打下牢固的基礎，實現之後更穩健的成長。
善用搜索引擎和論壇
並不是你遇到的所有問題都能自己找出明顯的解決方案。所以記得善用搜索引擎，可能會有數百萬的開發人員遇到過與您相同的問題，並且已經找到解決方案。所以，不要花過多時間獨自尋求解決方案。很多開發人員低估了搜索作爲程序員工作中一部分的重要性。
搜索引擎方面Google是不错的选择，论坛则推荐Stack Overflow。有时候工作需要的更多是知道如何获取知识和解决方案，而非实际编程。
互相合作可以遵循敏捷開發的結對編程：兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。二人經常互換角色，工作交替進行。在結對編程中，審查的角色需同時考慮工作的戰略性方向，提出改進的意見或找出將來可能出現的問題以便處理。
雖然不能有完全的人力成本全面推行結對編程，但尋求他人建議時，看似無法改變的錯誤或無法學習的話題，可以通過新思維或對這個話題的新的解釋來迅速緩解。所以不要在筒倉裏編程，要經常討論並推進。當你重新開始自己編寫代碼時，接觸到多種想法和思維方式將有助于你解決問題。
而另一方面，編程語言有一個廣泛的範例，存在著相似的族譜。所以，如果你知道一種和另一種語言相似的語言，那麽學會這種語言就很容易。
例如，Python和Ruby幾乎是同一種編程語言。二者雖在文化上存在著巨大的差異，但除此之外，它們幾乎完全相同，所以當你知道另一個的時候學習一個是非常容易的。因此，不要將自己與任何技術或編程語言綁定在一起，而只將它們視爲幫助自己解決手頭問題的工具。
編程是一個長期的過程，在這個過程中，您將一直面臨新的障礙。養成記錄錯誤的習慣，這樣你以後就不會犯同樣的錯誤了，這表明你作爲一個開發人員在不斷地學習和提升自己。
做好以上十點，相信你能夠從合格的程序員，變爲優秀的程序員，那麽對于新技術和新知識的擁抱，就是一件水到渠成的事。“你的職責是平整土地，而非焦慮時光。你做三四月的事，在八九月自有答案。”
參考文獻：
Nitish Deshpande .10Tips to Become a Software Engineer[OL].(2020-05-27)
https://dzone.com/articles/10-tips-to-become-a-better-software-engineer
及時更新任務清單
當要實現一個功能點時，最好將較大的任務分割成較小且更清晰的任務，這些任務是相對獨立的邏輯單元，可以單獨進行測試。列一張這樣可完成的較小任務的清單，並在完成之後勾選、更新。這樣會形成自我激勵，並促使自己去不斷完成更多的小任務。目前主流項目管理軟件中，往往內置任務分解和更新功能。如在 禅道項目管理軟件內，開發負責人進行系統分析，拆解成相對獨立的任務並指派給個人，而開發人員可以在自己的頁面清晰地看到任務數量及剩余工時，完成後進度將同步更新，這種持續的正向反饋會帶來極大的成就感。
遵循適當的版本控制
通过创建开发、特性、主分支和设置适当的访问权限来遵循適當的版本控制策略。无论何时开始编码，都要确保先获取代码库的最新版本后再开始。在逻辑部分或功能完成后继续提交/推送代码，不要让代码库长时间处于未提交状态。在将代码提交给版本控制之前，始终在本地机器上测试代码。无论变更多么细微，在输入代码时都要检查修改文件的差异，这将帮助追溯意料之外的变更，并有效避免不必要的Bug。持續重構
代碼重構是在不改變源代碼的功能行爲的情況下改變源代碼的過程，目的是通過提高代碼的可擴展性、降低代碼的複雜度，以此來提高代碼的可讀性和可維護性。未能執行重構可能會導致技術債務的累積，開發人員會在之後的時間裏對這些技術債務付出代價。要知道，沒有任何一個開發人員願意處于這種境況中，他們常常拒絕接觸已經工作了很長時間的代碼。當需要增強現有特性時，問題就出現了。如果代碼的形式不適合進行簡易擴展，那麽它將是開發人員的地獄。因此，爲了避免出現這種情況，需要始終在代碼中尋找可以改進的地方。如果你自己做不到，那就向團隊尋求幫助。
敲代碼前先手寫代碼
在實際將解決方案轉換爲代碼之前，要養成手寫算法/僞代碼的習慣。手寫還可以幫助你在將代碼移至計算機之前規劃代碼。寫出需要的函數和類、以及它們如何交互，可以在之後節省大量時間。盡管要比直接敲代碼更耗時間，但這種規範會讓你打下牢固的基礎，實現之後更穩健的成長。給自己的代碼進行注釋
在自己寫的代碼中留下注釋，解釋爲什麽要做出某些選擇。這將幫助到之後拿到這段代碼的人，因爲不是每個人都清楚你爲什麽以這種特定的方式編寫代碼。不需要對非常明顯的編碼行爲進行注釋，因爲這無關緊要。正確的代碼注釋將提高代碼庫的可維護性。
善用搜索引擎和論壇
並不是你遇到的所有問題都能自己找出明顯的解決方案。所以記得善用搜索引擎，可能會有數百萬的開發人員遇到過與您相同的問題，並且已經找到解決方案。所以，不要花過多時間獨自尋求解決方案。很多開發人員低估了搜索作爲程序員工作中一部分的重要性。搜索引擎方面Google是不错的选择，论坛则推荐Stack Overflow。有时候工作需要的更多是知道如何获取知识和解决方案，而非实际编程。
尋求他人幫助
編程實際上是一種社交活動。我的程序員朋友都會在某些方面有突出優勢，所以每當我有問題的時候，都知道該請教其中的哪一個。當他們有問題的時候，我也會幫助他們。這真的是完成任務的絕佳方法。互相合作可以遵循敏捷開發的結對編程：兩個程序員在一個計算機上共同工作。一個人輸入代碼，而另一個人審查他輸入的每一行代碼。二人經常互換角色，工作交替進行。在結對編程中，審查的角色需同時考慮工作的戰略性方向，提出改進的意見或找出將來可能出現的問題以便處理。
雖然不能有完全的人力成本全面推行結對編程，但尋求他人建議時，看似無法改變的錯誤或無法學習的話題，可以通過新思維或對這個話題的新的解釋來迅速緩解。所以不要在筒倉裏編程，要經常討論並推進。當你重新開始自己編寫代碼時，接觸到多種想法和思維方式將有助于你解決問題。
記住技術永遠在變化
我將自己的身份首先視爲程序員，第二身份才是編程語言專家，因爲總有一天我們現在使用的所有編程語言將不再被使用。比如我從80年代開始使用的某些形式的程序集代碼，這些代碼現在大部分都已經不存在了。這將發生在任何技術上，無論其自身好壞。總會有一天，沒有人會再使用Java。而另一方面，編程語言有一個廣泛的範例，存在著相似的族譜。所以，如果你知道一種和另一種語言相似的語言，那麽學會這種語言就很容易。
例如，Python和Ruby幾乎是同一種編程語言。二者雖在文化上存在著巨大的差異，但除此之外，它們幾乎完全相同，所以當你知道另一個的時候學習一個是非常容易的。因此，不要將自己與任何技術或編程語言綁定在一起，而只將它們視爲幫助自己解決手頭問題的工具。
正視並接受Bug的存在
程序員經常看到在自己開發的功能中報告了很多Bug，這意味著大多數時候，任務是失敗的。但如果我們所有的程序都是功能完整的，並且沒有任何Bug，那麽編程就完全不成其爲編程了。事實上，我們正處于編程過程中，這意味著我們要麽還缺乏很多功能，要麽軟件有Bug。所以，在某些方面，你作爲一個程序員總是失敗的，因爲總是存在Bug。這可能很奇怪，但你確實需要對不完美和不工作的事情保持良好的心態，因爲這正是我們的工作。編程是一個長期的過程，在這個過程中，您將一直面臨新的障礙。養成記錄錯誤的習慣，這樣你以後就不會犯同樣的錯誤了，這表明你作爲一個開發人員在不斷地學習和提升自己。
讓重複性任務自動化
經常會有一些任務是需要重複做的。例如運行一組命令或執行某些活動，這些活動涉及在多個應用程序和屏幕之間切換，這會占用您的大部分時間。建議將這些耗時的日常活動轉換爲通過腳本或簡單程序（可以通過單擊或命令運行）以某種方式自動化。如針對重複的單元、接口等重複的測試執行，可以進行自動化測試。這將節省你的時間，讓你可以專注于更有意義的任務，而不必擔心日常繁瑣的任務。做好以上十點，相信你能夠從合格的程序員，變爲優秀的程序員，那麽對于新技術和新知識的擁抱，就是一件水到渠成的事。“你的職責是平整土地，而非焦慮時光。你做三四月的事，在八九月自有答案。”
參考文獻：
Nitish Deshpande .10Tips to Become a Software Engineer[OL].(2020-05-27)
https://dzone.com/articles/10-tips-to-become-a-better-software-engineer
DevOps幹貨
