技術的進步日新月異，作為一個新手程式設計師，你可能會不知所措，手忙腳亂，畢竟今天掌握的知識技能，有可能明天就過時了。再加上經驗的缺乏，從事軟體開發這個工作只會更加困難。但是要知道，每一個大牛都是從新手期，一步步成長起來的，所以要有信心。那麼，該如何做才能快速的成長起來呢？

對於有經驗的開發人員來說是基本技能的原始碼控制，但對於新手來說，就不是那麼容易了，或多或少都會遇到一些困難。想要紮實自己的技能獲得成長，那麼不僅僅需要掌握，每個開發人員都應該掌握的pull、commit和push這些基本命令，還需要掌握如何將檔案放入暫存區、如何合併衝突，並瞭解建立補丁程式和發行版本的基本流程；要了解這些功能背後的理論，瞭解每個功能的用途以及使用的時機。

編寫程式碼，是佔據程式設計師大部分工作時間的內容，但對於新入程式碼世界的新手程式設計師來說，可能就是一個很大的挑戰。程式碼的編寫，應該儘可能的簡單明瞭，避免將簡單的問題複雜化。對於新手程式設計師來說，經歷一次完整的開發週期，去完成一個專案，不僅可以更好的瞭解工作的流程，專案涉及的範圍，也可以開拓自己的視野，從而提升自己的能力。

初入程式碼世界的新手，知識和經驗肯定是遠比不上一般的開發人員的，這是事實。因此，不斷學習很重要，你需要不斷縮小晉級下一級別所需的知識鴻溝，不斷的去學習，去汲取資訊。你可以檢視其它開發人員寫好的程式碼，去看他們解決問題的方法；如果有機會與另一位隊友結對程式設計，那麼應該牢牢抓住機會，一邊寫程式碼，一邊說出你的想法，讓隊友瞭解你的思考過程，並相應地提供反饋；最後你必須透過大量程式設計，來犯錯，改正，推動自己的進步，這是提升自己技能，推動自己成長的最好方法。

這篇文章的標題定的很大,說實話我不知道自己有沒有資格在這裡對如此之多的”網際網路行業未來從業者”的職場起點說三道四.雖然我無法像眾多前輩一樣在部落格論壇中站在一個從業多年的技術經理或技術專家的角度來談程式設計師的職業規劃,但對於”程式設計師職場的起點”這個話題,你將要面對的一切都是我不久前所經歷的,並且我深知此刻初入職場的你需要這些建議!初入職場,對一個程式設計師來說最重要的是什麼?

”初級程式設計師應有的職業規劃,

1. 技術基礎

2. 業務積累

3. 職場情商技 術基礎是指作為一名程式設計師來講的一些基本的、通用的技術,諸如資料結構、演算法、數學能力、軟體工程理論、作業系統基本知識、編譯原理以及你所從事的技術崗 位所使用的技術。

這些是學校裡教給你的東西,無論學得怎麼樣,在你的程式設計師生涯中它們都將跟隨你一輩子,因為無論你從事什麼技術崗位,在這個行業中,這些東西都是共通和必 要的,身為一名軟體工程師的立足之本.業務積累指的是你在部門裡邊具體承擔的業務,相對前一條 來說,這一條是不存在行業中的普遍性和通用性的, 然而如果說前面一條是使你順利拿到校招offer的前提,那麼這一條則是你所在的公司每個月付給你”比任何一個行業的任何職位在初期都要高得多”的薪資的 理由. 換言之,如果你是一名實習生而你手上卻沒有任何業務積累,你該為自己能否得到offer而感到忐忑,而相反的情況如果你手上已有很多業務,每天忙得要命, 你也該清楚現在的這個部門給你發offer應該是板上釘釘的事了.第三點也許是最容易被我們程式設計師這樣一個群體所忽略的——情商.

