【拓展】642- 前端如何在項目中做出亮點

作者: 磐衝
https://segmentfault.com/a/1190000022795484

你負責的業務是什麼？(學會發現問題)

之前在羣裏參加活動的同學，有不少說在小公司，被業務需求壓着。既然大家都說在做業務，那麼，正看到這裏的你，能不能5分鐘說明白，你負責的業務是什麼？

這個問題我在活動羣的github issue活動中，帶有業務理解標籤的題目裏經常會問到，可是大部分同學都沒有說到位，甚至答非所問。

這裏談談我個人對業務的理解，或許沒有普遍意義，所以僅供參考。

業務最核心的要素是業務本身的價值

一家公司，或者一個部門，做的事情有許許多多，零零散散。也有很多事情合到一起，促成了一件大事的時候。那麼，我們是把那些零散的事情都看成業務？還是隻把那一件大事看成業務呢？我認爲都可以。決定權在於這件事是否邏輯自洽，以及是否具有獨特的價值。

接下來讓我們拿着一個例子來說，假設你在開發一個營銷活動頁，這個頁面能夠給公司帶來3000人的新用戶，這些人有可能會購買公司的產品，從而帶來收入。

這裏明顯可以感受到，營銷是一個業務線，他的商業邏輯是投放頁面 -> 拉新迴流 -> 商品銷售，價值在於新用戶的觸達，以及商品銷售利益。基於這兩點，我們就值得投入精力，因爲做的越好，公司業績越好。

那麼，做個頁面就是亮點了？

當然不是，但是亮點已經離我們很近了。如果你想要有亮點，那你需要保持思考。在上面的例子中，我們有許多可以優化和驗證的事情。

營銷頁每天換內容，怎麼快速替換？
營銷部門人越來越多了，頁面每天要10個，一個人怎麼做得完？
前端的人也越來越多了，改個組件不能只靠複製黏貼，怎麼管理？
拉新迴流效率具體有多高？新人真的有買我們的商品嗎？這麼多人投入，都是要工資的，賣出去的商品能夠發我們的工資嗎？
轉化率低了，怎麼才能提升？
這個按鈕寫錯個樣式到了右邊，居然點的人特別多？那下次是不是都應該放右邊？

上面列舉的幾個問題，估計很多同學日常都有做類似的事情。但問題是，這些事情是你想做的，還是產品讓你做的？這些事情能誕生什麼出來呢？

運營配置後臺與投放策略
營銷搭建體系
工程化研發套件
業務埋點與數據分析系統
數據倉庫與數據分析後臺
A/B test系統

至少在我看來，如果面試的同學上來自我介紹的時候，能夠講一下上面例子中遇到的問題，之後再說做了下面對應的某一個系統，那麼，這就是絕對夠分量的亮點。只可惜這樣的同學少之又少，大部分同學是因爲產品說要做就去做了。

所以，你真的想過業務是什麼嗎？有爲業務想過什麼嗎？有了你，業務有什麼不同嗎？

可以開始寫代碼了？(學會思考的方式)

好了，假設我們思考了一下，想了點東西出來，接下來我們可以開始寫代碼了.....嗎？

做一個有亮點的技術產出，可不是擼起袖子就能快速幹出來的，當然，如果你是個天才，那請自便。如果和我一樣是普通人，那麼請先做好技術方案設計。而設計的第一步，就是做一個ppt工程師，畫圖。

圖，是思想的結晶

在上面提到過的github issue活動裏，大部分同學的業務大圖或者技術架構圖，都沒法說明白先表達的意思。

幾個最典型的問題是：

思路混亂：下面幾個框在寫業務的系統，上面畫了一個vue或者webpack的框。
層級混亂：底層寫的是native容器，上層畫了個api gateway。
答非所問：要求畫業務大圖，結果畫了一堆前端腳手架的關鍵字，或者畫成了流程圖。

如果看到這裏，不明白畫圖是幹什麼的同學，可以去查一下架構圖是什麼，以及如何做程序設計。這經常是被大家忽略的事情，雖然很多同學在大學裏學習的時候，都學過相關的課程，但是估計大部分都還回去了。

怎麼畫好一張圖？

這裏不做具體的展開，畢竟我自己也不是畫圖高手，每次畫圖也是遲遲不知如何下筆。只給到幾個建議，供大家參考。同時，以一個模擬面試同學的案例來做參考。

原圖：

第一步，先想明白這張圖要表達什麼？

這位同學說他參加過很多技術會議，看那些分享的ppt裏面的大圖，都很酷炫，自己平時也有總結(這點非常好)，但是總畫不出那種圖來。面試過程中我問了這位同學，這張圖他想表達什麼，答案是他想說明白消息通信業務的技術方案。但是，這張圖並不能表達出一個技術方案來。

這張圖第一個問題是不夠完整，他只有一條主鏈路，對於IM這樣的複雜技術產品，主鏈路只是冰山一角，如果真的只做了主鏈路，那麼代表思考不夠，早晚會出現線上故障。

第二個問題在於含義不明與層次混亂。最下面的UI層有個箭頭指向存儲層，那是指渲染進程會去調用localStorage？那再向上2級的網關層呢？UI層會調用網關層？這裏顯然邏輯是不通順的。

第二步，圖裏的每一個大塊必須是同一個領域或類似概念的，每一個框都有意義

