作為老碼農老程式設計師，日常工作中打交道最多的也是程式設計師，在這個過程中，我發現不少程式設計師在技術、產品等方面的思維有各種各樣的小問題。現在我就來回憶一下，把這些我認為不太好的思維習慣記錄下來，在提醒自己的同時，也供程式設計師朋友們參考，不必對號入座，有則改之，無則加勉，或者你甚至認為這些不是思維誤區都可以的，我也不知道起怎麼樣的標題比較合適，且稱“程式設計師的十大思維誤區”吧，祝閱讀愉快！

 

1. 測試人員不按我的實現來測

前端介面有幾個下拉列表框，需要選擇後才能點“提交”按鈕，但前端的實現是，即使不選擇下拉框，也能點選“提交”按鈕。而如果沒選擇時就提交，會出錯。前端開發人員會說，你不按我的要求來使用，才出錯的啊。嗯，嗯，好像有點道理哈。

從測試的角度來看，粗暴點說，就是要把你的東西搞垮，當然不會按照開發人員想象的流程來測試，前端開發人員必須力求保證無論使用者怎麼使用，都不能出現崩潰的現象，使用者使用流程不合理時，進行適當提示，而不是掛掉。比如不滿足輸入條件的情況下，“提交”按鈕最好變灰，這樣也有助於引導使用者按照正常流程來使用產品功能。

 

2. 介面沒有資料，當然就出錯

APP或網站出錯了，找前端開發人員過來看。看完之後說：“介面返回空資料了，前端沒有問題”。真的沒問題嗎？

前端需要進行防禦式程式設計，永遠不要假定後端介面有資料返回或者資料格式一定是合理的，因此需要針對這些情況做處理，比如進行一些轉換然後展示給使用者。而不是：後端介面沒有返回資料，我就崩潰給你們看，跟我沒關係！

 

3. 把資料庫的錯誤返回給前端

後端開發人員有時候會將操作資料庫的異常資訊返回給前端，如果你跟他說需要遮蔽掉這種資訊，然後轉換成前端可以理解的資訊再返回，他會說正常情況下不會這樣的，只是因為資料庫的資料是測試資料，資料關係不合理。

就像前端開發人員不能假設後端介面一定返回資料給他一樣，後端開發人員不能對資料庫的資料做任何假設。在操作資料的時候，需要想象如果這個資料不是你想要的格式時，要怎麼處理，然後再返回給前端相應的資訊，而不是把異常資訊返回給前端。 

 

4. 功能開發完成，萬事大吉了

有些開發人員在寫完某個功能後，常常就覺得沒什麼事情了。功能開發之後，測試就不用說了，但此外，開發人員最好能多從運維、運營的角度去思考。比如怎樣的資訊有利用運維人員快速定位問題，也有助於自己快速找到應用程式碼中的問題。同樣，得想想，怎樣的資料資訊可以幫助運營人員做決策，怎樣的策略具有更好的安全性。

功能開發完成，只是第一步，一個系統要完整運轉起來並運轉得好，還需要很多其它的輔助工作，因此，開發同學具有運維、運營式研發思維，才有可能成長為一個能統領全域性的技術負責人之類的角色。

 

5. 口頭禪：我電腦上沒問題啊

聽到某個功能出問題時，技術人員往往會說：我電腦上沒問題啊。這倒是可以理解的，畢竟開發人員完成某個功能後，一般都是在自己電腦上測試過的，測試沒問題了才釋出出去。

但是開發人員自己測試，往往不能測出問題，因為他已經按自己的實現思路去使用了，但很有可能測試得不全面。而且，別人電腦和自己電腦環境可能不一樣，相容性是個問題。“我電腦上沒問題啊”，這句話給我們碼農掙回一點尊嚴是可以的，然後，應該認真對待別人提出的問題並解決掉。

 

6. 懷疑作業系統或者硬體問題

聽到產品有問題時，經常懷疑是作業系統或是硬體問題，而不主動想辦法解決。倒不是說作業系統和硬體是完美的不會出問題，而是這些東西都是經過千萬次測試後才推出來的產品，我們寫的程式碼可能沒有經過足夠的測試就釋出出去了。

