作為老碼農老程式設計師，日常工作中打交道最多的也是程式設計師，在這個過程中，我發現不少程式設計師在技術、產品等方面的思維有各種各樣的小問題。現在我就來回憶一下，把這些我認為不太好的思維習慣記錄下來，在提醒自己的同時，也供程式設計師朋友們參考，不必對號入座，有則改之，無則加勉，或者你甚至認為這些不是思維誤區都可以的，我也不知道起怎麼樣的標題比較合適，且稱「程式設計師的十大思維誤區」吧，祝閱讀愉快！
前端介面有幾個下拉列表框，需要選擇後才能點「提交」按鈕，但前端的實現是，即使不選擇下拉框，也能點選「提交」按鈕。而如果沒選擇時就提交，會出錯。前端開發人員會說，你不按我的要求來使用，才出錯的啊。嗯，嗯，好像有點道理哈。
從測試的角度來看，粗暴點說，就是要把你的東西搞垮，當然不會按照開發人員想象的流程來測試，前端開發人員必須力求保證無論使用者怎麼使用，都不能出現崩潰的現象，使用者使用流程不合理時，進行適當提示，而不是掛掉。比如不滿足輸入條件的情況下，「提交」按鈕最好變灰，這樣也有助於引導使用者按照正常流程來使用產品功能。
前端需要進行防禦式程式設計，永遠不要假定後端介面有資料返回或者資料格式一定是合理的，因此需要針對這些情況做處理，比如進行一些轉換然後展示給使用者。而不是：後端介面沒有返回資料，我就崩潰給你們看，跟我沒關係！
後端開發人員有時候會將運算元據庫的異常資訊返回給前端，如果你跟他說需要遮蔽掉這種資訊，然後轉換成前端可以理解的資訊再返回，他會說正常情況下不會這樣的，只是因為資料庫的資料是測試資料，資料關係不合理。
就像前端開發人員不能假設後端介面一定返回資料給他一樣，後端開發人員不能對資料庫的資料做任何假設。在運算元據的時候，需要想象如果這個資料不是你想要的格式時，要怎麼處理，然後再返回給前端相應的資訊，而不是把異常資訊返回給前端。
有些開發人員在寫完某個功能後，常常就覺得沒什麼事情了。功能開發之後，測試就不用說了，但此外，開發人員最好能多從運維、運營的角度去思考。比如怎樣的資訊有利用運維人員快速定位問題，也有助於自己快速找到應用**中的問題。同樣，得想想，怎樣的資料資訊可以幫助運營人員做決策，怎樣的策略具有更好的安全性。
功能開發完成，只是第一步，乙個系統要完整運轉起來並運轉得好，還需要很多其它的輔助工作，因此，開發同學具有運維、運營式研發思維，才有可能成長為乙個能統領全域性的技術負責人之類的角色。
聽到某個功能出問題時，技術人員往往會說：我電腦上沒問題啊。這倒是可以理解的，畢竟開發人員完成某個功能後，一般都是在自己電腦上測試過的，測試沒問題了才發布出去。
但是開發人員自己測試，往往不能測出問題，因為他已經按自己的實現思路去使用了，但很有可能測試得不全面。而且，別人電腦和自己電腦環境可能不一樣，相容性是個問題。「我電腦上沒問題啊」，這句話給我們碼農掙回一點尊嚴是可以的，然後，應該認真對待別人提出的問題並解決掉。
聽到產品有問題時，經常懷疑是作業系統或是硬體問題，而不主動想辦法解決。倒不是說作業系統和硬體是完美的不會出問題，而是這些東西都是經過千萬次測試後才推出來的產品，我們寫的**可能沒有經過足夠的測試就發布出去了。
從經驗來看的話，99%的情況下，是開發者不理解系統機制，或者是自己**有問題。因此，一般遇到問題時，先想想自己****比較可能出問題，然後再考慮其它方面的問題，當然，有些問題很明顯就不是**問題的，那另當別論。
而實際上，程式在執行時，各種異常情況都有可能發生，可謂如履薄冰。因此處理異常的**是非常必要的，甚至有時候，處理異常的**比正常流程的**量還要多，這都是為了程式的健壯性。
同樣的，因為歡樂路徑的思維，開發人員在估計開發時間的時候，也往往會以最順利情況下的時間作為進度計畫，而實際上在開發過程中，還會遇到各種各樣難以預料的問題，都需要花時間解決，因此程式設計師估算時間，一般差個2-3倍是比較常見的。
技術人員有時候分不清主次，該理解的不去仔細理解，不該背誦的選擇背誦。有些東西其實理解了原理，使用時候再查一下文件就可以了，沒有必要花費精力去記憶。
還比如，捨不得花時間做設計，就早早動手寫**了，理由是沒有時間設計。但到頭來，因為沒有提前做好設計而需要返工，導致花的時間更多。因此，除非不得已，建議先稍微想好再動手幹活，沒必要太急，這就是所謂的慢工出細活。
技術人員有時候跟業務人員、產品經理寒暄幾句，就以為都理解了需求，於是回頭就蠻幹起來。等到做得差不多了，拿給業務人員看時，可能會發現做的東西不是他們想要的，或者相差甚遠。
還有些時候，是因為不深入理解需求和環境，導致了複雜性。舉個例子，比如要給自動化部署的伺服器集群分配內網ip，剛開始可能想到要生成各個網段的ip然後讓伺服器通過dhcp來自動獲取屬於這個網段內的ip，網段還不能重複。但如果理解了具體場景，比如每一次部署，在同一網段內的伺服器都不超過200臺，那其實就不需要用**生成網段了，使用固定的網段就可以，因為不同的部署相互之間是隔離開的，不同次的部署，即使ip相同，也不會衝突，這就簡化了問題，本來要寫的**現在也不需要寫了。有一種比較拗口的說法大致可以描述這種場景，就是：解決問題的最好辦法就是不去解決它。
以前有位碼農問我，知不知道mvc模式，我只好苦笑。儘管我不敢說自己對一些模式的理解有多好，但這種東西在剛開始程式設計的那些年，也早就接觸了是不是。我估計他平時很少跟人溝通，或者看技術文章、技術資料比較少，以為自己偶然學過的東西，很多人都不懂，而實際上並非如此。
他還說，使用具有mvc模式的php框架後，後端的model被修改後，瀏覽器前端立即有響應。我估計他受vc++裡面文件檢視程式設計的方式影響比較深，在單一的桌面程式裡面，mvc模式確實會這樣的。但是到web程式設計時，代表資料的model在後端被修改了，前端瀏覽器並不能看到view的變化，需要重新整理才能從後端獲取view的新內容，或者需要使用ajax請求，又或者需要使用websocket之類的技術從後端向前端推送。這種時候，後端框架使用mvc模式，是為了模組劃分和更好的**組織方式，並不是後端資料修改了，瀏覽器上顯示的view部分自動就更新了。
技術的更新實在太快了，即使身處於這個行業中，我們也時常會因為要跟進新技術而疲於奔命。比較有效的辦法是，盡量去理解一些本質性的原理性的知識，這些知識往往通用性比較強，同時選擇學習某些新框架。選擇的依據可以是這種框架的社群活躍程度、遇到問題時網上找解決辦法的難易程度、開發周期長短、市場上人才儲備情況等等。
程式設計師的十大級別
第一級 神人，天資過人而又是技術狂熱者同時還擁有過人的商業頭腦，遠矚，技術過人，大器也。如丁磊，求伯君。第二級 高人，有天賦，技術過人但沒有過人的商業頭腦，通常此類人不是頂尖黑客就是技術總監之流。第 牛人，技術精湛，熟悉行業知識，敢於創新，有自己的公司和軟體產品。第四級 工頭，技術精湛，有領導團隊的...
程式設計師的十大無奈
2 做程式設計師的女朋友幸福不？這個問題記得以前有人問過我女朋友，我當時當場回答那人，我說 做程式設計師的女朋友，不一定幸福，而做我的女朋友呢？絕對幸福 所以說呢，事在人為。3 程式設計師的生活單調不單調？對於生活，我無法用單調這個詞來形容，因為每個人都有自己喜歡的生活，可能我呢，喜歡看書，研究程式...
程式設計師的十大無奈
2 做程式設計師的女朋友幸福不？這個問題記得以前有人問過我女朋友，我當時當場回答那人，我說 做程式設計師的女朋友，不一定幸福，而做我的女朋友呢？絕對幸福 所以說呢，事在人為。3 程式設計師的生活單調不單調？對於生活，我無法用單調這個詞來形容，因為每個人都有自己喜歡的生活，可能我呢，喜歡看書，研究程式...