首頁>Club>
總是在廣度和深度上得不到很好的平衡
32
回覆列表
  • 1 # 嵐肖

    我的回答:實事求是的說,你的這個提問非常好,非常棒,可以說問到我心坎裡了。

    第一問:有沒有遇到技術瓶頸呢?第一個問題:有沒有遇到技術瓶頸呢?技術瓶頸是指沒有上升空間或者自己的技術無法一直提高。所以這是每個人都會經歷的。我也一樣,其實我的技術並不是很牛,也一般,只不過可能我個人看的書比較多,技術,產品,運營我都喜歡。回到正題,目前對我來說,其實Android應用端一般的功能和需求,App基本上都能做,應該不會太難了。所以當這種情況的時候,我也遇到過心浮氣躁,感覺自己技術無法提高,有了技術焦慮症了。我如何解決這個問題呢?下面會講到。

    第二問:會不會業務程式碼失去興趣?第二個問題:說實話,如果一個人對於同樣的工作和產品,尤其是整個產品的業務邏輯程式碼熟悉了之後,開發基本上沒有什麼難度,可能對於我們移動端應用來說,最難的應該是介面,尤其是各種效果和動畫,複雜的效果和動畫實現可能會比較困難。所以對於業務邏輯程式碼失去興趣和不失去興趣沒有什麼區別。因為熟練了之後,可能最多的就是複製貼上,讓自己無聊一點。而介面的千遍萬化可能會讓你有興趣,乃至厭惡或者頭疼。因為有時會實現不了或者難度太大。

    第三問:如何才能一直保持熱情?第三個問題:如何保持熱情,這個其實跟自己的性格和特點有關吧,就像前幾天我說的,往往並不是有興趣才能做好,而是做好了才有興趣。如果你在現有的工作中遇到了困難,可能你就會想,這並不是我的興趣所在,我要換個工作,找到我感興趣的一點去做,但是如果你真的按照自己的內心換了工作之後,這個在你心中所謂的興趣工作,如果你在其中又遇到了困難,可能這時你又會想:這原來也不是我的興趣。興趣只是逃避困難的藉口,熱情亦然,也是這樣。你乾的順手,輕鬆你就會有熱情,你乾的痛苦,很累,就會打擊你的積極性。所以熱情這個東西是偽的。真正的在於你要能夠控制自己的心智,有不怕困難,迎難而上的勇氣才行。要想保持所謂的熱情,只能不斷學習,讓自己一直保持自信,擁有解決問題的能力。

    第四問:自己喜歡學習的,工作又用不到,怎麼辦?第四個問題:對於自己喜歡的東西,公司業務用不到,正常,平時如果時間充足,可以去學習和實踐啊,這個並不和工作衝突,比如:你喜歡打籃球,你會因為工作不用,而不去打籃球麼?這個不用糾結,學習效果的問題:我前幾天寫過一段話,不知道你看過沒有,不要帶有目的性的去做一件事,如果你帶有目的性的去做,在你達不到目的的時候,容易放棄,從而更不會成功。未來並不可知,你怎麼知道你現在學的,將來用不到?你怎麼知道,你現在的工作你能幹一輩子?

    反正,與其悲春傷秋,不如現在就去行動,你所謂的自己喜歡的,可能並不是你真心喜歡的,只不過是你想逃避你現在的困難罷了。或許工作不順心,所以感覺自己業餘想找點事做,而那件你感覺喜歡的事就是在幫助你逃避工作的困難。不需要如何去調整去達到最優,你從現在就開始做就行,別多想,你現在想到了要做什麼,就馬上去做,別想其他的,別想我將來有沒有用,你在想的過程中流逝的是大把的時間。不需要調整,想到什麼去做就行,就這個建議。等將來有一天你回顧的時候,你就會想到:原來我這麼厲害,竟然會了這麼多東西,對自己可能是由衷的敬佩。

    最後,我再囉嗦一句:現在的人最大的問題就是考慮問題太多了,憂慮來憂慮去,什麼都做不了,顧慮太多反而容易讓自己丟掉最佳的學習時機,耽誤了很多時間。所以,什麼都別想,做就行!

  • 2 # 郝海峰002

    作為一個五六年的java程式猿,到現在還沒有遇到技術瓶頸。這個問題可能我還不夠格回答,但看到了問題,也想和大家交流下心得。

    一直感覺自己像是在學生時代,程式猿的知識學無止境,永遠可能隨時會蹦出一堆疑問縈繞心頭,和你的好奇心一起驅動你去學習進步。

    有過一遍一遍重複地實現相似功能的經歷,有過夜以繼日攻克技術壁壘的時候,也有過深挖原始碼,準備徹底搞明白三方中介軟體底層結構原理的例子。但僅僅是這些又有什麼意思。為解決生產環境各種千奇百怪的問題逼迫著你去了解jvm,瞭解java編譯器,瞭解第三方框架類庫,瞭解各種web伺服器,各種流行容器。有時候這些都不夠。你還需要深入瞭解各種標準,各種協議去解決問題,估摸要不要自己開創性地搞個實現福利大家。

    這麼一折騰五六年就過去了。也曾中途換個語言玩幾天,但玩到後來發現也只是殊途同歸,語言僅僅是語言。

    重複性的工作會麻痺自己。為了防止這種麻痺,我會時不時設法挑戰下自己。理論也好實戰也罷,不定期給自己搞個學期測試。計算機技術、網路技術發展半個多世紀,多數成果都需要我搞清楚,這裡如果再提到數學就太打擊人了。所以一直提醒自己保持一顆求知的心。我是程式猿,我是靠手藝吃飯。

  • 3 # Gfilsxin

    如果你覺得遇到技術瓶頸,不如嘗試做以下幾點:

    堅持長期閱讀技術文章或書籍,涉及面可以廣一點,不只是侷限在自己的領域,這樣可以逐漸開啟你的視野。如何開啟思維,可以閱讀一些管理類的書籍,當然最好還是和技術管理相關,也可以閱讀一些與程式設計思維模式相關的書,如架構師類、設計模式類、程式碼之美等書籍;逐漸培養自己的附加技能,不要總是侷限於上班需要的那點技能。比如現在自媒體這麼發達,為什麼不學習一下寫作、影片等技能,逐漸打造自己的內容品牌,也許能給自己開闢一個新的賺錢領域!堅持運動,每天堅持做一件事,會讓自己覺得充實一點,少看抖音多閱讀!

    基本就這些吧,希望對你有幫助。

  • 4 # 人生路誰主沉浮

    什麼是技術瓶頸?技術瓶頸是困擾,是似懂非懂!

    一名程式設計師的素養應該具備不斷的學習能力,邏輯思考能力,快速掌握新技術的能力!很多程式設計師都是在不斷的培養自己的能力!但是,也有很多程式設計師不知道如何去提高自己知識的廣度和深度!

    計算機,說白了只有五樣東西,控制器,運算器,儲存器,輸入,輸出裝置!任何的語言技術都離不開馮諾依曼計算機原理!現代計算機原理模型都在該基礎之上建立的,包括諸多語言的發展!於是乎,程式設計師對計算機應該保留最基本的認識去理解技術層面的運用!這就是程式設計師必備第一點,計算機原理,深刻認識計算機原理就會讓你清楚的認識到不同語言程式碼的設計思路,任何語言都是在為這五大元件服務,並且,透過對這五大元件的理解,加深對語言宏觀方面的結構認知!

    那麼離程式設計師最近的就是作業系統,但凡在一個計算機上寫程式碼,都需要作業系統來控制,都需要透過對作業系統的介面,類庫進行呼叫!作業系統是計算機最重要的組成,是人機互動必須的!也就是說,懂了作業系統如何對計算機硬體怎麼管理,你就懂了語言是怎麼對計算機完成操作的,作業系統方方面面都很重要,Windows,Linux現在是主流的個人計算機作業系統和伺服器作業系統,就好比JAVA虛擬機器需要對這兩個作業系統做適配(面向物件設計模式——介面卡模式),因此很多語言的設計模式也是來源於工作,生活,自然科學,是大自然促成了人類智慧,也就是說任何博大高深的成就都來源於對自然的領悟!

    我們或許平時工作,會有很多的問題,我們需要做的是面對,以誠懇的態度面對工作的問題,以更加卓越的心態完成自己的程式設計,這就是程式設計師第三個必備特點,心態!調整自己的心態,積極面對上級安排任務,才會不斷提升,擁有源源不斷的想法,然後透過自己的想法去查詢自己所需要的資料,去查閱不同的書籍,這樣就可以提高自己知識點的廣度和深度!

    第一點,第二點,是基礎,不可敷衍,否則會沒有靈感完成第三點,因為你若不認真對待第一點,第二點,你就無法深刻認知,就無法擁有想法去解決發現問題!

    獻給鍾愛科學的人!

  • 5 # 光明右使8787

    可以說九成的程式設計師是不需要技術的,只需要記憶力。對IDE和框架操作的熟練程度,對API手冊的熟悉程度,決定了一個程式設計師的業務水平。

    真正需要技術的是研發框架的和底層開發的程式設計師,這類程式設計師提高技術的捷徑是讀各種開源專案和Linux核心的原始碼,只有站在巨人的肩膀上才能看得更遠,並能避免重複造輪子的悲劇。

  • 6 # ibrothergang

    之前寫過一篇文章,可以看下,如果能有幫助就更好。

    之前和兄弟們閒聊,聊到一個瓶頸的問題。開發 3 年多了,做過的專案和產品也有好幾個了,感覺移動端的知識基本也都瞭解了,最近好像遇到了瓶頸,感覺不知道如何提升了。體現在跟別人技術交流的過程中,大方向業務層面的東西基本沒有什麼問題,可是一旦就某一點深聊的時候,發現自己知識點好像還是停留在表面,不能深入其中。

    其實需要恭喜你,當你意識到遇到了技術或者發展的瓶頸,感到比較困惑時,表明你來到了工作或者職業的一個分界點,一旦突破瓶頸,你又會達到另外一個境界。這個很像長跑,長跑的人在跑步的過程中都會出現幾個極點。到極點的時候你會覺得腿特別沉,雖然有力氣,但是就是感覺抬不動腿。一般的人可能到了極點之後就放棄了,但是有經驗的人到了極點後,他會慢慢的調整,突破這個極點。突破之後,跑步就變成了一個機械的過程,甚至不需要去關心是否有在用力,整個腿步肌肉會自動帶著你往前跑。也就是說,這時候達到了另外一個境界。

    無論是工作還是人生,我們的成長過程就像是在不斷攀登一座巨大的山峰。如果山腳代表你出生的那一刻,那麼山頂代表你死亡的那一刻。而你遇到瓶頸的時候,猶如你爬到了山峰的某一層,你發現似乎沒有可以攀爬的地方,無法再往上。每一層都會有很多人,你要做的就是利用你之前的經驗、知識、認知,去發現你的落腳點,爬上去。這時候你就又達到了一個全新的高度。

    所以,遇到瓶頸不用太慌,你甚至應該為即將遇見全新的自己而竊喜。

    遇到瓶頸後的困惑是自然的,大部分是因為不瞭解產生瓶頸的原因,當你瞭解了之後,一切也就那麼回事。

    程式設計師,一般會經歷幾個瓶頸(時間段):

    1. 工作經驗的瓶頸(1~2 年)

    這個階段剛剛學校畢業,帶著書本里的知識,投入到了工作當中,除了一些研究性的工作,大部分的工作會跟著產品的業務線走。這時候你會發現很多東西和學校裡學習的有很大差別。這時候的瓶頸,是實際工作經驗的缺乏。但是突破的方法也很簡單,學就是了。難度也不大,因為這時候的你,應該是學習速度最快的時候。對於很多的業務內容,和書本的知識不太一樣,會有很強的新鮮感。書本更多傳授的是理論知識,而公司的專案和產品要解決的大部分是工程問題。這是一個可以充分把理論的東西結合實踐的階段,你終於發現了學校裡學習的那些東西的真正用處。

    2. 專案管理的瓶頸(2~3 年)

    經過了第一個時間段,如果產品本身比較好,基本上移動端 Android/iOS 的邊邊角角都會涉及到。UI、網路、資料庫、安全、適配、效能最佳化、第三方庫的使用等等。這時候的挑戰會慢慢從技術上變成專案管理上。因為這個時候你對業務比較瞭解,很多的技術也基本掌握了,會自然的承擔部分專案管理的角色。這會是另外一個挑戰,從跟機器打交道變成了和人打交道。這時候考慮的不一定是要把某一塊技術做的多好,而是需要綜合各個業務,達到專案整體上的最優。

    比如專案的前期,時間是第一位的。首要的任務是如何在最短的時間內產出最小可行性產品(Minimun Variable Product:MVP)。質量和程式碼的架構重要性就會相對變低。最主要的是考慮如何最快的把產品推出去。但是,等 MVP 驗證通過後,就需要不斷迭代,一方面最佳化功能,一方面需要償還之前快速開發欠下的技術債。

    3. 技術深度的瓶頸(3~5 年)

    做了很多的產品,專案管理也做過了。這時候會面臨幾個抉擇,繼續做技術還是轉管理,還是拓展其他的職業。對於那部分技術上想要繼續深入的同學就會有這種困惑。因為做了很多的專案,或者在摸個產品或者專案中做了很多的功能,大部分的知識點都覆蓋到了。但是由於平時主要還是圍繞業務展開,所以潛意識裡是解決了what的問題。比如資料庫會選用 GreenDao,也會使用 SQLite,網路會使用 OKHttp + Retrofit,圖片會使用 Glide 或者 Frasco 等等,這個階段很多的時候我們會因為業務二陷入怎麼用的階段。這也是為什麼大家覺得好像各個方面都懂一些,但是深度不夠的原因。怎麼突破,需要去了解它是如何實現的,有哪些小的功能模組組成。

    瞭解的時候不要貪多,有一句話形容一些讀書人:買書如山倒,讀書如抽絲。同樣也可以形容開發對技術的態度。不能想著這也要了解,那也要明白。一個人的精力有限,就像做產品,需要找一兩項核心的功能去深入打磨,而不是所有的功能都做一遍。

    怎麼去找那個點。根據自己的愛好。一句話,你對哪方面感興趣,或者目前你擅長哪塊,就深入下去。

    舉個例子,有的人喜歡 UI,那麼佈局,動畫,事件這些基本的東西肯定是瞭解的。這樣的話就是屬於第一個階段了。第二個階段,你需要關注一些自定的 UI ,需要了解 View 的繪製過程,熟悉canvas,熟悉paint,對於一些比較有意思的 UI ,能夠仿寫。開始關注效能方面的東西。如何能夠減少繪製次數,如何減少記憶體使用等等。第三階段,就要從原始碼入手,去了解背後實現的原理,比如 TextView 到底是如何實現繪製在螢幕上的,都做了那些最佳化。經過這三個階段,基本上 UI 相關的東西就沒有什麼能夠難倒你了。

    在第三個階段,雖然看似只在某一個點深入瞭解,但是需要補充很多相關的邊緣知識進來。比如說設計模式,GPU 的工作方式,演算法等等,這個過程也就完成了從點到面的擴充套件。相信突破這個瓶頸,跟別人聊起技術,再也不會覺得自己還是那個什麼都懂一點,又好像什麼都不夠深入的工程師了。

    4. 職業轉型的瓶頸(5 年以上)

    這個階段,就需要考慮的更加長遠。是繼續往技術方面深入,還是考慮其他方面。技術方面,比如全棧、技術經理、架構師、技術總監、CTO等,管理方面,比如專案經理、團隊Leader 等,其他如產品經理、產品總監等等。

    遇到瓶頸,說明你知道了自己不知道。很多的時候,我們的悲哀不在於不知道,而在於不知道自己不知道。

    雅典人說,蘇格拉底是雅典最聰明的人,他什麼都知道。

    蘇格拉底說,「我唯一知道的就是我不知道,而你們也不知道,但是你們不知道自己不知道。」

    當遇到瓶頸,知道自己不知道的時候,也是提升自己,讓自己知道的好機會。跨過去,美好的風景在等著你。

  • 7 # Kapu

    1.多讀書,書上的知識講的更加系統化,便於全面瞭解某個思想,框架,功能;

    2.多關注業界動態,如果是架構師,你知道一點概要資訊(如,KeyDB是Redis的fork版本,並進行了強化,添加了更多功能,license也更友好),就比你知道redis某個API具體怎麼用更重要,目前jdk版本如果想用比8新的選OpenJDK 11比較好,這些可以透過圈子知道,也可以透過閱讀知道,但是此類閱讀比較零散,比較概要,,對知識面的廣度很重要,對某項的深度幫助不大;

    3.多實踐,架構師都是練出來的,第一次做架構肯定是戰戰兢兢,問東問西,求爺爺告奶奶,四處找支援,,第二次基本就好多了,有過一次經歷,腦子裡有東西了,這次根據客戶需求進行調整即可,當然也需要加入上次沒有的要求,這部分還是痛點的;

    4.寫程式碼,更加上手的實踐,很多人說做了管理/架構師就不需要寫程式碼了,別被他們坑,不得不說華人有些方面的固有思想缺陷是有害的,有一點就是“階級思想”,做了管理,寫程式碼是不是丟範兒啊,還有就是“偷懶”思想,管理的事都忙的要死,哪裡有空寫程式碼啊等等,一定要摒棄一些消極思維,積極的不斷學習;(這裡的寫程式碼,指的是更細緻化的工作,不只是coding)

    5.攻關的心態和能力,碰到問題沒人能幫忙咋辦,自己百度啊,這個會比較亂,要有辨識的找,還有思考,還要嘗試,實在不行就看官方手冊,這個對英文要求比較高,更重要的是耐心,,有過一兩次這種經歷,你就會逐漸培養起自己解決難點的信心;

    6.程式設計世界觀的建立,這個比較抽象,軟體是對現實世界的抽象,所以要注重觀察,注重總結,,同時很多事情不是一是一二是二這樣非常明確的,比如網路訪問時的路由器丟包是無法把控的,只能採取容錯措施。

    1系統性,2.廣度,3.實踐,4.勤奮,5.信心,6.思想。

    還有比如站在使用者的角度考慮問題,以及避免讓使用者帶入歧途,你是專業的,要避免使用者/客戶的不良要求。(這點說起來容易,做起來難)

    技術路線,籠統的說有架構師和技術專家兩個方向,架構師比較偏重廣度,但是核心的部分他也得至少是半個專家,整體抽象思維能力要強,決策能力要強;技術專家眼光會窄一些,窄了才有更多時間經歷深入,比如資料庫專家,聚焦關係型資料庫,甚至MySQL專家,熟悉MySQL的方方面面,但是外面的事情,就顯得有點弱了,但是MySQL調優,底層問題,版本固有缺陷的避讓,他就是大牛。

    還有,永遠要不斷的學習,不斷的總結,永遠不要說自己夠用了。永遠不要去侷限在所謂的前段,中臺,後端,資料端,那是給真碼農準備的,不想做螺絲釘就不要分,即使你現在是螺絲釘,你也要有成為部件,成為組建,成為成品的期望。

    就說這些吧,祝好運。

  • 中秋節和大豐收的關聯?
  • 林黛玉對趙姨娘不假辭色,不怕探春不開心麼?