又到了一年一度回家過年的時候，不可避免的，又要和父母以及後續抵達的三姑六婆解釋這一年的職業歷程，忍不住想要賦詩一首：
每年回家像高考
親戚問題真不少
耐住性子好好答
否則春節過不好
那些年，關於工作，作為程式設計師的你都遭遇過哪些來自親朋好友的盤問或者是誤解？
「來給叔叔阿姨表演一段敲代碼」▼
「來幫我修個電腦吧」▼
「月薪五萬過得像月薪五千？」▼
「產品經理出車禍了是你幹的吧」▼
「小心被戴綠帽子啊」▼
「同一款式的格子襯衫你有 10 件吧」▼
「再出 Bug 就拿你來祭天」▼
「女程式設計師都是女漢子」▼
「還沒有脫髮是不是工作不飽和」▼
社會對咱們程式設計師的誤解實在太多了......這裡就不一一列舉了！做為一名程式設計師，沒有誰能比自己更了解程式設計師的生活了，每個程式設計師都有自己的理想，可是除了那臺破電腦還有什麼陪伴呢？
今天小編用動圖的方式帶大家了解程式設計師這個逗逼、可愛的群體。
程式設計師的生存狀態▼
雙核CPU的真相▼
當年學 C 語言的過程▼
測試環境一切 ok，馬上上線▼
調試 Bug▼
正在調試，突然內存溢出了▼
臥槽，你動我代碼，知道後果有多嚴重嗎▼
需求文檔又改了▼
資深程式設計師解釋如何用他的庫▼
單身網際網路狗的一天▼
過年回家，總少不了家人的盤問，身為程式設計師你是如何跟外行解釋編程的呢?
這篇回答並不是講述在生活中程式設計師如何買蘋果，而是以買蘋果為例說明程式設計師如何解決問題。
程式設計師需要對問題進行透徹的分析，理清其涉及的所有細節，預測可能發生的所有意外與非意外的情況，列出解決方案的所有步驟，以及對解決方案進行儘量全面的測試。
而這些正是我認為編程難的地方，任何一點遺漏都會成為 Bug，輕則導致挨罵，重則導致經濟損失甚至危害安全。
普通人：我今天要買一斤蘋果。
程式設計師：我今天要買一斤蘋果。
根據上述條件，我設計出以下的買蘋果的流程：
（以下區域，可以左右拖動查看完整內容）
買蘋果流程開始
對水果店0、水果店1、水果店2依次執行：
拜訪一家水果店流程開始
走到此水果店
如果此水果店沒有開門，則結束當前的「拜訪一家水果店流程」
如果此水果店沒有蘋果，則結束當前的「拜訪一家水果店流程」
如果此水果店的蘋果當中沒有紅富士蘋果，則結束當前的「拜訪一家水果店流程」
如果此水果店的紅富士蘋果剩餘不到一斤，則結束當前的「拜訪一家水果店流程」
如果此水果店的紅富士蘋果的價格高於10元/斤，則執行3次：
講價流程開始
詢問店主是否願意將價格降到10元/斤或更低
如果店主願意，則跳過剩餘的「講價流程」
講價流程結束
如果此水果店的紅富士蘋果的價格仍然高於10元/斤，則結束當前的「拜訪一家水果店流程」
打開一個袋子，將其作為當前的袋子
重複執行以下流程，直到總重量大於一斤：
裝袋一個蘋果流程開始
從所有的不在袋子中的紅富士蘋果中選出最好的一個
如果此蘋果能裝入當前的袋子，則將此蘋果裝入當前的袋子，否則執行：
換袋子流程開始
如果我有剩餘的袋子，則從中任意選出一個並作為當前的袋子，否則執行：
向店主要袋子流程開始
向店主索要一個袋子
如果店主拒絕給我袋子，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「拜訪一家水果店流程」
將店主給我的袋子作為當前的袋子
向店主要袋子流程結束
換袋子流程結束
測量我的所有袋子裡的所有蘋果的總重量
裝袋一個蘋果流程結束
根據我的所有袋子裡的所有蘋果的總重量和店主給出的價格，計算我應付的價格
向店主詢問我應付的價格
如果我不接受店主索要的價格，則執行3次：
校對流程開始
向店主解釋我計算出的價格，並詢問其是否同意
如果店主同意，則跳過剩餘的「校對流程」
校對流程結束
如果我仍然不接受店主索要的價格，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「拜訪一家水果店流程」
如果我沒帶錢，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「拜訪一家水果店流程」
付錢拿走蘋果
跳過剩餘的「拜訪一家水果店流程」
拜訪一家水果店流程結束
買蘋果流程結束
這個流程怎麼樣？我來設計一些測試樣例，測試一下這個流程。
測試發現一個問題：如果水果店 0 和水果店 1 都有紅富士蘋果並且價格都低於 10 元/斤，而且水果店 1 的價格比水果店 0 更低，那麼我希望買水果店 1 的蘋果，但我設計的流程會讓我買水果店 0 的蘋果。
為了解決這個問題，我應該先詢問所有水果店的價格，然後去價格最低的那一家買蘋果。
經過修改，我重新設計出以下的買蘋果的流程：
（以下區域，可以左右拖動）
買蘋果流程開始
對水果店0、水果店1、水果店2依次執行：
詢問一家水果店的紅富士價格流程開始
走到此水果店
如果此水果店沒有開門，則視此水果店的紅富士價格為無窮大元/斤，並結束當前的「詢問一家水果店的紅富士價格流程」
如果此水果店沒有蘋果，則視此水果店的紅富士價格為無窮大元/斤，並結束當前的「詢問一家水果店的紅富士價格流程」
如果此水果店的蘋果當中沒有紅富士蘋果，則視此水果店的紅富士價格為無窮大元/斤，並結束當前的「詢問一家水果店的紅富士價格流程」
如果此水果店的紅富士蘋果剩餘不到一斤，則視此水果店的紅富士價格為無窮大元/斤，並結束當前的「詢問一家水果店的紅富士價格流程」
向店主詢問此水果店的紅富士蘋果價格並記錄
詢問一家水果店的紅富士價格流程結束
從3家水果店中選出紅富士價格最低的一家（如果有並列則隨機選擇），將其作為目標水果店
如果目標水果店的紅富士蘋果價格為無窮大元/斤，則結束當前的「買蘋果流程」
走到目標水果店
如果此水果店的紅富士蘋果的價格高於10元/斤，則執行3次：
講價流程開始
詢問店主是否願意將價格降到10元/斤或更低
如果店主願意，則跳過剩餘的「講價流程」
講價流程結束
如果此水果店的紅富士蘋果的價格仍然高於10元/斤，則結束當前的「買蘋果流程」
打開一個袋子，將其作為當前的袋子
重複執行以下流程，直到總重量大於一斤：
裝袋一個蘋果流程開始
從所有的不在袋子中的紅富士蘋果中選出最好的一個
如果此蘋果能裝入當前的袋子，則將此蘋果裝入當前的袋子，否則執行：
換袋子流程開始
如果我有剩餘的袋子，則從中任意選出一個並作為當前的袋子，否則執行：
向店主要袋子流程開始
向店主索要一個袋子
如果店主拒絕給我袋子，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「買蘋果流程」
將店主給我的袋子作為當前的袋子
向店主要袋子流程結束
換袋子流程結束
測量我的所有袋子裡的所有蘋果的總重量
裝袋一個蘋果流程結束
根據我的所有袋子裡的所有蘋果的總重量和店主給出的價格，計算我應付的價格
向店主詢問我應付的價格
如果我不接受店主索要的價格，則執行3次：
校對流程開始
向店主解釋我計算出的價格，並詢問其是否同意
如果店主同意，則跳過剩餘的「校對流程」
校對流程結束
如果我仍然不接受店主索要的價格，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「買蘋果流程」
如果我沒帶錢，則將我的所有袋子裡的所有蘋果取出，然後結束當前的「買蘋果流程」
付錢拿走蘋果
買蘋果流程結束
現在這個流程是不是完美了呢？不是，我還能發現很多問題。
如果 3 家水果店都有紅富士蘋果但都不到一斤，但是三家店加起來能達到一斤，那麼我不應該結束流程回家，而是應該把三家店的紅富士蘋果都買下來。
如果我向水果店詢問價格的時候這家店還有紅富士蘋果，但我詢問完所有水果店的價格後這家店的紅富士蘋果賣完了，那麼我的流程會讓我試圖處理不存在的紅富士蘋果。
我走路的過程中可能會遇到突發事件，比如發現了新的水果店，比如袋子破掉了蘋果掉一地，對於這些情況我的流程都無法進行處理。
啊......問題太多了我懶得再改流程了，我還是去 X 寶買吧。那麼接下來我要設計一個在 X 寶買紅富士蘋果的流程……
最後送給大家一份關於程式設計師的搞笑但卻真實無比的編程語錄。
我收集了很多編程語錄，基本上都跟程式設計師的生活有關。這些語錄涉及軟體開發，代碼維護，調試糾錯，軟體 Bug，系統設計、文檔，代碼質量，測試和軟體開發團隊管理等方面。
下面的這 59 條語錄雖然很搞笑，但卻真實無比，只有程式設計師才能理解這些編程語句裡的真正內涵。閒言少敘，開始吧…
一個好的程式設計師是那種過單行線馬路都要往兩邊看的人。(Doug Linder)
程序有問題時不要擔心。如果所有東西都沒問題，你就失業了。(軟體工程的Mosher定律)
程式設計師的麻煩在於，你無法弄清他在搗騰什麼，當你最終弄明白時，也許已經晚了。(超級計算機之父Seymour Cray)
我想大部分人都知道通常一個程式設計師會具有的美德。當然了，有三種：懶惰，暴躁，傲慢。(Perl語言發明者Larry Wall)
編程時要保持這種心態：就好象將來要維護你這些代碼的人是一位殘暴的精神病患者，而且他知道你住在哪。(Martin Golding)
一個人寫的爛軟體將會給另一個人帶來一份全職工作。(Jessica Gaston)
如果建築工人像程式設計師寫軟體那樣蓋房子，那第一隻飛來的啄木鳥就能毀掉人類文明。(Gerald Weinberg)
這世界最有可能毀滅的方式——大多數專家都同意——是次意外。這就是為什麼會有我們，我們是計算機專家，我們創造意外。(Nathaniel Borenstein)
我們這個行業有個特別奇怪的現象：不僅我們不從失敗裡吸取教訓，同時也不從成功中學習經驗。 (Keith Braithwaite)
一種新技術一旦開始流行，你要麼坐上壓路機，要麼成為鋪路石。(Stewart Brand)
如果沒能一次成功，那就叫它 1.0 版吧。(unknown)
所有的程式設計師都是編劇，所有的計算機都是爛演員。(Anonymous Hack Actor)
工作進度上越早落後，你就會有越充足的時間趕上。(Anonymous Scheduler)
當有這樣的一種程式語言出現：它能讓程式設計師用簡單的英語編程，你將會發現，程式設計師都開始不會說英語。(Anonymous Linguist)
為什麼我們沒有時間把事情做對，卻總有時間把事情做過頭？(Anonymous)
傻瓜都能寫出計算機能理解的程序。優秀的程式設計師寫出的是人類能讀懂的代碼。
任何你寫的代碼，超過 6 個月不去看它，當你再看時，都像是別人寫的。(Eagleson’s law)
按代碼行數來評估軟體開發的進度，就如同按重量來評估飛機建造的進度。(比爾-蓋茨)
軟體就像做愛。一次犯錯，你需要用餘下一生來維護支持。(Michael Sinz)
在水上行走和按需求文檔開發軟體都很容易——前提是它們都是凍結狀態。(Edward V Berard)
最初 90% 的代碼用去了最初 90% 的開發時間…餘下 10% 的代碼用去了另外 90% 的開發時間。(Tom Cargill)
注釋代碼很像清潔你的廁所——你不想幹，但如果你做了，這絕對會給你和你的客人帶來更愉悅的體驗。(Ryan Campbell)
如今的編程是一場程式設計師和上帝的競賽，程式設計師要開發出更大更好、傻瓜都會用到軟體。而上帝在努力創造出更大更傻的傻瓜。目前為止，上帝是贏的。(Rick Cook)
軟體設計最困難的部分…是阻擋新功能的引入。(Donald Norman)
為了理解遞歸，我們首先要理解的是遞歸。(Anonymous)
世上只有兩類程式語言：那些擁有被人詬病的和那些沒人用的。(Bjarne Stroustrup)
The best thing about a boolean is even if you are wrong, you are only off by a bit. (Anonymous)
如果Java能實現真的垃圾回收，那大部分的程序都會在執行時刪除自己。(Robert Swell)
理論上，理論和實踐是沒有差異的。但實踐中，是有的。(Jan L. A. van de Snepscheut)
預備，開火，瞄準：這是最快的軟體開發方法。預備，瞄準，瞄準，瞄準，瞄準：這是最慢的軟體開發方法。(Anonymous)
編程是 10% 的科學，20% 天份和 70% 的讓這天份符合科學。(Anonymous)
評估一個事情要比去理解你評估了什麼容易。(Anonymous)
測評不會撒謊，但測評的人會。(Anonymous)
培養員工，即使他們有跳槽的風險。什麼都不做而留他們在公司，這樣風險更大。(Anonymous)
計算機科學的目標是做出一個東西，並且保證它至少能堅持到我們將它開發完成。(Anonymous)
Java 之於 JavaScript 如同 Car 之於 Carpet。 (Chris Heilmann)
起初就把事情做對是完全沒必要的。但最後要把事情做對是絕對必要的。(Andrew Hunt and David Thomas)
數組的起始索引應該從 0 開始還是從 1 開始？我的 0.5 的折中提議被他們未經認真考慮就拒絕了——我認為是這樣的。(Stan Kelly-Bootle)
程序必須是為了給人看而寫，給機器去執行只是附帶任務。(Abelson / Sussman)
編程可以很有趣，你可以用它做密碼學研究，但兩者絕對不能合二為一。(Kreitzberg and Shneiderman)
拷貝-粘貼是一種設計錯誤。(David Parnas)
計算機善於遵循指令，但不善於理解你的思維。(Donald Knuth)
刪除的代碼是沒有 Bug 的代碼。(Jeff Sickel)
如果糾錯是消除軟體 Bug 的過程，那編程一定是把它們放進去的過程。(Edsger Dijkstra)
代碼糾錯要比新編寫代碼困難一倍。因為，如果你寫出了最聰明的代碼，按此推算，你將沒有更大的智慧來 debug 它。
想在自己的代碼裡找出一個錯誤是十分困難的。而當你認為你的代碼沒有錯誤時，那就更難了。(Steve McConnel)
這不是個 Bug——這是一個未註明的功能特徵。(Anonymous)
沒有需求或設計，編程就是一種將bug添加到一個空文本文件裡的藝術。(Louis Srygley)
爛代碼並不爛，只是被誤解了。(Anonymous Code Behaviorist)
有兩種方法能寫出沒有錯誤的程序；但只有第三種好用。(Alan J. Perlis)
小心上面代碼中的 Bug；我只知道這些代碼是正確的，但沒有試過。(Donald Knuth)
軟體能夠復用前，它必須要可用。(Ralph Johnson)
軟體通常在 beta 測試完成不久後發布。Beta 在拉丁語中是「還不能用」的意思。(Anonymous)
最好的性能改進是將軟體從不能用的狀態變成可用。(J. Osterhout)
最廉價、最快速、最可信賴的組件是那些還未出現的組件。(Gordon Bell)
I think Microsoft named .Net so it wouldn’t show up in a Unix directory listing. (Oktal)
軟體和教堂非常相似——建成之後我們就在祈禱。(Sam Redwine)
除非最後一個用戶死掉，軟體是不會有完工的時候的。(Anonymous)
如今的大部分軟體都非常像埃及金字塔，由成千上萬的石塊一個摞一個構成，沒有結構上的集成，是由暴力強制和成千上萬的奴隸完成。(Alan Kay)
身為程式設計師的您，是否曾經也被誤解過呢？如果是你，如何向外行解釋編程？歡迎底部留言分享！
長按下方圖片
識別二維碼 關註腳本之家
♡ 版權聲明：轉載文章和圖片均來自公開網絡，版權歸作者本人所有，推送文章除非無法確認，我們都會註明作者和來源。如果出處有誤或侵犯到原作者權益與我們聯繫刪除或授權事宜。