最好的技術(shù)就是你現(xiàn)在做的技術(shù)

有讀者今天問了我一個(gè)問題，覺得研究的技術(shù)在工作中都用不上，工作上主要都是寫些 if else，跟那些高并發(fā)、分布式都不沾邊，這種情況應(yīng)該怎么辦？

我想到了我早先剛參加工作沒多久，那時(shí)候還在外包公司，在江蘇某家銀行駐場(chǎng)干活，做的項(xiàng)目就是用 ECharts 報(bào)表 + 幾個(gè)前端頁(yè)面寫可視化大盤，前端用的是jQuery，后端還用的 Servlet，沒用Spring，部署也沒有什么 Jenkins 這種打包部署，直接Eclipse 編譯成 war 包，丟到 Tomcat 的web目錄，而且那時(shí)候還是單機(jī)部署，連主備都沒用，因?yàn)榫褪强梢暬瑥臄?shù)據(jù)庫(kù)查查數(shù)據(jù)，然后展示在頁(yè)面上，前端寫個(gè)每隔5 秒定時(shí)刷新，跟核心系統(tǒng)毫無(wú)關(guān)系。

當(dāng)時(shí)我記得遇到的最大的技術(shù)挑戰(zhàn)還是自己作死，不用成熟的框架，自己手寫了個(gè)數(shù)據(jù)庫(kù)線程池，發(fā)布之后運(yùn)行一段時(shí)間就報(bào)數(shù)據(jù)庫(kù)連接不夠了，開始排查，那時(shí)候技術(shù)還是很青澀的，解決問題的辦法就是百度，然后各種嘗試，看代碼數(shù)據(jù)庫(kù)連接也都釋放了，修改了之后重新發(fā)布，然后運(yùn)行一段時(shí)間之后還是報(bào)連接數(shù)不夠，最后費(fèi)了很大勁，后來(lái)具體怎么解決的已經(jīng)忘了，但是這個(gè)問題讓我開始決心好好研究當(dāng)時(shí)用的DB2數(shù)據(jù)庫(kù)。

我就開始深入了解DB2 的原理，在網(wǎng)上找DB2 相關(guān)原理的資料看，我后來(lái)又自己寫了一些跟DB2 打交道的代碼, 自己有了一些常用的DB2 的工具包，非常簡(jiǎn)陋的需求，加上非常簡(jiǎn)陋的系統(tǒng)，但是還是有問題值得深入了解背后的技術(shù)原理。

講這段經(jīng)歷的意思其實(shí)是想回答讀者說的這個(gè)問題，很多人都喜歡研究一些看似高大上的技術(shù)，但是對(duì)自己日常工作相關(guān)的技術(shù)反倒理解還非常膚淺，比如我問過候選人幾個(gè)問題：現(xiàn)在應(yīng)用使用的容器的啟動(dòng)原理嗎，現(xiàn)在系統(tǒng)模塊為什么這么設(shè)計(jì)，有沒有需要改進(jìn)的地方？了解你系統(tǒng)單測(cè)使用的框架mock實(shí)現(xiàn)機(jī)制嗎，日常遇到的一些項(xiàng)目上的問題，都是什么原因引起的？

我現(xiàn)在面試候選人，不太會(huì)對(duì)分布式高并發(fā)張口就來(lái)的有所青睞，喜歡安安靜靜的看候選人寫寫代碼，一道中等難度的場(chǎng)景題，看邏輯是不是清晰，邊界條件、異常case 是否都能考慮到，是不是在意細(xì)節(jié)處理，遇到問題會(huì)不會(huì)想要了解引發(fā)問題的根本原因。

原因也很簡(jiǎn)單，實(shí)際上在大廠做技術(shù)，尤其是我們業(yè)務(wù)技術(shù)，大部分的場(chǎng)景和業(yè)務(wù)問題都有很成熟的解決方案，比如大促高并發(fā)的一整套方案已經(jīng)非常成熟了，大部分中間件也是自研的，有問題找對(duì)應(yīng)的開發(fā)同學(xué)。

復(fù)雜的往往是業(yè)務(wù)場(chǎng)景和鏈路，現(xiàn)在都是微服務(wù)，你一個(gè)系統(tǒng)可能被幾十個(gè)系統(tǒng)調(diào)用，接口出入?yún)⒁紤]以后的升級(jí)維護(hù)，日常的技術(shù)方案要考慮邏輯的合理性，方案未來(lái)的可擴(kuò)展性，所有可能出現(xiàn)的情況，邊界條件、異常case 是否都能考慮到，這其實(shí)不是一件容易的事情，需要認(rèn)真對(duì)待日常需求的一個(gè)個(gè)技術(shù)方案，是從一次次代碼編碼，重構(gòu)優(yōu)化、解決一個(gè)個(gè)問題，解決再優(yōu)化的實(shí)踐中總結(jié)出來(lái)的。

所以重視你手上的工作吧，從日常工作中學(xué)習(xí)技術(shù)，延伸技術(shù)。