做爲一個iOS開發者，咱們應該如何突破自身的瓶頸呢？

前言：

針對工做幾年的程序員工程師,常常會遇到瓶頸,這個瓶頸不必定技術上的,也多是職業發展上的.通常技術的職業規劃會有兩個方向

技術方向:

架構師,系統分析師,CTO

這種每每是走純技術路線, 發展到最後都是在公司中深刻某一塊技術,例如存儲,MQ,通訊,等等,後面發展路線也每每是架構師/系統分析師,技術專家,高級培訓師,而後就是技術總監

業務方向:

產品經理,項目經理,部門經理,CEO

我以爲業務方向更多的是關注項目,針對當前業務,很是瞭解業務的整個流程,而若是有些業務由於特殊性,會遇到技術難點,要麼讓公司基礎技術部提供解決方案,要麼扔給手下人去作技術調研以及技術攻堅,若是本身部門針對這個技術作出了不少成績,那麼能夠分享推廣到全公司去使用,你們都來調用你的接口,都來參閱你的文檔,可想你本身也是很是高興的.

但是我一直以爲,若是技術不懂業務,不瞭解業務痛點,沒有產品思惟,那麼也沒法針對技術作出改進,改善,業務驅動技術, 根據不一樣的業務,會有特殊的技術要求,實時性高,穩定性強,多數據聚合計算,等等,都考驗了程序員的技術儲備,亦或者技術攻堅水準.

這兩天讀了本書<<我編程,我快樂>>一眼看書名,我覺得是某個國內無良人士出了一本騙錢的書,可是後來看到是外國著做,國人翻譯,且豆瓣評論還不錯,所以就耐心的看了下去,總體還不錯,下面針對本書寫一些心得

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個個人iOS交流羣：413038000，無論你是大牛仍是小白都歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！

推薦閱讀

iOS開發——最新 BAT面試題合集（持續更新中）

作一個通才

頂尖的程序員都每每是某一個領域的專家,其餘領域大部分都是興趣所致,你能夠理解他不如專精領域那麼厲害,可是也比普通程序員要厲害的多.

咱們在項目中,每每不可能只使用一門技術,每每都是多門技術並行前進,所以多會一門技術就表明着多一種解決方式,多一個思考方向,也許新的解決方式每每比你固有的思惟更加有效,這也是爲何如今流行混合編程

記住,是咱們選擇編程語言和技術,而非它們選擇咱們,一樣的項目下,我用ruby寫出的web應用更加迅速,30天也許就能發佈上線,而你使用java也許須要3個月,而若是你用ruby去寫通訊服務,業務你30天就能搞定,可是遠遠沒有java來的穩定,真正的大牛是針對業務場景去選擇技術,而不是在某個特定的技術框框下去完成任務,所以程序員須要作一名通才,固然這個通才指的是某個領域中的通才,切記不能好高騖遠,什麼都學,什麼都只會皮毛,那不如不學.

跳出本身的溫馨區

不少程序員都會下意識的標榜本身是一名c++程序員,java程序員,ios開發,安卓開發,php程序員等等,可是他們每每忽略了一個事實,就是你首先是一名程序員,有意無心的將本身綁定在某個領域或者某一個語言上是很是危險的事情.

若是你這個時候還一直強調函數式編程性能不行的固有思惟,那麼你也許該考慮本身是否是該充充電了.

舉個例子:

以前公司業務擴張,招攬了不少java程序員,可是由於咱們公司原先架構都是php的,讓那些java程序員來寫php,他們成天嗷嗷叫,痛苦不堪,我原先以爲奇怪,難道php開發比java還難麼

後來正面我錯了.並非php的門檻比java高,而是他們不願跳出本身的溫馨區,從心底生成了一種抵觸的想法,從而致使他們工 做的並不開心,可是公司招聘你進來是爲了創造價值的,真正厲害的程序員針對各類技術都是信手拈來,而且我相信,我學習到的 任何技術,在未來都是有用的.也許只是時間未到.在10幾年前,你會想到帶有GC和麪向對象編程的開發語言會如此之火麼?如今 又有哪一個新興開發語言沒有這兩種東西的.因此千萬不要一直保留着本身那可憐的固有思惟,試着跳出溫馨區,也許你會看到新大 陸

對本身喜歡的事情投入100%的熱情

我有個優勢,也正是個人缺點,當我喜歡作某個事情的時候,我會投入100%的熱情,說廢寢忘食也不會過,由於這段時間內,我滿腦子都是這件事情,甚至睡覺上廁所,吃飯,走路都會想着它,這樣的優勢讓我能迅速掌握某個新技術,可是每每由於這樣,也一樣讓我產生了.我是天才,學什麼都很快的錯覺,從而致使本身不少東西都學不精通就放棄了.我以爲之後須要更正這個錯誤的想法

好比以前公司項目中有一個圖庫,全國各地的用戶上傳圖片到服務器,以爲很是簡單,可是真由於很是簡單,裏面須要涉及的東西卻很是多,各地的用戶使用的網絡環境不一致,他們的通訊節點也不一致,怎麼保證每一個人的上傳速度都是可控的.

