代碼很爛，因此離職？

前一段時間一直在面試，有不少感悟，今天分享下其中的一個話題。

我在面試的時候一般會問這麼一個問題：你爲何離職？

其中有很多同窗會提到這麼一個緣由，如今的項目代碼太爛了，前人留下了不少坑，我實在忍受不了了。

其實在我看來，這個緣由顯得未免太不職業了，並且可能把工做想的太過於理想化了。若是由於代碼很爛就離職，那麼你跳槽到下一個公司依然會面對一樣的現狀，由於幾乎每一個人，都會以爲本身公司的項目代碼很爛。

咱們先說說形成這種現象的緣由是什麼，首先，咱們得相信，沒有任何一我的故意把本身的代碼寫的很爛，每一個人都想把本身的代碼寫的很優雅，擴展性很好，可是可能當初水平不夠，在當時看似還不錯的代碼，往後在別人看來就是所謂的垃圾代碼，咱們每一個人都在進步，別說別人了，你如今看你三個月以前的代碼，可能你都會以爲寫的很垃圾，若是你沒有這種感受，只能說你在止步不前。

其次，技術更新換代太快，市場的變化也太快，產品天然也一直在演變，也許在當時看起來還不錯的代碼，隨着時間的推移，功能的更新，代碼的堆徹，慢慢就變成後來者眼中的爛代碼了。

也許你說，我跳到一個新的公司，作一個全新的產品，就不用忍受那些垃圾代碼了，我有信心把架構設計的很是牛逼，爲以後作足夠的擴展性考慮，我只能說你想的過於理想化了，咱們永遠無法預測將來，隨着需求與市場的變化，咱們的功能一直在迭代，咱們的產品也一直在變化，你會發現極可能你以前花了不少心思設計的架構，徹底被推翻了，尤爲在新產品剛推出的階段，這是一個快速驗證快速迭代的階段，你的理想化的技術性思惟，對產品沒有任何幫助，隨着產品的更新迭代，代碼的不斷增長組合，慢慢的你就會發現，你的那些優雅的代碼設計，極可能就是你本身口中的爛代碼，這是一個必然的結果。

這裏也衍生出一個問題，在產品的初期，不要過多的考慮架構設計、性能優化之類的，先把主要精力把功能實現，把產品的體驗提高上去，技術人老是沉醉於先把本身的代碼寫的完美，其實卻不知，產品能不能成仍是一回事呢，先實現再優化，是當今快速發展的互聯網市場最基本的原則。可是你也不必故意把代碼寫的很爛，想着之後單獨抽時間去作重構，我以一個過來人的經驗告訴你，給你單獨的留出時間去作重構幾乎不可能。

因此，若是一家公司各方面發展還不錯，僅僅由於代碼很爛就離職，跳槽到了另外一家公司極可能更糟，並且越是成熟的產品，代碼遺留問題越多，包括 Google、BAT 等大型互聯網公司依然如此，若是你以爲這家公司還不錯，想一塊兒發展下去，代碼很爛的話那就試圖去改變一下，給你單獨的時間去作重構很難，那就邊開發功能邊重構，邊迭代邊優化，在不影響產品迭代的狀況下，嘗試着去作些力所能及的改變，在這個過程當中你會發現，其實你也在慢慢的成長。

大部分人其實都在抱怨環境，只有極少數人會去作點改變，哪怕這些改變微不足道，有些時候，你極可能會由於這些微不足道的改變，獲得一些更好的機會。

本文原創發佈微信公衆號 AndroidDeveloper，歡迎關注，聽我扯淡。