對程序員的意見和建議

① 如何看待程序員這個工作，你覺得這個工作有何優勢

社會上的每份工作都會有自身的優勢和劣勢，沒有哪一份工作是只有優點而沒有缺點的。現如今，越來越多的人對程序員這份工作感興趣，想要從事這份工作。不過並不是每個人都可以直接去當程序員的，這份工作有一定的門檻。不過，如果你成功當上了程序員，這份工作還是非常不錯的。下面我就來說說當程序員的好處。

在互聯網行業或者說IT行業，每項技術都是日新月異的，因此程序員必須保持一顆熱愛學習的心，主動學習新的東西，那麼在學習的過程中，我們就能夠不斷地提高自己，提高自己的實踐能力。這種提高對於我們未來的發展是非常有好處的，永遠保持一顆學徒的心，我們遲早能夠成為大師。還有，程序員每天的工作就是解決麻煩，在解決各種各樣的麻煩的過程中，我們還能積累很多的工作經驗。

② 程序員好嗎，大學畢業沒多久，不想干軟體開發了，大家給點意見啊，突然很迷茫

我覺得你可以去做美工之類的，這樣就不會太累了，其實你的專業很好，可以繼續的，就是有點累，但是以後工資很高，你可以先去遼沈人才網找個一般的程序員干著

③ 作為一個程序員 你的職業規劃求助咨詢是什麼意見

一般程序員有以下幾種發展路線。如果你選擇了某一個路線，我可以給你更進一步的建議。

1、技術路線，要求能力強智商高，把握公司核心技術和公司的技術發展。
初級程序員，中級，高級，系統架構師，技術部經理、技術總監。總經理

2、業務路線，要求知識面廣，懂得大部分技術，並知道該怎麼做，不一定會做，表達能力好，協調能力好，對某一個行業的業務精通。
初級程序員，中級，高級，系統分析員，項目經理、產品經理、研發總監，總經理

3、實施路線。
初級程序員，中級，高級，系統分析員，項目經理、實施經理，實施總監

4、銷售路線
初級程序員，中級，高級，系統分析員，項目經理、實施經理，產品經理，售前顧問，銷售經理

④ 對於程序員這份工作有什麼看法

程序員其實也還好，只是一個職業不會有太大的區別，人際關系可能差點點，然後邏輯肯定不差。其他就是宅。

⑤ 你對程序員這個職業有什麼看法呢

程序員，外面都說人傻，錢多，死的早。
不過我本人是程序員，所以不完全認同，但是也不能說沒有。程序員因為天天和代碼打交道，代碼是很多邏輯的部分，所以程序員一般邏輯思維不會太差，但是整體來說和人交接和情商就比較低。因為一群大老爺們討論需求什麼的就是各種吵吵，基本上說弄就弄。
然後程序員的起步工資確實比較理想，但是後期其他行業工資也會上來。程序員的工資都是加班加出來的，不管多麼好的公司，出產品的時候各種加班，有一些加班是階段性，但是有很多的公司就是長期性，基本上每天都是加班。所以加班也是程序員的標簽之一。
程序員因為邏輯長期腦力運動，再加上程序員都是很懶的，肯定也有愛運動的，但大部分都比較懶，我接觸的懶人居多，不會特別去裝扮自己（包括女程序員，基本都不會化妝的）。所以程序員會有一點點的邋遢，但是邋遢和臟是兩回事，邋遢只是不愛打扮，但是個人衛生一般還是可以的。然後體格方面也不會太好，長時間坐著，大肚子的概率和禿頭非常高，我的幾個老大頭發都比較稀少掉頭發，我現在也開始掉頭發。所以死的早應該是說這個。
還有一點，程序員聊天的時候喜歡說一些代碼性的東西，外行感覺十分奇怪，但是這是程序員的笑話，這個是職業病，其他職業應該也有。
不過程序員談戀愛的時候這些毛病一般很少存在，都會刻意去避免。
總的來說程序員其實也還好，只是一個職業不會有太大的區別，人際關系可能差點點，然後邏輯肯定不差。其他就是宅。

⑥ 大廠程序員的發展瓶頸是什麼

大廠程序員的發展瓶頸是年齡大了，但依然在寫代碼，沒有當上領導，這時候精力和體力都不足了。

⑦ 24了，想轉行做程序員，懂的人，或過來人有什麼建議或意見嗎

對於像你一樣，24歲，想轉行做程序員的人，我的建議只有四個字，就是貴在堅持。
轉行做一個技術含量高的行當，不是一個容易的事情，自己要心裡有數，程序員雖然待遇優厚，但是不是白來的一份付出？一份收獲，你要做好努力的准備。

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

作為一名程序員，一個「程序員的自我修養」是什麼？
盡管我們不一定要像尹天仇那麼的認真對待自己的事業，但，一些基本的修養，作為一名新時代的碼農，總應該是要具備的吧。不過真要說修養，方面還是挺多的，技術自我提示自不必說。但我並不打算從這個大家都覺得理所當然的技術方面入手，而是談談，可讀性代碼，這個容易被大家忽視的基本素養。
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、堅持並捍衛上面的准則
經常能聽到，有些公司是代碼行數來定義績效的，但作為一個有操守，並秉承基本自我修養的程序員，我們絕不能為了各種誘惑或者脅迫，甚至是自己的惰性、個性，而放棄寫出簡潔清晰，可讀的代碼。

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

⑨ 程序員日常生活面臨的問題和挑戰有哪些

一、熬夜
很多程序員將熬夜變成了生活習慣，還口口聲聲解釋「程序員只有在晚上效率才高」，這是非常扯淡的理論。有人將程序員做下圖的類比，雖然比較貼切，但這種方式對你的健康傷害是最大的。建議你嘗試一下晚上10點睡覺，早上6點起來工作的作息方式，也許會事半功倍。
二、久坐
有些程序員在電腦面前一坐就是一天，中間除了吃飯上廁所外，基本不起來動動。這是非常不好的習慣，時間久了，很容易得肩周炎、頸椎病，到時候後悔就晚了。建議每坐一個小時就起來動10分鍾，主要是轉轉手臂和脖子。
三、外賣和泡麵

很多程序員在飲食上也非常不注重健康，上班的時候為了貪圖方便經常叫一些外賣，更厲害的是直接搞一桶方便麵來做午餐。這里建議大家中午出去吃，葷素搭配，再可以弄點水果。
四、缺乏鍛煉

建議在工作日下班後做一些簡單的球類運動，乒乓球、羽毛球。
五、用眼過度
IT公司的員工的體檢報告中大部分程序員都患有「慢性結膜炎」，當然對於這個病並不是長時間對著電腦引起的，但是用眼過度也會加劇「慢性結膜炎」的惡化。
建議大家平時准備防止眼乾的眼葯水，如果確定是結膜炎的話，還要及時去醫院就診。另外電腦的背景可以設成綠色，這樣對眼睛也能起到一定的保護作用。