北京尚學堂|程序員的真實成長」礪程「

版權聲明：本文爲北京尚學堂原創文章，未經容許不得轉載。​

寫這篇文章的初衷是爲了來記錄一下我工做十一年來的一些點滴，但願對年輕的朋友有些幫助，有些啓發，至少是有些借鑑做用吧，少走些彎路。​

由於我發現我一路走來，幾乎都是本身在努力，沒有一個高人從旁給我點播，讓我能少走些彎路，我是想寫給十一年前剛剛畢業的我，但願那時的我能看到，若是真的能夠的話，我想，我如今應該能夠發展的更好吧。

第一階段：不知道本身不知道

大學期間，我和老師作過一些小項目，自認爲本身很牛，當時還去過一些公司面試作兼職，可是就是不知道爲何沒有回覆。那個時期的我，壓根不知道本身不知道，還覺得本身懂不少，如今想起本身之前就可笑，那個時候還算不上程序員，頂多只能算是個業餘編程愛好者。

我大學畢業了。對人生充滿了迷茫，沒有人給予我所謂的人生經驗的指引，一我的跌跌撞撞的開始找工做了。我考大學的時候，是計算機專業考分最高的一年，隨後就迎來了高校擴招，你們都知道計算機專業好，都奔着計算機專業來，等到我畢業的時候，迎來了計算機軟件行業最不景氣的時候。比我高的學長，剛畢業的起薪基本三、4K，可輪到咱們這一屆，就變成了區區的2K。

而我本身，還面臨着一個更難的難題---我沒有學位證。其實也不能說是沒有吧，只不過還沒拿到手，由於我到畢業前英語4級還沒過（提及來好丟人呀），畢業前的最後一次考試考完了，可是成績還沒下來，沒有四級成績，學校就不給發學位證。沒有學位證的我就這樣在面試時四處碰壁。幸運的是我畢業前那次考試過了，很快就拿到了學位。​

第二階段：知道本身不知道

那時之後，我幾乎每次都能經過筆試、面試，到了最後卻由於學位的問題沒有地方要。我甚至一度想要放棄作技術這一行，還去面試過技術類的銷售，也就是售前工程師吧，由於這個對學歷要求不高，又要懂些技術。不過還好我最後堅持到了，找到了一個我隨後堅持的工做——北京尚學堂。可能我能堅持這麼久，也是由於感激那時候能在我走投無路的時候幫到我吧。​​

2.1太懼怕學不會新的工具、語言和框架

通常的程序員會墨守他們最喜歡的工具，而不但願學習新的，由於他們認爲，離開了那些語言和工具，多年的經驗就會付諸東流。而強大的程序員會擁抱那些挑戰和機會，積極地學習新的工做方式。​

2.2直到特性「完成」的時候纔會提交。（但永遠都不會完成！）

有些程序員沒有足夠的信心來承受團隊中其餘成員的批評和審查，所以會把本身的工做藏起來，直到「完成」狀態才提交。

這種開發者會損害團隊中其餘人員的生產力，由於團隊看不到他天天的成果，並且他也不會在正常開發的過程當中尋求幫助，這樣就會形成不少「最後一分鐘」的缺陷，從而讓交付延遲。而強大的程序員會知道，代碼並非他們本身，所以會把代碼常常自信地呈如今其餘團隊成員的眼前，得到批評和建議。

第三階段：知道本身知道​

工做三四年後，本身的技能逐步提升，成爲了項目組的技術大拿，這時候也很自信，知道本身可以解決遇到的全部問題，這時候就是高級程序員階段了。​

3.1只是「知其然」會很危險

好比，以微軟最近在C# 5.0中引入的async和await關鍵字爲例，這兩個關鍵字會讓建立和管理異步調用變得很容易，可是也會形成上下文切換、對共享資源進行多線程訪問的成本，僅僅對此有基本瞭解的程序員會盲目地使用這些特性，把全部I/O調用都封裝成C#中的Task對象，這會建立出危險的、不可預測的並且很是難以測試的代碼。

好的開發者不只「知其然」，並且會了解爲何這麼作以及應該在什麼樣的條件下使用。

3.2 分析癱瘓（Analysis paralysis）

分析癱瘓是指在程序開發初期進行系統分析，常由於太過執着於控制全部可能的變化和意外，而形成大量時間的浪費，裹足不前。這是一種很經典的問題，會影響不少通常的程序員。它一般是由過分分析形成的，可是我認爲其根本緣由在於不敢作出壞的決定。通常的程序員會擔憂犯錯，只想一次成功。

而強大的程序員不會懼怕，他們會編寫很爛的代碼，對其進行單元測試，若是認爲沒法達到目的，就會在45分鐘以內把它拋棄。強大的程序員會積極地限制用來研究的時間，由於他們知道那是個陷阱——看起來是有效的，但常常都無效。​

3.3沒有對工具和開發過程投入

若是你想要成爲天才程序員，那麼就須要投入時間提高技能和知識，而將你和普通的代碼工人區分開來的是快速編寫出生產級別代碼的能力。你能夠同時擁有好的代碼和速度，可是你須要先對你用於構建的過程投入。

通常的程序員不會對工具、過程和環境投入，只會使用大量的時間學習新的語言特性和API如何工做，但那並不會改變什麼。

