寫這篇文章，是想和身邊的同學談一談在阿裡做業務開發的方法，這些總結可能來自某本書或者某條理論或者是生拉硬拽，但都是本人這些年摸爬滾打的經驗。有時候摔倒爬起來，突然想到當初看的某句話，心有戚戚焉，默默記下，但并沒有去深究背後的理論，所以喜歡規規矩矩、條條框框的可以忽略本文。俗話說“文無第一武無第二”，這些經驗不是最優的，也不一定适合所有人，大家自由評判，如果有人看完會心一笑，我就很滿足了。

心态

開放

工作多年後感覺“诶，别人知道這個，我卻不知道”的機會有點少了，可能有點焦慮，但是沒關系，學習，聞道則喜，年輕的朋友們更應該努力，養成習慣終身受益。從别人那兒學到了，也要能教給别人，互相交流才能形成良性循環，現在是信息時代，沒必要藏私。做到這兩點足夠應付日常工作，還能形成一些影響力。

合作

公司裡做事，遇到對方推诿或争吵，有的人選擇剛到底（比如我），但也有人選擇統統接受，無論哪種，我們要學會合作和拒絕。吵架的能力後面講“産品思維”時還會讨論，先讨論“拒絕”。我們有一些同學很謙虛，也非常努力，總是盡最大的努力滿足需求，但也總是被傷害，996 都搞不完，這時候就要嘗試拒絕。當然，有時拒絕的同時也要幫對方想一下，看看有沒有其他的解決方案。尤其是當大家都為了同一個事業奮鬥并且對方也有足夠理由的時候，簡單粗暴的拒絕，隻能導緻停滞不前，最終損失的是整體利益。

追求卓越

人類從共同組織到社會的發展過程需要集體道德，它是法律的基礎。寫代碼也要講道德：設計是否有缺陷？實現是否有漏洞？多思考，不要簡單為了通過測試、交付差事來寫代碼。有追求才能有提高，保證代碼整潔高效才能赢得他人的尊重，未來别人接手時才能少罵幾句。

思維

結構化思維

初高中數學需要掌握的一項重要技能是把論證分支條件都覆蓋到，工作以後要做的是結構化思維，按照某個維度切分到完全覆蓋，相互之間又沒有交集，這就是 MECE。

有些同學在讨論問題時不容易被大家理解，那麼就嘗試一下：抓主線、核心，确定讨論問題的深層本質，可能一時半會想不到最根本，但是通過一層層問自己為什麼，不斷尋找答案，至少能找到一個比較深入的層級，然後在這個基礎上把主線逐條拆分，不要着急，一二三四講完，基本不會太偏。這大概是《思考的快與慢》中的慢思考。

産品化思維

開發同學需要培養自己的産品思維。

産品的價值是使用價值，關鍵是用戶體驗，用戶體驗是需要打磨的。代碼寫完、測完、發布完成，但是用戶一定還有各種各樣的意見，而且，在數據量增大的情況下是否能保證體驗是個問題，在系統失敗的情況下怎麼保證用戶體驗也是一個問題，在面臨高流量壓力情況下的表現更是問題。我們時刻想着用戶的操作，再加上一些“技術性需求”，做方案就會簡單點，讨論問題也會“顯得”高大上一點。

理解用戶需求，管理用戶期望：很多人相信“唯快不破”，快不是唯一的指标，至少我們還要保證成功率、數據準确性，以及用戶的操作體驗。ToB 的産品避不開大數據量的操作，我們要在保證數據準确、同時在不影響C端的情況下盡量做到快，做不到也沒關系，可以和運營溝通好，說明系統為什麼慢，有多慢，有什麼影響，管理好用戶的期望。對于 C 端，我個人遇到轉圈圈的網頁等待 10 秒就沒有耐心了，當然等待不是不行，但最好要有個進度條之類的東西；對于電商搶購的核心場景，用戶體驗沒有商量的餘地，也很難“管理用戶期望”，我們隻能做到盡可能快，盡最大努力保證吞吐量。

做業務需求，跟産品打交道是最多的，我想聊聊與産品同學的合作。