這也是本文真正想要表達的重點,是我想在這篇文章中給你的建議.程式設計師的情商有那麼重要嗎?引用大家所熟知的OOP的思想,無論你是一名服務端、Android還是機器學習演算法、資料探勘工程師,你的職位title都是從軟體工程師這個父類繼承下來的,而軟體工程師這個職位繼承於工程師,更繼承於”公司職員”.但凡是一名公司職員,就免不了職場中的人情冷暖、酸甜苦辣.因為身處公司最基層,每一個工作日你無法避免的要與各種人和事打交道.說的直白一點,有人的地方就有利益,職場中人與人之間的利益不可能沒有衝突.當你的個人利益與其他同事的個人利益、團隊利益甚至公司的利益發生矛盾時,你至少應該清楚沒有哪個職場人能夠避免這一點.在諸多利益交織下,到一定程度以後你會明白始終維持著這一切的不是別的,是人情!那些充滿”正能量”的新員工培訓可能告訴你什麼”主人翁意識”什麼”不想當老闆的員工不是好員工”,

然而在現階段對你來說最重要的卻是融入團隊,和你身邊的同事還有領導搞好關係.如果你跟部門裡的任何一位同事關係鬧僵,我敢保證在這個公司裡你將舉步維艱,每天上班的心情猶如上墳.情商體現在哪裡?對於一名初入行業的軟體工程師來說,你不只需要和程式碼打交道,更需要與產品溝通需求、向領導彙報工作進度以及跟其他技術崗位的同事協商和聯調程式碼.我從沒見過或是聽過哪個公司的哪個專案可以從產品策劃到UI設計再到前後端程式設計開發除錯測試上線釋出後續運營維護等工作全部由一個人來完成的,如果有,這也一定不常見.我知道校招生們多數願意進BAT這些大公司,我當年也不例外,並且回頭看來這一步也確實沒有錯,大公司給你的不只是更高的起薪以及畢業時在老師們面前優人一等的光環,更重要的是你將會認識更多和你一樣優秀的同齡人,你的視野將會更開闊.

然而細細想想在一個大公司裡,我們工作的更多時間是開會而不是寫程式碼.捫心自問在一個公司裡幹了一個月以後,你究竟寫了多少行程式碼?你又開了多少個會?這 不叫效率低下,在公司體制龐大以後這些溝通我認為全都是必要的,這些花在管理和溝通上面的成本對公司來講絕對值得,就像一塊硬碟能存下多少資料就必須產生 相應的區塊儲存資料的物理地址和邏輯地址, 再加上系統級的記憶體管理、應用級的框架消耗和垃圾回收,仔細想想我們每天使用的手機、平板和電腦裝置的更多記憶體資源和CPU使用其實都是消耗在了裝置自身 對資料的管理上,機器尚且如此,更何況人呢.所以不要對開會產生反感,每一次會議都是你學習的機 會,更是你表現自己的機會.如果在一次會議上你提出了一處UI設計稿上面的缺失剛好是你的leader沒考慮到的,他下次還會帶上你一起開會; 如果在服務端Rest介面確認的過程中你想到了一個leader們沒考慮到的資料項,這很可能為整個開發週期節省一到兩天;

與產品溝通需求時,並不是一味地否定和砍減需求,也不是毫不過腦子的點頭,你應該設身處地的站在把一個產品做到盡善盡美的角度去跟對方溝通,刪掉對大家都 沒有利益的需求,必要的時候甚至增添一個對雙方都有收益的需求.這一切都能夠讓你的工作狀態更為積極,而積極的工作狀態對你對公司對所有人都是有利的.初期應該如何融入團隊?

