程序員遇到困難的時候怎麼辦

❶ 程序員的職業生涯通常會遇到哪些為人熟知的職業瓶頸該如何應對

會的。身邊同事工資翻了一番，但自己跳槽加薪難，面試無回復，跳槽加薪不高;我想離開一線的開發工作，做一個技術管理的職位。我對自己的技術實力和項目管理能力沒有信心。不願意寫一輩子的代碼，想尋求職業突破(進入知名公司，拿高薪)卻找不到方法，缺乏明確的職業規劃。這類朋友還是比較多的，主要是想學但沒有方向，這應該是廣大程序員工作人群的困惑。

其實，剛開始的時候掘坦，我並不喜歡把自己的作品記錄下來，更不喜歡把它寫成微博，發布在公眾號上。即使在公司里，我也嘲笑它，認為這只是形式主義。但在我被困住的那些年裡，我一直在寫作，讓自己不去想那些事情。這次經歷讓我想到了用一種新的方式總結經驗。乍一看，根據某一條目逐字逐句地輸入你的工作經歷似乎是在浪費時間。但在不斷總結工作經驗的過程中，我們對工作進行了更仔細的梳理。這實際上是一個思考的過程，在經驗中尋找共性，並逐漸形成自己的工作方式。隨著時間的推移，你會擺脫焦慮，找到一條適合自己的道路。

❷ 程序員在Bug面前的反應

開發應用程序過程中一定會遇到bug，這是很正常的事。程序員會有各種反應：生氣，沮喪，郁悶甚至泄氣，也有一些程序員會比較淡定。怎麼修復bug，解決問題，也是一項技能。下面北大青鳥來分享程序員在bug面前反應情況。

當氛圍變得緊張的時候，這些話就會顯得輕松幽默。最終，bug也會修復成功，你將會繼續下一個任務。我相信許多web開發人員和程序員在編程中都會遇到困難，而事後回想起來，會覺得很好笑。

程序員在bug面前反應情況

1、我不知道該刪掉還是重寫

看這些曾經的代碼也別想重寫，邏輯性差，冗餘代碼多，讓人難以理解。B不過，如果功能沒出現問題，千萬別去修改。

2、一開始架構時就該查Github

Github上面每天都會發布的一些神奇的開源項目。所有語言的程序員都會肆粗利用網路，為已存在的項目創建分支，添加項目wiki描述，或者創建自己的代碼庫，這些都為各種各樣的項目的插件和模板提供了豐富的資源。

3、為什麼這個腳本要依賴這么多庫

說到一些越宏悔來越被廣泛使用的計算機語言，像Java和Objective-C，庫文件的數量也不斷增加。明顯能看出，構建一個框架需要許多基礎庫，一些JavaScript插件也要大量的附加文件。

4、網上一定有解決辦法

遇到困難時，第一反應是上網查資料，很多程序員會在論壇上發布他們的問題，最終這些問題都會被解決並存檔。Google會很神奇地選擇一些跟你的問題相關的關鍵字，就能夠輕松得到一些有幫裂絕鎮助的信息。不過，有時一些特定的問題，相關的信息並不多。

5、有這個功能的插件嗎

何必多此一舉，插件是擴展任何程序或者網站用戶介面的很好的資源。另外它們還為開發者提供了一些定製及獨特的選項。

6、對於網站項目，好擔心InternetExplorer

使用IE渲染網頁遇到的各種困難，我就不提了，從5。5版本到IE9-IE10，對於瀏覽器的支持問題的爭議就一直不斷。Web開發員很害怕網頁調試，使用IE6進行渲染更是噩夢，幸好那已成為歷史。

❸ 工作一到五年的Java程序員遇到瓶頸應該如何提升

