有哪些老程序員都知道對新手很有用的經驗？

11-26

即將畢業開始找工作，變成程序猿大軍的一員，目前方向是移動互聯開發。
不知到有哪些經驗可以避免新人入職以及就業後碰得頭破血流，請前輩不吝賜教。
—————
我就順便一問…為什麼大家都提到女朋友的問題…程序員真的是不好找女朋友的群體嗎

學習技術的時候，多看看「官方文檔」。

我們學習一樣東西或者遇到問題，經常會採用google百度的方式去搜索答案和資料，這一點當然沒有錯，也確實可以解決很多實際問題。

但是，多年來的學習和工作經歷，讓我更深刻認識到一點：看「官方文檔」非常重要。
我們很多的問題和技術細節，其實，只要我們認真將官方文檔過一遍，會發覺大部分的問題和認識模糊的地方都消失了。甚至，你還能發現自己之前搜索的到一些資料，可能是不準確或者已經過時了的。

官方文檔是真正的好東西，因為編寫文檔的人群，通常就是這些技術或者軟體的開發者，他們才是對這些東西最了解的人，因此，他們寫的文檔質量是很高的。通常，也是最新的。

官方文檔的不足的地方，大概是中文版本不多，看起來可能會比較吃力。不過，請相信我，你下載一個有道之類的翻譯軟體，慢慢看還是問題不大的。還有一個問題，就是這些文檔編寫者，通常是技術界大牛，他們編寫文檔有時候是基於他們自己的技術認知水平，跳過了很多基礎概念，也增加了閱讀難度。不過，這個我們也可以通過多查資料，慢慢看來解決，並且通常會帶來額外的學習收穫。

不得不又來更改答案，謝絕轉載，已轉的請聲明轉載，謝謝！
———————————以下是關掉評論的聲明—————————
我把評論關掉了，因為老跳出評論提醒，影響到我自己瀏覽知乎。
對於有人質疑版本管理和注釋的問題，我本來不想回應，因為作為過來人以自己的經歷說些經驗，本來只是出於對後輩的關愛，沒想到寫個往事還要被質疑，還不得不交待時代背景證明自己沒撒謊，真是很煩。不過既然要關評論，以防又有人懷疑我是心虛了，就回應一下吧。我說的刪代碼這件事，發生在十三年前，那個時候git，svn都沒普及，也可能是我學藝不精，但當時我工作的公司的確沒有現在那麼完善的版本管理方法。另外開發項目長度，這個真的連解釋都不太好解釋了。有些人把東西做完丟給客戶就算做完，有些項目是逐步替客戶更換舊系統，跨度幾年其實不奇怪，而且我也說了實際上這個項目因為我的決策失誤耽擱了很多時間。回答個問題扯了那麼多沒用的話，浪費大家時間了不好意思。
————以下是正文————
用我的親身經歷（也可以說是血淚經驗）來給樓主一些參考吧。
大學畢業第一年，進了個非常大的國企的軟體開發中心，因為是校園招聘，所以同期進來許多應屆畢業生。還在實習期的時候便開始分組做項目，算是入職的第一次實力考察。當時我和另一個新人共同負責開發某部分的功能，我開發底層，她要基於我的程序做後續開發。
然後我花了大約兩個多月把自己的程序做好，但另外那個女生做得很慢，deadline快到了還什麼都沒做出來。還記得當時遇到五一長假，我把自己程序交待給她之後就直接放假去了，而她就趁長假加班趕工。結果長假快結束的時候，她突然給我打電話，告訴我她不小心把我在伺服器上的代碼全刪除了。那可是我兩個多月日夜趕工的心血！
這裡我要解釋一下，當時那份工作所有的代碼都是大機底層代碼，無法在個人電腦上測試的。所以大家都是一人在測試機上有個目錄，有自己的許可權，代碼就放在那個目錄下，做好了就直接測試。我當時因為交接代碼，把自己目錄的用戶給了這個同事，結果她有意也好無意也好，把我全部代碼刪了。這事對我人生第一份工作影響之大，我都不忍心描述了。
如果你覺得我說那麼一大通是想說任何情況下不要借賬號給同事，那隻猜對一半。這些年我一直很自責的一點是：我為什麼不備份！現在看起來非常不可思議的事，當時剛畢業的我就是傻傻的沒想到。以為伺服器是最安全的地方了，自己就沒有在本地備份，更加沒做版本管理。我知道不是每個新人都像我那麼傻，但仍然寫出來警醒大家。備份備份備份！永遠最重要！
第一條就寫了那麼多。。。其實還有幾個心得，下回再來補充。
-----------------
接著上一個回復繼續說。第二個經驗是關於怎樣辨別其他程序員的實力。每個人都知道向有經驗有能力的人學習是促進自己技術成長最迅速的方法，但不是每個人都懂怎麼去跟對師父，怎麼辨別誰是繡花枕頭誰是真人不露相。在這行待了這些年，我去到一個新環境，並不會馬上對身邊的同事下結論。有的人特別能侃，開會特別多意見和問題，你問他們問題的時候他們甚至非常熱情給你解答，但這樣的人並不一定是高手。要看一個人是否高手（單指編程能力上），得看三個方面。首先你要去看他的代碼，一個好的程序員，代碼無論是什麼風格必定是清晰有條理，而且必定是有非常完善的注釋。相信我，一個似乎無所不能卻從不寫代碼注釋的人，不會是一個好的師父。另外你要看這個人對問題的理解能力，有些人寫代碼永遠都是『實現功能』，從來不會真正地替使用者思考，也不會考慮以後維護的成本。比如同樣是做一個用戶管理系統，有些人就是簡單的以為實現添加編輯刪除的功能就可以，可是有些人會連導出信息，安全備份等方面都去考慮，這就是能力的不同。最後要觀察一個人是否有實力，還要看他對信息的敏感程度和熱愛程度。做這一行，絕對是需要不斷學習，不進則退。如果一個人除了不得不完成的工作，對於相關行業新聞和知識不感興趣或者沒有學習動力，這個人基本應該差不多被淘汰了。希望這些看人的技巧能給你帶來幫助，跟對師父的重要性我就不強調了，要強調的是必須謙虛！好學！努力！不要妒忌，不要固步自封，要多和別人交流想法和技術。

