[[438025]]

本文轉載自微信公眾號「bugstack蟲洞?！梗髡咝「蹈?。轉載本文請聯系bugstack蟲洞棧公眾號。

研發已經討厭我了!

傅哥，我是剛來公司的產品，就是還懂點技術的產品，因為我以前也是學的軟件工程專業，但不太喜歡寫代碼就想著做產品吧，指揮別人寫代碼。夢寐以求的想法終于得以實現了

我通過王者輔助、零食投喂、介紹對象的方式終于和研發打成一片了，但最近他們有點討厭我了。因為我接到了個業務老板著急要上線沖量的需求，但因為上線節奏過于著急從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文檔，這里可能有很多內容是你可以提供的服務，也有一些是產品在猶豫使用哪種方式實現的功能，在與你討論后，而決定復用你已經有的系統。所以溝通真的可以給你后期開發帶來很大的收益，減少很多不必要的事情的蹦出來!

• 業務，不要做產品的渣男
• 產品，不要做研發的渣男
• 研發，不要做測試的渣男
• 測試，不要做業務的渣男 

做一件事，就把一件事做好，我們都不做下一環的渣男，也是對自己成長的負責!