工作了5年的Java程序員，該如何提升,做了3~5年Java開發，你已經積累了不少項目經驗，擴寬了技術廣度，也許已發力成為團隊管理者。到了這個階段，大家卻常有這種感受：感覺自己卡在瓶頸進步緩慢，技術水平很難像早期一樣實現大幅突破？
其實大家往往忽略了這一點——提升自己的架構認知（工作5年左右程序員必須重視架構認知的提升，這會很大程度上推動你今後的成長）。架構的本質在於面對業務場景給出優雅的解決方案，使得業務能夠快速迭代和持續交付，從而達到降本增效的目標。提升架構認知高度，就像達克效應所描述的一樣，要敢於從愚昧之巔跳到絕望之谷，通過爬升開悟之坡，從而達到架構認知的巔峰時刻。到達巔峰時刻也就掌握了架構背後設計的哲學，面對具體業務場景在架構層面你便能夠輕松應對，以無招勝有招。
提升架構認知，要緊抓3個關鍵點：業務洞察力、技術視野、原創力（執行力）。
1.業務洞察力是技術戰略層面的問題，在當下能夠做出合理的判斷，清楚公司做什麼事情收益最大；

2. 技術視野即技術選型能力，是技術戰術層面的問題，在清楚做什麼事情後，需要進一步解決怎麼做的問題，也就是能夠給出合理的技術選型方案：是完全基於開源的方案，還是基於開源二次開發的方案，還是完全自研的方案；
3. 原創力（執行力）是技術落地執行層面的問題，一旦技術設計方案確定後，需要能夠快速Rush完成。
這3點層層遞進，最重要的是先把技術戰略問題思考清楚，然後再進一步解決技術戰術問題，最後是快速落地執行的問題。
工作5年左右的程序員，在原創力（執行力）層面比較有競爭力，往往欠缺技術視野以及業務洞察力。後面2點更加重要，這2點解決的是架構設計哲學問題，是架構師能夠持續擁有競爭力和影響力的立身之道。

舉個場景的例子來詳細說明：一提到分布式鎖問題，大多數人想到的方案是基於Redis的Master-Slave模式來實現。這個實現方案行不行？分布式鎖本質是一個CP需求，基於Redis的實現是一個AP需求，乍一看基於Redis的實現是無法滿足的。脫離業務場景來談架構都是耍流氓。
從技術戰略的需求層面來看，如果分布式鎖在極端情況下獲取鎖的不一致，社交業務場景能夠接受，那麼基於Redis的實現是完全可行的。如果業務是交易場景，分布式鎖在極端情況下獲取鎖的不一致性無法接受，那麼基於Redis的實現方案是不可行的。在鎖強一致性的場景下，需要採取基於CP模型的etcd等方案來實現。

❹ 程序員遇到很難的技術問題是怎樣的感覺

昨天剛領一個線上P0級重大事故，持續時間1小時，影響范圍全站 ！准確的時間點是下午17點開始，具體問題定位且聽我下文細細道來。

先說感覺，那感覺真是太刺激了，本來下午五點，昏昏沉沉的，瞬間一個激靈就清醒了（想像一下高中課堂，你在打瞌睡，突然老師走到你面前給你一下子的感覺），原本准備再過一小時吃晚飯了，吃完晚飯再摸魚到21點就可以下班了呀，別問我為啥到21點，問你就不是程序員！

帶著無比緊張且顫抖的心情開始定位問題，先來個錯誤日誌嘗嘗鮮：

整個事情的發酵是這樣的：

1、下午五點開始有少量的慢sql報警，沒有人當回事，因為這種事情總發生，雖然大家都知道在實際開發中如何避免慢sql，但是整個團隊要想完全避免慢sql卻很難；

2、五點十分左右，開始零星有用戶反饋指定功能不可用，SLB開始報警，技術開始介入排查；

3、十五分左右，客服部門電話開始爆炸，用戶密集反饋指定功能不可用，技術部開始重視；

4、二十分左右，所有服務大面積出現介面無法響應，整體服務不可用；

5、我們一開始定位覺得是MySQL的問題，因為前面有mycat的慢SQL報警，後來定位並不是MySQL，因為MySQL的內存、連接數、流量這些指標都很平穩；