幸 運的是程式設計師畢竟男多女少,因為我想舉的例子和足球有關.我很愛看球,我們往往關注的都是那些場上閃耀的球星,然而任何一個年輕的小球員在初入球隊時都是 從替補席冷板凳坐起的, 哪怕你是羅納爾多這樣的超級巨星(球迷們不要怪我,只是我覺得拿大羅來舉例相對爭議小一些).初入職場的你,就如同一個剛進入球隊坐在替補席上的小球員一樣,最初很可能連90分鐘末補時的那幾分鐘上場機會對你來說都是無比珍貴.在這種情況下,要學會撿別人不要的活兒幹,而不是坐在工位上開啟qq和同學抱怨自己在部門裡不受重視.舉個例子:如果說部門裡缺前端,你作為服務端也該自己學會寫後臺管理頁面,這些東西leader看在眼裡,他會明白你的努力.另外千萬不要放過任何和同事們溝通的機會,哪怕是午餐時的閒談.這恰恰是發現一些”可撿的活兒”的一個途徑.遇到技術上的問題該怎麼解決?對於這個問題的看法有很多版本,我個人偏向於盡量靠自己解決問題.原 因有二:第一個原因是作為一名初入崗位的工程師,不是看不起你,很多時候你對自己遇到的問題究竟該不該問別人,該問的話該問誰你都是不知道的.在這樣的情 況下, 你很可能把一個google五分鐘就能解決的程式語法報錯拿過去問了你的同事,問問題存在溝通成本和理解成本,你的描述不清以及對方缺乏上下文了解這些都 可能增加以上兩個成本, 這樣一來不僅耽誤雙方的時間,長此以往還會讓對方覺得你的技術基本功不紮實,獨立處理問題能力差.第二個原因是,即使這個問題真的是一個較為冷門的程式設計語 言執行環境層面的bug, 你在不經過任何思考的前提下把它拋給了你的導師或是你的leader,

他很可能是遇到過這個問題的,於是直接把問題的答案告訴了你,這樣你就完美地錯過了 一次在你所使用的語言環境下親自踩坑然後填坑的機會.我認為對於程式設計師來說,總有一天你要獨立 面對這些編譯環境、執行環境的偏門bug,因為你不可能一輩子只寫一門語言或是隻從事一種開發崗位,你現在可以問你的導師問你的leader, 那麼你自己當上leader之後又該問誰呢?總不能告訴自己的老闆,這問題太難了,我解決不了.我記不清好像是之前百度的首席工程師說過的一句話:衡量一個程式設計師價值的標準並不是他掌握了多少知識,而是他掌握的知識與學會這些所花的時間之比.對於初入開發崗位的你來說,

每一次踩到一個坑然後獨立填坑的經歷都將會加速你對更多技術領域內的知識和問題的學習速度,也將會提高你作為一個工程師的價值.如何與產品溝通?在技術圈裡這是老生常談的話題,我認為與產品溝通的過程中是最能體現出一個程式設計師情商的時候.無論對方提出的需求是怎樣的,你考慮問題的邏輯應該是:當前提的這一條需求做完以後對產品有什麼收益?對技術這邊又有什麼收益?更重要的是leader們是否會在乎這一點?然而這一切都應該發生在你的內心中,權衡利弊之後如果有什麼沒考慮到的你可以提出來,如果並不是十分確認自己的想法,你可以等會後私下裡和你的leader提出自己的看法,這既是對leader的尊重也是節省開會時間.幸運的是,在網際網路這個行業裡,需求溝通的過程中,

技術人員的話語權通常還是較大的,然而絕不要濫用你的話語權.我可以捫心自問的說,在我正式入職以後溝透過的每一位產品,沒有和任何一位發生過爭吵,相反的是產品們都願意與我對需求.這並不是因為我把PM們當大爺一樣供著,對任何奇葩的需求都有求必應,而是因為我往往把”與PM對需求”這件事放在”人情”這樣感性的層面來考慮,而不像很多程式設計師那樣只考慮程式碼邏輯的理性思維方式.人是複雜的動物,一個PM提出了一個看似無理的需求,你卻不應該不問青紅皂白直接拒之門外,設身處地將心比心的想一想,公司裡這樣複雜的環境下,他/她是否也有自己的無奈和苦衷?如果有,這個問題是否存在其他折中的解決方案?武斷砍需求的程式設計師往往錯過了這樣的商討”折中方案”的機會,同時也錯過了一個讓PM認可你的機會!這一點其實很重要.我見過很多同期進公司的校招生,他們把職場中”老油條們”習以為常的做事方式直接照搬到了自己的行事風格當中,內心裡對PM的抱怨將會在潛意識裡左右你與PM溝通的態度和方式.換個角度考慮,我倒覺得在其他職位的人眼中,你的技術多麼多麼的NB他們是無法直觀洞悉的,每一個無理取鬧的需求也都是一個你證明自己的機會.更 重要的是,公司裡與產品交涉問題並不同於市場上買菜那樣,你們的工作很可能在接下來的幾個月中都存在溝通和交集,今天你賣給他一個人情,明天他也會替你扛 一個線上的錯誤,