從經驗來看的話，99%的情況下，是開發者不理解系統機制，或者是自己程式碼有問題。因此，一般遇到問題時，先想想自己程式碼哪裡比較可能出問題，然後再考慮其它方面的問題，當然，有些問題很明顯就不是程式碼問題的，那另當別論。

 

7. 假設程式碼都走“Happy Path”

Happy Path，也可以叫歡樂路徑。有些開發人員總會假設，程式執行時，配置檔案好好地躺那裡了，網路連線總是好好的，因此程式都會按理想中的流程執行著。

而實際上，程式在執行時，各種異常情況都有可能發生，可謂如履薄冰。因此處理異常的程式碼是非常必要的，甚至有時候，處理異常的程式碼比正常流程的程式碼量還要多，這都是為了程式的健壯性。

同樣的，因為歡樂路徑的思維，開發人員在估計開發時間的時候，也往往會以最順利情況下的時間作為進度計劃，而實際上在開發過程中，還會遇到各種各樣難以預料的問題，都需要花時間解決，因此程式設計師估算時間，一般差個2-3倍是比較常見的。

 

8. 主與次、抽象與具體分不清

技術人員有時候分不清主次，該理解的不去仔細理解，不該背誦的選擇背誦。有些東西其實理解了原理，使用時候再查一下文件就可以了，沒有必要花費精力去記憶。

還比如，捨不得花時間做設計，就早早動手寫程式碼了，理由是沒有時間設計。但到頭來，因為沒有提前做好設計而需要返工，導致花的時間更多。因此，除非不得已，建議先稍微想好再動手幹活，沒必要太急，這就是所謂的慢工出細活。 

 

9. 少溝通，以為都理解需求了

技術人員有時候跟業務人員、產品經理寒暄幾句，就以為都理解了需求，於是回頭就蠻幹起來。等到做得差不多了，拿給業務人員看時，可能會發現做的東西不是他們想要的，或者相差甚遠。

還有些時候，是因為不深入理解需求和環境，導致了複雜性。舉個例子，比如要給自動化部署的伺服器叢集分配內網IP，剛開始可能想到要生成各個網段的IP然後讓伺服器通過DHCP來自動獲取屬於這個網段內的IP，網段還不能重複。但如果理解了具體場景，比如每一次部署，在同一網段內的伺服器都不超過200臺，那其實就不需要用程式碼生成網段了，使用固定的網段就可以，因為不同的部署相互之間是隔離開的，不同次的部署，即使IP相同，也不會衝突，這就簡化了問題，本來要寫的程式碼現在也不需要寫了。有一種比較拗口的說法大致可以描述這種場景，就是：解決問題的最好辦法就是不去解決它。

 

10. 抱殘守缺不主動學習新知識

以前有位碼農問我，知不知道MVC模式，我只好苦笑。儘管我不敢說自己對一些模式的理解有多好，但這種東西在剛開始程式設計的那些年，也早就接觸了是不是。我估計他平時很少跟人溝通，或者看技術文章、技術資料比較少，以為自己偶然學過的東西，很多人都不懂，而實際上並非如此。

他還說，使用具有MVC模式的PHP框架後，後端的Model被修改後，瀏覽器前端立即有響應。我估計他受VC++裡面文件檢視程式設計的方式影響比較深，在單一的桌面程式裡面，MVC模式確實會這樣的。但是到Web程式設計時，代表資料的Model在後端被修改了，前端瀏覽器並不能看到View的變化，需要重新整理才能從後端獲取View的新內容，或者需要使用Ajax請求，又或者需要使用WebSocket之類的技術從後端向前端推送。這種時候，後端框架使用MVC模式，是為了模組劃分和更好的程式碼組織方式，並不是後端資料修改了，瀏覽器上顯示的View部分自動就更新了。

技術的更新實在太快了，即使身處於這個行業中，我們也時常會因為要跟進新技術而疲於奔命。比較有效的辦法是，儘量去理解一些本質性的原理性的知識，這些知識往往通用性比較強，同時選擇學習某些新框架。選擇的依據可以是這種框架的社群活躍程度、遇到問題時網上找解決辦法的難易程度、開發週期長短、市場上人才儲備情況等等。

 

文章來自：技術人成長

 

歡迎關注公眾號：

相關推薦