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

?

1.?測試人員不按我的實現(xiàn)來測


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


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

?

2.?接口沒有數(shù)據(jù)，當然就出錯

APP或網(wǎng)站出錯了，找前端開發(fā)人員過來看?？赐曛笳f：“接口返回空數(shù)據(jù)了，前端沒有問題”。真的沒問題嗎？


前端需要進行防御式編程，永遠不要假定后端接口有數(shù)據(jù)返回或者數(shù)據(jù)格式一定是合理的，因此需要針對這些情況做處理，比如進行一些轉(zhuǎn)換然后展示給用戶。而不是：后端接口沒有返回數(shù)據(jù)，我就崩潰給你們看，跟我沒關(guān)系！

?

3.?把數(shù)據(jù)庫的錯誤返回給前端


后端開發(fā)人員有時候會將操作數(shù)據(jù)庫的異常信息返回給前端，如果你跟他說需要屏蔽掉這種信息，然后轉(zhuǎn)換成前端可以理解的信息再返回，他會說正常情況下不會這樣的，只是因為數(shù)據(jù)庫的數(shù)據(jù)是測試數(shù)據(jù)，數(shù)據(jù)關(guān)系不合理。


就像前端開發(fā)人員不能假設(shè)后端接口一定返回數(shù)據(jù)給他一樣，后端開發(fā)人員不能對數(shù)據(jù)庫的數(shù)據(jù)做任何假設(shè)。在操作數(shù)據(jù)的時候，需要想象如果這個數(shù)據(jù)不是你想要的格式時，要怎么處理，然后再返回給前端相應(yīng)的信息，而不是把異常信息返回給前端。
?

?

4.?功能開發(fā)完成，萬事大吉了


有些開發(fā)人員在寫完某個功能后，常常就覺得沒什么事情了。功能開發(fā)之后，測試就不用說了，但此外，開發(fā)人員最好能多從運維、運營的角度去思考。比如怎樣的信息有利用運維人員快速定位問題，也有助于自己快速找到應(yīng)用代碼中的問題。同樣，得想想，怎樣的數(shù)據(jù)信息可以幫助運營人員做決策，怎樣的策略具有更好的安全性。


功能開發(fā)完成，只是第一步，一個系統(tǒng)要完整運轉(zhuǎn)起來并運轉(zhuǎn)得好，還需要很多其它的輔助工作，因此，開發(fā)同學(xué)具有運維、運營式研發(fā)思維，才有可能成長為一個能統(tǒng)領(lǐng)全局的技術(shù)負責人之類的角色。

?

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

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


但是開發(fā)人員自己測試，往往不能測出問題，因為他已經(jīng)按自己的實現(xiàn)思路去使用了，但很有可能測試得不全面。而且，別人電腦和自己電腦環(huán)境可能不一樣，兼容性是個問題?！拔译娔X上沒問題啊”，這句話給我們碼農(nóng)掙回一點尊嚴是可以的，然后，應(yīng)該認真對待別人提出的問題并解決掉。

?

6.?懷疑操作系統(tǒng)或者硬件問題


聽到產(chǎn)品有問題時，經(jīng)常懷疑是操作系統(tǒng)或是硬件問題，而不主動想辦法解決。倒不是說操作系統(tǒng)和硬件是完美的不會出問題，而是這些東西都是經(jīng)過千萬次測試后才推出來的產(chǎn)品，我們寫的代碼可能沒有經(jīng)過足夠的測試就發(fā)布出去了。


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

?

7.?假設(shè)代碼都走“Happy Path”

Happy Path，也可以叫歡樂路徑。有些開發(fā)人員總會假設(shè)，程序運行時，配置文件好好地躺那里了，網(wǎng)絡(luò)連接總是好好的，因此程序都會按理想中的流程運行著。


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


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

?

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

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


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

?

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


技術(shù)人員有時候跟業(yè)務(wù)人員、產(chǎn)品經(jīng)理寒暄幾句，就以為都理解了需求，于是回頭就蠻干起來。等到做得差不多了，拿給業(yè)務(wù)人員看時，可能會發(fā)現(xiàn)做的東西不是他們想要的，或者相差甚遠。


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

?

10.?抱殘守缺不主動學(xué)習(xí)新知識


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


他還說，使用具有MVC模式的PHP框架后，后端的Model被修改后，瀏覽器前端立即有響應(yīng)。我估計他受VC++里面文檔視圖編程的方式影響比較深，在單一的桌面程序里面，MVC模式確實會這樣的。但是到Web編程時，代表數(shù)據(jù)的Model在后端被修改了，前端瀏覽器并不能看到View的變化，需要刷新才能從后端獲取View的新內(nèi)容，或者需要使用Ajax請求，又或者需要使用WebSocket之類的技術(shù)從后端向前端推送。這種時候，后端框架使用MVC模式，是為了模塊劃分和更好的代碼組織方式，并不是后端數(shù)據(jù)修改了，瀏覽器上顯示的View部分自動就更新了。


技術(shù)的更新實在太快了，即使身處于這個行業(yè)中，我們也時常會因為要跟進新技術(shù)而疲于奔命。比較有效的辦法是，盡量去理解一些本質(zhì)性的原理性的知識，這些知識往往通用性比較強，同時選擇學(xué)習(xí)某些新框架。選擇的依據(jù)可以是這種框架的社區(qū)活躍程度、遇到問題時網(wǎng)上找解決辦法的難易程度、開發(fā)周期長短、市場上人才儲備情況等等。

?

文章來自：技術(shù)人成長 <https://www.nndev.cn/archives/2001>

?

歡迎關(guān)注公眾號：

• ? 上一篇：程序員是最好的產(chǎn)品經(jīng)理
• ? 下一篇：linux 查看系統(tǒng)當前時間，修改時間