去年三月份開始進入一家外包公司實習,六月份辭職並於七月份正式畢業,隨後在八月中旬進入目前所在的創業公司,不想已然過去了一年有餘,歲月如梭,着實不饒人。那個年輕,稚嫩的咱們在一年的洗禮下悄然發生了變化,至少體重已經快超標了。本着一個程序猿的碼農工做者,心裏卻住着一個如此文藝騷青年,老是忍不住想要寫點東西,祭奠祭奠已然逝去的一年,所發生的那些事,以及關於成長,關於感慨,關於當下對本身的定位的見解。程序員
進入創業公司,是真的很累。很慶幸去了一家技術氛圍相對濃厚的創業公司,雖然終日加班——莫名想起一個段子,話說程序員畢業一年卻寫着三年工做經驗,而兩年時間來自於加班……咱們是996的工做制度,其次咱們七八個後端技術人員每週發一個版本,因此說996彷佛不是很貼切,畢竟每週總有一兩個夜晚是凌晨三四點纔在樓下點開滴滴軟件,坐在出租車裏,隔着玻璃窗望着天上的明月,彷佛也沒有多麼明亮。記得有段時間,進入全員瘋狂加班的狀態,近乎天天都在增量發版本。這段顯得有點黑暗,有點陰沉的時間裏,我慌張過,忐忑過,想過逃避加班,想過離職,總之,就是想着若是能夠無所不用其極的躲避加班,那該多好?現在回過頭去思考,看待過去,反而以爲當時彷佛也沒有那麼累,由於天天都彷佛在進步,那種感受恐怕也是有點奇妙與刺激的吧。固然,除此以外,必須感恩個人愛人,是她給了我無微不至的關懷與鼓勵。可是,反正即使再刺激,我也不會回去那樣的生活……後端
不知道其餘程序猿是否會有一種心理:我寧願將時間花在研究各類中間件,各類框架,乃至各類框架源碼,也不肯多花時間在業務代碼上。設計模式
經常我便會有這種強烈的感受,做爲技術人員我渴望去研究框架研究技術,業務代碼反反覆覆都是if else……技術談何進步?薪資談何上升?這種顯得有點偏激,有點執着的想法直接致使我提出了離職。緣由大體是,新的框架來了,網上各類人討論的熱火朝天,如火如荼,衆說紛紜,而我剛剛於十二點下班,複製完今天的最後一行業務代碼。論壇,QQ技術羣裏各類大牛分析,網上博客層出不窮,別人都在進步而我居然還在寫這些鳥玩意,什麼鬼!!!大概有一個月後,便開始有人在羣裏招聘,精通XXX新技術新框架,月薪XXK,地址XXX地址。看到羣裏這樣的招聘,慌了,個人天,外邊的世界都開始使用它了,而我竟然偏安一隅,我這是作技術的嗎?苦苦掙扎的心情,可是你始終沒有提出說要離職,直到……你身邊的朋友開始在討論這些你不是很懂的問題,或者看到他的QQ頭像在某個羣裏發表大牛般的指導性言論,探討如何新技術新框架的前世此生的時候,在回去的路上心裏翻騰不止,在同窗之中已經落後這麼多了嗎,因而拍案而起,於凌晨三點在宿舍電腦前寫完離職申請,並定時於明早十點發給了人事……架構
最後,在大佬們的遊說下,我仍是沒有離職,緣由不少,可是本質緣由是我沒錢,沒工做在深圳過不下去……框架
時至今日,對於新技術新框架的層出不窮,態度反而是更加謙卑而敬畏。以前我是打算在一個系列文章,探索一下MyBatis的源代碼,雖然網上很是多這樣的系列文章,可是那畢竟不是本身的東西,沒有真正去探索一下,很難將其中的內部架構,內部原理真正的瞭然於胸,因而動手寫了好幾篇,但是後來又被我刪掉了,緣由不外乎就是我本身沒有那個能力真的輸出一些本身思考過,經得起探索,經得起考驗的真知灼見,假若寫的有偏差,而又恰好與人瞧見,豈非誤人子弟?其次,若是從產品的角度來看待框架看待技術彷佛會有意想不到的另外一番「美景」。學習
在創業公司待的這段時間,彷佛迴歸業務反而更是難了,至少若是去接手一個新的框架的時候,滿滿的文檔拿過來跑個demo出來,參照文檔持續跟進總歸是能夠解決技術問題。可是業務上的思考,纔是檢驗成長的關鍵成果。當接手一個業務功能的時候,是否去思考這個功能給咱們的用戶帶來了什麼樣的價值?又能爲咱們帶來多少價值,挽回多少用戶,提升多少競爭力,戰略層面上它的所扮演的角色是什麼(站在公司戰略的層面去思考)? 市場反饋回來的需求是不是僞需求?競品是如何實現這個業務功能(站在產品的角度去思考)?須要投入多少時間需實現該業務功能?如何設計這個業務功能?代碼層面是如何設計這個功能?該功能波及多少其餘功能(站在實際實現功能的角度去思考)?等等……接手一個業務功能到真正的投入編碼所花費的時間真的不少。當咱們仔細去看待這個過程的時候,就會發現這一系列下來,思考的越前的人,他的所關注的點也就愈發的不同。因此,咱們再寫着代碼,而老闆卻在寫着融資方案(這些思惟都是技術總監時常給我安利的,感恩總監大人)優化
成長,彷佛就是看待問題的角度,以及解決問題的思路。編碼
另一點說到從產品的角度去看待一個框架,本來在我看到學習框架的最佳方式就是打開該官方文檔跑demo,後來與朋友交流過程當中,發現若是從一個產品的角度來看到一個框架的意義,可讓咱們站在另一個角度來看待這個問題。好比MyBatis,咱們用了那麼久的Mybatis,寫了那麼多的代碼,是否拷問過本身,爲何會有MyBatis?或許你能夠羅列出一大堆的東西,可是你卻很難有條不紊的講出來,可能就是想到一個就是一個。彷彿你並無真正的用上它,感覺它的好,也接受它的壞,乃至你本身投入開發MyBatis插件進行優化……好比:爲何會有它 --> 規範哪裏很差 --> 競品對比 --> 哪裏好,爲何好,哪裏很差,爲何很差--> …… --> 最終迴歸到原理的時候,每每你已然理解的很透徹,去看源碼,每每偏向於瞭解它的架構設計,代碼設計。其實做爲開發者,我一直都最喜歡設計模式,鍾情於它,總以爲它的魅力實在是太大了。在實際開發上,個人老大是一個將近十年的開發老兵了,由於我偏向於熱衷這些東西,因此常常請教他。我常常說這裏我應該怎麼設計,其實我就想說我要用什麼設計模式,而後我在百度一下看看怎麼搞,結果他上來以後看了看,說這裏抽一個接口,那裏抽一個抽象類……從頭至尾沒說過什麼設計模式,而後我就照作了。有時候我會說,這裏用什麼設計模式是否是更好,他卻說這裏抽象一個接口就能夠了,搞那麼複雜作什麼。三兩次後我再問他,他卻說,什麼設計模式,那些東西本身搞去,別浪費我時間。……後來我慢慢放棄了執着於遵循設計模式(雖然我在博客裏搞了挺多的,寫博客的目的是作筆記),後來跟老大聊天的時候問起設計模式,他說好多年之前他用C#跟C++打過demo,早忘了這些東西了……他用他十年的經驗讓我其實少走了不少彎路,我雖然依然很菜,可是他教給個人解決方式實際上是迴歸到本質問題——抽象的理解。因此在設計層面上若是你也拷問本身 :這麼作有什麼問題?怎麼作會更好擴展?等等……慢慢的,這些問題彷佛都變成了爲何。(雖然個人產品眼光是狹隘的,可是我堅持多看看產品經歷的文章,多學習產品經理的思惟,指望後續能夠有更多的機會去學習產品理念)插件
簡單覆盤了一下,對本身當下的定位已然很明確了。覆盤事後,思惟上老是會有所變化。架構設計
真的很是感謝技術總監與研發經理兩位大牛對個人深入指導。改變了個人思惟方式。改變了我看待問題的方式,角度,處理問題的手段,姿式,幫助我成長了不少,在看了不少文章後,我以爲有句話其實仍是有點道理的:用產品經理的眼光去看待問題,用架構師的眼光去解決問題。