---------------
繼續說第三點，就是要以開放的心態接受新工具和新技術。編程這一行，尤其是最近幾年，各種IDE，framework，open source plugin和方法論湧現，這種現象對於在學校里一板一眼學知識的新人來說有可能難以適應。也許你已經有用了許多年已經很熟悉的editor，但是有人向你推薦新的編輯工具和IDE的時候，一定要樂於嘗試。如果一直堅持只使用自己熟悉的技能和工具，很快就會落後。以我自己的例子來說。兩年多以前我轉行開始做網站架構，剛入行就接到一個比較大的項目，要構建某個公司的後台管理系統。當時主流建站framework有zend和phpcake等等，而且當時有個同事極力向我推薦laravel，這個新出的建站框架，可是因為我在這之前幾年有參與過另一個項目，熟悉了那一套自己開發的框架，所以堅持用自己的方法去做。這個項目最後是做了出來，但是花費了差不多兩年的時間，期間我私下去學習了一下laravel，心裡明白如果當時我嘗試接觸一下這個系統，用這個新的框架來開發的話至少能節省一半的時間，而且代碼健壯性也會好很多。選擇做技術，就不能害怕技術的更新，這是我能給的第三個建議。最後一點，do it right is more important than do it。不要想著把東西迅速用很難看的代碼做出來之後再慢慢修補，你永遠不會有機會從頭修補你的代碼。接到任務的時候，不要急著開始編程，必須做好設計。現在很流行的agile開發方法摒棄了以前瀑布式寫文檔的開發方法，其實我本人並不是很喜歡這樣匆忙的迴旋式的模式。不過即使你們公司採用這樣的工作模式，你自己個人也必須堅持不要被看上去很緊的開發時間約束。動手編碼之前，三思，小的task結束後，三思。希望以上幾條拙見能給入行的新人帶來幫助。

想清楚再去敲代碼，這句話可以用一輩子，

新的一年又開始了，祝各位新年裡身體健康，工作順利
----------------------2015年工作回顧-------------------
0、少說話多做事

1、多參照優秀代碼培養自己的代碼風格，今天多花的時間會在將來節省幾倍的時間，一次性代碼除外。

2、工作有幹活和做事之分，5份活才抵得上一份事，磚頭搬得再多也成不了包工頭。

3、幹活和做事的區別在於能否為boss分憂。

4、工作只是一份混飯的技能，要把時間和精力投資在自己身上。

5、知易行難，實踐是學習技術和提升實力的最佳捷徑。

6、能者多勞，做事越多責任越大，犯錯的機會也越多。

---------------------------我是分隔線---------------------這答案本來是在車上隨便寫的，沒想到也收穫一些贊，很感謝大家的支持。

這次編輯修改一下表述並增加一些內容。

2015-07-04

除少部分人以外，大部分剛入這個行業的程序員都會面臨發胖的問題，在這裡談談如何保持體重。

核心在於：少吃多餐。控制固定三餐的食量，在此基礎上添加2-3餐，補充水果蛋白質。正餐一定要控制食量，多吃蔬菜，飯量根據餓的時間調整，根據每天攝入菜的種類和量決定是否需要吃水果補充維生素。如果有痔瘡或者便秘，那麼每天必須吃一些高纖維的東西，例如香蕉，蘋果，番薯，
玉米，燕麥等食物。其中由於番薯的澱粉含量比較高，建議早上食用，並搭配雞蛋，牛奶等高蛋白食物，還可以搭配蘋果。根據晚餐的時間，如果吃飯時間比較遲或經常餓到肚子難受，那麼可以根據情況在4-5點吃兩根香蕉，或者兩顆雞蛋，或半瓶牛奶充饑。此外，不要吃夜宵，如果睡得遲會餓的話就吃一點低熱量的水果。一般來說，每天在正餐之外加一瓶牛奶，兩顆雞蛋，一顆蘋果，一顆番薯。或者一瓶牛奶，兩顆雞蛋，兩根玉米，兩根香蕉就足夠了，如果食譜里有高澱粉食物，那麼不能吃太多，否則會發胖。吃正餐時要注意不要吃太快或吃太多，在有加餐的情況下吃6-7分飽即可。