(說實話程式設計師在程式碼上線之前往往喜歡叫PM來做最後確認,言外之意是上線是你確認的,出了問題也得你扛著.我覺得一個專案是大家一起做的, 說句良心話,把所有的責任一股腦全部都推給PM我個人認為也是不公平的,PM往往在很多專案中充當著”背鍋俠”的角色,人要相互理解)人非聖賢孰能無過, 任何線上的程式碼都不可能永遠是不出錯的.PM對於一個之前敲定好的需求的修改,確實有可能是出於他本人工作上的疏忽,但是這不代表你的工作就不會出錯,如 果人之間沒有”良好的信任關係”

問題就會被相互放大,像手電筒一樣給別人挑錯很簡單,難的是互相的彌補對方的失誤從而建立一種長久的友好合作關係,而能做到這一點也正是所謂情商的體現.情商不是叫你如何精明的算計對方,那叫”別有用心的智商”,情商是包容與理解.有了人情作為基礎,我覺得沒有哪個PM會和你在一兩天的deadline問題上面扯皮.即使利益之間的衝突真的無法解決,也沒有任何折中方案,你至少可以把問題記錄下來,拿到leader們那裡交給他們去做決定,而沒必要當面撕破臉傷及雙方的感情,畢竟產品是公司的,人際關係是自己的.如何看待加班?加 班就像借錢,原則上必然是救急不救窮.然而並不是說對於一個”窮”的部門程式設計師就一定要選擇離開,

這既不是負責任的表現,又錯過了一個成為部門核心骨幹力 量的機會. 很多公司裡的leader都是在危難關頭扛下了部門的人手不足的壓力,leader的職位也就順理成章.除非部門真的氣數已盡.ruby on rails的作者曾說過,熬夜加班相當於借高利貸,偶爾一次可能是難免的,但如果你的工作長期需要你熬夜加班(IT運維崗除外),你可能確實該考慮換一份工作.最後祝願各位未來的程式設計師在校招的潮流中能夠成為offer收割機,並且得到自己真正心儀公司的offer!如果覺得本文中說的確有些乾貨, 對web方面感興趣的同學，可以關注下我。

1.循序漸進，學習任何一門新知識，最主要的是要有興趣，興趣怎麼培養?就是要透過一個個小成就來激勵自己。由易到難，當你每次敲出執行鍵都能得到pass時，作為新手，自信心自然會不斷增強，會有強烈的願望去挑戰新的題目。

2.歸納總結，程式語言包含的知識點非常多，今天認真學習個新知識，時間長了沒用到，過段時間就會遺忘，這樣感覺自己不斷學習，卻不斷忘記，像漏斗裝水似的，會異常惱火的。好的學習方法是要懂得總結歸納，形成自己的知識樹，每學一個新的知識點就丟到樹枝或樹葉上，這樣在腦海中就有一個比較清晰的印象，想忘記都難（後面我會總結下java的知識樹，感興趣可以關注我哦）

3.持之以恆，這個有點廢話的意思，學習任何東西都要持之以恆，像現在流傳的“一萬小時定律”之類，也是這個道理，要堅持，大家都懂，就不多言了。

死命敲程式碼，公司沒事做自己做，每天抽點時間看書，好吧，其實我自己只是每天下班回去打遊戲而已，程式碼到是敲了不少。不知道我來湊什麼熱鬧

其實，我們不管學習什麼知識，學習方法都大同小異。

例如：我們上小學了，開始學數學，老師就從1+1,2+2開始教，每天的家庭作業也都是翻來覆去的1+2,2+1這種，然後十位數以內的加法教完了，就開始各種的測驗。

然後10以內的減法、20以內的加減法，小數分數，乘除法。

然後初高中的三角函式，勾股定理，圓周率等等

我們都是經過題海戰術不停的灌輸，最後融會貫通的。

那程式設計師其實也一樣，可能每個人的能力、悟性、學習方法各有不同。

但都是從最基礎的開始，然後各種練習，各種運用，搞清楚了，就開始進入下一個階段。

