“我做的事情，複雜度不太夠，可怎麼辦呀” 這樣一句感嘆，可能是大廠前端部分同學在工作中總有一天會聽到的心聲。因為在這裡，有無數的人會問你：“做成這個事情，你在裡面做了什麼？”“你做和他做，有什麼不同？”等等。每個人都想做牛逼的事，一鳴驚人，可似乎牛逼的事情就這麼多，我手上的事情怎麼就牛逼不起來呢，聽起來就像一個三線小廠的新人也能自如應對。
那麼，這個複雜度，我們怎麼“深挖”呢？注意這裡為什麼用挖這個動詞，因為複雜度其實就埋在了我們自己的陳見之下。下面就讓我們一層層地去刨開來看看。
不要把複雜度想複雜了
其實討論這個問題首先我們要確定清楚，這個所謂的業務的複雜度，我們到底說的是什麼的複雜度。對此，團隊同學之前的文章曾作出以下的歸納，比較全面得對複雜度這個事情進行了涵蓋：
- 描述這件事情有多困難：事情所處業務背景的複雜程度。
- 產生這件事情有多困難：事物所牽扯的各方利益、業務邊界、生產力關係的複雜程度。
- 實現這件事情有多困難：具體實現事情，面對的技術挑戰的複雜程度。
- 證明事情正確有多困難：具體衡量事情的價值的複雜程度。
我知道，其實同學們常說的複雜度可能是第三個，實現上有多困難。很多前端同學如魔怔般得在這一點上往下刨，還記得曾經有幾年，每個團隊都想搞個自己的大而全的框架，雖然也和當時時代背景有關，但多多少少還是有些過於“鑽”了。
所以雖然技術實現本身是立命之本，在討論這點之前，我們還是應該先跳出來看看，其他幾個維度上是否存在問題痛點，是否存在複雜度需要解決，這都是我們作為 Owner 需要去看的事情。
那麼如何去判斷某一維度是否存在複雜度呢，第一步就是要能夠講清楚現狀，不管是理清楚業務概念業務邏輯，還是理清楚合作方式合作邊界，還是理清楚架構模式等，有了清晰的全域性感，才能幫助我們更好地去做分析。第二步就是去定義痛點，不管是從自己/合作方/使用者任何視角出發，我們可以去主動尋找痛點，根據痛點去篩選，哪些是重點問題，從問題本身去發現複雜度。畢竟我們作為工程師，本質上的職責就是通過分析問題，挑選符合問題場景的技術進行組合調參，從而解決問題。不管是哪個工程領域，都是一樣的。
複雜來源於變化
從問題去發現複雜度，就是下一步的重點了。說到複雜度，大家最先想到的是什麼？我最先想到的是演算法的複雜度。演算法的複雜度本質是衡量一個演算法在資源上消耗的方法，其從時間和空間兩個成本出發，去評價一個演算法的成本。這個指標的評價方式也是很有意思的，它不是簡單直接地去衡量時間本身的消耗總量，而是去衡量其隨著處理的資料集大小變化而表現出來的增長趨勢。
從演算法複雜度衡量的方式中，我們可以得到一個很有趣的啟示，當你總是關注與一個小場景下的問題時，你是非常難以評估複雜度的，當你在某些維度上把問題放大的時候，比如演算法中的輸入資料集大小，你才能夠更清晰地抓住主要矛盾。
總結一下在我們日常工作中，可以去擴張思考的幾個維度：
- 時間維度：看看隨著未來的業務發展或者系統持續迭代，是否有一些問題會被擴大化複雜化
- 鏈路維度：如果目前處理的業務，是整個鏈路的一環，那可以跳出來看一下，是不是上下邊界存在問題或比較模糊，或者鏈路怎麼調整能夠更好的解決問題。切忌一直在屎山上雕花，不破不立，不要拿著錘子看啥都是釘子。
- 規模維度：隨著使用者量，業務量的增加，是否存在一些問題被持續放大。比如我們去解決每天處理 N 次 1+1 的問題。如果我們的工作確定是每天做 10 次 1+1 的計算，那可能真的是沒什麼複雜度了。
- 橫向維度：當然在這個場景下我們就可以看看，是不是有其他人也要做這個事情，從而提升我們所謂的增長規模。也就是橫向維度。看看類似的問題在別的業務中是否存在共性，是不是可以用同一個方案去解決多個業務中的類似問題。
這些都是幫助我們去發現複雜度的方法。所以說複雜更多是來源於去解決未來不確定的變化。一個問題之所以複雜，往往是我們因為我們希望我們的方案在未來依然能夠解決這類問題。
為未來做投資
之前有同學曾經提出過一個問題：“很多事情簡單做業務目標就能達成，但是技術深度體現不出來，團隊同學成長就有限。更優的方案意味著更多的投入，在業務壓力較大的情況下，各方也會挑戰你的方案，如何抉擇？”
這個其實一個比較常見的問題，“這個事情可以簡單點搞嘛，不要搞這麼複雜”，每每當我們照著上面複雜度分析心法去做了方案之後，總有一些人會跳出來說這些話，抱怨我們沒有考慮 ROI 云云。首先，如果是 Leader 和你說這話，你可以在心中先默唸一句“SB”，哈哈哈。當然罵歸罵，我們還是需要仔細分析一下，對方說得是否有道理。
首先我們一定要再次確認一下，我們的方案是否是用來解決我們已經定義出的痛點問題的，以及方案的複雜度是否是根據我們上面講到的幾個維度去考慮所得出的結論。如果這兩點不滿足，請你先自己反思一下。如果依然覺得是正確的，那下一步就是把推導的依據和思考做對焦，看是否有一些誤判在裡面。
經過這些步驟，我們至少能確認方案本身是具備合理性的。那這裡除了方案本身的複雜度是否合理之外，就還有一個“時機”的問題。有些時候你發現了 規模因素、成本點，但是有些情況是在很長一段時間內其實並不會發生增長，這時候你過早地做了方案，一方面可能會因為業務變更被廢棄，另一方面可能也並看不太出效果。就像 1+1 的運算，執行 1 次和執行 10 次，對於現代 CPU 來說感受不到區別。
時機這個問題本身又涉及了“遠見”，有時候我們是把未來的投入提前到了現在，從而減少整個時間軸上的整體投入。我們可以先把這方面的考慮嘗試和合作方溝通，看是否能達成共識。如果對方比較短視（可以考慮不合作，需要與 TL 對焦），或者有時間上的硬指標，那我們就需要看看是否能得到更多的資源投入。一方面可以是可以自己主動多投入一些幫助自己成長，一方面是和 TL 溝通，看看團隊中是不是這個事情更有價值，來投入更多的同學去一起完成。
就像是條條大路通羅馬，今天你可以自己雙腳踏出一條小路，但是可能過幾天就雜草叢生，需要重新開闢一條路徑；也可以號召大家建設一條寬廣大道，福惠百世。只要你堅信羅馬永遠是羅馬。
作者：ES2049 / armslave00
文章可隨意轉載，但請保留此原文連結。
非常歡迎有激情的你加入 ES2049 Studio，簡歷請傳送至 caijun.hcj@alibaba-inc.com 。