【轉】七年之癢，再見理想

https://blog.csdn.net/iteye_12448/article/details/82005880

 

不肯定「再見理想」是「再見了，理想」仍是「再次燃起理想」，稀裏糊塗地對這句話有感受。做爲程序員，總會有本身的技術價值觀和技術理想。工做七年多，開始癢了。

程序員的生活老是喜憂參半，出入體面的寫字樓，在小小的cubicle裏虐殺腦細胞；偶爾有條件小資一下，常被工做、生活壓力逼得點燈熬油；有時候 想，這麼辛苦，不論作什麼行業都會作的好，是否是入錯行了？手放在鍵盤的時候，又享受投入思考的快感。或許註定是個程序員，限於天賦，或許註定是個庸庸碌 碌的程序員。

前端時間由於跑到鄉下，無法上網，網癮一上來撞牆流鼻涕，百無聊賴開始勾畫價值觀和技術理想。人總追求快樂，天天清醒的十六個小時中，——程序員可 能有十八個小時，至少有八小時花在工做上，因此，爲了過得快樂，工做必定要快樂。若是當前的工做註定無法使你快樂，就趕快結束它。畢竟，多數時候，拼命工做不如拼命找工做來得實在 。程序員固然不算光鮮的職業，但確實挺費腦子，若是你智商低於110，換個軟件公司也註定痛苦，仍是直接換個行業吧。

工做的基本原則是要保持身價，何爲身價？不是你如今月薪多少，而是你如今跳槽，能拿多高的offer。這跟不少因素有關，主要因素包括

1.你當前薪水——HR每每參考這個給你定薪水；

2.你的資歷——畢業的學校，工做年限，外企工做年限，你當前的title，在當前公司工做了已經幾年…

3.你在面試中的表現——能發揮多少技術水平，英語對答如何。

像我這種身價的原本沒資格討論身價，但誰叫這是個人blog，個人地盤聽個人呢.挨個亂噴一下。

1. 關於當前薪水

假如你跟我同樣笨，沒有別的好辦法，就只能多投入精力工做。在之前的博客 與神對話 裏也提過一個程序員對於產品的價值。天天上班8小時，天天多專一一點，日積月累，作的事情會多不少，對本身的提升也會多不少。加薪或許是水到渠成的事，如 果不順利，要麼跟領導談談，或者直接閃人。不管如何，不要抱怨。善於抱怨的人表示他還不夠強。你須要尊重權利，包括他人的權利和本身的權利 。

2. 關於資歷

若是你畢業於名校，學歷又好，一畢業天然就能進大公司。若是你還在江湖三流公司混，就得天天想着早點換工做。工做年限不總算是資歷，好公司的工做經歷纔有用。要記得換工做是有成本的 ，我工做七年多，如今的工做是第五份工做，全部公司都詬病我不stable，這樣的資歷很難騙取信任，教訓啊！聰明的你確定想到簡歷做假，但好公司都有reference check的，我仍是勸你別冒險。

3. 面試

千萬記住，必定要預先作好充分的準備才能參加面試 。對於一個java程序員來講，面試以前要翻一遍相似於 Thinking in Java的書，背一遍設計模式，複習sql，複習mvc框架，複習Hibernate,複習Spring, 複習Servlet spec。或許還有其餘的，web service之類的。你能夠想象，真要複習一遍，起碼要三個月，這就是我認爲換工做以前至少要預留出來的準備時間。機會有限，僥倖心理出去碰運氣純粹是 浪費機會。平時工做總有侷限，看書是最有效準備面試的途徑。

上面說的都是不登大雅之堂的事情，有熱情的程序員總想成長爲高手，我固然也有這樣的願望。問題是你認爲何樣的人算是高手，每一個人內心會有不一樣的答案，關鍵是找出你和理想之間的差距並儘可能縮短它。高手必定不只僅是技術超羣的，高手必然有高手的胸懷 。

本身有時候會考慮一些工做和技術上的原則，想到哪兒敲到哪兒吧。

關於工做：

做爲程序員，你要關心產品 。這沒什麼可說的，這是職業道德問題。

做爲程序員，你要尊重QA 。工做越久，就越以爲QA對產品很是重要，程序員不少時候陷在具體的技術問題中，太多精力被牽扯住了。好的QA讓程序員心安，可以有助於控制風險. QA應該有作最後決定的權利，因此QA須要對產品有很好的insight. 並且好QA須要明白，測試不是找bug的遊戲 。

關於技術：

effective java 和 Refactor書都是總結各類編程原則的書，那些熟爲人知的原則不說，我只說個人理解

static： Joshua在effective java裏強調儘可能使用static method。這確定是沒錯的[這句話說錯了，請看下面T.H.E的評論。他說的頗有道理。我是作應用的程序員，不暴露API給其餘產品，因此一直都以爲 IDE裏移動static method沒成本。但若是寫Service層給未知產品用的話，耦合class的確有危險]。太看重這一點，就容易轉到一個誤區——多使用static field. 而static field有時表明了封裝的問題，須要謹慎。

exception: 包括Thinking in java的Bruce, Martin Fowler等不少人都對checked exception不感冒。本身也思考了一下，你固然能舉出checked exception的應用場景。你能夠說某個方法它拋出checked exception是爲了讓caller處理exception.但你說的是讓「這個caller」處理它。從重用的角度說，你並不預知全部被調用的情 況，因此不能排除一些狀況下這個checked exception並不能獲得特別的處理。這個想法更本質的原則是，寫底層程序的時候，要裝做不知道caller是怎麼使用它的，哪怕是你本身調用它。

重複代碼：全部程序員都對重複代碼表現出深惡痛絕的樣子。但我以爲，重複代碼不是定性問題，而是個定量問題 。能夠這樣考慮：三行代碼反覆出如今三個不一樣的文件裏，甚至在不一樣的package裏，這算重複代碼麼？四行代碼呢？十行代碼呢？曾經聽到一個高手說，編程的核心在於重用。我不反對這個說法，但我更傾向於說，編程的核心在於可維護性 。對於重複代碼，大段的重複確定要消滅的，三五行的重複不是不能夠存在，可是要儘可能把它圈在一個小範圍裏，好比一個包，或者文件，或者方法裏。有時候刻意追求「不重複」，反而讓程序變得彆扭。

技術存在的價值在於可以解決現實問題。你能夠對技術狂熱，但不能忘了這個客觀事實，技術須要實現商業價值，須要最求投入產出比。最最根本的原則，是pragmatic