Time will tell.

本章節就和你說一說從初級晉級為高級程序員的必經之路，同時也反思一下自己還有哪些不足之處。

1、 命名的規范

我們在學習編程的時候，老師都或多或少地有提到過命名的問題。但命名隨意起來時，真的是什么奇奇怪怪的命名都有的：xiaonaigou,xxx,j1,jl,llst.

可能沒完全習慣過來，也可能是沒意識到命名規范的價值和意義。這些問題尤其是會出在年紀偏小的程序員身上。

2、日志，日志的規范

曾經有一個3年后端經驗的小伙伴，出了問題不知道怎么解決，只好重啟，找我來協助，問他：“怎么錯了？”

“不知道。”

“日志呢？”

“沒有。”

這怎么解決嘛…

到后來才知道，他們解決問題都是本地改代碼然后直接部署，重新訪問看錯誤消失沒，沒有消失就繼續在本地改源碼。

3 、不寫接口和假數據

一個菜雞不可怕，可怕的是菜雞遇到菜雞。

曾經有一個項目中有兩個菜雞，一個前端的一個后端的，他們很歡快地調接口，根本不寫文檔 ，兩個人效率特別高。

直到有一天，發現項目可能做不完了，需要另外兩個前端菜雞協助一下。新來的兩個菜雞要獲取后端的數據，不知道接口的 Url 地址，不知道Get 還是Post ，不知道發送的參數和返回值。就這樣寫！

我壓根沒想過可以這么寫代碼，兩個菜雞很開心！拍手稱快：“通了，通了！”

我說你們通什么呢？他們說接口終于通了！原來他們兩個參考之間的頁面，硬生生的一次一次不停的嘗試，就這樣把接口猜出來了！

這就是編程的樂趣嗎？

還有不寫假數據。

曾有一位馬姓小哥，對趙姓小哥信誓旦旦地說：“3天，給我3天時間 ，我把真數據給你。”

趙姓小哥信以為真。就這樣3天又3天，如此往復 …

一個半月后，我們仍未見到那天說的全部數據！

4、不寫單元測試

確切來說是不按 TDD 的方式開發。在現在 IDE 這么強大的情況下，先寫單元測試的習慣，不僅僅是代碼的嚴謹性，也是效率的代名詞啊。

很多菜雞理解不了單元測試的價值，沒關系，等到代碼重構，需求變更的時候，哭都哭不出來！

好的單元測試，你的邏輯必然會清楚。

5、先集成，再測試，再放棄

很多時候，菜雞在引入第三方的庫、框架、接口或者是服務時，最喜歡的事情就是直接和自己原有的代碼集成在一起。

結果是什么呢？突然間不能用了，跑不起來，不知道問題出在哪了，根本分不清倒底是第三方的問題還是自己的問題。

好的方法是先跑通官方提供的 Demo，再想辦法一點一點加上自己的業務。

6 、理不清楚邏輯，邊做邊猜

前端在這里的問題特別多，做支付，不清楚支付的流程，分不清楚定義，總以為前端就是接口處理好數據展示好拉倒。

很多菜雞都會有這種習慣，這樣不好，先把邏輯處理好，弄清楚流程，再去動手才好。

7 、不做方案

不做方案代表什么含義呢？完全就是憑直覺走位。

寫代碼的好習慣應該是先在腦袋里把所有的需求細節過一遍，實現細節拿出來。

上個月就有一個張姓小哥，做一個匿名評論功能。基本上沒有經驗，腦子也有些Ennn，給出的方式是什么你們能猜到么？

用戶刷新一次就往用戶表里插入一條數據，密碼默認昵稱隨機。

說多了都是淚，見過太多讓人目瞪狗呆的方案了，看著滿屏的代碼，你怎么幫他調錯調優，最好的方式就是全部重寫。

做了方案的好處太多了。

8、不關注性能

不關注性能也是新人很容易犯的錯。什么是性能？對后端來說就是 TPS 和響應時間，對前端來說就是響應時間。

很多新人程序員的習慣就是把東西做出來，然后再優化。最后就是東西做出來了，優化留給別人了。

對性能的關注也是晉升中級程序員最關鍵的技能點。在寫代碼的時候，有經驗的工程師已經知道了這個方法這個函數這個功能點的性能怎么樣，瓶頸在哪里。

9、 害怕重構

“程序員最大的勇氣就是看自己三個月前寫的代碼。”

其實重構并不應該是在幾個月之后重構，最好的方式是實時重構。寫一天代碼，70%的時間都放到重構上都不過份。

而新人磕磕跘跘地完成一個功能，就跟多米諾骨牌做成的大黃蜂一樣，你敢動一下他的代碼，他會跟你拼命。

不重構在某種程度上也意味著你的代碼實現無法重塑。