養生方面

保證每天的休息時間，經常運動，在12點以前入睡，保證7-8個小時的睡眠，並且注意不要在8點半到9點後進行劇烈運動，否則一部分神經衰弱的人可能會因為睡前劇烈運動而導致入睡困難，在運動結束和入睡期間間隔4-5小時為宜。

如果經常加班，或者就餐時間在七點之後，那麼請帶一些能夠充饑的水果饅頭雞蛋之類的食物，在5點左右食用，不要讓胃有餓過頭的感覺。無論工作多忙，項目工期如何緊張，都要保護好自己的胃，工作可以換，胃壞了可換不了。

工作方面

學好基礎的數據結構和演算法，例如堆棧，隊列，樹，哈希表等，演算法如幾種排序演算法，樹的遍歷等。

學好英文，中文文檔看不太懂時請查閱英文版，英文的表述往往比中文更加通俗易懂。

在學好英文的基礎上，程序的函數，變數命名要盡量有意義，推薦使用單詞或縮寫。

時不時回頭看看自己寫的代碼，重構的過程中你會收穫很多東西，當局者迷旁觀者清，有些問題只有在重構的時候才會發現。不要固執己見，多思考多總結。

估算工期時請在自己估算的必要時間上乘以2-3倍時間，避免無意義的加班。不要試圖快速完成任務來取悅領導，或證明自己，尤其是剛步入這個行業的新程序員，寧願估長工期用少於工期的時間完成任務，也不要估短工期延期完成。

悶著不說話，不交流才會頭破血流。敢問問題，盡全力查找資料，經常思考就不會頭破血流

曾在大公司寫了好些年程序，不過下面這些經驗跟寫程序可能沒啥關係。
新人最需要快速掌握的，是職場規則。

流量預警：本文長度超過8頁，新手9大技能樹天梯系統，無圖。
開卷有益，歡迎各位拉同學來看。

永遠先想清楚，再去動手。
&>&>（我是不會說自己每周只敲一天代碼的）

不懂要問！問之前先儘可能去查！
&>&>（萌萌地跑來問我的下屬，是把我當作GOOGLE機器人助手還是書櫥？）

求助之前要先自己儘力去解決，搞不定及時求助！
&>&>（上司和同事不是給你打雜的；事情搞砸了再求助毫無意義）

你腦子的想法，不通過口頭特別是文檔表達出來，它事實上不存在。
&>&>（寫文檔，寫注釋，寫日程表，寫計劃表，寫會議紀要……不說了）

公司的各種設計指南、編程規範、XXX規範要仔細學習
&>&>（否則去參加外面的培訓公司接受培訓需要花錢還不靠譜）

新技術是好東西，但自作主張用了，多半是作死，特別是自作主張用開源軟體的傢伙
&>&>（我手下要是自作主張用開源軟體，最起碼一個大過處分，不預警，直接通報）

各種介面不要隨便亂改；花半天先把介面吵清楚再動手，有益無害。
&>&>（當年專職負責吵介面吵了大半年呢，每個人都眼巴巴看著你的感覺好奇妙）

公共配置項不要亂動，特別是配置庫和編譯器的
&>&>（出問題了找BUG找死人啊）

下面是9大技能樹：如何XXX系列

如何對待上司

上面吩咐了做啥事，腦子好就記住，腦子不好就拿本子寫下來，然後去做。
&>&>（反正最多說三遍，再不好好學習就打入冷宮）

安排的工作一般都要接；接不了的要清楚說明客觀原因，而且要客氣。不要在其他人面前拒絕。
&>&>（隨便拒絕工作安排，基本都是作死；當著外人不給上司面子，這不是作死而是作大死）

如果工作安排不清晰，請主動與上司溝通，明確關鍵的時間點和交付物。溝通前自己要有預案。
&>&>（沒有上司喜歡不帶著腦子跑來問問問的下屬的）

如果完成工作需要其他資源，先儘力協調，再向上司求助，並明確說明理由和已協調結果。
&>&>（他出面跟人撕逼需要子彈，不要讓他自己到處找子彈）

上司的技能樹和技能點分布，可能跟你完全不同
&>&>（自己那坨技能點不全是金子，別人的技能也不全是屎，世界主體仍是分工合作）

