業務需求永遠第一

沒有和 PM 吵過架的 RD 不是好 RD，那沒有被需求整哭過的人生不是完整的人生。

一直以來，PM 和 RD 就是一對歡喜冤家。
“這個需求很簡單，就是加個按鈕”
“你能不能想清楚再提。這個需求能帶來多大收益？”
“小哥哥，我要改個顏色，馬上上線，急”
“能不能晚點和其他需求一起上線？”
...

現實中，PM 的需求有時候就是合理的；現實中，有些 RD 的疲于應付就是架構設計不到位；現實中，有時候哭過的 RD 才能成長得更好。

下面我們就來看下這個場景。

典型場景?

相信在很多業務下我們需要定義一些規則，比如滿足規則 A，則 xx1，滿足規則 B 則 xx2。用一個“高端”一點的表達就是一棵決策樹，很簡單的需求。

圖一：規則的決策樹表示

基于這種思維方式，在一次活動期間，我們需要對參與活動的人進行風險控制。PM 的需求很簡單：兩個人是好友，則 3 天內只能使用 1 個優惠，兩個人不是好友，則 3 天可以使用 2 個優惠。

用決策樹表示則為：

圖二：需求Demo

? 程序員成長之路?

01?/? 程序員1.0

無知者無畏

涉世未深的程序員，看到這個需求后，心里暗暗的覺得“so easy”，不就是 if/else 輕松解決么。

有經驗一點的程序員，心里盤算，PM 是易變的生物，這些“幾天幾個”肯定要變來變去，得配置化。

因此針對這個需求的 1.0 版本：

圖三：基于純業務開發的系統

看似完美的解決方法，上線后，等待程序員的苦日子就來了。

• 我需要把某棵樹的 A 節點和 C 節點重新組織，形成一條行的規則。

• 我需要修改閾值，修改時間范圍。

• 我需要根據不同的規則，觸發不同的響應。

????。。。

擁抱變化，程序員 1.0 開始忙于改配置、測試、上線。隨著策略變復雜，需求變化更快，上線出問題也越來越多。程序員 1.0 開始應接不暇了，開始頻繁的出錯，決策樹代碼復雜而不可維護了。

我明明很努力，怎么結果就這么不好呢。凌晨下班的1.0，落下了“不甘心的淚”。

02?/? 程序員2.0

迭代是互聯網的利刃，也是我們程序員持續成長的法寶。

2.0 版本的程序員，吸收了前面的經驗教訓，在決策樹的原理上，復用最大化。我們將決策樹的每個節點都按照最小化規則來組織，抽象最小規則元素。

圖四：最小規則抽象

特征：按照一定業務邏輯實現的類型。比如是否好友、3天使用優惠數量等等

閾值：配置的觸發規則的值

邏輯判斷：用于比較特征和閾值之間關系的實現。

對于決策樹的分叉，在邏輯上可以抽取成獨立的鏈式關系。即對于圖一，我們可以抽象出 ABB1/ABB2/AC 三條規則鏈，且三條規則鏈相互獨立。

圖五：鏈式規則

對這個鏈式的規則結果進行統計，將得到和決策樹一致的結論，但是節點的存儲和組織更加的冗余了。

基于這個認知，我們做了一個規則引擎：

圖六：基于最小節點的規則引擎設計

所有的節點都格式化成：特征、閾值、邏輯判斷 三要素

所有的決策樹打散成獨立的鏈式節點

標準化，表示我們可以搭建一套很完整的產品管理后臺，徹底釋放RD的生產力。

程序員2.0 松了一口氣，總算熬出頭了。

03?/? 程序員3.0

追求更高、更快、更強。

自研的規則引擎就完事了嗎？顯然不是，程序員成神的道路沒這么簡單。

相同的需求，隔壁公司會怎么做？比如美團Maze框架？

基于鏈式規則不夠精簡，是否用DAG（有向無環圖）方案更科學？
開源的Drools 有什么優缺點？

實現功能的方案有很多，NX的架構師，不會唯技術論，也不會讓自己跟著需求追。

這個時候有一句名言“任何脫離業務場景談架構，都是耍流氓。”（沒錯，就是我說的。）

在成大神的道路上，必定充滿坎坷。有些人需要3年，有些人需要5年，但人生有多少個5年。我創業做IT教育培訓，就是希望能夠幫助技術人，做好指路人，用我的經驗，將場景與技術結合，讓技術人具備更高的架構設計能力，節省最寶貴的時間成本。

?-END-?

推薦閱讀 1.?漫畫：8年估值千億美金的字節跳動是如何修煉的 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經30歲了，更扎心的是…7. 圖解：這才是程序員加班的真正原因！8.?漫畫：中國互聯網往事(2000-2020)

好看就點在看！

總結

以上是生活随笔為你收集整理的句句属实，90%的人都被需求整“哭”过！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。