程序員是個

❶ 作為一個程序員，其最有價值東西的是什麼

做為程序員，除了要掌握多門程序語言和多種資料庫，了解前端技術、後端技術，通曉網路七層架構，知道 TCP/IP三次握手和四次揮手，編寫漂亮的代碼，設計優美的架構……之外，我們還要解決研發、程序運行和產品上線過程中遇到的各種問題，而且被要求以最小的代價來解決問題……我們容易嗎？
除了編程技巧和程序設計能力，解決問題的穩准狠是衡量一個程序員是否優秀的重要因素之一，也是資深技術人員真正的價值所在。在科技浪潮澎湃、技術信息撲面而來的今天，一位剛畢業的大學生如果足夠勤奮，他可以在兩三個月之內掌握一門編程語言，並編寫出像模像樣的軟體，他們的學習速度甚至超過了我們這些老程序員，但是解決問題的能力是無法速成的，只能依靠時間、經驗和慘痛的教訓歷練而成。有時候還需要靈感和運氣。
程序員是IT行業的支柱，最基礎的根基。ITjob官網有IT行業人的生活工作分享，或者行業小結。很多大牛的博客也會有行業的解析。如果你對自己的價值產生了懷疑，可以多去看看看其他人的生活，多溝通交流。盡快調整自己的工作狀態，生活還是很美好的~

❷ 如何成為一個程序員

如果想做一個程序員，在沒有基礎的情況下，買書自學是一個辦法。但是大多數人會因為沒有相關的基礎知識，導致看書看得一知半解，因為有不同的語言，不同的開發環境，在你不了解的時候，買的書不一定合適。

比較速成的辦法還是去報名一個培訓班，系統的學習一下基礎知識，然後選擇一個發展方向，再具體的針對性的買點書籍來學習。

程序員是一個不停學習的崗位，你需要每天除了工作以外，花一定的時間了解新的技術或正在使用的技術的原理，這樣才能一直提高，不然，可能會被淘汰。在你了解代碼以後，你還需要了解邏輯，就等於你要熟悉你所從事的這個領域及行業。

注意事項：

不管任何行業和任何工作，概念的理解都是成功的關鍵。除非你有強大的概念基礎，否則就不可能成為一名優秀的程序員。

核心概念的理解有助於你用最佳的方式設計和實施解決方案。如果你覺得你現在還沒有好好掌握關於核心計算機科學和編程語言的特定概念，那麼現在回過頭去重新學習這些基礎知識猶未晚矣。

❸ 程序員是一個吃青春飯的職業嗎

在中國有很多人都認為IT行業是吃青春飯的，如果過了40歲就很難有機會再發展下去！說程序員是一碗青春飯，大多是因為這是一個需要高強度腦力勞動的工種，而超過40歲的程序員身體機能逐漸弱化，家庭瑣事纏身，往往面臨繼續做技術還是轉做管理的局面。有人考慮轉型，當然也有人選擇對這份職業矢志不渝。
如果說程序員是吃青春飯的話，那搬磚的算什麼？搬磚的都可以成為工頭，程序員為什麼不能晉升管理層？為什麼非要跟年輕人去競爭最底層的開發崗位？誰會在一個底層崗位上干一輩子？
那麼，程序員的職業發展方向是怎麼樣的呢？一般來說，程序員的發展方向是從程序員到team leader 到PM（項目經理）甚至是技術總監，或者你單純痴迷於技術，也可以嘗試登上技術的巔峰。或者自主創業，都是一名優秀的程序員可以選擇的發展道路。
所以說程序員是一個吃青春飯的職業就是一個偽命題，完全沒必要為此而焦慮。

❹ 有哪些話一聽就知道一個程序員是個水貨

其實如果要嚴格說起來，工作經驗少於一年半的程序員基本上可以算是「假」的程序員。這里的「假」可以這樣來理解。

你的編程能力只有復制粘貼的水準