自己的工作可以求助，但工作主體仍然是你；每次求助都是偷師的機會。
&>&>（誰給誰打工？這很重要）

遇到例外情況，及時反饋給上司；確信自己有能力且得到授權的，可以同步開始解決，否則等指示
&>&>（不反饋那叫知情不報；不解決那叫消極怠工；自己亂搞叫越權行事）

事情進展順利也要定期反饋進展；每日三省吾身，不要讓別人逼著你寫總結。
&>&>（老舊的Unix程序默認沒有return，但你不是它。他跑來問的時候，心裡是充滿疑惑的）

是男人都會犯錯（from DuangLong），但相同的錯誤不要一而再、再而三地犯
&>&>（上司不是你爹，他口水幹了就會變得異常煩躁）

不要隨便發脾氣，更不要對著上司發脾氣
&>&>（否則的話，很快就會通過慘痛教訓明白：平等、自由都是相對的）

在絕大部分情況下，不要跟上司談情說愛玩曖昧，搞基也不行
&>&>（除非你打算辭職）

不要當上司是傻逼；如果覺得他不是很懂，委婉地教會他。
&>&>（絕大部分情況下，後果是下屬傻逼了）

我不排除有很噁心的上司，但你的上司是一種非常珍稀、寶貴的業務資源。
好好對待他，不要有意無意地濫用他、損耗他，盡量讓他開心。
否則等到闖禍了，讓爹媽來公司保佑你么？
比上司更能保佑你的是你的客戶。

如何對待同僚
我知道一定會有人大叫著說：如今是平權時代，哪裡有什麼狗屁上司。
好吧。

一般情況下，把你的同僚當作上司對待——可以套用上面的大部分建議
&>&>（你敬人一尺，人敬你一丈。鬼知道什麼時候同僚變上司）

工作要通過定期碰頭協商分工和通報進展
&>&>（要不你單幹吧）

答應了別人的事情要做到，要不就不要答應；
&>&>（做不到比拒絕的後果更嚴重）

有啥事情可能起紛爭時，事先講好道理，商議好規矩
&>&>（這一條是金科玉律！）

不要吝嗇於分享經驗，但不要隨便發表看法
&>&>（大家都喜歡對自己有幫助的人。但看法么……說者無心聽者有意）

一定要有幾個死黨，關鍵時刻可以幫你扛扛工作、通風報信；
&>&>（誰沒有難處呢？但沒人欠你的）

今天求助了別人，記得日後要還，晚還不如早還。反之同理。
&>&>（紙牌屋）

條數是不是很少？混過幾年職場後，大部分人就掛在這幾條上。

如何對待業務
業務不是編程，業務是鈔票。

搞清楚自己的崗位職責；搞清楚跟你工作直接相關的周邊崗位職責
&>&>（基本入門要求）

搞清楚業務流程，自己在其中的位置；
搞清楚公司靠神馬賺錢，自己在其中的作用；
&>&>（最好的公司都是流程化運作的，沒有也要理出來）

編程之餘，多看看公司對應的商業和工程專業書籍
但請務必記住：業務不是學來的，是干出來的
&>&>（業務不是編程和0/1，業務是非常複雜的，它很難掌握但比程序的變化要少得多）

搞清楚你對老大，同僚，周邊部門的價值；
搞清楚老大，同僚，周邊部門對你的價值；
&>&>（不清楚這些，工作中怎麼互幫互助 or 談條件 or 撕逼）

經常跳出自己的崗位看問題，有極大好處
&>&>（否則很容易固執己見討人厭呢）

要區分有價值的功勞和沒有價值的苦勞
&>&>（否則白忙一場空）

幹得好就可以多要錢，但要有理有據，最好的辦法是拿好的考評
&>&>（連考評周期和規則都沒有的公司，還是算了吧）

如何對待編程

脫離業務的編程毫無價值，除了畢業生

精通一門語言，最好是C和JAVA，腳本隨意；其他的都可以類推。

軟體程序質量的底線，是你知道你的程序和編譯器到底都幹了啥。
因此：程序語言中的高級技巧都是巨坑，如果沒有十足的必要和把握，不要用。

編碼注釋是最好的文檔？不全是，學會Office和MindManager，否則試下用編程表達流體力學。

熟記常用的調用介面（系統，資料庫，函數庫，中間件），其他的備好手冊，不要費太多腦。

有括弧，不要浪費腦子去記憶運算優先順序。
更不要隨便相信高級運算符。

讓別人能看懂代碼，否則自己也會看不懂。

時刻謹記性能和存儲約束，它們可以交換；更可以跟鈔票交換。
如果這兩者嚴重受限，高級程序語言都是渣。

任何複雜的系統都可以分解，函數和有限狀態機是最重要的概念。
類、對象不一定重要（想不到吧），模版、繼承、派生很容易坑了你。

絕大部分的「跨平台」、「可擴展性」設計目的，大部分還是要依賴重構去解決。
更悲劇的是，很大比例的重構是由於這兩類設計而導致的。

