作者：小傅哥
部落格：https://bugstack.cn
系列：https://mp.weixin.qq.com/s/PhR8HvGC49d0cerYxGJ3_g
沉澱、分享、成長，讓自己和他人都能有所收穫！?
研發已經討厭我了！
傅哥，我是剛來公司的產品，就是還懂點技術的產品，因為我以前也是學的軟體工程專業，但不太喜歡寫程式碼就想著做產品吧，指揮別人寫程式碼。夢寐以求的想法終於得以實現了
我通過王者輔助、零食投喂、介紹物件的方式終於和研發打成一片了，但最近他們有點討厭我了。因為我接到了個業務老闆著急要上線衝量的需求，但因為上線節奏過於著急從BRP評審到PRD產出已經佔了大部分時間，到研發和測試完成上線的排期只能倒排，而且這期間還總是修修改改的補需求，研發說他的程式碼已經成屎山了，而我就像那個攪屎棍，臨近提測又來了一槓子！
那，這槓子我不想再當了，我想知道都什麼情況讓碼磚兄弟頭大，我儘可能以後繞開，我是一個有良知的好產品！
以上是杜撰的一段，不過也就差念身份證了，基本只要寫程式碼的研發，就會遇到各種各樣的產品，但並不是所有產品都瞭解研發寫程式碼怎麼就會遇到這麼多問題，因此想結合這段來講講那些有坑的路上，我們研發是怎麼走的。
那些年踩過的坑
1. 新碼的，著急上
當一個新的需求來不及讓研發思考、設計、評審，所預留卡死的上線時間後，只能是堆人的方式怎麼快怎麼寫功能，不會有文件、不會有註釋、不會有單測，尤其是在這個階段還有很多是產品沒有確認清楚的功能反覆修改時候，就更會把程式碼的實現搞得一團糟。
可能產品、業務，甚至是提這個需求的老闆也搞不清楚，就是寫程式碼嗎，修修改改有那麼難？有，這就像原來你給了一堆撿來的磚頭、扣來的泥沙、手畫的圖紙，需求是蓋一個廁所，現在廁所的坑挖好了要起架子了，不行改，我們不要廁所了，要豬圈。好像豬也得拉屎，挖的坑也夠用，修修改改，擴大擴大面積，豬圈好像也行了，但這個時候埋下了很多的隱患，指不定豬進場的時候，就給你拱塌了，但就在即將貼膏藥式修補豬圈安插水管的時候，產品傳達了老闆的最新意圖，這個場地現在我們們決定要住人了，得給這UI介面改改，再豪華裝修一下。都知道蓋房子挖地基，放到寫程式碼上好像就不懂了
舉個例子，程式碼是怎麼死的
- 需求無規劃，想要啥就加啥，加著加著就出事故了。這也是大部分研發一天天在面對的場景。
- 從一個需求的提出到研發開發、測試驗證、上線部署，這些過程都需要合理評估時間來執行，否則就不會有像蘋果IOS那麼好的體驗產品。
2. 交接的，堆屎山
你以為你開發的工程都是從零開始嗎，其實並不是的，尤其是網際網路公司經常快速調整適應市場變化，也會導致你所接手的程式碼可能是別人寫的，甚至是很多個別人累計寫出來的，而你之前寫的想寶貝一樣的程式碼，也會被別人拿去堆成屎山。
屎山程式碼是什麼樣，同樣是vo2dto有12種以上的寫法、json2object 也有常見的3、4種、生成個編號ID也是N多種方式。那麼現在任何一個人接手別人的程式碼，根本找不到文件、也看不註釋、方法名也是隨意英文和拼音，把queryBatch寫成queryBitch也是常有的事。所以，就這麼多花樣百出同樣功能多種實現方式的程式碼，怎麼能更快的在裡面迭代需求呢。我不知道我要改了什麼，但別人加的我也不敢刪
產品可能又不懂了，那不是刪了就可以嗎，會有難度？有，這想啥呢，比如你家裡是一個三居的格局，有衛生間、有廚房、有客廳、有臥室，第一任住客還算講究安裝了馬桶、買了沙發、裝了臥室的床，後來交給中介出租，中介說這不浪費嗎，廚房這麼大也沒安裝啥，拆拆裝個床，在裝個馬桶，獨立衛浴，還多租一間。客廳也給它打個隔斷，接個上水管和下水管，也給它來個獨立衛浴，主臥、次臥都裝獨立衛浴。好，後來房子交給你了，你整租了，發現這屋裡到處都是馬桶，拆哪個的時候，都開始往出噴水，不知道他們的水管是怎麼連結的，與找師傅修的成本看，不如都拆了重新裝修了。這像不像，程式碼根本沒法重構，只能重寫！
3. 複用的，不合身
不能重複造輪子，已經有現成的你為什麼不用，你自己寫的這個有什麼創新，為什麼不找某某部門調研下，你這是不是技術自嗨。你聽了還怕不，嚇人不，明明你可能就是為了更好的、快速的、熟練的把專案寫完，但現在你為了做一個專案，需要跑遍所有部門調研他們都有什麼元件能支撐你的需求，之後開始要文件、對接、聯調，好，你的需求可能原來並不大，現在一對接你甚至從原本三天干完的事，現在要幹兩週。妥妥的增加工作量，年終獎又是你的了！
一般在述職、答辯、彙報的時候，大家都把自己做的事包裝的非常牛皮，甚至只要是用上你這個元件，公司都能早上市三年。但一彙報完，再去找問你這個東西是否能對接的時候，完了，這塊不支援，那塊不能做。為啥？因為一個需求功能的設計很多時候是偏向於自己業務訴求的，而不是一個統一的標準方案，不能解決其他業務部門的個性所求，甚至為了支援很小的一部分功能都要從頭到尾的梳理和開發，加表、加欄位、寫類、寫方法、寫單測，一全套下來並不是那麼容易的就支援了，可能支援不好還給自己的系統帶來非常沉重的負擔。
產品可能又不懂了，複用一下不是減少開發了嗎？這就像啥呢，一個老爺，家裡大老婆和幾個姨太太，大老婆位置穩平常就當當評委，分分蛋糕，大姨太喜歡錶現自己，和大老婆走的近，沒事就給老爺和大老婆彙報最近的工作成果，小姨太剛進門沒有什麼成績，跟老爺說想做個褲衩穿，老爺說那大姨太上次彙報說她那不是有褲衩嗎，你還浪費那工期幹啥，去複用一下就穿唄。小姨太找到大姨太，問褲衩能不能借來穿穿，大姨太說有點難呀，我這褲衩太小了，你那身材也穿不進去呀，我要按照你那尺寸改，都能提到脖子了，你看看要不我們找老爺說說，你就說你的褲衩比較定製，還得要一些特殊功能，比如說展開是裙子、收起來是褲子、夏天是褲衩、冬天是棉褲，這樣就給你批了，你就創新了。
爬上來皆是過往
1. 提高自身能力
在職經歷了這麼久，讓我深深感受到，即使非常有技術含量的專案在沒有太多經驗的研發面前，也能用CRUD+整篇的ifelse寫出來，產品的PRD流程是啥樣，程式碼裡的分支判斷走向就是啥，不會有點的模型抽象也不會有一些共性提煉，這樣方式的寫程式碼只能是讓程式碼一篇篇的爛下去，這與產品無關、與排期無關、只與自身的技術能力和專案經歷有關，也許只是因為你寫，所以才會這樣。
經歷了這些以後我會每次開發新的功能都與上次做對比，把那些比較不錯的實現方式複用下來，再把實現的不太好的地方進行優化，一點點沉澱出自己對技術實現過程的經驗積累。慢慢也就有了一定的條件反射，知道那些專案會刺激到我創造出更好的設計，那些專案可以複用我之前的邏輯，這樣既能快速且高質量的完成需求，又可以滿足產品功能的迭代。每一次成長，都是自己的收穫
2. 遵守規範標準
其實你要知道人並不是穩定輸出的機器，只要是人在寫程式碼就一定會有不規範、缺流程、出異常的情況，因此這些需要有一個制定的標準，大家統一按照一個方式進行執行，這樣即使在出問題的時候，也可以很快的定位和處理，否則你用一個方式開發，他用另外一個標準編碼，最終一個團隊就要維護兩套內容，即耗費人力又可能出問題。
尤其是我們開發的專案並不是小作坊的時候尤其重要，從市場BD，業務運營提出BRD、產品評審PRD、架構做設計、研發做細節、程式碼要評審、完成要提測、上線要把控、交付要驗證等，每一個環節都需要有執行標準，如果整個組、整個部門、整個公司，都有標準的流程規範，即使在交接程式碼、協調資源、共同開發時，也都不會那麼多的障礙在阻隔我們深厚的碼磚情義了。
3. 產研測多溝通
我們並不能保證產品不改需求，即使是快到要上線的時候，因為市場、因為風控、因為流程、因為財務等等，可能甚至都不是研發所能知道的一些特殊原因的情況下，不改需求根本就不可能讓你上線。那研發可能會問，為什麼不能早早的提出來，那是因為這些特殊情況都是來自於不確定性，就像我們跑著的程式碼一樣，沒人知道是因為網路、IO、負載、明星突然官宣流量猛增，而導致出問題的。
為了能更好的承接產品需求，最好的方式就是溝通，多溝通，尤其是在產品需求設計初期，提前檢視他們的PRD文件，這裡可能有很多內容是你可以提供的服務，也有一些是產品在猶豫使用哪種方式實現的功能，在與你討論後，而決定複用你已經有的系統。所以溝通真的可以給你後期開發帶來很大的收益，減少很多不必要的事情的蹦出來！
- 業務，不要做產品的
渣男 - 產品，不要做研發的
渣男 - 研發，不要做測試的
渣男 - 測試，不要做業務的
渣男
做一件事，就把一件事做好，我們都不做下一環的渣男，也是對自己成長的負責！