之前在群裡參加活動的同學，有不少說在小公司，被業務需求壓著。既然大家都說在做業務，那麼，正看到這裡的你，能不能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傳送？如果需要登入鑑權怎麼辦？如果出現跨域問題怎麼辦？兩種場景都有，都要實現，怎麼封裝元件？
任務的拆解
對於平時願意學習的同學，到這一步可能開始陷入迷茫了，我之前也遇到過類似的困惑，那就是：要不要造輪子
我們經常會發現好像什麼都能做，比如：你有的，我改改也能實現；社群有個差不多能用的，要不要直接用；好像大圖上都有差不多的，那是不是拼拼湊湊就可以了，這個方案是不是沒什麼好做的了。
從我個人來說，每次畫圖我都會陷入這樣的思考，還常常會鑽牛角尖，為了整點差異化，故意換一些思路去做，這樣能保證這個餅是我的。但最後我都會繞出來，這得益於上面畫圖的第三步，每次畫完我都會重新回顧一下我真正想做的事情是什麼。我認為這也是是否造輪子的乙個評判標準：從業務的價值出發，思考真正核心的目標，並且為之努力，如果有現成的輪子，能滿足業務核心訴求，那就放手去用。
首先，現實往往是這樣的，當我們放手去用的時候，會發現這個輪子好像不那麼好用，或者這個輪子沒人維護了，又或者業務變化太快，輪子自己覺得頂不住了。機會自然會來到身邊，而觸發這些機會的，是我們不斷的站在業務的視角去思考問題，業務的變化一定比乙個平台化的輪子要來得快。
其次，真正核心的系統一定是緊貼業務，而且很難大範圍復用的，好的技術架構在設計的時候，講究的是夠用即可，過度設計大部分就是沒用的設計。在之後的迭代中，會隨著業務的不斷變化，被帶動著自我進化，那最終的產物也自然是和業務形態非常貼合。所以，我個人在選擇的時候，一些核心的輪子，該造就造起來，但這些輪子一定是帶有業務特色的，比如我會去造乙個業務元件庫，但是我絕不會去造乙個antd。
最後，隨著事物的演變，分久必合合久必分，單一業務用的好的系統一定是可以在更高的視角上抽象、整合的，在整個過程中，每個人的成長就會是我們想要的亮點了。或許在簡歷上你寫下的是乙個已經廢棄的系統，但是它的靈魂在你心裡，也存在於把他整合了的系統裡，這種亮點在個人介紹的時候，一定是能侃侃而談的。
終於，我們經歷的各種抉擇，投入了大量的時間，把乙個亮點做出來了，完成了美好的從0到1，可有時候我們會發現的問題：從0到1看上去有很多要做的，做完了，從1到10還能做什麼？
這個問題我個人也沒有太多話語權，因為這兩年總是在做從0到1的事情，甚至和我老闆也聊過這個，總感覺自己沒有個確定的事情。從0到1做一次挺爽的，一直做，不會一直爽，卻只會讓人覺得心慌，畢竟誰能保證永遠能想出從0到1的事情呢？
而靜下來反思之後，我發現事情並不是這麼一刀切的，誰能說明白現在做的事情是0到1，還是1到10呢？這裡的邊界其實並沒有那麼明確，但抽象看，他們都是同乙個套路
業務/技術思考 => 發現痛點 => 產出方案 => 拆解實現
伴隨著這個閉環，業務永遠在變化，而變化又會帶來新的問題，只要保持乙個思考的狀態，沒有必要區分具體再哪個階段，因為你總能找到可以實現自我價值的地方，發現屬於你的亮點。
如何在Vue Element專案中配置國際化
vue i18n 1 建立i18n資料夾 在專案根目錄，即src目錄項建立i18n目錄，此目錄下用於存放多語言的翻譯如zh.js儲存中文翻譯,en.js儲存英文翻譯，id.js 儲存印尼語等。en.js export default zh.js export default 2 建立preset資料...
如何在java web專案後端專案中獲取路徑
1 獲取類檔案下的絕對路徑 youclass.class.getresource tostring replaceall file 2 獲取專案路徑 getservletcontext getrealpath 3 獲取類檔案路徑 this.getclass getclassloader getres...
如何在專案中設定使用GDataXML解析類庫
2.解壓縮檔案，找到source xmlsupport，並且將其中的gdataxmlnode.h 和 gdataxmlnode.m檔案拖到專案中 3.選中專案，選中 build settings 標籤頁 4.將build settings頁中，頂部的 basic 標籤切換到 all 5.找到 pat...