謹慎對待重構，一般來說初次重構的失敗率高達50%以上，大多數情況下是質量問題導致失敗。
所以，要做好3個版本的成本預算。
新人玩重構？百分之百失敗。

函數、API、消息、通訊報文沒有區別，都是介面

常用演算法並不多，複雜演算法要學好數學和庫

開源軟體不要亂用，其授權文件和律師團可能讓公司破產，一定要問老闆和律師！

商用軟體收費並不僅僅是因為功能，還有性能和質量。開源軟體的質量良莠不齊。

好好讀編程規範！好好讀編程規範！好好讀編程規範！

不要依賴於DEBUG！事先想好軟體邏輯可以節約大量的DEBUG時間。

硬體是會壞和異常的！伺服器、配置庫不說了，感測器和執行器同理。

人是會犯錯的，而且很經常！做好代碼和數據備份；檢查輸入，盡量控制輸出。

如何對待工具

不能提高工作效率的工具毫無意義

工具是拿來用的，不是拿來炫技的

優先考慮測試工具，其次考慮編碼工具，最後考慮代碼檢查工具
&>&>（理應如此，但實際上哪個好到手就先整哪個，呵呵）

工具本身是帶缺陷的，要考慮潛在缺陷的風險和代價，否則會死得很難看。

開發系統集成的IDE最「好」用；純編輯器請隨心，注意保存配置數據。

一個需要大量配置才能實現功能的工具，要慎用。

優先選擇收費的商業工具，除非實在沒錢。

帶有「雲」系統的工具，呃，去與老大對話，觀察他是否變成了大菠蘿第一章的BOSS。

很多奇奇怪怪的小工具會做很多奇奇怪怪的事情，特別是安全類工具。留個心眼。

如果找不到合適的工具，自己寫一個，注意性價比（哦，我們有個小小的工具團隊）

開發環境幾乎永遠比客戶的運行環境奢華，時刻記住這一點。

買一套你用得順手的硬體外設，包括鍵盤、滑鼠、顯示器，這個投入相當划算。
（聽說新浪的開發環境是眾所周知的負面案例）

奇怪的鍵盤布局會降低效率，慎用此類逼格高的鍵盤。

有午休的開放辦公室，慎用噼噼啪啪的鍵盤滑鼠，否則可能導致你的臉噼噼啪啪作響。

Office是最應當掌握的非編程類工具，沒有之一。

拋棄各種IM工具，回歸到電話、簡訊和Email。還需要說理由？

努力變成你的老大最好用的工具，否則他會尋思著換工具，就像你尋思著換鍵盤一樣。

如何學習提升

最好的學習，是工作中學習，學以致用。
因為這樣目的最為明確，效率最高，正向負向刺激最強烈。

找個好師傅，默認情況下抱緊上司的大腿。
一天最多問他一次，逼著自己先想清楚再去問。

編碼不是目標，實現功能不叫大牛。
一般對代碼的優化集中在性能，可維護性，可擴展性，安全性和質量健壯性上。
大牛們就牛在這裡。

不要把工作帶回家！學習同理。
家裡有太多分散注意力的事情，而且非常容易模糊各種邊界和deadline。

某些公司有嚴格的信息安全管理制度，不可以在公司做自己的事情。
那在家裡好好布置一個書桌書架，並盡量減少干擾。

出於集中精力的考慮，書桌上應當盡量簡單，比如不要有妹紙和電視，嘿嘿。
每天2個小時的時間，把所有干擾都排除；要麼就不學，要學就沉浸進去。

在家裡做東西學東西，同樣要堅持有特定目標，否則都是胡亂學，成不了體系出不了東西。

社區是好東西，但很零散，不能依賴。
官方手冊和文檔是最系統的，開源可看代碼。

不要沉浸在具體編碼中，理清目標，邏輯，流程，模塊和狀態遷移。更重要的是理清業務。

邏輯思維清晰、表達簡明扼要、英文起碼閱讀無壓力。
&>&>（溝通都成問題就不要談提高了，真的）

寫博客、上論壇撕逼、寫教材、做培訓講師，對理清邏輯、提升表達和建立個人品牌很有幫助。
&>&>（好為人師不是錯，知錯就改好同志）

如何對待租房
首先請搜索此文章：怎麼花最少的錢提升出租屋的格調？ - Charles Stone 的回答

其他：
房租不要超過工資的1/3（日後供樓也是同理）
跟誰一起租很重要，最好跟死黨一起租房子，否則寧願單住
作為程序員，房子要能擺下一張大書桌！

如何對待妹子

一般來說，公司里的妹紙更可靠
&>&>（只是相對論而已）

盡量找到共同的興趣愛好
&>&>（找不到？遲早出事）

通過寵物勾搭，又快又多
&>&>（狗男女就是這麼回事）

有花堪折直須折
&>&>（最好的兄弟會對你說：承讓）

