往期干貨筆記整理

0x00

最近高考不是剛落下帷幕嘛。每年高考一結束，怎么選專業，怎么填志愿就成了熱門話題。

去年幫老家那邊兩個親戚家小孩參考過志愿，今年也接到了老家幾個叔嬸的電話。雖說寫這篇的時候分還沒出，但是家長比小孩還急呀，也各種打聽，各種調研的。

去年是一個去了計算機，一個去了師范。今年估計家那邊兩個小孩應該也會填計算機(或相關)吧，學的理科。

當然這不是說我推薦他們填計算機。我個人始終覺得興趣很重要，但是一問有沒有興趣專業，都說沒啥明確目標，希望填個熱門好就業的。況且現在互聯網這么發達，小孩們自己一查，也知道這幾年計算機火，然后也詳細調研一些有關計算機的情況。孩子們關心的就是好不好學，家長關心的就是好不好就業。

但是我會建議說沖一沖、穩一穩、保一保。能沖進計算機相關專業當然沒問題，但如果投檔進不了，那通信/電子也不是不可以，保底嘛。

0x01

我至今依然覺得工科類專業是對我們這些普通家庭出身的理科生比較友好的選擇吧。沒有什么太高壁壘，你有技術就有機會，學完最起碼有點實用的技術傍身。

只要你有興趣學，選這個一般沒啥問題。當然這個興趣不是說要特別特別地強，有時候不討厭也是一種興趣。

尤其是計算機相關專業，這幾年的確是工科界的頂流。

首先大家都知道工資高。稍微好一點學校出來的應屆畢業生，在北上廣深一畢業年薪拿幾十個基本都沒啥問題。所以學計算機出來一定是可以滿足我們安身立命，反哺家庭，以及對未來美好生活向往的目標。我盤點了一下自己熟悉的同學也是，通信/電子/計算機這一塊的，發展得也都還可以。因此選計算機專業確實也比較迎合市場。

另外一個，個人感覺計算機的學習門檻好像不算高吧。一般來說理科出身，具備點邏輯思維，一般都能學得不差。況且計算機的各種學習資源不要太多，開源世界也很豐富，網上都能找到，沒有什么明顯的學習壁壘，有一臺電腦就能學。而且付出與回報成正比，也不拼其他的，就純靠技術了。

所以可能也正因為這些方方面面的原因吧，現在報計算機的人實在太多了，那叫一個火。除了高考志愿填計算機的，還有轉專業到計算機的，考研跨考計算機的，工作后轉行從事計算機的，甚至包括培訓班培訓計算機的...所以我也會跟他們說壓力和競爭是不小的，要有心理準備。

0x02

聊到卷的問題，從兩個最常見的點就能看出來，一是考研，另外一個就是找工作的面試難度，我想很多小伙伴可能有親歷體會。

現在考研不僅是計算機，但凡熱門一點的工科專業壓力都大。我們那時候考研多少分？300出頭就有學上?，F在看看呢，好點學校的計算機相關專業400分神仙打架的多的很，報的人多，大神也多。

而聊到求職面試。以前背一背八股文，然后刷刷題，找個還行的工作沒啥問題。什么叫八股文呢？就可以背的，比如像什么OOP特性、接口和抽象類的區別、原理、List和Set區別、Java運行時內存區、Get和Post請求、三次握手四次揮手、OS頁面置換算法...等等，大家可能也背過。

然后刷題，我們那時候劍指上四五十個題目刷完基本就可以保個底，我記得好像也沒有現在這么多題目吧。

但是站在當下的時間再看一看面試都問啥。

問底層，深入到骨髓。像什么JVM底層原理、JVM調優實踐、JDK源碼、JUC并發包、鎖的實現原理、數據庫底層原理、索引優化、SQL調優、源碼、各種框架的機制，然后還有像什么集群、分布式鎖、緩存一致性...等等一些問題也是被高頻地問起。

然后就是問項目。要么就是往底層挖，最后也是底層原理，像上面一樣，要么就是往架構層面上升，比如架構設計、框架選型、鏈路設計、架構擴展...等等。

除了這些還有手撕算法題。現在求職沒個幾百道題量，怕是連筆試都很難找到感覺吧，面過的小伙伴一定有所感受。

所以現在自學，包括面試準備的時候，真的不是說背一背八股文，會用個 Boot， 就可以的。比較值錢的兩個方面剛也聊過：

而這些一般是需要理解并實踐的。

