高效程序員的 7 項技能 [復制鏈接]

2019-9-26 09:51
水刀八木 閱讀:245 評論:0 贊:0
Tag:  程序員

受 TechLead 高效程序員的七項技能啟發,我們團隊想就這個話題發表自己的看法。

下面是我們總結的高效程序員的七項技能。

1. 學會如何閱讀他人的代碼



除了你,所有人寫的代碼都很糟糕。

這就是為什么能夠追蹤他人的代碼是一項具有多重好處的偉大技能。

不管之前工程師的代碼有多么混亂或欠考慮,你仍然需要仔細閱讀它。畢竟,這是你的工作。甚至一年前的那個工程師也是你。

這項技能對你有兩個好處。第一,能閱讀別人的代碼讓你有一個很好的機會去了解什么是糟糕的設計。當你在瀏覽別人的代碼時,你會了解到什么有用什么沒用。更重要的是,你還會了解到,對其他工程師來說,哪種類型的代碼比較容易理解哪種代碼比較難理解。

在閱讀其他人的代碼時,你可以盡情地地抱怨。這樣,其他工程師就會明白你有多么優秀。

務必要提一下可維護代碼和良好注釋的重要性。這可以進一步顯示出你在編程領域的優勢。

你的代碼應該設計得非常好,以至于不需要任何文檔。事實上,如果你是一名優秀的程序員,就不應該編寫任何代碼的文檔。這只是浪費時間,你需要把時間花在編程和會議上。

能閱讀他人編寫的混亂代碼也使得在需要時更新變得更容易。這有時意味著更新你不了解的代碼。例如,我們曾經追蹤一個腳本,從 Powershell 到 Python 再到 Perl 。雖然我們在 Perl 方面的經驗有限,但我們仍然有足夠的上下文來了解發生了什么,并做出所需的更改。

這源于我們很好地理解了所有代碼并且能夠閱讀 Perl 腳本。

閱讀別人的代碼會提升你的價值,因為你可以追蹤那些因為過于復雜而讓他人感到困惑的系統。

2. 能夠感知糟糕的項目

有很多技能需要花時間去學習。我們相信有一項技能是有必要了解的,那就是知道哪些項目不值得做,哪些項目必然失敗。

大公司總是有很多正在進行中的項目,而有些項目可能永遠無法完成或產生影響。有一些項目可能沒有任何商業意義(至少對你來說沒有),還有一些項目管理不善。這并不是說,當你不贊成某個項目的時候,你就應該打斷別人的想法。不過,如果涉眾不能適當地解釋他們將利用最終結果做什么,那么這個項目可能不值得做。

此外,有些項目可能過于關注技術而不是解決方案,因此從一開始就很清楚它不會帶來太大的影響。對于這項技能,你需要在做過很多糟糕的項目之后,才能懂得什么樣的項目是糟糕項目。所以,不要過早地花太多時間去辨別每個項目。

在你職業生涯的某個時候,你就會有一個很好的直覺了。

3. 少開會


高效程序員的 7 項技能


無論你是軟件工程師還是數據科學家,會議都是必要的,因為你需要能夠與項目經理、最終用戶和客戶保持一致。然而,會議有時會突然占滿你的日程表。這就是為什么懂得如何避免不必要的會議很重要。也許用“管理”這個詞比“避免”更好。這里的目標是確保你花在會議上的時間是為了推動決策并幫助你的團隊前進。

最常見的方法就是在經常開會的日子里留出兩個小時的時間。通常,大多數人會在他們認為有益的時候安排定期會議。他們將利用這段時間來趕上他們的開發工作。

另一種少開會的方法是比其他人早到,這樣你就能完成工作。就我個人而言,我喜歡早到,因為總的來說,辦公室比較安靜。大多數早到的人都和你一樣,只是想把工作做完,這樣就不會有人打擾你了。

這對個人貢獻者來說很重要,因為我們的工作需要我們有時間可以保持專注,不和其他人交談。是的,有時候你可能想和別人一起解決問題。但是一旦你解決了阻礙你前進的問題,你就只需要編碼了。就是說,你需要進入一種狀態,你的頭腦中不斷地保持著許多關于你正在做的工作的復雜想法。如果你不斷地停下來,你就很難從停止的地方繼續。

4. Github


高效程序員的 7 項技能