要學會怎麼識別綠茶婊
&>&>（這是猛追三個月以後的else處理分支）

沒有我的火眼金睛？帶她去游泳
&>&>（咳咳，咳咳）

無論娶或不娶，0.03就在那裡
&>&>（咳咳咳咳，不要淘）

把妹比搞革命更困難，革命尚未成功，同志就仍需努力
&>&>（身體是革命的本錢，把妹還要事業）

三觀一致挺重要的
&>&>（這就是祖訓的門當戶對）

在打算跟妹紙共度餘生之前，最好離開雙方家庭同居一段時間
&>&>（獨立生存能力挺要命的）

後代的家教質量主要取決於女方，妹子的學歷越高越好
&>&>（要打我的妹紙們，有本事放開BB！）

有BB之後，要祈禱不要被丈母娘坑
&>&>（各種祖傳秘方神馬鬼，哈哈哈哈）

你是妹紙程序員？生娃要做好計劃！
&>&>（這件事非常非常重要，特別是如果還想在事業上有進一步發展的話。畢竟最少有6個月事業和生仔不能兩全，生完了還要奶幾個月娃，挺辛苦的。所以，選擇高強度工作的間隙，跟上司和同事打好招呼，自己的工作寫好委託清單。就算是意外得子，也要趁著孕期早做準備。否則生仔去了工作一丟，周圍這個怨念啊~）

如何保持安康
吃喝和減肥？
看這個吧：什麼樣的食物滿足好吃、頂餓、低脂低熱這幾項要求？ - Charles Stone 的回答

飲食要規律，早中晚三餐都盡量都吃，多喝水
&>&>（胃病、膽囊炎、膽囊結石啥的，30多歲的人很多的）

保護好你的頸椎，關鍵是顯示器要夠高，用書墊高它或者買個升降支架
&>&>（頸椎病嚴重的話，手會廢掉，不開玩笑）

保護好你的手指和手腕，椅子高度要調節好，鍵盤滑鼠不要用太爛的。
&>&>（請自行搜索「脈管炎」）

保護好你的腰椎，可以考慮站立辦公、站立會議、經常起來走一走。車上的座椅要調好。
&>&>（神馬椎間盤突出啊之類的……）

保護好你的眼睛，夜晚的屏幕四周一定要有背景光，手機比PC屏幕更傷眼睛。
&>&>（長時間玩手機對頸椎也是大殺器）

晚上不要經常熬夜，基本睡眠要保證，否則白天精神會不好，同事間的印象會很差
&>&>（我是壞榜樣）

找個女朋友有助於養生
&>&>（生活會變得規律很多，食材會豐富很多，體育活動更有動力，夜晚不會焦躁不安……）

鍛煉這玩意是因人而異的，不要瘋狂鍛煉，關節受損極難恢復
&>&>（特別是登山、羽毛球、瑜伽，搞過頭了非常容易受傷）

--------------------------
熬了10多年，能寫的不太少。
歡迎准畢業生們提出各種腦洞大開的問題，呵呵。

寫代碼的時候要先想好在寫，思路清晰起來，寫代碼其實很快
寫完代碼自己審查，考慮異常情況
多思考，遇到不會的問題，換不同的關鍵詞，問問谷歌，搜商高也是一種本領，在你搜索的過程也吃對當前問題的一個思考的過程。沒事多在SOF提問，看看自己的語言和思路是否能夠把自己遇到的問題描述清楚
多寫代碼，閱讀別人的代碼
對新的技術要有一定的感知度，優秀的框架需要鑽研
多溝通交流，一味地低頭敲代碼，並不能讓自己走的更遠
懂得團隊協作，一個人的力量畢竟有限
學會利用官方的文檔和例子，官方文檔在開發中的作用非常重要。不要懼怕英文，計算機文檔中辭彙就那麼多，看多了就熟悉了。再者官方文檔大部分都是軟體開發者編寫，所以他們懂程序猿需要什麼。多看看文檔，定會有新的發現。

代碼也寫了不少了...
困的時候不要重構, 困的時候不要重構, 困的時候不要重構
重構的時候做好版本管理, 重構的時候做好版本管理, 重構的時候做好版本管理
發現重構工程量太大及時停手, 發現重構工程量太大及時停手, 發現重構工程量太大及時停手

以下一些經驗會對新手有幫助：

1、靈活地運用Google。你需要知道如何使用關鍵詞查詢，查看其他開發人員的代碼，並將其應用於你要解決的問題。

2、日復一日的堅持。始終保持作為編程新人時的那種對新知識、新技術的渴望，不斷地在實踐中成長。

3、任何一個看似不起眼的地方都至關重要。例如，變數命名、調用函數、命名CSS屬性，哈希表及數組的選擇，這些恭喜雖然看不起眼，但是他們都將對結果產生很大的影響。