6、最終在五點三十分的時候我們定位到是ES出問題了，因為所有的Java服務不可用最終都指向上面的錯誤日誌，bbo提供的服務線程池滿了，再有請求進來直接拒絕了，查看這個服務的代碼，最終查詢的是ES，此時的ES進程已經處於假死狀態。

那接下來大家說怎麼辦？如何快速的恢復線上服務？

重啟！

是的，只有重啟大法此時是最快的解決辦法，你不可能說保留ES事故現場，讓我用arthas之類的工具來現場分析jvm內存情況。

然而重啟之後服務依舊是不可用，介面還是無法響應， 大家知道這個時候是什麼原因嗎？為什麼重啟了ES服務還是不行？

後續繼續重啟報錯bbo日誌的相應服務，當這些服務全部重啟完畢後，我們的服務終於恢復訪問了，這個過程持續了十幾分鍾，確切的說，直到17點五十多分，我們的所有服務才恢復了訪問。

接下來就是事故總結、相關責任人、產生問題的原因、接下來的優化方案，全公司郵件通報！

你說這個難不難？本身並不難，難的是事情緊急且重要，這個時候你慌了啊，亂手亂腳的，大家你一言我一語的，如何冷靜提取有效信息然後盡可能快的解決生產的重大故障才是最難的！

最後，當一切都恢復平靜的時候，你會發現：「卧槽，好累啊！」。

虛脫的感覺！

最後祝大家程序員節日快樂，今年可是程序員的本命年哦

2020 = 1024 + 996 = 404 + 404 + 404 + 404

這種感覺能難受，很壓抑。

技術難題，對於程序員來說，是經常有的事，關鍵是如何面對吧。

說下我的事情，雖然也會寫點代碼，但並不是以此為正業，所以對於真正的程序員來說，可能說法會有點偏頗。

遇到難題時，一般都在網上搜索解決方法，一般來說，都有很優秀的程序員分享他的勞動成果，所以一般都能解決問題。但也真正碰到難的問題，一個就是循環的問題，無限極菜單問題，當時都是找了很久，看了很多遍才明白過來，當時自己是幾天都不太開心，也不太想說話，總是在測試著程序。挺煩也挺不開心的。只是最後做出來了，心情就好多了。

這是我的一些經歷，當然，如果全職程序員，可能壓力就更大了。

如何形容這種感覺呢？焦躁，緊張，失落，無助，亞歷山大...

再多詞可能都描述不清楚。本人在工作中經常遇到難題，有些問題一兩個月都搞不定。遇到這種問題，估計只有下面這張圖的表情能描述此時此刻的心態了。

程序員遇到的難題其實分為兩種，一種是沒有辦法定位清除的問題，另外一種是定位清除了，但是沒辦法，或者很難解決的問題。

難定位的問題

所謂難定位的問題，其實就是你根本不知道這個問題是什麼。比如系統突然掛掉了，你從現有的信息根本不能確定問題在哪。這個時候你剩下的可能只有滿腦子的問號了。

如果系統只掛了一次，後面不再出問題，那就很難找出問題的根源了。不過這樣也有好處，那就是問題的影響的程度相對較輕，畢竟不容易出現。所以在軟體開發中通常不是什麼問題都解決的，因為不是所有問題都能搞清楚是什麼問題，談何解決呢！

難解決的問題

難解決的問題是問題搞清楚了，但是基於現有架構很難，或者沒法搞定。遇到這種情況，通常先是很高興，興奮，然後就只剩下無奈了。

當然，從技術層面來說並不是完全解決不掉。只是如果要解決需要涉及架構調整或者其它方面的改動，修改調整的內容太多。這種情況下就要考慮利弊得失了。

如果改動太大，可能會引入很多新的問題，可能得不償失。因此，遇到此類問題可能會採取一些規避方案。

當然，在開發和運營當中遇到各種問題是很正常的，關鍵是遇到不同的問題採用不同的策略。首先保證的是業務的正常運行，然後是考慮是否需要徹底解決。這樣慢慢調整，心理壓力會小一些。