10、 做出來就好，不考慮優雅的方案

有個詞叫做最佳實踐，其實編碼規范和最佳實踐，是編程功底的重要體現。優雅方案可以認為是最佳實踐的升級版，它和上面說到的不斷的重構是相輔相成的。

不好的方案是什么呢？

硬編碼居多，沒有可擴展性，用很丑陋的方式完成了功能。

上次他們去做一個關于試聽課的方案，一個人能試聽多少節課，正常的邏輯應該是在用戶的表里加一個字段來表示。需求是寫著邀請幾個人，可以試聽多少節課，所以他們判斷試聽多少節課就直接在通過邀請人的表里查詢去做。完全沒考慮到以后如果我變換了試聽課的判斷條件怎么辦？

實際上這是應該拆解成兩部分，一個是試聽課的產生條件，這是一個獨立的模塊，加一個是試聽課的確認。

這種例子太多了，也和不做方案、不考慮擴展性有關系。

11、不考慮未來需求的變化

工程師的水準，其實可以分成以下幾個階段：

• 面向功能編程

• 面向性能編程

• 面向未來編程

工程師拿到需求的第一件事，應該聚集在以下幾個問題：

• 哪些需求是我之前完成過的

• 哪些需求是有可能變化的

• 有幾種方案，分別支持什么樣的需求變化

但是差一點的程序員就考慮不到那么遠，一個是對業務不熟悉，判斷不出來哪些需求可能會產生變化，一個是對可選的方案掌握的不多，根本就沒有什么可選的余地，還有就是沒有這種思維習慣，分不清楚哪些是現在要完成的，哪些是未來可能會支持或者是變動的。

12、遇到問題的時候不會試錯

這也是新手常見的問題。很多時候新人會遇到問題，解決不了，去找一個有經驗的工程師，這個有經驗的工程師呢，大概也未曾遇到這種情況，但是他解決問題的思路清楚啊。

一會兒試試這個，一會兒刪刪那段代碼，很快就跑通了。

解決問題是一個很見功底的技術點，而且是有很多方法論的，之前總結過一些，簡單列舉過來：

尋找正確的代碼

理清楚正確的執行順序

重現錯誤

最小化錯誤產生的場景

修改代碼到一個已知的錯誤類型

…

解決問題就是一個分析推理的過程，而在這里呢，背后的功底就是你知道很多哪些是肯定不會錯的小公理，然后再挨個去定位可能產生錯誤的環節，分解流程是最基礎的工作。

13、不會寫偽代碼

偽代碼是什么呢？就是自然語言啊。其實編程只有三種邏輯控制塊，順序，循環，判斷。

所以你只要用自然語言來描述出來，先做什么，再做什么，什么時候循環，什么時候判斷，代碼寫出來的問題就不大。

這是一個先寫偽代碼再寫細節的過程。你不要上來就開始平鋪寫代碼。平鋪代碼是最菜的方式，好的代碼是有結構的，有不同的抽像層級。

第一步干嘛，

第二步干嘛，

第三步該干嘛。

先把這個列清楚，這是偽代碼的第一級。然后變成注釋，這是第二級。刪掉注釋變成函數名，這是第三級。

所以說，好的程序員寫代碼是不需要注釋的，不是說讓你把注釋刪掉，而是讓你完成這三步升華的過程。

寫的好的代碼，命名規范，你看到的真的是一首詩， 是一種編程語言，是在用語言來描述一件功能的完成，這種編程藝術的工業感很爽快，你看那些不爽的代碼，簡直了。。

14、不做數據量的預估

后端工程師在前期經常會忽視數據量的大小，沒有影成一個好的習慣。

寫代碼只注重功能，沒有一個關于數據量的概念。這個地方其實還和性能是一致的，在性能上，前后端并沒有太大的差別。

推薦的做法是，程序員要對數據很敏感，后端要知道每一個表的規模可能會有多大，當前的系統能支持的數據庫表的大小是多大，而前后端都需要知道每一個操作，都分成了哪幾個步驟，每一個步驟花費的時間是多少，大概占用的內存是什么樣的。

做到這一點其實并不難，難的是養成這種習慣，初級工程師眼里看的是功能和代碼，中級工程師眼里看到的是數據和時間。

好啦，以上內容就到這里，如果你對Python自動化軟件測試、面試題等更多內容感興趣的話可以加入我們175317069。群里會有各項測試學習資源發放，更有行業深潛多年的技術人分析講解。期待你的加入！

歡迎【點贊】、【評論】、【關注】~

Time will tell.（時間會說明一切）

總結

以上是生活随笔為你收集整理的14道初级程序员进阶中高级的必经环节的全部內容，希望文章能夠幫你解決所遇到的問題。

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