4、認識到那些看似重大的決定其實並沒有想像的那麼重要。經驗豐富的開發人員總是明白怎麼去大事化小，怎麼去避開一些開發人員經常陷入的大麻煩。這些事情在某些程度上來說，頗具有些禪意。

5、使用正確的工具。現在市面上存在這麼多不同的庫、工具和框架。經驗豐富的程序員們總能知道在面對不同的問題時應該選擇什麼工具。

6、你需要清楚代碼本身不值錢。如果需要，你可以刪除幾百行的代碼，用另一種方法對問題進行解決。

7、綜合考慮所有特性對技術進行評估。例如，我一直看好Elixir。它有精彩的語法，很棒的社區和光明的未來。但是它太新了，以至於如果你想要實現這麼多複雜的功能，你很難找到相應的技術。而所有這些因素，你都是需要考慮的。

8、學會說「不知道」。作為一個開發人員，沒有什麼比不承認你的不知道更節約時間的了。

9、學會分析錯誤提示中的線索。傳統教育告訴我們失敗是恥辱的，而錯誤提示總與失敗相關。好的程序員知道那些錯誤提示中總是包含獲得正確解決方案的線索。不要輕視這些錯誤提示。

10、了解早期優化和必要時候停止優化之間的區別。好的程序員知道什麼時候去優化、如何去優化，才能寫出一些看似奇怪但是實際上能讓結果運算更快的代碼。

11、對錯誤負責。錯誤總會發生，特別是以一個團隊的方式進行工作的時候。這時候，互相責怪就是一件十分浪費時間的事情，因為錯誤背後總是有多方的因素。

12、不要在意工作的時間。對於那些停不下來的程序員來說，他們經常花費很多時間在更深層次的工作上（與那些淺嘗則止的工作相對），而且他們明白，計較花了多少時間工作其實是沒有意義的

13、淡定地接受責難。當你的代碼被毀了，你要學會給出理性、具有邏輯的反應。

14、多與有經驗的人相處。沒有什麼能比這種方式更快的提高你的編程水平了，你不僅需要從他們身上學習硬技能，還需要從他們那裡學會如何提升自己的軟技能。

15、重視代碼檢查。在Github上發出請求之前，你應該先檢查下代碼，並將其分開，就如同這個代碼是別人寫的一樣。

16、認識到一個優秀程序員不是只需要精於編寫代碼，還需要一些別的素質，比如銷售，營銷，客戶支持，質量保證和產品管理等，這些都將花費大量時間去學習。

17、了解並解決更大的問題。最好的程序員總是不會局限於眼前的問題。他們樂於尋找一種解決的方式，不但能實現對眼前問題的解決，還能實現長期問題的解決。

18、深入研究一些大型的開放源碼，並應用於實際工作中。

19、在合適的時候進行回饋。當你達到一定的水準時，你就應該花一些時間去幫助新人，就像你導師曾經帶你的那樣。

20、能夠寫那些看起來不怎麼樣的代碼。很多時候，成為一個查漏補缺型的程序員也是不錯的。隨著時間的推移，你更需要知道什麼時候可以走捷徑，什麼時候必須好好做。這是最難學會的一項技能。

21、讓別人知道即使你工作到了很遲，但是你並沒有浪費時間。如果你是最後一個離開辦公室的，那麼就給別人發送一份包含你最新進展的郵件。人們一般會注意到郵件的時間戳的

22、多去參加團隊活動。從長期來看，和其他開發人員建立良好的關係（或其他職位的人）將會比長期處在自我局限中更有價值。

23、在壓力下學習。當整體情況開始惡化的時候，即使你不知道具體應該怎麼做，你也要試著學會如何去掌控情況並有責任將其恢復。

24、「快速前進，打破常規」。不要讓「完美」成為「不錯」的敵人。錯誤是在所難免的，但也能給你提供一個不錯的學習機會。所以不要將你犯的錯看做是一次失敗，而要將其視為一個可以學習的機會。你要知道，解決錯誤可以讓你更快的成長。

歡迎關注我的微信公眾號：九章演算法（ninechapter）,幫助你了解IT技術前沿，通過面試、拿到offer、找到好工作！

先說一個簡單的：把Ctrl+s變成一種下意識行為。

你寫代碼也好，寫文檔也好，總不可能是一直勻速的，中間總有停頓，用來思考，理清思路，或者單純的休息一下。

把每次停頓之前你敲擊的最後兩個鍵變成Ctrl + S！把每次停頓之前你敲擊的最後兩個鍵變成Ctrl + S！把每次停頓之前你敲擊的最後兩個鍵變成Ctrl + S！

重要的事說三遍。這並不難，稍微訓練幾天就能做到！相信我，這小小的習慣會讓你的人生快樂那麼一些！

1. 把基礎打好, C , C++ 學好
2. 自己獨立寫一些東西，工作之外的，堅持下來，你會吃驚的
3. 多交交朋友吧，朋友就是你以後的圈子，這個很有用
4. 多了解其他職業的工作，方便合作，也為以後當老闆打基礎