一些計算機專業的學生從出生那天起就開始使用 GitHub。他們能夠理解每一個命令和參數,并且遠遠超過了專業人士。

有些人則是在第一份工作中首次接觸到 GitHub 。對他們來說,Github 令人困惑的命令和流程猶如夢魘。他們從來都無法 100% 確定自己在做什么(這就是速查表受歡迎的原因)。

無論你的公司使用哪種存儲庫系統,如果使用得當,那么該系統就有幫助;如果使用不當,那么它就會成為障礙。一個不費多少時間的簡單推送或提交就可以讓你花費幾個小時去理清多個分支和復刻(fork)。此外,如果你經常忘記拉取存儲庫的最新版本,那么你還將處理并不好玩的合并沖突。

如果你需要保存一份 Github 命令速查表,那么這樣做就好。只要能讓你的生活變得更簡單。

5. 編寫簡潔可維護的代碼


高效程序員的 7 項技能


年輕工程師可能會傾向于將他們知道的所有東西都在一個解決方案中實現。這種愿望讓你把自己對面向對象編程、數據結構、設計模式和新技術的理解全部都用在了每一段代碼的編寫中。這增加了不必要的復雜性,因為很容易過度依賴于你過去使用過的解決方案或設計模式。

復雜的設計概念和簡單的代碼之間存在一種平衡。設計模式和面向對象的設計應該從整體上簡化代碼。不過,一個過程如果抽象、封裝和黑盒化程度越高,調試就越困難。

6. 學會說“不”,分清輕重緩急

這適用于任何角色,無論是金融分析師還是軟件工程師。但尤其值得一提的是,似乎每個人都需要技術角色提供一些東西。如果你是一名數據工程師,那么你需要做的可能不僅僅是開發管道。一些團隊需要數據提取,一些團隊則需要儀表板,還有一些團隊需要你為他們的數據科學家提供新的管道。

分清輕重緩急和說“不”可能真的是兩種不同的技能,但它們緊密地交織在一起。分清輕重緩急意味著你只把時間花在對公司有重大影響的事情上。而說“不”有時候只是意味著避開應該由另一個團隊來處理的工作。不管對于什么角色,它們都常常是同時發生的。

這是一項很難掌握的技能,因為你很容易接受別人提出的每一個要求,尤其是如果你剛大學畢業。你想要避免讓任何人失望,你總是會獲得大量的工作。

在大公司里,總是有無窮無盡的工作要做。關鍵在于只承擔能完成的工作。

有很多技巧沒有經過面試檢驗,甚至在大學里也沒有教授過。通常,這更多的是環境限制,而不是不想讓學生接觸真實開發環境中存在的問題。

7. 面向操作的設計思維


高效程序員的 7 項技能


有一項技能在面試中很難檢驗,在大學里上課時也很難學到,那就是思考最終用戶在使用你的軟件時可能會犯什么錯。我們通常把這個叫做通過操作場景進行思考。

不過,這只是一種禮貌的說法,意思是“你正在設法實現蠢人也不會搞砸的代碼”。

例如,由于大多數編程都是維護,所以這通常意味著修改與其他代碼混在一起的代碼。即使是簡單的修改也需要跟蹤對象、方法和 / 或 API 的所有可能引用。否則,很容易意外破壞相關的模塊。即使只是修改數據庫中的數據類型。

這還包括在開發之前考慮邊緣情況和整個高層設計。

對于開發新模塊或微服務這種更復雜的情況,花時間考慮正在構建的軟件的操作場景很重要。考慮未來的用戶可能需要如何使用你的新模塊,他們在使用它時可能會犯什么錯,可能需要哪些參數,以及未來的程序員可能要以不同的方式使用你的代碼。

簡單的編碼和編程只是問題的一部分。創建可以在你的電腦上正常運行的軟件很容易。但部署代碼出錯的方式很多。一旦投入生產,就很難說代碼將被如何使用,以及其他哪些代碼將附加到原來的代碼中。五年后,未來的程序員可能會對代碼的限制感到沮喪。


我來說兩句
您需要登錄后才可以評論 登錄 | 立即注冊
facelist
所有評論(0)
領先的中文移動開發者社區
18620764416
7*24全天服務
意見反饋:[email protected]

掃一掃關注我們

Powered by Discuz! X3.2© 2001-2019 Comsenz Inc.( 粵ICP備15117877號 )

海南特区七星彩