我一般把程式設計師成長的過程分為了四個階段：

怎麼就算是入門了呢？寫一些簡單的CRUD和頁面展現不需要再去翻書/百度/Google了，這個就是入門了。

我們先不管實現的方式好壞，不要求要運用怎麼怎麼框架，只要我們能夠用最初級的方式，將一個最簡單的企業門戶站實現出來，可能就3-5個頁面，那就OK了。

這個時候，我們就算是入門了。

什麼是懂呢？也就是我們能夠把實現的原理搞懂。

例如，我們可能在很多時候會選擇使用session，cookie來快取一些資料。

那什麼時候用session，cookie可能我們已經瞭解了，那session，cookie的實現原理是什麼呢？

我們在選擇使用這種資料快取的方式時，又哪些優點和缺點呢？

那當我們把大部分的基礎函式的實現原理都瞭解清楚了，我們差不多就算是懂了。

通的意思自然就是融會貫通。

也就是說，你能夠舉一反三了。

例如：你看到一個ORM的框架，你搞懂了如何使用，並且還研究了他的實現程式碼，覺得他不適合你的某些地方，或者需要最佳化的某些地方，你能夠自己完成這些框架的最佳化。

對於整個系統的架構方面，能夠獨立的完成一般網際網路級別的系統架構的設計及搭建。

並且在技術的實現過程中提出更多的合理化建議。

這個時候，基本就是通的級別了。

這個階段是一個非常抽象的階段，不懂！

啥意思呢？

其實我們每個人都會有一個成長過程，而很多人在這個過程中會出現這樣的情況。

“我什麼都懂了，什麼都會了。”

“做一個京東/天貓的架構，分分鐘的事。”

其實也就是一個自滿的狀態。

但事實上是不是真的什麼都懂了呢？其實不然，不管任何人，學習和解決問題的能力都會有一個極限，當到達某個狀態的時候，其實並不是我們所有的知識都學完了，只是可能我們工作中會用到的知識我們都瞭解了。

這個時候我們就會有瓶頸了，而突破這個瓶頸是需要契機的。

我們要把眼光放開，從發現問題，解決問題變為製造問題。

也就是說，我們需要去想象了，想象出來某些問題，然後想想解決方案，合理化分析，然後實踐去證明。

這個時候，我們就會發現，我們有太多太多不懂的東西了。太多太多需要學習的東西了。

這個很抽象，能到達這個階段的人並不多，我其實也沒到這個階段，可能是由於天賦不足，製造不出來問題。

那這裡推薦幾個學習的方法吧。

第一個自然是去買書來看，個人是不喜歡電子書的，一般會買實體書。還能劃個重點啥的。

第二個就是去看別人的原始碼，然後先照著自己也做一樣的東西。這個就好像學畫畫一樣，開始都是臨摹，然後在臨摹中形成自己的風格。

第三個就是去開源社群交流，看別人遇到的問題，然後自己想解決方案，然後再看其他人的解決方案。在發現問題和解決問題的過程中，就可以很好的提高了。

第四個就是多寫程式碼，做專案，公司沒得做，就到開源社群去做，接一些外單也可以。反正實踐出真知嘛。

剛剛入職一家IT公司成為一名初級開發工程師，我們如何在技術這條路線上野蠻生長呢。

這條技術進階之路就是一個金字塔形，越往上人越少。

奶爸在IT職場很多年接觸了很多技術大咖，他們的成長路線大概都是以下幾步：

1、規範程式設計，夯實基礎

不管你是計算機專業科班出身，還是半路出家，剛開始寫程式碼都是一張白紙，如果一開始不懂的規範寫程式碼，就會養成不好的習慣，以後很難改。

按照規範格式編寫程式碼，不用格式化工具，自己寫出可讀性極好的程式碼，特別是要養成寫註釋的好習慣，再好的腦子也不如寫上完整得註釋。

一定要記住這句話，別太相信自己都能記住，就算是你自己寫的程式碼，半年後再去看，如果沒有註釋也很難看懂。

另外這個時候要把最基礎的程式設計演算法打牢，如果你用的是JAVA語言，那就要把J2SE核心的類苦弄明白，最常用的演算法多多演練。

