為什么寫這篇文章？
我發(fā)現(xiàn) 很多程序員都不想做一輩子的程序員，包括我周圍的程序員朋友也跟我說 當(dāng)他看到公司來了一名四十多歲的程序員時，他心情是焦慮的，因為他不想自己四十多歲了還坐在電腦面前寫代碼。
聽了之后，我不知道該怎么接？
這種想法會產(chǎn)生一個阻力，這個阻力會阻礙我們成為更優(yōu)秀的程序員。當(dāng)然這種想法或許已經(jīng)透漏出 成為優(yōu)秀的程序員 已經(jīng)沒有誘惑力了。
那么，既然沒有誘惑力，為何你還在苦逼編程？
我寫這篇文章并不是希望你轉(zhuǎn)行，而是想說 其實編程不僅僅是編程。
不管從事什么行業(yè)，也不管學(xué)的什么專業(yè)，其實它們之間都是互通的。
例如編程，不要只看編程本身，看到更多的應(yīng)該是在編程過程中如何提升我們的認(rèn)知的?；蛘?如何通過編程來提升我們的認(rèn)知？
根據(jù)芒格的格柵理論，我認(rèn)為就是所謂的跨界學(xué)習(xí)。也就是說 不同的專業(yè)學(xué)術(shù)，都有它的思想理念，掌握這些思想理念，將其納入自己的思維格柵中，它能幫助我們在多個維度來分析問題，從而作出更理性的決策。
我目前差不多近三年的編程經(jīng)驗了(不多也不少吧)，下面我分享一下 編程給我?guī)砹四男┧季S上的提升：
這里我分了三個小節(jié)，分別是：
- 程序設(shè)計過程
- 程序編碼過程
- 程序測試過程
程序設(shè)計過程
在一開始程序編寫過程也許不存在設(shè)計過程。但慢慢會發(fā)現(xiàn) 如果沒有良好的設(shè)計，程序在未來維護(hù)起來是很困難的。
甚至不需要等到維護(hù)階段，在測試過程中 就會發(fā)現(xiàn)各種偶然性問題，偶然性問題的根本原因不是出自偶然，而是程序流程混亂導(dǎo)致的。
想到這種問題的根本原因在于：
一種思維模式：
程序的一種特征是 指定一個輸入 必然會有一個對應(yīng)的輸出。程序是單純的。
所以 一個錯誤的輸出 肯定來源于一個錯誤的輸入。
而程序又是一段一個接一個的執(zhí)行過程，所以錯誤的輸出 肯定是因為這個流程中出了問題。
這種思維方式對我們測試程序很有幫助。
這應(yīng)該算是一種看待世界的方式既：
如果要解決問題 就要找到問題的根本原因。
就像我們分析源碼的目的一樣，“知其然 也要知其所以然”，相信所有事物運轉(zhuǎn)正常都有它內(nèi)在原理。
偶然性問題也許是因為：
- 它也許不是真的能工作
- 你依靠的邊界條件也許只是一個偶然，在不同情形下 它的表現(xiàn)可能就會不同
- 也許你都不知道它為什么能工作
...
解決偶然性問題的方法就是在編碼之前做好程序的設(shè)計工作。
主要設(shè)計包括：
- 程序結(jié)構(gòu)設(shè)計
這種設(shè)計 可以提升我們的抽象思維。
這種結(jié)構(gòu)設(shè)計 就是我們經(jīng)常說到的 模塊化、組件化等架構(gòu)相關(guān)的內(nèi)容。
它需要我們將一個復(fù)雜的東西 拆分成具體可實施的小模塊。
這也是一種思維模式：
將復(fù)雜問題 分解成多個可解決的問題。
這種思維模式同樣也可以運用在其它領(lǐng)域。
如何運用的呢？
碰到一個難解的問題，就試著分解這個問題，分解到具體可以實施的地步，再一個一個的解決。
模塊化、組件化等架構(gòu)設(shè)計的目的是為了解藕。解藕的目的是便于管理。
這種思維模式可以運用到管理中，就是我們經(jīng)常見到的 各司其職。
上到國家管理 下到公司的管理，都是如此。
- 程序流程設(shè)計
簡單來說 就是如何讓程序跑起來正常、可控。
首先就是如何保證正常，比如：處理同步異步問題的方法。
讓整個流程是正常的，也就是上面所說的 非偶然性的正確輸出。
可控，在以后新增、更改需求也能保證流程正常。
這里就涉及到了各種設(shè)計模式，以及一些編程語言
(很多編程語言之所以能提升效率 我認(rèn)為就是它的設(shè)計能讓程序更加可控，例如：函數(shù)式編程里函數(shù)作為一等公民，可以像普通變量一樣傳遞，讓我們省心去設(shè)計一些復(fù)雜的東西，因為每多寫一行代碼 可能就會多一個bug)
在其它領(lǐng)域中的應(yīng)用：
比如：工廠的流水線設(shè)計、各種流程手續(xù)的辦理等。
正常 就類似于 流水線能夠正常運轉(zhuǎn)；
可控 就類似于 在流水線中間加入一個環(huán)節(jié)或者減少一個環(huán)節(jié) 不會干擾到其它環(huán)節(jié)。
程序編碼過程
有了設(shè)計過程，編碼過程就應(yīng)該是按照設(shè)計合約來完成的。當(dāng)然設(shè)計也不能保證完美無缺，所以在編碼過程中 如果發(fā)現(xiàn)設(shè)計有問題或者是設(shè)計過程未想到的場景，應(yīng)該更新設(shè)計(剛開始做設(shè)計會經(jīng)常出現(xiàn)設(shè)計不完善問題)。
在這個過程中能讓思維更加謹(jǐn)密。
在其它領(lǐng)域也一樣，這種謹(jǐn)密的思維 能減少出錯的機率。
測試過程
我們程序員都知道，不管代碼寫得多優(yōu)雅、流程多風(fēng)騷，都需要來一場測試拼殺。
測完得到了一堆bug，往往能給我們更多反思，測試之前的自信哪來的？
或者是，
我就知道會有這么多bug，因為我寫得爛嘛～
然后就是一個一個的解決它，BUT，沒那么容易
在 bug 的解決過程中，你又會發(fā)現(xiàn) 如果一個問題解決方法不對 這個解決方法又會產(chǎn)生新的問題。
也或許是因為對問題的定義不對而導(dǎo)致的。
所以說，問題的定義決定了問題的解決方法，而問題解決方法又決定了新問題的來源。
所以 “我們有必要對方案實施后可能產(chǎn)生的后果進(jìn)行預(yù)判”
但 就算進(jìn)行了預(yù)判，之后又可能出現(xiàn)其它問題。
不過 就算永遠(yuǎn)無法確定已經(jīng)找到的問題定義是正確的，但是永遠(yuǎn)不要停下來尋找正確定義的腳步
這是不是也算一種人生的態(tài)度呢？
回到開頭，為什么 不想做一輩子程序員？這個問題的本質(zhì)是什么？
是因為程序員太累？還是覺得做一輩子程序員沒出息，工資太低？或者是覺得自己應(yīng)該干一番大事，而做程序員格局太小了？
問題的本質(zhì)其實就是在于理想與現(xiàn)實之間的區(qū)別。
如何解決這個問題，就看你怎么定義這個問題了。
我覺得編程確實可以給我們程序員帶來很多提升，能有多大提升 這就在于你有多在意它。而把編程思維納入到我們自己的思維格柵中 不管未來從事什么行業(yè)，都是很有幫助的，所以說了這么多 其實就是好好的對待你的代碼吧。哈哈～