總之，別把自己局限為程序員，你可以做的很多，未來能做什麼，取決於你的努力和積累。攢著資源，攢著大招吧

要注意頭髮健康君不見觀眾席全是光頭嘛？

看基本職業要求類書籍如：《代碼大全》等
看基本職業管理類書籍如：《人月神話》等
看演算法類書籍如：《演算法》等
看科普性入門書籍如：《深入理解計算機系統》等
看代碼組織類書籍如：《設計模式》等
學會看英文官方文檔如：java sdk, w3c reference等
多寫代碼，多造輪子如：網路套件，bus套件，事件路由，狀態機等
寫代碼准守代碼規約如：google編程規範等
使用各種開發工具如：IDE，github，UT，CI tools 等
多利用網路學習和交流如：stackoverflow，github 等
善於溝通，樂於溝通如：與同事合作，網路上寫BLOG等
選擇自己感興趣的技術體系深入學習如: MS系，LINUX系

說一個看來的技巧，向別人請教之前，先把問題和小黃鴨說一遍，也就是自己說給自己聽一遍，親測有用

別怕麻煩，別trick。
trick一時爽，維護火葬場。
trick三分鐘，debug十年功。

我有很多經驗，但如果只能說一條的話，就是了解你們公司的業務。

用的技術再牛b，如果對公司現有業務沒有幫助，做多少都是無用功。

年輕程序員，分享一些血淚史。個人拙見如下：

簡單點說：

讀萬卷書不如行萬里路，行萬里路不如閱人無數，閱人無數不如高人指路，
高人指路不如貴人相助，貴人相助不如自己去悟。

--- --- --- ---

聊聊項目執行過程：

1.做項目先要在立項前對所有技術點進行測試。
2.選擇方案，選擇技術資產衰減小的方案。
3.優先製作MVP最小可行版本，切勿貪，單點打最核心的功能，步步為營。
4.選擇單純的種子用戶，快速實現單一需求。
5.複雜業務，先進行分層，明確最少功能點，以及各層系統之間的簡單測試驗證，再進行開發。
6.前期遇到問題，能繞則繞，如果實在要攻關技術點，先將整套系統都梳理清楚了再開始，切莫一頭紮緊技術實現細節。
7.及時與上級進行溝通。

--- --- --- ---

再聊點其他的（比較早時候的一點總結）：

情緒的利用

情緒是很巨大到變態的能量，積極和消極的情緒對於完成事情有截然不同的影響，努力保持積極情緒十分重要。

你需要合理調節，努力拋開干擾，沉浸到你的積極情緒中。

消極情緒要儘早面對，合理的規避和釋放掉。

暗示和設定何時的時間點去完成事情十分重要。這個時候，需要todo list和周期反饋（互動或者固定時間的習慣）。

個人職業方向（前端）

你的行業組成、公司構成、發展階段、工作內容對於個人的職業方向都比較重要。選擇行業、選擇什麼樣子的公司、什麼樣子的工作內容要慎重。至少和性格匹配。

移動端比例越來越高的今天，作為傳統的前端，不論是否堅守原來的comfort zone，要不要跳出當前的領域，思變都是好事情。

可以繼續精耕細作在某些未來的方向和行業上。

可以去接觸佔比更高的客戶端，或者未來主流的客戶端。時間點適度。

去迎合你的目標用戶（注意：典型用戶不一定是大眾用戶）。

去玩你想玩的東西和事情（沒有興趣或者缺乏衝擊力和破壞力，那麼東西可能玩的不夠深入）。

職業上很重要的事情

你的直接老闆是誰（自己當老闆不在此範圍內）

你和你老闆的距離，以及他的胸襟和能力決定了你的成長空間。

你的工作內容是什麼

你的具體工作，決定了你的技能成長的方向，但是不是絕對的事情。

你的工作時間

工作時間、加班狀況、周末雙休時間、值班（On Call）一定程度上決定了你的生活品質。

當然，自發使用時間去創造和維護的東西不在此列。

任何問題，如果題目不夠嚴謹，答案就不會完善，所以對於風險的預估要儘可能收集更多的異常情況以及添加足夠多的限定條件，以及要在這些限制內找到主要的限制因素。

任何問題的答案都會隨著時間的變化而變化，所以，請不要懷著背了答案就好了的心態，擁抱細節差異和變化，並且嘗試去理解這些變化。

取捨

任何時候，都不會有兩全其美的事情，得失失得，何必患得患失，捨得得舍，不妨不捨不得。

最後夾雜一點私貨：團隊招人，自覺靠譜的童鞋歡迎私信聯繫。

不是什麼老程序員但是看到上面有許多知友提到rm -rf的問題這裡有實現安全刪除的教程希望有所幫助

http://www.ibm.com/developerworks/cn/linux/1410_licy_linuxtrash/index.html

慎用rm，特別是rm -rf。

寫文檔是程序員走向成熟的標誌