用戶是很懶惰的，能走直線不走彎路，能點一下不點兩下（所以，要用戶點兩下的功能一定是有影響的功能），相信産品在設計時會有相關的考慮，我們可能因為實現難度的原因而有質疑，但是不能否認産品同學設計的初衷。當然，提高用戶的體驗有很多種，大家可以一起想辦法，既然我們想吵架，那還是要拿出點硬實力的。

信息是有勢能差的。當初通信業的祖師爺香農提出了信息論，從此信息有了度量。信息在傳輸中也會有衰減、噪聲疊加，每個人得到的信息有差異。從做決策到 PRD 評審，如果我們沒有足夠的信息，不要簡單直接地否定或質疑别人的業務方案，那樣效果非常差，基本上等于指着别人鼻子開罵了。我們要做的是吸收信息，同時用自有信息和自己的理解來補充、修正相關方案。當然，也不排除産品同學在設計時沒有做好調研的場景，如果方案與現狀不符，那大家随意……

我們的産品同學都喜歡講“這個功能現在是這樣，不排除以後要變成xxx樣的可能”，有些同學喜歡揪住這個可能性不放。我個人覺得，這些隻是提醒我們注意設計系統時為變化預留空間、封裝變化、保證擴展性， 而聚焦主流程才是在有限的 PRD 評審時間裡最該做的。“我心不動，随機而動”，隻要能想明白，沒什麼好擔心的。

信任産品同學，但也要有自己的堅持。曾經我們有一個後台管理功能，需要直接展示大量數據，用戶一次保存也可能要保存很多，PRD 評審時就讨論很久，但是沒有找到比較好的方案。後來我們又調研了兩種方案，還是要獲取、保存大量數據，不斷跟運營讨論使用方式，最終确定了一套“粗調+微調”的解決方案，順利交付。整個過程體現的就是大家對體驗、對穩定性的堅持，如果項目保密相關制度允許的話之後再另寫短文分享。

與産品、運營緊密合作的意義，如果我們相互信任，那麼信息傳遞就會很順暢，在做決策時，會從各自的視角嘗試給解法。在這種合作模式下，大家的合力更大。我們在開發中經常會想到很多的“小場景”、“小概率”，解決他們需要花費的時間和精力很大，如果能從運營、産品層面解決，那麼效果一定是事半功倍。當然，運營 SOP 也是要管控的，否則也會付出代價。

跟産品、運營溝通要學會講“人話”， 我們做開發久了，對技術名詞信手拈來，但是運營同學一臉懵，我建議多用類比的方案，這三年我們已經把跟我們對接的運營同學培養成了“半個開發”（運營小姐姐的原話）， 說明大家的科普能力不錯。

與産品運營的合作我講的有點多，看來産品和技術的矛盾确實是永恒的話題。

計算機思維

相對于産品思維，我們開發同學還需具備計算機思維。隻按照産品思維或者說“産品同學的理解”來設計我們的系統是很危險的，産品的要求絕對不應該直接映射成我們的實現，開發需要在開發框架内來做設計。

計算機思維可以幫助我們評估方案，在有多種選擇的情況下與産品共同産出最優解。作為産品、安全對接的接口人，好多時候都需要現場評估方案的複雜度、可行性，對系統不了解，對編程能力、技術細節不了解肯定是不行的。尤其是“細節決定一切”，多想多思考，免得踩坑。

計算機思維偏硬核技能，我們需要不斷學習，知識面要保證“寬+深”。“寬”是指與當前工作不相關的内容也要多了解，遇到問題時知道怎麼用。“深”則是對于當前工作所需的技能要足夠了解，了解最佳實踐，追求卓越。

向上思考

如果一直都囿于自己的小圈子不考慮更高更遠大的目标，那我們根本不可能達到那些目标，還在躺平的同學還是起來吧。

