丟什麼別丟原則

 也不知道這個標題中的原則一詞用的對不對，我姑且叫他原則吧。對於寫代碼的我們來說，其實我後面會叫他規範，但是想了想，對於其他方面來說，又或許是原則，好啦，不糾結，直接進入正題。

 來新公司一個多月了，從我剛到公司那天剛好是一個迭代的開始，直到昨天，後臺版本已經同步到公網，APP因為需要審核稍微延遲了點，但是內部測試也正緊鑼密鼓的進行中。剛換了一個環境，對新環境里的開發模式，代碼規範，代碼提交模式等都是新的，感受最深的自然就是代碼提交的方式。習慣了以前的code review方式，來這裡之後目前是沒有這個強制的機制，所以有所放縱，也正因如此，我自己鬆懈了。

 鬆懈的代價有點慘烈，直到版本上線前夕也就是昨天，才真正理解很多事情是需要原則，需要規矩，需要規範的，沒有規矩不成方圓，代碼沒有規範，就不能稱為好的產品，我是Android開發，那自然就是出不了好的APP。先從我的角度說說規範的事。從編程規範來說，尤其是Java編程規範，空指針是最容易出現的問題之一，如果後臺加了個欄位，但是APP版本如果想先對接舊後臺對比下前後的功能，此時沒有做過入參判斷，那是什麼結果可想而知，APP崩潰啊。倘若做了判斷，那OK至少從用戶體驗來說，APP沒有出現致命的問題。不過入參判斷只是其中一步，沒有判斷null的前提下，也可以讓他不崩潰，也就是網上也會出的技巧，讓常量作為判斷前提方可。其實寫這段話的時候，看的同學肯定也覺得，這麼簡單的事情，還是輕輕鬆松的嘛，那很好，說明這個小錯誤我很傻唄。這也是我昨天到家之後，第一個深刻感受，並不是你不會或者你不懂，而是你沒註意，一個小小的細節引發的血案。

 非空判斷，還有數組的越界異常，這些無論是在Java還是c都是很容易出現的問題。記得在以前的項目組裡，還有Java和c的軍規呢，把這些低級錯誤都需要杜絕。杜絕的一個很好的方式就是code review，Google那麼牛的公司都需要做，何況是我們呢。記得剛到杭州公司的時候，同事讓我去review，一時間沒反應過來，後來漸漸的熟悉了這一流程，把一些平時容易錯的都列出為review必備條件。網上看過很多雞湯文，提到很多次的也是review的重要性，多看看別人的代碼，也是提高能力的方式。Code review，以前是項目組必備，現在因為沒有強制執行，所以我鬆懈了，代碼就是新版本上線出問題了。其實我也可以推卸責任的，版本上線後臺也出了差錯，回滾了3次才弄好，但是還有參數沒有配置，導致配置不對，APP獲取參數不正確。按理來說，APP和後臺強相關的情境下，其實我之前是和後臺確認過的，但是原因不可抗拒，所以也並不是說後臺同事告訴你肯定沒問題，你就得百分之百確信，這也是一種自我判斷的能力，需要嚴格遵守自己內心的編程規範原則，無論何時何處，都需要做好APP的萬全之策，而且保證用戶體驗。

 第一次參與新公司的版本上線，客戶端就是遇到了入參未進行非空判斷，未進行數組長度的判斷引起的崩潰，實在是心有愧疚，其實這個以前都是必備的操作，這次完全是因為我沒有嚴格遵守導致的問題，還好只是預上線，在內部消化了問題。後臺的問題我不大清楚，但是就知道回滾了幾次，好在在可控範圍之內，有驚無險。據我所知，後臺的問題大部分還是因為配置未同步、代碼未同步到線上。忽然發現了一個共通的問題，我遇到的版本上線當天，開發都是嚴陣以待，總會出現大的小的問題，不是部署就是APP忽然測出來的問題，不知道大家有沒有經歷過，哈哈。

 有過第一次經歷了，我也知道套路了，我還想說說自己另一個感受，做產品是一件很嚴肅的事情。還記得以前和幾個新同事一起開發的時候，因為其中一位的懈怠，組內老大在開早會當著眾人的面說：我們做產品的，再也不會像是學校做畢業設計那樣了，每個人需要有產品意識。從那以後，我便把這句話銘記在心，但是很遺憾，我自己也沒好好做到，尤其是對待寫代碼這件事情上，在自我懈怠中失去了產品的意識。做一款產品，寫代碼只是其中一件事，還有需求分析，需求評估，甚至流程圖等等，我會把我這三年學到的東西發揮最大的作用，讓產品做的更好。也借第一次發版本的經歷，告誡自己，丟什麼別丟原則，否則你做的永遠只是APP，而不是產品。