剛工作的程序員大致可以分為兩類人：1 高校畢業；2 培訓班出身。對於第一類的人來說，在讀書期間老師和學校教的內容都是基礎內容，而且要學的內容非常的多。但學校只讓你學廣，並沒有讓學生專研一門學科。畢竟學校並不能保證每個學生對某個方向一定感興趣，只能把基礎知識教給學生。讓學生自己去選擇自己感興趣的方向，自己自學。所以在校期間對於大部分學生來說，實戰能力基本為零，都是像剛重生在新手村，無知茫然，這也是許多企業愛招應屆生的原因。開始工作，基本只能靠谷歌、靠網路上網找代碼，復制粘貼。這段時間就比誰找代碼能力強了。而對於培訓的人來說更是如此。不要看你在培訓期間學習了非常多的編程知識，好像做了非常多的練習，甚至還自己寫了一個實戰項目。但這些都是在短時間內，靠著培訓老師手把手帶你們寫的。你只管跟著老師走就好，不懂的問下老師就行。你根本就沒有過自己的思考，就只懂：好！今天老師叫我們寫這個代碼！我們就寫！換個角度來看，培訓機構就像富士康工廠一樣，批量製造編程機器，沒有自己的思維。

想要擺脫「假」程序員的身份，你只有努力提升自己的編程水平，讓自己有更好的能力。在工作上能靠自己的實力，去完成分配的任務。你只有這樣才能提升，才能突破薪水的瓶頸，達到更高的層次。

❺ 在大家眼中，程序員是一個怎樣的職業

程序員首先是雇員、然後是工程師；比起創造力，工程能力對這個職位更為重要

為什麼有人在技術造神

大家應該已經感受到，技術圈這兩年已經和娛樂圈創業圈差不多的氛圍了，這其實是有原因的。

最主要的原因是，創業公司和創業媒體越來越多，他們需要大量的程序員投身到創業這個高風險的行業中，而造神，正是讓程序員們自動跳進火坑的絕佳辦法。不是說程序員不能創業，我是說，創業媒體們故意模糊了創造和創業的界限，把程序員們的創造沖動偷換概念，鼓吹了太多不適合的人去創業。

另一個原因是，招聘成本高漲，CTO 們為了能提升影響力，不得不頻頻出席各種大會刷臉。文筆好的再做做自媒體和技術社群，既能強化個人品牌提高身價，又能在融資的時候提升成功率。

總之，這個行業出現了各種技術大神。

這些大神在普通人類和初級程序員眼裡是無所不能的，是他們嚮往的目標；在中級程序員和高級程序員眼裡，這些大神就是他自己，只不過他還沒紅起來而已…

於是攀比心理也開始泛濫，全國第三的架構師比比皆是，整個圈子漸漸就浮躁起來。

然而絕大部分程序員，依然是雇員

媒體們在包裝時，最喜歡按獨立開發者的路線來整。「從小就對技術有天分」、「大學時曾在某編程大賽一鳴驚人」、「寫了個 APP 玩結果一個月有了千萬用戶」、「從公司離職自立門戶三年上市」。

OK，這的確是程序員的一條職業路線圖。但是媒體們不願意告訴你的是，一：只有極少數程序員是通過這個路線成功的；二：這條線其實需要太多非程序員職位的技能，比如產品設計能力和銷售能力。

程序員的價值決定

絕大部分互聯網公司的程序員職位，沒有技術門檻

然而不幸的是，絕大部分互聯網公司都不是技術驅動的公司。真的就是鳥哥說的那樣，絕大部分技術崗位，其實技術門檻都不高（門檻在工程上，後文細講）。技術不過是這些公司的護航艦，而不是破冰船。

先別打我，冷靜下來想想，到底有多少你會的那些技術，是你的同行們不會的呢？不多，對吧？

幾年前億級別的搜索還是問題，現在已經到處是通用解決方案了；幾年前千萬到億級別的網站和 APP 解決方案還在大公司手裡，現在各個架構大會都講爛啦，而且其實都差不多；就連 DeepLearning，帶 API 介面的框架也開始涌現，只需要把圖片用 REST 傳進去就能取到結果了。