作為一個工作多年的老碼農，在工作也遇到過一些艱難的技術問題，就以切身體會談談對這個問題的看法。

首先需要明確一下，問題是否困難除了取決於問題本身之外，還在於解決問題的人的水平，也許對你很難的問題，在別人看來不過是小菜一碟。明白了這一點，那麼這些技術問題也就成了考察程序員水平的試金石，有些人可能會因此氣餒，甚至放棄；而有些人則通過解決問題學到了很多新的技術，也讓自己進一步成長。

記得多年前看工作中要用到一款開源庫，那時候剛學完C++不久，自以為對面向對象了解甚深，然而學習這個庫時卻是一頭霧水，最後在經過泡論壇，然後又認真的學習了面向對象設計模式，後來不但能使用那個庫，更重要的是對面向對象編程有了更深的認識！

後來還有很多類似的事情，剛開始時感覺無比困難，但是通過自己的努力，或求助他人、或查閱資料，當最終問題解決時，你會發現自己又牛逼了一些，然後再遇到一些新的問題，如此循環……

其實編程也是一個學習的過程，就如同爬山一樣，每一階段都會有一些山頭，只有當你爬上山頭才能欣賞美麗的風景，但是當你爬上一座山頭的時候，就會發現更高山峰！只有當你爬上最高峰，才能「一覽眾山小」，可是到那時，你可能會嚮往地球之外的天地！

很難解決一般就是遇到某些瓶頸了，不同瓶頸的感覺是不一樣的，但無非可以歸結為下面幾類。

成本原因
不讓馬兒吃草，還想讓馬跑。這個是有些不太理解互聯網的一些領導的錯誤觀念，他們會給你安排一個老舊台式機，想要讓你承載幾萬、幾十萬並發的秒殺系統，你當然很難解決。
外界的評論可能是，「這幫程序員是吃干飯的么？這系統也太垃圾了！」
老闆的評論是，「我這台式機也不少錢呢。」
程序員的評論是，「這摳門老闆不會是個傻子吧。哎，再優化優化吧。」

當然，有些情況也是能夠理解的，公司明白需要更好的設備，但是由於成本控制，不得不在某些方面節省。但換句話說，設備成本是占不了一個大頭的，可能有其他方面的成本更加需要收緊。

如果是因為成本原因，我們的心情可能是無奈，又有些不能施展拳腳的束縛感。

歷史 原因
舉個例子，系統用了5年了，迭代了N個版本，在面對新的需求的時候，就會出現需求限制於系統的情況，常常會有程序員說，這個實現不了，那個不符合現在系統規則。其中很大一部分是這些年的積累，欠下的技術債造成的。俗話說，大船難調頭。

這種情況更多的出現在剛創業之後的幾年，由於一開始的快速迭代，追求先把業務流程跑通，先生存再規范，會讓一開始的軟體開發流程並不那麼規范，如果在1-2年內沒有進行重構，那麼積攢的3-5年的技術債就會慢慢把你壓得喘不過氣來。

解決這種情況，一是需要時機，給出足夠的空間和時間讓技術團隊重構，二是需要魄力，你得有成功的把握，不能幹著干著說不行了，咱們還是回到原來吧。

如果是因為 歷史 原因，我們的心情可能是期待和渴望，又有些對現狀的無奈。

能力原因
雖然說專家很厲害，但說白了，大部分企業需要的研發人員，還到不了需要專家的級別。所以，一般而言，沒有什麼技術是攻克不了的。如果真的遇上了，那就說明你的公司已經到達了一個新的層次，從而需要那個層次的人員來解決，可以通過外聘或者顧問的方式，引進新的技術。

如果是因為能力原因，我們的心情雖然有些力不從心，但又為公司在新的台階而高興。

不管怎樣，程序員是一群追求美好的人，不管是外部限制還是內部限制，不能解決的難題對於技術人員來說總是很憋屈的。

不能著急，慢慢分析，找到問題點，沒有解決不了的問題