紮紮實實走好第一步，基礎打牢了，以後的路更好走。

2、實戰演練，技能拓展

一定要多參與不同的軟體開發專案，不同類的軟體開發專案用到的技術側重不同，這樣能讓你的技術透過專案實戰，更加精進、全面。

分析類的軟體，需要對資料處理和展現的技術要求更高，這時你可能會接觸一些ETL工具，圖表展現工具（比如EChart等）。如果涉及到海量資料處理，你將有機會開始你的大資料開發之路，除了會使用oracel進行關係型資料庫的開發，還要學會使用類似Hadoop這樣的分散式框架進行開發。

流程類軟體，側重流程和表單得配置，這樣你會熟悉JBPM的設計機制，如何基於流程引擎完成開發，如何開發各類表單（單筆、多筆等）。如果涉及到長流程，還會讓你學到依據狀態機實現流程管控、有序流轉的技術。

ESB類的軟體，讓你學會如何進行介面匯流排開發，這時候你會開始接觸各類介面方式，比如webservice，FTP、JMS、rest等，開始學會如何呼叫郵件和簡訊閘道器。

門戶類軟體，讓你學會如何開發統一代辦，如何透過CAS實現單點登入，如何透過門戶實現首頁的定製開發，面板定製，不同子系統如何整合等。

第二步，透過實戰，讓你的技術更全面、更精進，要想達到這個目的就不能死磕在一個專案組裡。

3、學會做軟體設計

到這，你要學會進行軟體設計，大到整個系統，小到一個功能模組，你的設計方案將是開發人員進行軟體開發地依據，就像蓋房子，你畫圖紙，程式設計師施工，是不是感覺自己變得有一點牛了。

做一個軟體設計師，還是要懂得基本的設計思想，常見的設計模式要好好研究一下，比如單例模式、工廠模式、策略模式等。其實這些方法論的基礎都是面向物件的程式設計思想，在基礎思想加上一些應用場景，便有了各類設計模式。

一個軟體設計師，最主要的職責就是寫設計文件並指導開發人員按照設計開發。設計文件的核心包含類圖設計、活動圖設計、狀態圖設計、功能設計、效能設計等。

設計師和開發工程師的最大區別是，設計師能依賴軟體架構完成軟體設計，而開發不能。

4、成為一個架構師

到了架構師這個級別就需要對底層軟體模型完成架構設計，包含展示層的封裝、應用層的服務封裝，公共技術元件封裝，比如前面說的流程引擎工具、表單元件、圖表展示元件都需要由架構師完成封裝，形成可複用的元件，提供給開發人員使用。

一般架構師這個級別的人就需要開始深入研究一些開源元件，閱讀核心的開原始碼，比較勤奮的架構師已經開始做自己的開源專案了。

架構師一般是一個團隊中的技術專家，產品研發中遇到的技術難點一般由他來攻克，比如軟體的執行效率問題，軟體的效能問題等。

比較厲害的架構師，還要學會軟硬體整合部署，設計應用和資料庫的負載均衡方案，讓系統更加健壯、更加靈活。

架構師是一個軟體架構的締造者，一個團隊的生產力高低，很大程度上取決於架構師的水平高低。

5、走向CTO

聽起來是個很高大上的職位，能夠走到架構師位置的人已經鳳毛麟角了，要能成為一個企業的CTO更是難上加難。

CTO最重要的工作就是關注行業的技術趨勢，進行技術選型，將比較好用的新技術引入到技術架構體系中。不斷升級現有的技術架構，應付不斷增長和擴充套件的業務。

所以你會看到很多的CTO經常奔走在，各種論壇，峰會，目的就是為了培養敏銳的技術嗅覺，拓展人脈，建立技術合作關係。

走到這裡基本上已到了技術的頂點了，有點高出不勝寒的感覺，回頭看看來時的路，是否會感嘆，無限風光在險峰。

簡明的說：想要做好任何一件事情，都要有毅力，程式碼剛學要經常敲，不斷提升自己，挑戰稍微有點難度的題型才能夠得到昇華。越到後面你要學的跟多而且跟難，如果沒有那種毅力建議還是不要學了！