很多事情，已經沒有難度，只需要持續投入。是的，對絕大部分程序員來講，他們不需要成為科學家，而需要成為工程師，成為從科學家手裡接過火種，去燎原大地的人。

怎樣才是一個好工程師

工程的本質不是創造，而是去風險化。

工程是關於如何低成本、高效率、按時按量完成既定任務的。所以判斷一個工程師是否優秀，並不是他多有創意多有名氣，而是看他有多穩，看他能多 GettingThingsDone，中文就是「靠譜」。

有時候一個好的解決方案，未必採用了最新的技術和框架，而是看上去朴實無華，功力都包涵在背後的細節里。就像頂尖高手打的斯洛克檯球，每一桿都平淡無奇，只是因為上一桿的回球太到位。

有同學問，那我工程做的太好，豈不是沒有機會遇到一些高難度挑戰了么？放心，一般公司都僱傭了產品經理來幫你製造高危事件。

同樣的，一個好的工程師，會選擇最適合需求和團隊的方案，考慮開發效率和系統效率的均衡，從而已達到最優效果；而不是整天和別人去爭論什麼語言最好、哪些框架過時了。

工程的另一個要求是進度控制和質量控制。

在項目立項之後動工之前，對要做的事項作出詳盡的規劃，對未來一到兩周的工作給出細致的排期，這是進度控制的基礎。

代碼的及時入庫與合並，自動化測試和每日構建，CodeReview 和文檔編寫，這些看似無關緊要的習慣則決定了項目質量。

不幸的是，很多程序員把這些工程上至關重要的東西當成垃圾，視為對他們「創造力」的壓抑。

他們總是以創造力為借口去尋求自身的自在，比如上班不帶胸牌不打卡，中午休息時間在公司看視頻打游戲，最好可以遠程上班，項目到期之前再來檢查進度，公司不要用統一框架，只有傻逼才寫文檔。

對職業的理解偏差和工程能力上的荒蕪，培養了大批能寫代碼但死活寫不好代碼的「碼農」，反而讓那些有著彪悍工程能力和良好習慣的程序員變得奇貨可居。

最後，來說說程序員那無處安放的創造力

有了錘子想找釘子是很正常的原始沖動，但我們必須認識到，創造力對於程序員這個職業來講，是錦上添花的東西。如果你沒有強大的工程能力，那麼創造力也不過是無本之木。所以扎扎實實的把工程基礎打好，這是最根本的。

在此基礎上，我比較推薦程序員採用內外兩條線來培養自己。在公司內的項目上採取相對保守的策略，盡力把穩定性做到最好，培養出自己卓越的工程能力；然後在公司外的開源項目和自己的獨立項目上，採用一些新的技術、實踐一些新的想法、充分發揮自己的創造力，夢想還是要有的，對吧。

這樣做最明顯的好處是，你可以了解到新技術和激進方案的優缺點，從而在進行方案選型時，有更多的依據；還有一個職業發展上的好處：如果不是主負責人，公司的項目往往不能代表你的能力；但獨立項目卻可以作為一個非常好的能力證明出現在你的簡歷里邊。

你可以是一個身懷絕技的手藝人，在自己家裡你嘗試各種手法各種風格的個人作品；但當你參與頤和園這種級別的工程時，好好的把自己負責的石頭雕成總設計師要求的樣子就好 —— 畢竟這個時代一個人已經很難負責整個項目了。這就是我所理解的程序員的工匠精神。

❻ 程序員是跳槽率非常高的一個職業，你身邊的程序員是這樣的嗎

程序員是跳槽率非常高的一個職業，你身邊的程序員是這樣的嗎？

我身邊的程序員不全是這樣，我身邊的程序員有的跳槽頻繁，有的很少跳槽。年程序員的發展基本上是一個閉環，從學習到就業，他們可以通過提高技術和積累項目經驗，來達到一定的市場需求，然後獲得相應的工資。