舉個現實中的例子。作為技術人，設計方案時處處都要做決策做取舍，當我們要向上彙報或者大家一起評審決策時怎麼辦？首先需要明确一點，如果我們負責調研，那這個事情裡邊我們相比領導有很多關于細節的信息，領導可能會有其他的來自客戶或者運營的信息，大家聚集一堂開會決策，要的是效率，那在開會前，負責調研的我們自己需要先有傾向，這是每個人都可以做的，因為我們已經有了相關的信息，我們可以做取舍、做決策，這是免費的鍛煉機會，不要因為“讓領導想去吧”而錯過。

技能

設計位面

各種方案設計，自底向上和自頂向下的設計是相輔相成的，自底向上的設計可以幫助我們了解當前的狀況，比如有哪些接口可用、還需要增加哪些接口；自頂向下的設計能幫我們更好的理解需求，厘清系統之間的邊界，在滿足業務需求的前提下設計合理的架構。

自頂向下怎麼設計？一個複雜的系統應該怎麼描述？架構師在英文中也是建築師，這說明設計系統和建築是有相似點的。當我們把系統想象成一個立體的物體，肉眼看到的隻是一個投影，這就是設計位面。
在開發設計系統時要考慮的位面包括但不限于：

• 業務需求：用戶的真實訴求、用戶體驗
• 技術需求：領域劃分、系統劃分、Map Reduce、可測試性
• 穩定性：QPS、RT、監控報警、面向失敗設計（可能與業務相關）
• 安全合規：鑒權（功能權限、水平權限）、加密、訪問頻次、内容校驗，以及各種安全組件支持的防護能力。
• 成本考量：業務的雲資源開銷及第三方成本、開發時間，需求變更後可能造成的修改成本。

各種方案設計，自底向上和自頂向下的設計是相輔相成的，自底向上的設計可以幫助我們了解當前的狀況，比如有哪些接口可用、還需要增加哪些接口；自頂向下的設計能幫我們更好地理解需求，厘清系統之間的邊界，在滿足業務需求的前提下設計合理的架構。

1. 業務需求

我們現在做的業務特殊，好幾個甲方提需求，一個業務要讨論很久。作為開發同學， 在過程中要拿捏到位，要不斷确定優先級，探求用戶的需求底線，了解需求的内涵、外延。比如，甲方希望做分批多次履約，甲方還希望支付前配座， 甲方可能還有各種各樣的想法但又都不确定，那我們怎麼辦？

漸進叠代。先按照簡單的方案做，先保證可用，保留擴展性。舉個例子，我們做抽簽時隻是确定了算法，具體的業務玩法都還沒确定，我們就開工了（實在是因為甲方太慢），先确定流程分，然後确定哪些地方還不确定，需要簡單做保持擴展，然後我們就開始做了。後來加上了數據回流、庫存兜底釋放，後來為了解決支付前配座又在抽數字庫存的基礎上加了抽座位庫存的邏輯。整體流程框架沒有太大變化，我們在各種流程确定後也沒推倒重來。

作為開發，我們要有“不怕需求”的氣魄，敢于迎接挑戰，不斷探索更優的解法。不要習慣于說“不”、“做不了”，簡單的拒絕會讓人上瘾，同時也會讓我們喪失一次深入思考業務和鍛煉自己能力的機會。

堅守底線。有些原則是技術方案的重要假設，比如庫存扣減指定渠道。這些“假設”對我們的方案至關重要，打破後會産生颠覆性的影響。我們要有意識地跟産品和運營達成共識，讓産品和運營知道如果推翻這些假設要付出多少代價，這樣他們跟甲方溝通時可以盡量避坑，大家讨論也節省唇舌。

2. 技術需求

可擴展，易維護，可測試。

• 用戶體驗：同步、異步，用戶的操作習慣如何，是否讓用戶有困擾，盡量“不讓用戶思考”，最小驚訝（最小驚吓）。
• 可測試性：是否要回滾數據還是願意承受新增一個作業空間的人力和資源開銷。
• 可擴展性：在現實和未來之間尋找一個平衡點。把握好系統複雜度和未來需求之間的平衡， 用最簡單的方式應對可能的變化，比如增加個配置開關決定兩種不同的處理流程，或者流程可編排，這些取決于我們有多少可投入的資源，取決于我們的決心和價值判斷，也取決于大家的設計能力。