在這個問題上，這位同學做的還是很好的，但也還是有些小問題，比如UI層裏的兩個進程。這兩個框顯得意義不明，在沒有描述的情況下，至少我是不明白他想表達的意思，而實際在溝通過程中，他也覺得這裏挺奇怪的。

第三步，畫完回顧一下是否描述清楚了第一步裏的核心邏輯

很多時候我們一氣呵成畫了一張大圖，結果一不小心容易畫成一張流程圖，把怎麼寫代碼的思路也畫到圖上了。這就會導致圖上有些地方是模塊劃分，而有些地方則是細節流程，整體就很失調。這隻能通過反覆的回顧和思考，進行自我調整了。

最後，我給出當時模擬面試時，對於這個業務的粗略設想：

知道原理有什麼用？(技術如何賦能)

有了大圖，我們終於可以開始實現亮點了......嗎？

現實很殘酷，哪怕我們想出了一個大餅，並不代表我們能喫到嘴裏，從圖變成麪餅，我們需要太多的中間步驟。而擺在技術人面前的問題是：如果有面粉了，你會揉麪嗎？你揉麪的技術能保證烤出來的餅好喫嗎？

知其然，而後使其然

我認爲這就是爲什麼我們要了解原理。曾經有一位模擬面試的同學，在最後互問互答的時候問了我一個問題，怎麼看待面試造火箭，平時擰螺絲？我覺得有點冤枉，因爲一面大部分問的都是怎麼擰螺絲，以及螺絲的型號，二面開始也就問問怎麼造飛機，但是真的進入工作狀態，阿里的場景裏，至少在我們團隊的場景裏，我們就是在造火箭，只是造火箭的時候必須要擰擰螺絲，沒螺絲你敢上？

有同學又不服了，我會擰螺絲，和我需要知道用什麼螺絲有什麼關係。那麼上面那個烤餅，你能告訴我放白芝麻好喫還是放黑芝麻好喫嗎？我相信大廚一定能回答上來，他甚至連小麥原產地都會和你掰扯一下。爲什麼到了同樣需要匠心的編碼領域，我們就不用關心用什麼螺絲了呢？

當時我給這個同學舉了個實際的例子：簡歷中有提到上傳，那你能不能當場告訴我，這個上傳是服務端http接口配合你上傳，還是用阿里雲oss？用oss是服務端每次加簽，還是用sts，還是前端直接加簽？http上傳你用什麼contentType？用form表單組件提交還是自己通過xhr發送？如果需要登錄鑑權怎麼辦？如果出現跨域問題怎麼辦？兩種場景都有，都要實現，怎麼封裝組件？

什麼？你說你要百度一下？你要百度一天？那我爲什麼不聘用那個不用百度的人呢？一天的工資算上5金這些成本，月薪20k來算，估計也得有小2000了，如果我把這2000增加到一個懂原理的大神手裏，我們豈不是雙贏，爲什麼要等你去搜索呢？只是個簡單的上傳文件功能，也就是頁面裏的一個豆腐塊，這麼小的螺絲，裏面卻有大大的學問。而日常工作中我們遇到類似的問題有非常多，具體可以參考我上一篇文章的解讀，這裏就不重複了。

任務的拆解

對於平時願意學習的同學，到這一步可能開始陷入迷茫了，我之前也遇到過類似的困惑，那就是：要不要造輪子

我們經常會發現好像什麼都能做，比如：你有的，我改改也能實現；社區有個差不多能用的，要不要直接用；好像大圖上都有差不多的，那是不是拼拼湊湊就可以了，這個方案是不是沒什麼好做的了。

從我個人來說，每次畫圖我都會陷入這樣的思考，還常常會鑽牛角尖，爲了整點差異化，故意換一些思路去做，這樣能保證這個餅是我的。但最後我都會繞出來，這得益於上面畫圖的第三步，每次畫完我都會重新回顧一下我真正想做的事情是什麼。我認爲這也是是否造輪子的一個評判標準：從業務的價值出發，思考真正核心的目標，並且爲之努力 ，如果有現成的輪子，能滿足業務核心訴求，那就放手去用。

首先，現實往往是這樣的，當我們放手去用的時候，會發現這個輪子好像不那麼好用，或者這個輪子沒人維護了，又或者業務變化太快，輪子自己覺得頂不住了。機會自然會來到身邊，而觸發這些機會的，是我們不斷的站在業務的視角去思考問題，業務的變化一定比一個平臺化的輪子要來得快。

其次，真正核心的系統一定是緊貼業務，而且很難大範圍複用的，好的技術架構在設計的時候，講究的是夠用即可，過度設計大部分就是沒用的設計。在之後的迭代中，會隨着業務的不斷變化，被帶動着自我進化，那最終的產物也自然是和業務形態非常貼合。所以，我個人在選擇的時候，一些核心的輪子，該造就造起來，但這些輪子一定是帶有業務特色的，比如我會去造一個業務組件庫，但是我絕不會去造一個antd。

最後，隨着事物的演變，分久必合合久必分，單一業務用的好的系統一定是可以在更高的視角上抽象、整合的，在整個過程中，每個人的成長就會是我們想要的亮點了。或許在簡歷上你寫下的是一個已經廢棄的系統，但是它的靈魂在你心裏，也存在於把他整合了的系統裏，這種亮點在個人介紹的時候，一定是能侃侃而談的。