程序員是跳槽率非常高的一個職業，跳槽這對於任何行業都是一樣的，但是跳槽在it從業者特別明顯，因為不同年齡和技術水平的程序員的工資水平，完全不同！對於剛進入工作場所的程序員來說，基本上工資每年都會改變一次。這一變化是逐年計算和調整的，如果你已經努力工作了一年，而你的上級領導或老闆，在年底不跟你談收入問題，那就是你的失敗。

在一家企業工作，而且加薪也比較到位。然而，由於長時間的工作，我們發現我們已經學會了幾乎在這個企業學習的技術。我們已經成為公司的頂樑柱，但是卻看不到未來有任何提升或改進的空間。在這種情況下，程序員也會有跳槽的想法，去更高的平台繼續工作和學習，讓自己保持增值狀態！

❼ 一個程序員要具備的基本素質是什麼

1. 團隊精神和協作能力 ：

   把它作為基本素質，並不是不重要，恰恰相反，這是程序員應該具備的最基本的，也是最重要的安身立命之本。

2. 文檔習慣：

   作為代碼程序員，30％的工作時間寫技術文檔是很正常的，而作為高級程序員和系統分析員，這個比例還要高很多。缺乏文檔，一個軟體系統就缺乏生命力，在未來的查錯，升級以及模塊的復用時就都會遇到極大的麻煩。

3. 規范化，標准化的代碼編寫習慣：

   作為一些外國知名軟體公司的規矩，代碼的變數命名，代碼內注釋格式，甚至嵌套中行縮進的長度和函數間的空行數字都有明確規定，良好的編寫習慣，不但有助於代碼的移植和糾錯，也有助於不同技術人員之間的協作。

4. 需求理解能力：

   作為程序員需要評估該模塊在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程序員至少需要2到3年的項目研發和跟蹤經驗才有可能有心得。

5. 復用性，模塊化思維能力：

   復用性設計，模塊化思維就是要程序員在完成任何一個功能模塊或函數的時候，要多想一些，不要局限在完成當前任務的簡單思路上，想想看該模塊是否可以脫離這個系統存在，是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重復性的開發工作。

6. 測試習慣：

   軟體研發作為一項工程而言，一個很重要的特點就是問題發現的越早，解決的代價就越低，程序員在每段代碼，每個子模塊完成後進行認真的測試，就可以盡量將一些潛在的問題最早的發現和解決，這樣對整體系統建設的效率和可靠性就有了最大的保證。

7. 學習和總結的能力：

   善於學習，對於任何職業而言，都是前進所必需的動力，對於程序員，這種要求就更加高了。但是學習也要找對目標，一些小coding fans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程序不懂通訊傳輸協議，做應用程序不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語言，永遠不會有質的提高。
   
   

❽ 現在程序員是一個很熱門的崗位，那什麼樣的程序員才是合格的呢

程序員，怎麼才算合格，不好說吧；他就像銷售一樣，一名銷售員，比如網路銷售賣茶葉，他賣茶葉很厲害呀，可是你讓他去銷售房地產，就算他有點銷售的基礎，也要重新去學怎麼銷售房地產，因為銷售的東西是不一樣的，要去了解這個產品，才能銷售的出去，程序員也是一樣呀，程序員的領域很大，有各種專攻，有的專攻入侵，有的專攻開發，有的專攻防禦，就像黑客跟紅客，他們也是程序員呀，只是一個擅於攻擊一個擅於防禦，當然也有全面型的，很少。
比如攻擊性的，入門起碼要三年，我們把它當做十個級別，1級算入門，2-3級算初學者，3-7級算中等，中等就是合格的啦，7-10就是黑客紅客大神級別咯。學習一門編程，兩三年才算入門，中等的最起碼要四年以上

❾ 你覺得程序員是什麼樣的呢能用一個詞形容嗎

我覺得程序員是聰明的！他們可以在虛擬的空間自由發揮，揮舞著各種我們看不懂的代碼，絕對的大神級別。

❿ 一個程序員需要有怎樣的自我修養

