最近有幸收到掘金的邀請，成為掘金專欄的一份子，唯恐自己不能有太多有質量的貢獻，但又想到這是一次鍛鍊和學習的機會，所以非常感謝掘金！
剛好今天不是很忙，於是思索著來寫些什麼！正好前段時間想寫一個關於工作、學習的總結，於是今天就獻醜了，在這裡拋磚引玉！原文地址 因為覺得有些地方可能別人可能有更高見的地方，歡迎issue上來於我學習，不勝感激！
目錄
- 1、你先上愛上這份工作
- 2、要有專的能力
- 3、先理論基礎，再實踐
- 4、找一個點持續關注它
- 5、你必須有個業餘愛好
- 6、鍛鍊一種“寫”的習慣
- 7、搜尋引擎用google，看文件儘量看英文版
- 8、你要擴充套件自己
- 9、善於以更好的方式替代原來不好的方式
- 10、如何在團隊中做的更好
- 11、寫技術文件或開發用例文件
前言
- 其實心中剛冒出這個題的時候，我也覺得有些不妥，總覺得這樣的話題起高了，以我現在的資歷恐怕難以有相關的“素材”來完善這篇文章。總感覺寫不好，但我最好還是說服了自己，因為不僅僅是表達觀點給別人，也是我自己對我之前所做的工作的一個總結，總結總是能讓人學到東西的，何樂而不為呢！誠然，我最初的看法認為一個合格的程式設計師只要具備以下幾個點就好了：
1、足夠的腦力軟體基礎；
2、跟隨一個好的團隊混幾個專案經驗就好了；
3、足夠強的自學能力、自覺能力及耐力。
可是我發現，如果已經具有這些能力、閱歷的情況下，那麼確實可以說你已經成為一個可以“機械式”寫程式碼的程式設計師了，但是你自己本身也就成了像你寫的程式碼了那樣的“程式碼”了，需要維護人員時刻維護才能正常運轉，或者說必要時候，需要全部換血（補充自己）才能解決已經存在的問題！
在繼續寫後面的內容之前，我其實想問一個問題，如果一個人不具備上面的幾點或者部分，他能不能成為一個合格的程式設計師呢？其實是可以的，這也就是我寫這篇的文章主要想表達的————我並非是想來一場不符實際的批判，而是想談談已經成為程式設計師之後如何擴充套件、彌補自己。亦或還沒有進入程式設計師的世界，怎麼了解它，有什麼“捷徑”可以征服它，這就是我想表達的。
好吧，進入正題
- 首先說明一下上面三個點的不足：
1、確實，一個人大腦轉的不是很快的話，相對來說做某些事情會慢一截，但是並不妨礙他把事情辦好，更何況，如果在一個team中，一個人的這種大腦運轉很快的發揮的相對作用影響不是很大，因為從一個team的點出發就大打折扣了，team更多的是需要團隊協調性，並非某個人的“特立獨行”。再做一個比較形象的比方：馬雲大家都知道吧，身為一個萬億級的企業老闆，難道僅僅是因為他個人能力、腦力特別強嗎？非也，因為如果假如公司就它一個人的話，我想他再厲害恐怕每天帶來的效益也只能可圈可點！但如果加上公司其它特別優秀的人一起工作的話就不一樣了！當然了，你不能斷章取義，我並沒有否定馬雲的作用哈！因為確實作為一個公司優秀的leader來說，他做到了——足夠的領導力團結大家一個更好地工作、足夠的眼界去攬別人看不到的市場、足夠的裁決力去修復團隊、專案中不該存在的“BUG”，等等！說這些，並不是在這裡簡單的“吹牛逼”而已，而是我想告訴你：一個team並不是在乎你是否真的腦力過人，因為你並不是機器需要以後每時每刻都在高效工作，而是更在乎你是否能與團隊協調一下步伐更好的完善工作，你是否擁有足夠的學習耐力去嘗試新鮮的東西從而時不時地為自己帶來一些新鮮的“血液”，這頗有點‘木桶原理’的味道！最後其實我也很好奇，大家在程式設計過程中，有多少工作是靠大腦而不是靠時間久而沉澱的經驗去“約定俗成”解決的呢？所以你不必特別在意的“大腦”，只要努力，定能“笨鳥先飛”。
2、能混到幾個專案經驗確實是不錯的，特別是那種大一點、覆蓋面廣的專案，這確實對你以後工作經驗影響較深、較大。但如果僅此而已，而不懂得擴充套件自己，或者總結一套較好的學習方法的話，其實你的經驗侷限性也是很大的。因為特別是程式設計這種工作，各種程式語言更新、迭代較快，所有公司都在尋求一種能夠極大提高生產效率的工作模式，所以你以前的開發經驗可能很短時間就會被替換，導致你不得不轉換你自己的思維和工作模式！
3、能擁有第三點能力的，我覺得其實本身已經很不錯的，可是無法蔑視的一個現實就是：你不愛好一個職業，而只是看好它的前景，從而不斷苛刻的要求自己來提高工作能力，那麼這樣你將會堅持的很累，很大可能就是你某一天堅持不了而放棄！
那麼，我認為的一個“合格”程式設計師應該具備那些特點呢？
在這之前，我想說一下為什麼這些點我認為是成為“合格”程式設計師所需要的點，或者說讓你更接近它。那麼在這裡先允許我“裝逼”來解釋下吧，確實這就是經驗，因為對比之前的學習、工作模式和現在的區別，我體會到兩種方式那個才能更好的幫助提升能力！所以有了下面這些觀點：
- 1、你先上愛上這份工作
很多事情一樣，如果你不是因為喜歡而是因為“衝動”而進入一份工作，那麼恐怕你很難堅持下去。因為你不愛好一份工作，你的身體本能是拒絕它的，很難想象你在工作過程中會有一種想完善、臻美它的興奮點，從而在這份工作長期發展。
- 2、要有專的能力
這裡想說一下，這裡的“專”不是“轉”牛角尖的的“轉”，而是想說的是一種專於找到問題本質的精神，其實有時候我們有些我們做的事情表面看上去很複雜，其實往往是簡單的疊加，不是有一種說法是大繁至簡嗎？我們如果擁有了專一個問題本質的精神，你就能由內到外看到問題深處，從而你以後再遇到這種類似的問題就能駕輕就熟了。比如你寫過一段程式碼之後不能把它放在哪裡就不管了，而是儘量弄懂它，問問自己能否從另外一個角度實現它？那種方式更優？那種體驗更好？如果你達到這一個層次，我想有很多問題你不光會解決它，你肯定也會喜歡上這個過程！
- 3、先理論基礎，再實踐
當接觸到一個東西的時候，你得先看它的理論，因為有道是以理論為基礎進行實踐開發。在看理論第一遍的時候，可以不用看得那麼深、那麼追根問底！因為畢竟這東西不是你發明的，你要想看第一次就能萬事皆全，那是不可能的，這樣做無非是加大你對它的仇恨度。並且有些東西你要在實踐使用中才能體會它的深妙！當然了，這裡不是要你只看重理論哈，還是要結合實際操作哦！程式設計實踐很重要，千萬別走“理論主義”的路線！
- 4、找一個點持續關注它
比如一個大牛的部落格、一個技術更新較勤的平臺等，或者你認為大部分開發者都在逛的一個社群。你所要做的並不是要一一去學習那些技術，技術是學不完的，而是從這個點看到你當前的所用的程式語言的一個大環境，某些新技術、新框架的更新等。這樣你才可以及時調整自己，從而不會跟不上新技術的節奏以被淘汰。打個比方，你以前一直在用jquery，用的很爽，可是現實呢？恐怕jquery已經“過時了”，你可能更多的是需要了解node、angular、vue及react等！當然了，我這裡的建議就是你先專一個框架就好，另外的可先做了解，等用到時再深究，因為它們道理是大同小異的！
- 5、你必須有個業餘愛好
這個愛好不限，可以是玩網遊（比如我）、比如旅遊、看書等等，只要是你喜歡的！但是不能是違法的哈，要不然出了事別怪我哈！為什麼要這樣做呢？因為我感覺當我們長期太過於專注一件事情的時候，我們的想法、思想等有時候會變得有些‘狹隘’，因為你沒有了解過其它東西，所以總以一種你現在的思維去批判它。也許，適當的時間轉換一下思維、放開也是挺好的！當然了這裡並不是專指程式設計師這個行業，其實每個行業都是這樣！
- 6、鍛鍊一種“寫”的習慣
當然了，這個是我個人觀點，並不強求，或許你有更好的方法用你的就是！因為之前學技術的時候，做過幾次以為就會了，可是發現過了一段時間，竟然忘得一乾二淨，又重新去看文件！但是奇妙就發生在這裡，看自己比看別人寫的總是會更爽、更簡單，並且有種滿滿的幸福感在裡面！其一，是你已經做過，你看起來更容易理解；其二，看自己寫的，更利於你回憶起當時你遇到的一些極端問題是怎麼解決的。所以我這裡說的是你得養成一種學習總結的習慣，並非要照我這樣做，你有更好的方法，你應該遵從你的本心！
- 7、搜尋引擎用google，看文件儘量看英文版
其實結合起來最終就是迫使你儘量看英文版的文件、逛英文社群！這樣做是有很多好處的，且聽我我慢慢道來：1、其一，能鍛鍊的英文學習能力，這也是一種能力，何樂而不為？2、看英文版更容易看到本質，更容易從原作者的角度理解作者的意願，我們看別人的翻譯之後文件時，經常會發現，因為兩種語言之間翻譯銜接的問題，導致表達的含義往往不是一樣，被翻譯者“斷章取義”了。你不妨試一試，同樣的內容，你看完之後，再對比一下兩個版本那個對你來說更好理解其含義？3、其實我之前也是用百度搜尋問題的，可是發現搜尋出來的答案往往是現成的，從某種意義上來說，這回阻止了你的自我思考，從而不會讓你看到更深的問題，也許，當時你可能真的把bug勉勉強強修復了，但是後期又會出現很多出人意料的問題，導致你摸不著頭腦；4、因為程式語言、語法本身就是英文的，而於我看來，英文的邏輯性很強，要不然用它來描述程式語句了！不信？你仔細體會、研究一下！看下面兩種語法：
//英文
var x = 10;
if(x>5){
//...
}else{
//...
};
//中文
/*
定義 x = 10;
如果x>5的話：
//執行xx操作
否則：
//執行xx操作
*/複製程式碼8、你要擴充套件自己
前面已經說過，技術學不完的，所以你應該在專注你的工作的同時，應該擴充套件自己的技術，這個擴充套件的技術可以是以你當前的工作為中心外延的技術，比如你是學前端的，那麼你可以嘗試一下學一下後臺、產品、研究使用者體驗等；亦或你可以選擇一個跟你現在所做的毫無關係的工作，如果可以的話！為什麼要這樣做呢？其一：可以擴充套件你的技術面，因為很難預料，你能把你現在的工作幹到一輩子，畢竟世事難料；其二：可以讓你從多方面、角度看待問題，解決起來相對容易些；其三：多學習總是好的。
9、善於以更好的方式替代原來不好的方式
這是我最近意識到的，因為什麼呢？最近剛做了幾個小的網頁頁面專案，這幾個頁面專案雖然描述的內容和營銷目的不是一樣的，但是大致邏輯是一樣的，也就是我可以js部分我可以不改動或者改動很少的部分就能在每個專案複用！這樣就能減少很大重複編寫的程式碼量了。可是我並沒有這麼做，因為我總覺得我前面的程式碼寫的有問題，寫的太過臃腫，所以我就想修改前面的程式碼，或者以不同的、更好的方式來實現前面寫過的邏輯！當我做了這個改動之後，其實我發現獲得了新的東西：1、以不同的思維看待問題、理解問題，拓寬思維方式，更助於理解原理；2、將會使你的開發體驗提升到一個非常好的體驗，因為什麼呢，如果你只是簡單重複地把你前面的程式碼複製到當前的專案中，那麼長此以往，你肯定會厭煩這種機械式重複的體驗；使你擁有一種架構的思維來思考你要解決的問題，因為從多個維度實現同樣的問題次數多了，你就知道那種方式更優，更利於大家方便開發。所以這一切都是有益無害的！
當然，我知道實現這一步最開始這是很難的，因為人總會有惰性思維，或者說很難願意去接受、嘗試新鮮的事物。這一點上，我也做的很差，就好像我一直不願意嘗試自己去裝系統一樣，總害怕把系統搞壞了，裝不回來怎麼辦！以至於我現在總是小心翼翼的玩電腦，弄壞了，沒人幫我重灌系統。可是當你大膽嘗試幾次之後，你會發現重灌系統也就那麼回事！
那麼，我們總結一下就是：如果你願意嘗試用好的（相對來說好的）方式替換舊的（相對來說不好的）方式，你就會獲得：拓寬思維、提升開發體驗、擁有大局觀等！
- 10、如何在團隊中做的更好
其實我最開始以為，只要自己技術足夠牛，就能在一個團隊中帶來更多產出、效率，團隊不允許有菜鳥（菜鳥在這裡不是貶義，後面解釋）！其實不是這樣的，因為如果是這樣的話，那麼勢必公司將永遠不會要畢業生和實習生了，因為他們最開始都是最菜的，世間也不會存在新人和老人、徒弟和師傅一說了！最終所有的技術都會因為找不到傳人而斷傳。其實我覺得一個良好的團隊應該是一個能接受新人和老人、徒弟和師傅良好結合的共同體，其原因有：1、你能保證把10個頂級美女放在一起它們之間不會鬧矛盾，或者以為她們各自對美麗的理解、定義不同而各執己見嗎？如果團隊是這樣的話，那麼很難保證我們的專案朝最終的目標走去；2、如果把10個高手或10新手放在一起，那麼之間就會少了一種向別人學習的動力，因為都覺得自己已經達到最高境界了，長此以往，大家也會厭倦這種孤獨的生活的！相反，如果把這兩種人放在一起，新手就會為有了新的方向（高手）而努力奮鬥，高手也會為了更好的帶新手而持續學習補充自己。其實，按我的理解，團隊裡面只需要一個所謂的高手就行了；3、當然了新手便宜，這從公司的角度出發，是有這個需求的，從社會責任和技術傳承的角度出發，公司也應該給一個新手工作的環境的！
說了這麼多，我並不是在為“不思進取、不努力工作”的菜鳥開拓的，我這裡說的菜鳥指的是一類真的想學習、踏實工作的人，只是當前欠缺工作經驗而已。好吧，接著前面的說，你在團隊中怎麼做更好呢！我覺得應該這樣（個人理解，願意接受不同的觀點）：1、如果你是新手，那麼你就應該努力工作、首先完成工作，潛心練好基本功、紮實基礎。找到自己的學習方式，實在不懂的時候可以和大家一起交流一下意見，但是切記，別一遇到問題就找別人，首先你應該確認以你現在的能力是不是真的在其它渠道找不到答案了，因為如此的話，別人也會煩你的；2、如果你是高手或者說技術管理者：你就應該構思好專案架構，然後分別交給不同部分的同事幹，把流程搞清晰，必要的時候組織大家起來一起交流、學習下技術中出現的問題！當然了，管理者也應該通過不斷的學習，來拓寬自己的思維，當然不必學的太過底層，因為畢竟可能你不需要做實際專案，這樣做只是幫你更好地讓你帶領大家完成工作和減少同事彼此之間的對需求的理解誤差！個人理解，切忌這樣的技術管理者：只做需求提供者和需要驗收者，也不考慮團隊的技術棧和需求的合理性等，這樣的管理者，只會讓團隊做更多的無用功而已！當然了，如果技術管理者是你的老闆的話，那麼你可以委婉適當地給他分析一下當前需求的理解，讓大家達成一致。如果實在不行，那麼就先做個樣板出來吧，因為可能等你樣板出來之後沒套資料之前，可能老闆的需求已經放鬆一些了，這時可以再試著分析一下需求！
- 11、寫技術文件或開發用例文件
為什麼單獨把這個作為一個獨立的話題來討論呢？因為我是覺得文件這個東西在開發中是很重要的，但是又是被很多團隊忽視的，都覺得在小團隊中這個東西完全是影響開發效率，所以這個步驟能省就省了！那為什麼重要呢？我來說下我的理解：1、文件這個東西首先可以幫你整理開發思路，記錄你在開發中遇到的一些問題，然後你是怎麼解決的，所以從某種意義上來說也是一種幫你總結問題的方法，你千萬不要以為這會影響開發效率，因為這個東西做好了，你將來回滾版本或者修復bug的時候才能找到為什麼這樣改的相關依據，其實這樣反而是提高你的開發效率的；2、更利於團隊之間的溝通，因為你開發的東西可能會給你的領導等非技術人員檢視，這個東西這個時候就能幫助大家增進對專案需求的理解；3、明確各個同事之間的職責，尤其在小公司或者小團隊中，避免讓無辜同事背鍋。記得曾經在一個團隊裡，專案經理提一個需求或者改動一個需求的時候總是嘴上說需求，哪裡該怎麼改嘴上說一下就好了！從來都不記錄問題的，最後搞得整個開發小組思路圍著他轉，影響開發體驗不說，而且嚴重打擊了大家的開發積極性。更為重要的，最終專案釋出的時候，老闆說內容顯示完全沒有主次、新意，不能夠提升使用者體驗，最後老闆就找到具體具體開發專案的同事，一頓痛斥，說了一些狠話，相反，老闆找到專案經理勸說他辛苦一下再改下需求而已。這裡我就奇怪了，這個責任只是跟具體開發專案的同事有關嗎？難道專案經理就一點責任都沒有了？這裡我並不是在意孰是孰非的問題，而是想表達如果沒有了開發文件，一些不明白開發流程的人是很難明確問題出現在哪裡！從而造成病急亂投醫的現象，傷害相關人員不說，更影響大家一起工作。
所以呀，開發文件這個東西還是很重要的！
結語
- 回想一下，自己目前所能想到的也就這些了，也許在大家的理解中，可能有更多、更好的學習、工作方式方法，歡迎issue上來，與大家一起分享！