這可以看做是典型的程式設計師思維，只不過略顯誇張，作為一個十多年的程式設計師，我覺得程式設計師思維確是給生活帶來很多影響和改變，但還是正面的居多,舉兩個例子。

if-else

開頭的笑話，那個程式設計師一定是這樣寫：

我覺得應該是這樣:

做比較複雜的事情，程式設計師的腦海總會想畫出一份設計圖，特別是有選擇的事情，總是自覺地在腦海裡先寫一遍if-else判斷，我覺得只要思路快，這樣還是挺好的，做事更有條理。

bug

這個應該也是程式設計師思維的通病吧，看到什麼東西運轉不管正常不正常，總會想是不是有bug，比如做電梯的時候，我和同事們討論最多的就是電梯的演算法是什麼，怎麼個按法會把電梯按出bug。或者是使用網站或者APP的時候，完全沒有惡意，總是出於本能的想進行一些不符合平常習慣的操作，看看能不能發現bug。

總之，有了程式設計師思維，感覺做事嚴謹了，邏輯清晰了，安全意識提高了，執行力強了，最近還把程式設計師思維和投資結合了起來，也就是量化投資。。。

發生在我身上的真實的事情，本人軟體技術專業在校大學生，大二的時候去學屋做兼職，主要工作是輔導三四年級的數學。

有一次我輔導的學生有一道數學的排序題不會做，然後我很認真的給他們講了排序的方法。我的學生表示一點沒聽懂，然後我又給他們講了一遍他們還是沒聽懂，當我給他們講第三遍的時候他們的表情是這樣的

我分明講的那麼明白，告訴了他們各種方法與每一種方法的排序步驟，他們為什麼還是不明白。後來我才想明白，原來——我給他們講了資料結構中的冒泡、插入、歸併三種排序演算法...那群小學生怎麼可能聽的懂

我這個還沒成為程式設計師的學生都會有這種情況，更別說專業的程式設計師了。

其實這種事情也很正常，如果覺得程式設計師思維對生活有影響是很奇怪的一件事情，你可以將這種事情理解為一個詞語——職業病。是不是覺得很正常了

結果是程式設計師丈夫拿著一個包子回了家。

老婆問為什麼呢？

雖然這只是一個笑話，但是我們不難看出，程式設計師的思維都是設定思維，條件思維模式。

一般人需要換個思維理解。

我是一名前端工程師，程式設計師的思維對我最大的影響就是： 每次瀏覽網頁，看到精美的網站或者特別難用的網站，情不自禁F12或者直接ctrl+alt+j或者滑鼠右鍵檢查元素; 看network去檢視響應時間。

看到精美的網站，是出於學習的目的去研究，讓自己更進一步。看它的html標籤佈局。學習新的語義化標籤，好的佈局會使DOM操作清晰明瞭，對於SEO和js操作都有很好的便利性。看它的css用了什麼特性。尋找有沒有自己不知道的好用的特性，有的話就去MDN查詢，記到筆記上，並做實驗驗證。看它用了什麼框架或者小而美的js庫。如果沒用庫的話，思考這個網站為什麼用原生js就能做的這麼好，自己怎麼就不會呢，反思並回頭複習;如果用了庫，說明這個庫有市場，在腦子裡面留下印象，以後使用的時候，記得用過，可以對這個庫的使用場景、能完成的功能有一定的瞭解。看到特別難用的網站，是出於反思的目的去學習，為什麼難用，自己要避免難用的使用者體驗要避免。例如：有些網站的點選按鈕或者候選項，只有點選○中間才能算點選，可是通常使用者會優先點選到按鈕或者候選項的文字部分，應該用label標籤包裹起來或者把label標籤的for屬性指向與之關聯的標籤的id屬性，類似這種html最佳化的方式，要經常總結挺高，把使用者體驗做好。頁面載入過慢。檢視是因為圖片沒有最佳化還是沒用快取機制，大圖不應該直接過去，必須最佳化，嘗試把不經常變動的大的js檔案快取起來，每次重新整理直接從記憶體快取或者硬碟快取獲得，使用HTML 5的localstorage做持久化，或者用cache-control。

以上是前端工程師思維對我生活的影響，歡迎大家一起交流～

有什麼影響？從此數數都從0開始算不算。

說起程式設計師思維給我生活帶來的好處，有些說出來，大家可能會說，原來這就是程式設計師思維啊？

抽象、畫流程、想分支

寫程式碼之前，會在腦子裡面串整個流程並寫出來虛擬碼，也就是程式第一步怎麼寫，第二步怎麼寫，這裡有幾種情況，需要怎麼判斷，每種情況的處理是怎麼樣的。於是在生活中也習慣使用“寫虛擬碼”的方法，把一個複雜的事情簡化成幾步，每一步要做什麼，達到什麼樣的目標之後再進行下一步。

找BUG

程式設計師難免要閱讀別人的程式碼，閱讀別人程式碼的時候，大部分時候邊看邊想“寫的真爛”，然後開始找BUG，以證明自己的看法是對的。

所以生活中，時不時的就要找找別人的BUG，雖然我不行，我也不上，但你就是錯的。

比如，讓我腹誹的一件事兒，上下班路上要走一段高速的輔路，短短兩公里的路上無數個井蓋，我就服了這井蓋的位置，我要是線內直著走一定會壓井蓋，想跨過井蓋就一定會騎著線，我覺得這個就是個大大的BUG。

這種思維方式帶來的好處，可能就是讓我更留意觀察生活吧。

程式設計師的慣性思維，比如看到雙十一有的商品是0點結賬，有的是1點才能結賬，我就會好奇為什麼要分開？

結合前幾年雙十一的巨大流量，我分析的原因是分流，即如果大家都趕在0點下單，會對結算系統有巨大的流量衝擊，極有可能造成崩盤，如果令一部分商品必須在1點才能結賬，無形之中就緩解了0點時候的系統壓力，而且要在1點結賬的人通常還會為了消磨時間繼續逛，說不定就會又下單買了些什麼，真的是一個一舉兩得的好辦法。

上面就是一個例子，是想說看到很多網際網路公司的策略的時候，會情不自禁的從技術的角度去分析策略的制定原因。

接下來再舉幾個例子和大家分享下。

比如路邊的廣告燈牌，其實是有N*M個小小燈泡組成的，從一個燈泡的角度來說，只有亮（1）和不亮（0）兩種狀態，但是透過操作全體燈泡，卻能營造出文字流動的效果。我就很喜歡去推算這種演算法的邏輯。

再比如平時做事，很喜歡用程式設計師拆解大功能到不同子方法並引入高併發的這樣的思維。就比如說我要做飯，這個時候，會首先把整個流程分為買菜，洗菜，切菜，下鍋，但是如果要同時做幾道菜的話，我會進一步想如何高併發的操作能最快完成整個烹飪過程呢，比如泡著菜的時候去切即將下鍋的菜，菜在鍋裡不需要翻的時候去把泡著的菜洗出來，等到只剩烹飪又不用盯著鍋的時候，把洗菜切菜的廚具清洗乾淨等等。這一整套流程看起來就是一個精明的家庭主婦會做的，但是其實裡面就使用了分解與高併發呀，假設你是準備完一道菜，烹飪一道菜，出鍋一道菜再準備下一道菜，那這個過程就是序列的，而你作為核心CPU，就會浪費很多時間在等待上了呀。

程式設計師思維最好的一點是講究邏輯，我相信這個社會是邏輯驅動的，因此這種思維也給我的生活帶來了很多便捷。