作為一名程序員，一個「程序員的自我修養」是什麼？
盡管我們不一定要像尹天仇那麼的認真對待自己的事業，但，一些基本的修養，作為一名新時代的碼農，總應該是要具備的吧。不過真要說修養，方面還是挺多的，技術自我提示自不必說。但我並不打算從這個大家都覺得理所當然的技術方面入手，而是談談，可讀性代碼，這個容易被大家忽視的基本素養。
1、遵從所在團隊的代碼規范。
一個高效、成熟的團隊，必定有一個屬於自己的代碼規范，這個規范是團隊的寶貴的財富，它是整個團隊從各種坑中爬起來後積累的經驗教訓。什麼是規范，它是人們從無數經驗中總結出來的規則，標准。而代碼規范，指導團隊成員如何以最短的時間寫成最高效，可讀性強的代碼。試想，如果成員不遵從規范，你用駝峰命名，他用下劃線，這對程序的可讀，將造成多大的影響。我想，應該沒有一個人願意去閱讀一段，各種變數命名形式都能見得到，private, public 方法隨意排序，甚至常量類都散落在各個角落的代碼吧。
代碼，一個作用是讓機器閱讀，另一個重要的作用是讓人閱讀！！！

2、遵從行業內通用的規范
在團隊的代碼規范未涉及到的，那請按照行業內的規范來編寫代碼。規范的一個好處是，可以明顯減少學習和交流成本。在java中，當我們看到全大寫的變數名時，我們就知道這是常量，而不需要去看注釋，不需要去看代碼邏輯。為什麼這么迅速，因為行業里大家都習慣把常量用大寫命名。但假如你用其他命名方式命名常量，比如team_nums命名常量，不僅不能讓人迅速知道這是個常量，而且可能讓人誤會這是個變數，增加了團隊成員學習和溝通成本，甚至可能誤導他們。就見過一位仁兄，明明用的是工廠模式，偏偏按模版模式的命名方式來命名，問他，他說他知道這是工廠模式，但他覺得，更應該叫模版模式。。。我的天，，你這么任性，以後還能做朋友么?
舉個例子，我們需要根據支付類型，來生產多個支付產品，於是，我們寫了個工廠類，命名為FactoryPay。當其他人看到一個類叫FactoryPay，他們會猜測，這應該是個工廠類，負責生產各種支付產品的工廠，然後按照這個猜測去閱讀代碼，就能比較快速的理解整個類的作用。但是，假如我取名PowerPay，別人還不知道是啥，看了半天，才明白，這是個工廠的作用。這就明顯增加了他人的學習成本和維護代碼的成本。

不管你是新手還是老鳥，務必了解施行行業規范，切勿為了標新立異而違反規范。這么低端的裝逼，就沒必要採用了，要裝也寫個高端的框架來提升逼格唄。

3、變數、方法命名要能表達變數作用
在程序員這個圈子很久了，就發現，程序員這貨，都喜歡這套，「這個介面幹嘛用的，有文檔么」，「自己看代碼去」。很多時候都是一臉黑。
盡管程序員閱讀別人代碼技術都是一流，不管你是有沒有注釋，不管你是怎麼循環嵌套，也不管你是怎麼命名，他們都能耐心的，把代碼分析個所以然來。但，對於程序員這個視時間寶貴如生命，分分鍾都能創造幾百萬價值的群體來說，您行行好，給我們省點時間吧，把變數是幹啥用的，說清楚唄，沒准節省的這幾分鍾，多賺個幾萬，還能請大家出去嗨呢。
每每看到部門的某大神，用一個神一般的變數名「flag」，我就有吐血的沖動，他還這個flag一直雪藏，不用，只是傳遞到第n個方法才使用，頓時心力交瘁，我的天，這個flag都是是幹嘛用的啊，後來才明白，是isPay的意思，用來標識用戶是否支付成功了。當時一口老血吐屏幕上，心裡狂吐槽，老兄，你命名個isPay會死么，我的腦細胞這么不值錢么。到後來看到，去魔法數字，用int NUM_7 = 7,而不是MAX_MEMBERS來表示最大成員、用x y z來命名變數名，各種只有作者，或者作者後來都忘了的獨特命名方式，都見怪不怪了。更有甚者，一個變數命名為passed，作用居然是「未通過」的意思，當時就石化了，作者還真是用心良苦，這都要考我細心不細心。
一個好的變數名，能幫助閱讀者了解變數的作用，也輔助了對整段代碼的理解。