總結起這個項目,我以爲後期維護的期間,我學到的知識比開發期間多的多.所以我想說,投入100%的熱情,並鍥而不捨,我知道這是很是難的事情,也正由於如此,技術專家,資深大牛才那麼稀缺.

站在巨人的肩膀上

另一點提升本身瓶頸的方法就是借鑑前人的代碼,程序員這個行業,並不必定非要什麼都不看直接寫,也許你在有基礎的狀況下,直接開始寫,遇到問題在查找問題會來的更加容易上手,可是正由於這樣,你寫出來的代碼每每質量很是差,優化性不夠,語法囉嗦,不夠優雅,所以咱們要學會多從其餘人的代碼中汲取優勢,多逛逛開源社區,針對本身感興趣的方向去學習別人的代碼,也是進步的一種方法.最討厭某個前輩或者資深人士說,看什麼看,直接寫,這樣的說法是極其不負責任的.

作團隊最差的人

作團隊最差的人,當你以爲其餘人都比你優秀,那麼你天然而然就成爲了最差的那我的,跟比你優秀的人工做,會讓你更加的快樂,學習到更多有用的東西,也許寧作鳳尾,不作雞頭也是這麼來的,而作團隊最差的人,每每能夠有很是強的學習動力,以及很是迅速的成長空間.不然只有固步自封,100行代碼寫了一萬次,有什麼意義麼?

學習如何失敗

越早的發現問題,就能越早的彌補損失,你應該慶幸如今發現了這麼多bug,而不是上線的時候,你也應該慶幸人少的時候發現了這麼多bug,而不是用戶擁堵的時候,若是你的軟件沒有按期向你抱怨,你就不知道危險的故障隱藏在哪裏,此外帶着防護性的措施進行編程也是很重要的.出現問題的時候,纔是考驗軟件開發質量的時候,出現問題的時候,解決方法,解決思惟也是檢測工程師技術的時候,學習處理也是很是重要的.

• 1.所以發現問題第一時間提出,在開發和測試中,越早發現錯誤,形成的問題就越小,越早發現而且暴露本身犯下的錯誤,形成的負面影響也就越小

• 2.接受批評,也許這個問題並非跟你有直接關係,也許只是間接關係,也許壓根跟你不要緊,可是當出現問題的時候,咱們第一時間須要的是解決方案,而不是互相甩鍋,咱們的目標是在最短的時間內解決修復問題,在誰來負責這個問題上糾纏不清的後果就是拖延解決問題的時間.

• 3.尋求幫助,當咱們遇到困難的時候,必定要學會跟團隊成員互相溝通,尋求解決方案,而不是由於責任感和自尊心而掩飾問題,以及拖延問題,沒有人不會犯錯,越是及早的解決問題,越是能減小問題帶來的負面影響.

上面都是從業務上面來講的.下面說說技術上

當你的項目經理問你是否能完成這個任務的時候,你模棱兩可的說能夠,也許行,好像行,也許你的項目經理只是詢問下你需不須要幫助,又也許你的項目經理聽了你的回答,會跟大老闆拍板保證,這些都是創建在他對你的信任上的.或許你只是想表現的不那麼弱,或許你只是想在你上司面前表現一下,我不是部門最菜的.可是這種信任是慢慢積累起來的,若是有一次你讓他失望了.兩次讓他失望了,甚至三次,那麼這種新人就會崩塌, 你能夠說"我不肯定我能hold住這個項目,這是一次挑戰,但我想要試一試."這就是很是好的答案. 提早告知你上司這個項目會遇到的風險點,以及不肯定因素,我想他更願意給你更多的時間去調研,去整理整個項目的技術難度

價值僵固

正如上面所說的跳出本身的溫馨區同樣,價值僵固依舊也很可怕,不少前輩都喜歡對後輩們諄諄教導,一部分前輩會把本身踩過的坑,遇到過的問題告訴你,你吸收了這些話,那麼之後能少走不少彎路,

可是若是這個前輩的思想已通過時,或者已經落伍了呢?

他的成功經驗每每還停留在他們本身的那個時期,他們以爲本身的成功能夠複製,但他們每每忽略了風向,站在風口,豬也能飛,若是有個公司的CTO跟你說他是學delphi起家的,讓你去學,你信麼?

你要知道delphi在二十世紀初,在C/S那個年代但是很是火的,而如今,你出去找工做,估計都找不到.因此能夠聽信前輩們的一些話,可是也不能全聽,每一個人都須要有本身的判斷力,以及獨立思考的想法,這是很是重要的.

不知不覺寫了這麼多.主要本身想說的話也太多,可能有些囉嗦,耐心看到這裏的人,也是厲害.

若是讓我在職業規劃上作出一種選擇,我但願技術走廣而不深的路線,業務上也同時齊頭並進.雖然整理文檔,寫項目彙報總結這些文檔會讓我痛苦不已,可是我以爲這纔是我應該走的路,也是最適合個人路,不過,也許過一段時間,我就不這麼想了

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個個人iOS交流羣：413038000，無論你是大牛仍是小白都歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！

推薦閱讀

iOS開發——最新 BAT面試題合集（持續更新中）