況且個人明顯感覺身邊的應屆生計算機素養普遍很高。不管是是面試的時候，還是工作后觀察身邊的一些新人。除了本身計算機方面思維很好，學東西賊快之外，而且還特別年輕，精力也旺盛，難頂哦。

所以基于這些，我也會跟家那面填志愿的小孩說，隨大流無腦梭哈計算機也不行。想報可以，首先要有心理準備，能Hold得住壓力，其次就是對這個東西要有點興趣（最起碼不討厭吧），最后還得有很強的自學能力和習慣，不然就算進去也很痛苦的。

0x03

然后一個問題就是關于編程難不難的話題？這是老家那邊幾個同學最近在調研專業的時候所共有的問題。

編程難嗎？其實這個問題真不知道怎么回答。

個人感覺計算機的學習門檻應該不算高吧。都是學理科的，具備一點邏輯思維一般都還行吧。當然這里不是說那種學到極致的天才型選手，我們指的是學個一般，做個普通開發的角度來聊的。

就以最常見的編程工作為例吧。它對人的思維能力是有點要求的，其實簡單一點理解，差不多就是分析問題，然后抽象出要素，最后建立模型的思維過程。如果覺得編程難，或者說代碼無從下手，那大概率可能還是沒有形成這種思考方式吧。說明首先基礎可能有待加強，另外則是可能鍛煉得還不夠多，沒有突破那個閾值。

尤其參加工作后，做的那些系統和各種業務。其實講白了就是把一個個實際需求抽象建模，用合適的數據結構和算法流程把它表示出來，然后輔助于一些框架或者工具，用編程語言把它描述出來，然后經過一系列處理，最后交由計算機執行。

先把功能實現，流程跑通，然后再考慮怎么才能做得更快，怎么才能并發更高，怎么才能更加安全。我們可以回想一下，項目里那些復雜的系統往往不都是這么演變過來的嘛。

所以很多剛入職的小伙伴所頭疼的一個問題就是說剛入職團隊，剛接觸實際項目，項目太大了，一時半會搞不懂吃不透。

為啥呢？因為這里面很多的演進和迭代過程，你并沒有看到。其實一開始系統沒那么復雜的，只不過后面迭代了好多個版本，改了很多東西，又加了很多東西。這時候如果沒有比較靠譜的迭代記錄，文檔，或者注釋，的確是很難看懂，太正常不過了。所以這時候只能靠自己多問，多想，多悟，上下文/前后段，由整體到局部，由局部再到整理，就這么來回反復摩擦，慢慢就吃透了。

所以有時候想一想，好像事情也沒那么復雜。但是你又想過沒，為什么現在的互聯網開發世界那么繁榮呢？尤其之前我們在梳理像大數據、后端開發那些知識點和學習路線時，涉及到的各種技術點和框架實在太多了。

其實細想一下，它們很多時候都是在做輔助用的。它們的出現很多時候都是為了應對企業級應用開發的所面臨的的諸如復雜性、代碼質量、可測試性、可擴展性、可維護性等一系列問題。一句話總結，都是為了更好地工程化迭代。

舉個例子可能更好理解一些。比如做Java后端開發的用框架很多，其實我們在寫這些Web化服務時，不用也完全可以。用樸素的方式也可以寫，這樣的話不同人都自己去造輪子，自己去封裝工具類，封裝自己的工具方法，也沒問題，能完成需求。

但是這時候因為不同人的思維方式不同，習慣不同，能力也不同，大家寫出來的代碼很有可能參差不齊，質量不一，那就很難達到企業級開發所講究的那些代碼質量、可測試性、可擴展性、可維護性、可迭代性。這樣寫出來的項目后面可能不好維護，沒辦法長期迭代演進了。

而這些框架它們內部用到了很多的機制，實現了很多的工具類，方法，以及流程，自己也規定了很多約束性寫法，給開發者或暴露API，或暴露接口...其實某一程度上來說都可以理解為提供了一種約束性編程。你要用我的框架？可以。那你就得遵守我這邊的游戲規則（編碼規則）。典型不就是這樣嘛，IoC容器用來干嘛的？方便管理對象，然后還搞了一堆像什么切面式編程、接口式編程、聲名式編程...等等，我們就可以理解為一種約束性的編程。這樣才能保證寫出來的代碼，在完成需求的同時，還能便于測試、擴展、維護、甚至便于和其他技術進行集成，來創造業務價值。

不過寫到這里，好像扯得有點遠了，時間也不早了，以后有機會再聊吧。

我們明天見。

往期干貨筆記整理