3. 高可用

面向失敗設計、性能、容量、預熱、預案、限流、一緻性、資損、容災、監控報警、安全防護。很多詞彙都和高可用相關，相互之間也有很多重疊，找到合适的子集堅決執行，日常常練常新，常懷敬畏之心，才能把穩定性做好。

4. 安全合規

我們奧運票務系統設計之初是面向全球的購票網站，所以安全合規更複雜。我經曆過内外部 10 次的安全測試，參加過數次法務的讨論，光 Cookie 協議就改了很多版本。總之，對外開放的業務必須關注安全，關注各種越權、數據合規。

5. 成本考量（ROI）

運營或者産品提出的絕大多數問題，技術上都“能”做，主要是看人力投入、時間成本以及價值，投入産出比是任何時刻都可以拿來衡量的标準。

有時候，我們會被質疑為什麼不能再增加點功能，比如說當前的方案還有變化的可能性，但是現在的方案已經有傾向性，那麼是否要沿着這條路走很深就需要做好權衡，如果有一天要調頭換方向，那麼就要付出很高的代價。這時候我們要提前把風險跟業務需求方說清楚：要麼少做簡單做，要麼讓需求方保證不要調頭。“不調頭”的内容就是我們與業務方達成共識的底線，大家應該把這種底線牢記于心，防止哪天翻車。

常識與基本規律

空間換時間（或資源置換）

什麼是空間？緩沖區、緩存、本地緩存、文件分發，都可以達到空間換時間的效果。

假如是 CS 或者 BS 的架構，有些工作在 Client 端或者 Browser 端做也未嘗不是好方法，這樣可以減少服務端的壓力和交互。但要謹記：不要相信外界的輸入，服務端要校驗，不然容易産生安全漏洞。

數據結構與算法

計算機程序是算法加數據結構，做程序員要具備相關基礎，不僅是為了面試，也是為了欣賞算法和數據結構的美妙之處，當有一天遇到類似的問題，至少有個思考的方向。

最短路徑猜測

如果我們的系統在壓測中報線程池滿了，你是猜 tomcat 的線程池設置過小，還是我們的請求處理太慢？我可能會猜請求處理慢，因為 tomcat 的線程池大小使用的是集團推薦的設置，之前也沒問題，而且，多數的線程池滿都是因為任務執行太耗時，所以我選擇相信我們内部某處處理有問題。當然 tomcat 線程池也可能有問題，怎麼證明誰對誰錯呢？那就看請求 trace 裡的 RT，系統的負載吧，如果都沒問題，那可能就是 tomcat 線程池不足，那怎麼證明是真的不足呢，改一下線程池大小看看是否有效。

程序員很多時候都是在解決各種問題（bug、性能、安全） ，解決問題不是靠争吵動嘴的，“Talk is cheap, show me the code'才是王道，推理、驗證、嘗試修改，不斷縮短處理問題的路徑很重要。

奧卡姆剃刀原理：有時候我們的産品同學、開發同學在讨論到情緒高漲的時候會有各種各樣的想法，這時候請大家還是堅持實用主義，堅持 “KISS” （Keep it simple stupid），堅持“如無必要，勿增實體”。

道

有時候我們需要一些理論來讓我們講的話聽起來高大上，但有時候我們真的需要一些深信不移的理論，比如 SOLID、KISS、DRY。在開發過程中，我們要不斷用各種假設結合這些原則來證明我們的設計，如果覺得之前的設計不好，不一定要改，但是要想、要思考，這會使我們有更深的體會。“知行合一”，既要知道理論，也要在實際中運用，慢慢形成自己的風格，形成對技術對行業的理解， 這就是每個人自己的“道”。

求知

“求知欲、好奇心、理解力” 是 2020 年一位諾貝爾獎獲得者說的三個詞。我們沒有機會接近諾獎，但這不妨礙我們去追求知識、藝術、愛情，去探索這個世界或者社會的奧秘，保持一顆年輕、求索的心。（正文完）