程序員的10個好習慣,值得堅持!

我總結了 10 個程序員的好習慣,今天分享給大家。

1. 引入新的技術棧的時候,要以官方文檔爲主

在項目裏,無論使用新的 jar 包,還是用新的中間件,一定要去看官方文檔。

現在網上的技術文章魚龍混雜,再加上國內那個不咋地的搜索引擎,所以在網上搜靠譜的技術文章,就相當於在屎坑裏撈金子。

比如,如果你想要對 SpringBoot2 寫的代碼進行單元測試,JUnit 版本你可能已經是 5 了。但你搜到的網上文章很可能會告訴你測試用例需要註解:

@RunWith(SpringRunner.class) 

但是官方文檔說了,其實如果你用 JUnit5,就不用加這個註解了,加了反而可能引起不必要的衝突。

所以,官方文檔對新技術的引入是唯一的參考金標準。

2. 一定要悄悄地把代碼測的沒問題了再交付

在職場上,什麼樣的人才能快速成長、快速得到重用?答案是可靠的人。

那就程序員來說,什麼樣的人才算是可靠的人?答案是交付可靠的技術產品。

那可靠的產品第一評估標準就是 bug 少。這個 bug 少是別人評估的,而不是自己評估的。

無論咱們自己代碼實現成什麼樣子,哪怕是代碼寫的還不完美,但是,只要咱們通過自測,在提交之前儘可能把問題解決掉,讓別人少發現你的錯誤,尤其是低級 bug,那麼你纔是一位可靠的程序員。

所以,交付任務前,一定要自己把代碼全方位地測試一遍,保證自己有着優秀的口碑纔好。

3. 打日誌的時候儘可能把輸入、輸出以及耗時都打印出來

我們打日誌的目的是什麼?是爲了定位問題的。

問題有哪些?其實大體就兩種,邏輯問題和性能問題。

邏輯問題,我們如果打印了輸入和輸出,那麼根據業務規則,這麼一對照就能很容易定位到問題。

性能問題,我們無論是通過像 grep、sort 等 shell 命令去直接對日誌做個過濾加排序,還是通過日誌蒐集加日誌搜索等工具,都能很容易的發現到問題。甚至還可以和監控系統聯合起來,直接做預警。

所以,打日誌的時候,我們要記得把輸入和輸出以及時間都打印出來。

4. 學好 Git

Git 這東西太重要了。現在的團隊開發,用 Git 管理各種代碼版本,代碼分支。如果你用不好 Git,很容易就會因爲合併代碼、升級版本等情況,產生出許多沒必要的 bug。

一個用不好 Git 的團隊,可能每次上線,都會帶來那麼幾個莫名其妙的問題。

給大家分享一本非常不錯的 Git 開源手冊。

這本手冊在豆瓣上評價極高,之前 9.3,現在也有 9.1 的高分,其作者是 GitHub 的員工,內容主要側重於各種場合中的慣用法和底層原理的講述,手冊中還針對不同的使用場景,設計了幾個合適的版本管理策略。

簡而言之,這本手冊無論是對於初學者還是想進一步瞭解 Git 工作原理的開發者都非常合適。

豆瓣9.1分的Git開源手冊!

5. 優先實現功能,性能問題或許沒那麼着急

我在帶團隊的時候,經常發現有些剛入行的同事,會邊寫代碼邊糾結自己寫的代碼性能是否有問題。其實真的不必這樣。像我們這些老程序員,都知道過早優化有時候可能白花費功夫。

像咱們如果寫一個批處理的定時任務,這個任務要求只要在凌晨運行,在大家上班前任務完成就行。那麼,這個任務從凌晨兩點運行到六點和運行到四點,有什麼區別嗎?

優化代碼一定要適度,要在寫完功能之後,看功能會怎麼被使用,根據實際的要求,去優化真正需要優化的地方。

6. 先實現最確定的需求,不確定或者模糊的需求先往後放

實現需求的先後順序,注意一定要以需求的可靠程度爲準。

在分配給我們的需求裏一般分兩類:

  • 有的需求是我們和產品經理都非常明確的需求;
  • 也有的需求比較模糊:開會討論時大家都覺得沒什麼問題,但是一到代碼實現的時候,就發現還存在很多問題。

這時候,咱們應對的技巧是,先對這些需求搭一個統一的架子,把已經非常明確的需求先開發出來。

由於架子搭建出來了,這時候再和產品經理討論那些模糊的需求,很容易就能讓產品明白困難的地方,這樣就可以把溝通難度降到最低。

7. 主動找項目裏的問題並給出解決方案

問題是什麼?問題就是在實踐過程中需要解決的東西。

把這些問題一個個找出來,解決掉,這些解決問題中產生出來的方案,全會形成推動項目前進的推動力。那麼產生這些推動力的你自己,一定會從中獲益良多。

8. 評估開發週期,要留出冗餘時間

留出冗餘時間的目的很明確,在咱們開發的時候,遇到的意外情況太多了:

  • 需求又雙叒叕變了
  • 團隊人員有變化
  • 當初估算的時間樂觀了
  • 這個功能需要動老代碼
  • 需要跨團隊合作開發
  • 領導說“加個小功能”,領導認爲這個小功能不影響開發週期(此處省略二百字)
  • ……

所以,冗餘時間是要留出來的。

留出的冗餘時間不等於摸魚時間,開發還是按照正常的節奏幹,早做完早交付。

9. 不要光看書去學習技術,要把感興趣的技術通過代碼實現出來

咱們程序員最重要的就是實踐,能把學到的知識轉化爲實踐用到工作上。

光看書學習技術,很可能只會讓咱們產生出已經學會的錯覺。只有通過代碼把感興趣的技術實踐練習了一遍,咱們才真正能明白這技術實際用起來是什麼樣子,需要注意什麼。

動手實踐的重要性就不多說了,我之前也寫過一些文章介紹過如何動手實踐,比如這篇通過模擬環境來學習高併發:插入

10. 英語還是挺重要的

你不得不承認,IT 這行,基本所有的創新都誕生於英語的世界。

比如 k8s,就我所知就是國內英語好的技術人員從英語社區逐漸在國內推廣開來,而這些推廣了 k8s 的先驅也自然掌握了 k8s 的話語權。大家可以看看 k8s 在市場上的流行程度,也可以看看一位 k8s 專家的工資大概是多少。

而且,我前面說過,大家引入新技術一定要看官方文檔,官方文檔百分之八十都是英語的,所以英語確實重要。

如果英語不好,是不是就沒機會了?沒這麼絕對。

就說我吧,不瞞大家,我英語四級沒過,但還是照樣能看英語資料,照樣和別人一起翻譯了國內的第一本 Hibernate 技術書。

當初我用 Hibernate 在國內算是比較早的一批程序員了,也經常去論壇回答問題,所以後來就有人找我一起翻譯書。我最開始是抗拒的,覺得自己英語太爛了,翻譯不好。後來我又想,既然我能看着英語文檔學 Hibernate,要不就試試。於是就這麼着幹了一把。

作爲一個過來人,我想說的是,技術文檔沒有特別複雜的語法、生僻單詞,而且現在還有翻譯軟件、插件可以幫我們閱讀。即使英語基礎一般,也沒什麼大不了的。

-完-


你好,我是四猿外。

一家上市公司的技術總監,管理的技術團隊一百餘人。

我從一名非計算機專業的畢業生,轉行到程序員,一路打拼,一路成長。

我會把自己的成長故事寫成文章,把枯燥的技術文章寫成故事。

歡迎關注我的公衆號,關注後可以領取高併發、算法學習資料。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章