程序員的技術問題，排除架構師技術選型錯誤以外，都是程序員的功夫不到家所致。

1,面向網路的程序員會第一時間問度娘，各大社區求助大神。

2,面向源碼的程序員會第一時間查看源碼實現，查找api文檔，思考解決方案。

3,不管技術如何發展，架構如何延伸，不變的是基本功，再先進的組件都是由基礎語法書寫出來的 。

練武不練功，到老一場空，共勉！

首先說下這個很難的技術定義，個人認為在你知道之外的知識都是很難的，一旦你深入了解其使用方式，原理，甚至閱讀了他的源碼，你會覺得有的時候會恍然大悟。程序員是一個不斷要學習的崗位，就要面臨很多從未知到已知技術的時候，每當遇到這樣的情況時候，總有種不解決了這個問題，睡不著覺的感覺，心裡不踏實，總是想盡各種辦法去解決這個問題。甚至可以一直追查這個問題。也許這就是一種執拗吧

我老公最近就遇到一個大石頭需要敲碎，我作為一個旁觀者，都挺心疼他。

他還在讀博，最近遇到的問題是他一個項目上的問題，也跟他的畢業設計相關。他剛讀博的時候確定了一個方向，去年開題的時候他覺得這個方向沒有什麼前景，真的是考慮了好久要不要換，如果不換，就是安穩的畢業，換的話接下來的一年多時間他會很艱難，很多新的問題需要一一克服，最後他決定換了，他說他讀博就是為了提高自己，還是想挑戰一下。

年前，系統板設計好了，然後最近做好回來了，開始調試，說這個板子跟個石頭一樣，不工作。本來就是禮拜一到禮拜六待在學校不回來，周日是休息的。現在放假回來都是在啃變壓器的東西，早上起的很早，晚上又很晚。真的挺心疼的，他還安慰我說，他又要進步了。挺擔心他的身體的，我特別希望時間能快點過去，能順利畢業。他卻不希望，總覺得時間過的太快，沒有時間搞研究。

今年的生日願望，希望他科研順利，身體 健康 。

以我的從業經歷，說說遇到很難的技術問題是什麼感覺吧： 興奮、充滿挑戰性 。尤其是在開發中遇到了技術難題，很多情況下真有種可遇不可求的感覺。

我認為能遇到技術難題，至少證明這個工作是有價值的。 這種價值體現了兩個方面，一是你的工作在整個產品開發中占據重要地位，甚至是核心地位。二是你的認知和經驗，仍然有成長的空間。如果你的工作一直沒有遇到難題，輕而易舉地就解決了一切，那麼很可能是你沒有機會深入重要的核心部分，或者你的工作性質可替代性很高，簡單重復性很高。

分解法。 把技術難題拆分，盡量的單元化、模塊化，這樣有利於逐步攻破，逐步解決。主要是降低技術難度，尋找真正的難點所在。如果問題無法拆分，就是那麼一個點，那麼需要逆向思維，可以先把問題擴大，看看涉及面有哪些，然後再縮小范圍，鎖定關鍵之處。

刨根法。 把技術難題抽象化，理論化，從根本的源頭去解決。很多技術問題，從基礎理論的角度去看，其實真的不難，只要你能定位到相關的技術點，困難點，知識點，就很容易進行快速解決。解決的終極辦法就是從理論上徹底解決，做到知行統一。

討論法。 三人行，必有我師。很多情況下，所謂的技術難題，在別人的眼中，也許並不是難題。很多情況下，小組討論，交換意見，方案互補，就可以解決難題。有些情況下，還需要和供應商一起討論，主要是補充信息的錯漏。經常出現的晶元問題，很多情況下供應商都更加有經驗。因為供應商有更多的使用客戶，有很多解決問題的經驗。最主要的是，晶元是他們設計的，他們更加清楚緣由。

沒有絕對的技術難題，有的只是尚未解決的技術難題。

❺ 程序員編程時心力交瘁，失去工作熱情怎麼辦