一般，你做爲程序員所可以作出的最大改進並非專一於你所編寫的代碼，而是優化你編寫代碼的過程。利用好工具能夠大大提高你的工做效率。

3.4羞於請求幫助

通常的程序員羞於或者不想讓人知道本身不懂，因此他們裝做什麼都知道，但這樣就有可能提交某種很是可怕的代碼到庫中。說「我不知道怎麼作。」沒什麼錯，強大的程序員知道這一點，因此當被問題難住的時候就會請求幫助。

第四階段：不知道本身知道​​

工做多年後，隨着本身知識的深度和廣度的提升，越學發現越不懂，有時好以爲本身之前真是浪費了太多時間。雖然以爲本身還有不少須要提升，可是對工做中遇到的問題基本沒有解決不了的，這個時候不少知識都自成體系，解決問題也有了本身的潛意識，有時連本身都不知道本身知道，這時候屬於架構師級別了。

4.1不知道如何讓其餘程序員更容易使用你的代碼

在全部技術團隊中，工做很重要的一部分就是人員的並行（human parallelism），也就是多我的可以同時對同一代碼庫工做的能力。可是對於團隊來講，可以異步工做也很重要，當你不在的時候我能夠修改你的代碼，反之亦然。

通常的開發者並不這麼認爲，他們會開始對一項任務編寫代碼，認爲他們會永遠擁有這段代碼。而強大的開發者會知道技術債務的說法，從而試圖經過設計代碼來對其限制，讓它儘量可維護和自解釋。

編寫可讀的代碼須要程序員改變他們的見解——你的代碼要比你在組織中存在的時間長。

4. 2不知道如何閱讀其餘人的代碼（或者不想讀）

當一位通常程序員看到用他所不熟悉的語言或框架編寫的代碼庫時，就想馬上重寫，而不考慮業務價值或者推向市場的時間。而強大的程序員會接受這樣的觀點，重寫所致使的業務成本一般是不可接受的，因此應該避免這種行爲。他們會試圖坐在計算機前，理解、學習而後修改現有的代碼。

閱讀代碼要比編寫代碼還難，可是強大的程序員會投入時間來學習如何超越。

4.3 不能從最終用戶的角度編碼（你考慮的範圍太狹窄）

有句話說得好：做爲程序員，你的工做不是解決技術問題，你之因此解決技術問題，是爲了解決業務問題。

通常的程序員只會陷在技術問題之中，而不知道最初是爲何要解決這個問題。更嚴重的是，通常程序員沒法從頭開始建立出具備業務價值的東西。當被要求基於簡單的用戶設計新特性的時候，他們會死板地、照着字面對故事或者說明書作出解釋，這樣交付的產品用戶根本沒法使用。由於他們不會考慮相關的用例；不會考慮最終用戶的體驗；而且在作面向用戶的內容時，設計都會很笨重。這致使他們沒法編寫業務應用，只能作產品。

好的程序員會從最終用戶的角度來看他們的代碼。我怎樣才能讓它更輕鬆地解決用戶的問題呢？故事的文字內容以外有哪些方面會讓這個特性給用戶帶來更多收益呢？

4. 4沒法判斷任何編程任務的業務價值

這個問題和上一個是相關的，不少技術上很強的程序員之因此沒法意識到本身的潛力，是由於他們不會停下來，從業務或者組織自己的角度去看一下他們的工做。

​

通常的程序員不會，他們只會拿着說明書，而後盲目地實現，直到結束，不關心他們的工做和公司的業務目標有什麼關係，以及對其餘團隊和業務組會產生什麼樣的影響。這樣，他們就會在業務價值很低的技術任務上浪費大量開發時間。​

我認爲

若是你想要成爲更好的程序員，那麼就要從改變你看待代碼以及編碼的方式開始。你須要理解所編寫的每行代碼背後的業務成本；你須要從客戶或者最終用戶的角度來看待工做；你須要接受代碼會比你在組織中存在的時間更長，因此要以其餘開發者可以繼承的方式來設計；最重要的，永遠都不要懼怕新的挑戰，也不要懼怕請求幫助，你沒法獨居一隅來提高工做效果，軟件開發也是社會化的工做。​

後記

以上就是我給你們分享我是如何走上編程這條路，以及一路的坎坎坷坷。可是這裏並無具體內容Java基礎、Java教程之類，不是我不推薦，而是內容過多不便作贅述，並且離我本身學習 Java基礎技術也過去好幾年了，我學習的時候看的什麼也忘了，因此我不能不負責任地推薦一些我本身都沒有看過的書給你們。對於Java基礎知識的學習， 我提兩點建議吧：

一、多寫多敲代碼，好的代碼與紮實的基礎知識必定是實踐出來的；

二、有學習意向和自學能力的同窗，能夠去北京尚學堂官網下載馬士兵和高淇300集的視頻來學習一下Java基礎，還挺不錯的，最近360雲盤即將下線，若是尚學堂官網上下載不了能夠底下回復，我分享給你們！​​

本文做者北京尚學堂原創，如需轉載請聯繫做者受權，未經受權，轉載必究。

須要更多資料微信掃一掃（資料領取驗證消息：156）