作為老碼農老程序員，日常工作中打交道最多的也是程序員，在這個過程中，我發現不少程序員在技術、產品等方面的思維有各種各樣的小問題。現在我就來回憶一下，把這些我認為不太好的思維習慣記錄下來，在提醒自己的同時，也供程序員朋友們參考，不必對號入座，有則改之，無則加勉，或者你甚至認為這些不是思維誤區都可以的，我也不知道起怎么樣的標題比較合適，且稱“程序員的十大思維誤區”吧，祝閱讀愉快！
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部分自動就更新了。
技術的更新實在太快了，即使身處於這個行業中，我們也時常會因為要跟進新技術而疲於奔命。比較有效的辦法是，盡量去理解一些本質性的原理性的知識，這些知識往往通用性比較強，同時選擇學習某些新框架。選擇的依據可以是這種框架的社區活躍程度、遇到問題時網上找解決辦法的難易程度、開發周期長短、市場上人才儲備情況等等。
文章來自：技術人成長
歡迎關注公眾號：