心力交瘁中

導讀：程序員在編程的時候因為心力交瘁，從而失去工作熱情的現象並不罕見。很多文章都可以成為這一方面的證據，證明這已經是IT行業一個普遍現象。因為我已經有處理過職業倦怠的經驗，所以我想要更深入地探索這個問題，幫助大家解決甚至預防它。

倦怠發生的原因

程序員比其他領域的專業人士更容易產生職業倦怠。至於為什麼會出現這種情況，我也沒有一個明確的答案，但我認為有四個主要原因

第一個是生理原因。每天坐在辦公桌前，面對著電腦，是不健康的，會讓人更加無精打采、昏昏欲睡。嗜睡還可能導致其他不良的生活習慣，如吃零食，抽煙，熬夜等。然後最終導致郁結於心，產生倦怠感。

第二個原因是，編程是認知高度密集並且壓力非常大的工作，會導致心理疲勞和損傷。

第三，有可能你現在已經精疲力竭了，因為正在做的工作耗盡了你的力量，並且收獲甚微。對此，唯一的解決辦法是離開一段時間，好好反省下――如果不考慮錢的因素，你希望做什麼樣的工作。

第四個原因不是我想出來的，是我在《Hacker News》的評論部分發現的。有一個人准確地描述了，「職業倦怠是由反復做大量犧牲，或努力完成高風險問題最後卻以失敗告終而導致的。這是伏隔核(nucleus accumbens)負面預測落差的結果。你的大腦需要理智地應對失敗。這一條說得真的太對了。在創建軟體的過程中，基本上沒有一天不是處在各種失敗和挫折中。

我本身也經歷過好幾次職業倦怠。雖然我沒有一次放棄編程，但偶爾我也會懷疑我選擇的職業是否正確。所以，從那時起，我開始注重策略化的工作方法，以保持長效的動力和生產力。我將在這篇文章中介紹我的一些開發習慣，以及一些可以預防或甚至消除倦怠的技術手段。

先從基本的開始。

吃好。不要以為做個素食主義者就萬事大吉了。試著逐漸用白開水代替蘇打，低糖飲食，多吃蔬菜，不要吃得過飽。還有最重要的是要持續下去。

睡好。這包括良好的睡眠質量和充足的睡眠時間。更好的睡眠環境，能夠讓我們一覺醒來倍感清爽。具體的一個技巧就是減少會讓人徹夜難眠的藍光照射。這可以通過安裝Flux，來調整計算機顯示器的色彩。

不要勞累過度。已經有很多證據表明，生產效率，即輸出，會在經過4個小時聚精會神的工作之後，急劇降低。像程序員這類認知高度密集的職業，要想長期保持高效，那是不可能的。

番茄工作法。這對於既要保持生產力，又要獲得一些必要休息的程序員，是一個既簡單又有效的方法。番茄工作法，即集中精神工作25分鍾，然後休息5分鍾，然後循環。如果在每次的工作時間都有一個特定目標，效果會更好。理想情況下，在休息時間里，應該去做一些遠離計算機的活動。如散步，俯卧撐等。當然你還可以在三次番茄工作法後，休息個30分鍾，效果也很好。

保持活性，保持前進。我本來想說的是――運動，但很多人有一種誤解就是，認為運動必須包括去健身房，或其他。但是在現實中，保持活性也可以通過用爬樓梯代替乘電梯，或者將汽車停放在一角，而選擇騎車上班，總之，其他在日常中就能運動的方式更易於實現，而不是讓人整天沉溺在電腦前。

更具體化的要點

實驗，玩，學，原型。這些事情能讓你在短期內獲益匪淺，並且迅速輸出。例如，以同樣的你慣用的方式，不斷地建立網站。但是，隨著時間的推移這會逐漸變得乏味，讓人提不起一點興趣。編程有部分也是工程，需要使用經過充分驗證的技術用於生產軟體。但它也可以讓你玩樂、實驗和嘗試新想法。將20%的時間消磨在技術上是避免職業倦怠最有效的策略之一。所謂消磨在技術上可以是嘗試新的庫，也可以是創造一些有趣的但與工作無關的東西，又或是學習一些自己以前不曾涉獵的內容，如函數式編程。