4、不要show英語，鄉下的孩子傷不起唉
LZ所在的團隊，英語一直都是團隊的硬傷，但總是能看到，某位仁兄，加上大把大把的英文注釋，有些變數名也取些高大上的復雜的英語單詞。敢問，你這么高的逼格，以後我們怎麼和你玩啊。(那位仁兄其實就是LZ，年輕時唉，罪過罪過)
代碼是用來溝通的，傳遞作者意圖的，都看不懂，怎麼溝通交流。建議英語好的童鞋，英語能力可以放到閱讀英文書籍中展示，在代碼中，如果團隊英語能力很弱，避免使用英文，變數命名也盡量按照團隊英語水平來命名

5、添加必要的注釋
正如上面LZ說的，經常遭遇「你仔細看看代碼，就知道幹嘛用的」這樣的神回復。盡管閱讀代碼是每個程序員的強項，但必要的注釋，比如邏輯比較復雜的地方，添加必要的注釋，對提升團隊成員閱讀熟悉代碼的效率是有很大幫助的。試想，一個類，幾百行，沒有一行注釋，對於閱讀者來說，閱讀它將是一個多麼恐怖的事。

6、注釋保持簡潔，避免沒有必要的注釋
即看過一行注釋都沒有的代碼，也看過注釋比代碼還要多的程序。一個是讓人生不如死，一個是讓人痛不欲生。(唉，有時不僅感嘆，在程序員界混，真的是難)。
LZ就經常看過，一大段注釋，啰嗦了半天，要不就是沒表達清楚重點，要不就是只為說明它是個循環的作用！！！譬如i++這樣的代碼，有必要加個「每個計數增加1」這樣的注釋么，這完全是把讀者定位為非程序員啊，或者就是嚴重鄙視讀者的編程水平。
注釋是幫助閱讀的人更好的理解程序的邏輯，只是輔助，如果不重視通過命名等方式來傳遞代碼的作用，而是依賴於注釋，這就是本末倒置了。而且，冗長啰嗦的注釋，這到底是幫助人理解，還是阻礙人理解啊，是讀程序還是讀小說啊。

7、擁有自己的編碼規范
規范是為了讓團隊更快的理解、熟悉代碼的，同理，擁有自己的一套規范，就能幫助其他人更快的理解我們所寫的功能，減少學習和溝通成本。

8、代碼清晰簡潔的表達出作者的意思
在我們每次寫完一段代碼時，一定要問問自己，代碼是否表達清楚了我的意思，是否需要添加些注釋，名字取得是否恰當了，別人在閱讀時是否吃力。。每每看到別人一團糟的費解的代碼，就時刻提醒自己，一定要把代碼寫好咯，我也確實是這么做的，一遍又一編的檢查，看變數名、方法名是否表明了它的用途，是否有些不必要的、只是為了提升逼格的代碼，別人是否能在短時間內看懂。所有的這些，只是為了寫出一段更優美的代碼。

9、堅持並捍衛上面的准則
經常能聽到，有些公司是代碼行數來定義績效的，但作為一個有操守，並秉承基本自我修養的程序員，我們絕不能為了各種誘惑或者脅迫，甚至是自己的惰性、個性，而放棄寫出簡潔清晰，可讀的代碼。

以上的幾點，並不是嚴格的意見或者建議，只是提醒廣大程序員同胞們，在痴心與高端的技術時，千萬不要忘了，代碼不僅機器要閱讀，人也需要閱讀。就算你寫出再復雜的代碼，但它讓人完全無法閱讀，這有什麼用呢。這就如同，你很牛逼很牛逼，但別人聽不懂你說的話，還不是沒用。如果你真的寫出了可讀性強的代碼，但你也不應該鳴鳴得意，我覺得，寫出一段優美，健壯，可讀性高的代碼，是一個程序員最基本的自我修養。