參加聚會，會議和收聽播客。編程會讓人感到孤單。和其他開發人員碰面，或在播客上聽他們的經驗，能讓你更在意和注重自己的工作。沒有人喜歡抱怨，但是分享或聆聽來自於其他程序員的奮斗經歷，以及他們如何克服困難的過程，能夠激勵你繼續前進。

打造良好的工作環境，千萬不要在工具上吝嗇。能快速編譯的PC，能讓你的時間不必浪費在沒有必要的等待上。確保有一個舒適的椅子、桌子和顯示器以及設置。如你在嘈雜的環境中工作，那麼買一個高品質的耳機，將噪音隔離開來。

掌握工具。良好的工具可以使得編程更加愉快，掌握這些工具能讓工作更加高效。這是眾所周知的一點，但我還是要再重復一遍。了解工具，如編輯器，操作系統，命令行中的所有快捷方式，可以為你節省很多時間。自動化日常任務可以加快進程，進一步遠離倦怠。

休息，涉獵其他方面。除了編程之外，還有許多有趣的活動。例如：體育運動，文化活動，sex，閱讀，樂高積木，社交活動，釣魚，烘焙，攝影等。如果你總是持續做一件事，如編程，那麼總有一天你會不可避免地心力交瘁。所以，做一些看似無關但實際可以重新點燃激情的工作，這些工作或許還能激發你新的想法和思路，就像那位傳奇的諾貝爾獎獲得者理查德費曼學習板擺動一樣。

考慮更換工作或啟動一個不同的項目。職業倦怠也有可能是因為你總是在做無趣，又耗費心力的工作，如整天微調現有的代碼庫。也有可能是因為你現在工作的項目已經不符合你的興趣，或你的價值標准。此外，如果你發現編碼再也激發不了你的激情，那麼也可以考慮相關領域，如信息架構，系統管理等，也許可以再次點燃你的激情。

將那些你可以順利完成的工作，整合為日常任務。這些工作包括測試代碼，寫注釋，改善變數命名等等，這些都可以釋放內啡肽，有助於恢復工作行為。這條技巧意在讓我們的大腦對我們做的工作更有積極性。

結論

世上並沒有治癒職業倦怠的仙丹妙葯，而且每個人的情況都不盡相同。所以，希望我上面列出來的這些我覺得有效的小貼士也能為你所用。

誠然，我們需要時間來培養新的習慣。但是吃得好，睡得好，鍛煉和好好照顧自己，能讓你感覺更好，從而幫助你在完成工作的時候做得更好，並保持對編程的熱愛。

❻ 程序員都會遇到一些職業瓶頸，程序員該如何規劃自己的職業生涯

我也有工作上的困難，就我自己的經驗來說吧，我是如何渡過的！工作上的困難和體重的困難都有一個共同點，那就是，緊張會讓你的情緒變得很糟糕。情緒的高低直接關繫到個人的心態，在開心的情況下，工作起來會很放鬆，而在情緒低落的時候，就像是一年那麼漫長。情緒低落大多是因為家庭的事情，人脈，壓力。這就要求我們去處理和緩解我們的緊張情緒。讓我談談如何緩解你的緊張情緒。

親戚朋友，把自己的情況告訴親戚和親戚，讓他們幫你解惑，如果你在這個地方，可以和你的好朋友或者家庭成員聊聊工作上的困難，大家一起努力，總要有一個好的辦法。要麼就是和他們一起工作，然後在外面走走，或者找個時間出來玩一玩，讓自己有個放鬆的機會。

❼ 程序員，感覺技術停滯了怎麼辦

你是一名程序員，感覺技術停滯了。那你就去深造唄，就是你可以選擇各種的程序任務去做。哦！針對自己有弱點的地方，然後去學習。活到老，學到老。