對象

身在成都小微企業(yè)，前兩天面試深圳老牌金蝶公司。對我這個荒廢了三年光影的人來說，怎一個跨度之大了得？作為人我生第一次面試的，整個面試過程，只能用詭異來形容這次感受。而結(jié)尾也是迷迷糊糊中草草收場。

不是很好的開局

我我畢業(yè)就進(jìn)了國企。畢業(yè)前，在我想象中，他是一個偉光正的形象。所以我抱著人生值得，未來可期的想法進(jìn)去了。結(jié)果不懂事的我被暗中轉(zhuǎn)了外包。之后那就是段黑暗中的日子了。一個書記負(fù)責(zé)畫大餅及洗腦，一個負(fù)責(zé)催加班。主打一個職責(zé)分離，找人時方便推卸責(zé)任。而工資也是入職以來一動不動的8000多，我也因此悲觀，頹廢了三年，感覺受到了欺騙，怎么是這樣的？世界觀崩塌了。整天就是行尸走肉的上下班，沒話可說，就這樣略去吧。

算了，學(xué)習(xí)其他的去了

這基本是我下班后唯一的學(xué)習(xí)和值得說的地方。生活總是先使人絕望，又去點燃人的希望，又讓人失望，再讓人希望，反反復(fù)復(fù)，這樣來訓(xùn)練我的認(rèn)知。作為工科生的我，關(guān)于自然的科學(xué)知識和計算機知識學(xué)了一大把，但關(guān)于人的社會知識卻沒有學(xué)。不知道社會險惡，所以碰到點事就繃不住了。

因此我進(jìn)公司幾個月之后，就伙著同事，和上級鬧情緒，搞串聯(lián)，搞曠工。不過我們在專業(yè)的書記面前搞這些，豈不是太嫩了點？我在這期間讀列寧的《帝國主義是資本注意的最高階段》，《資本論》第一卷。還專門跑到中馬庫讀了很多小冊子，工人小說。后來又向前，讀更早的盧梭的《社會契約論》。這時的我更像是在無力的臆想，精神可嘉，戰(zhàn)斗力拉跨。但遭受打擊卻催發(fā)了其他的東西。讀社會學(xué)怎么能不讀哲學(xué)？

完敗的我又跑去讀哲學(xué)，《讀西方哲學(xué)史》，讀《理想國》，留意智者和形而上學(xué)的針鋒相對的觀點，現(xiàn)在看來都不無道理。略過中世紀(jì)，從笛卡爾的我思故我在開始了解，到后面形而上學(xué)的終點，讀《純粹理性批判》、《實踐理性批判》、《判斷力批判》，《精神現(xiàn)象學(xué)》。最后到了理性的崩塌后的三個解決方案，馬克思的異化理論、尼采的超人、弗洛伊德的精神分析。把馬克思和之前的哲學(xué)史串聯(lián)了起來。

從馬克思的《1844年經(jīng)濟學(xué)哲學(xué)手稿》開始又轉(zhuǎn)到經(jīng)濟學(xué)。從古希臘的奴隸經(jīng)濟開始，到中世紀(jì)的莊園經(jīng)濟，再到近代的資本主義。從英國重商主義開始，讀托馬斯孟的《貿(mào)易論》《論英國本土的公共福利》，到法國重農(nóng)主義，讀《獻(xiàn)給國王和王后的政治經(jīng)濟學(xué)》。最后到古典政治經(jīng)濟學(xué)，讀英國威廉配第的《政治算術(shù)》、《獻(xiàn)給英明人士》、《賦稅論》、《貨幣略論》、法國布阿吉爾貝爾的《法國詳情》、魁奈的《經(jīng)濟表》、亞當(dāng)斯密的《國富論》、李嘉圖的《政治經(jīng)濟學(xué)及賦稅原理》、最后到了西蒙斯第的經(jīng)濟危機理論結(jié)束。
最后，當(dāng)然就是馬克思的經(jīng)濟理論了。這場經(jīng)濟學(xué)冒險也讓我經(jīng)濟學(xué)歷史串聯(lián)了起來。

走了算了

我人生加起來也沒讀過這么多書，遇到這么多針鋒相對而又各自明智的觀點。正印了那句“人是萬物的尺度”。我說不出具體的影響，但沒有這些知識，我可能還在渾渾噩噩。

到了去年過年，幾個親戚兄弟碰到一起，頓時激起了我的心思，社會形勢惡化不可逆轉(zhuǎn)，公司待遇惡化不可逆轉(zhuǎn)。人生沒有反途，不能在這坐以待斃，死耗下去了！

于是我今年過年后就開始努力學(xué)習(xí)，沒有一天荒廢。爭取把這三年落下的技術(shù)追回來。這樣從2月份到7月份，5個月時間，每天晚上4個小時學(xué)習(xí)，周末24個小時的學(xué)習(xí)。平時和同事暗中比較，技術(shù)已經(jīng)超過不少了。是時候走了，離開這個傷心之地了。他們有家庭，這份工還算能糊口，而我沒家庭牽掛，只剩下點技術(shù)，這里又缺少磨練和實踐，久了技術(shù)就忘了，走了。

面試

面試以騰訊語音會議的方式開始，時長大概40分鐘。聽聲音，是一個中老年人事，一個中青年技術(shù)。

首先是讓我 自我介紹 ，我之前總結(jié)了一段自我介紹，基本上照著念了一遍。這是我第一次面試，很緊張，感覺聲音有點發(fā)抖。沒有任何反映。

然后讓我 介紹一下平時怎么工作的，在團(tuán)隊中扮演的角色 。我對著準(zhǔn)備的資料，回憶著總結(jié)了一下日常工作以及面對新項目時的組織小組工作方式。沒有任何反映。

接下來問“ 你的工作經(jīng)歷和項目中遇到過哪些難題 ”。我說了一下剛開始那段時間用 XSLT 生成doc文檔，然后合并的經(jīng)歷。然后技術(shù)人員就問我假如我有20個文檔，要合成四個怎么辦？我蒙了，我們那是一個資料文件，要存檔的，分成四部分干什么？我提出了疑惑，他還是堅持問，并說，20個文檔合成4個，每5個合并成1個，最后四個怎么合并。我想了一會兒，我就說，你是想說多線程的問題嗎？那就線程同步唄。不過我們一般都使用異步，而不是多線程。我感覺他沉默了一下，不知道是不是記錯了。
然后最近還遇到一個內(nèi)存泄漏的問題，我起先以為是托管內(nèi)存泄漏，但用內(nèi)存診斷工具又沒發(fā)現(xiàn)異常。到現(xiàn)在也沒解決，只能一段時間就重啟。我在這方面也不懂太多。（這個我是真想找那個.net高級調(diào)試 一線碼農(nóng) 去問下）

他說那 你說一下多線程的異步的區(qū)別 。我就說異步是語法糖，會翻譯成狀態(tài)機，最后用線程池里面的線程執(zhí)行。多線程則是創(chuàng)建了一個新的線程。他問異步怎么回到原來的線程？我又懵了？為什么異步要回到原來的線程？（可能他是想問同步上下文？或者是他想問一發(fā)即忘和阻塞式的調(diào)用方式？）我就說異步方法碰到耗時任務(wù)后，原線程就返回最上層的同步方法繼續(xù)向下執(zhí)行了��？而異步方法中的代碼會有新線程來接手（用并行堆棧工具可以觀察到這個過程），為什么需要返回原來的線程？這整個異步方法都會被交給新線程。這樣可以避免原線程阻塞（控制臺中才需要手動配置任務(wù)返回原線程。只有更新ui才需要返回原線程，但WPF中任務(wù)會自動返回原線程，但這也不需要我們特別指定�。浚┮驗樗�始終不正面提問，我始終不知道他想問什么？這就是面試的方式嗎，詭異。

他然后問我看里 簡歷里面寫你們用webform和mvc,那他們有什么優(yōu)缺點 ？我說我們用的不多，只中間用了一年，后面就轉(zhuǎn)向webapi加web項目了。他又問，那 什么是前后端分離 ？我又懵了？這怎么回答？我想，后端寫webapi，前端寫html和js，js請求后端接口的數(shù)據(jù)刷新頁面，標(biāo)準(zhǔn)的web開發(fā)流程，這還要回答什么？我就說不明白你的意思。我感覺他又沉默了。他到底想問什么呢？也許webform和mvc是用的服務(wù)端組件和razor，而webapi+html不用？這有什么可說的嗎？難道他不是這個意思？好奇怪��？

我看你簡歷寫了redis，redis是怎么緩存的？ 我說我們主要是緩存主要用memorycache,redis還是主要用來存一些實時數(shù)據(jù)。我的話就是當(dāng)時做一個簽到的接口，因為短時間內(nèi)訪問量可能比較大，所以把redis作為消息隊列,用來削峰。（他是想問有哪些數(shù)據(jù)類型嗎？）

他又接著問，MVVM是什么？ 這下我激動了，就說MVVM的好處是增加了一個視圖模型VM，可以為UI建模，如何為UI建模，這是之前建模方法中沒有見過的。而UI易變，MVVM可以讓UI的變化不會影響到VM和Model。（也許還應(yīng)該加上VM利于測試？我一緊張就忘了，不過我們到現(xiàn)在都沒寫過正規(guī)單元測試，存疑）

他問VM如何跟UI通信 ，我說是通過命令command。他問 具體是怎么通信 ，我一時間沒想明白，問是不是調(diào)用和傳參。他說都講一下。然后我說調(diào)用是通過datacontext（xaml文件在訪問時通過構(gòu)造函數(shù)那句InitializeComponent代碼被實例化了，VM可以在這個過程中實例化，也可以通過構(gòu)造注入到這個對象中，因此VM是通過委托調(diào)用的。一緊張也忘了說出來）

然后他問界面的數(shù)據(jù)變化怎么通知到后端 。我說是INotification這個接口（實際上叫INotifyPropertyChanged）。他問具體怎么通知的？我想，界面的屬性是依賴屬性，通過將數(shù)據(jù)存到統(tǒng)一的一個私有靜態(tài)屬性中，通過屬性去訪問這個值，所以能知道數(shù)據(jù)的訪問。但是不是所有屬性都是依賴屬性啊。INotification接口原理沒搞清楚，沒回答上來。

然后人事問我， 你們加班情況怎么樣 ，我說我們是半個國企，很少加班。

面試差不多這就結(jié)束了。然后人事問我，你還有什么想問的嗎？我想好多都答得不好，估計沒戲了。就說沒什么想問的。結(jié)束得非常急迫，半分鐘不到。
至此，面試結(jié)束。

后續(xù)總結(jié)

• 第一個沒答上來的問題是前后端分離是什么
  這怪我不識廬山真面目，只緣身在此山中。基本上沒有寫過以前的面條代碼，一直都是前端后端分開寫。結(jié)果就忘了什么是前后端分離了。這里應(yīng)該是要談web的歷史。最開始只有靜態(tài)html文件。服務(wù)器就是去去文件，然后返回報文。到了動態(tài)網(wǎng)頁時期，因為后端接口返回的http報文，靜態(tài)網(wǎng)頁文件也是服務(wù)器響應(yīng)的http報文，所以是可以代碼拼字符串，設(shè)置content-type來模擬一個靜態(tài)文件的，這個時候只有后端。再后面一點有了模板引擎，razor，webform之類的，前端可以寫一些HTML+js了，但還是后端代碼生成網(wǎng)頁需要的靜態(tài)文件。而現(xiàn)在有了xhr和fetch,一般都是前端后端各寫各的。以后用blazor還是要回去。

• 第二個沒答上來的問題是wpf中INotifyPropertyChanged的原理
  從寫法上來看，繼承INotifyPropertyChanged接口的VM具有一個事件

  public event PropertyChangedEventHandler PropertyChanged;
  
  PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
  

  然后在屬性set中，觸發(fā)了此事件。到這里為止還是很好理解。那么應(yīng)該是UI元素綁定到這個屬性時，訂閱了此事件，所以才能接到通知并更新界面。UI元素有個SetBinding方法，應(yīng)該是實例化xaml文件時，遇到了 {Bingding} 標(biāo)記，這個SetBinding方法于是被調(diào)用，才建立了UI元素依賴屬性和VM的CLR屬性的binding關(guān)系。然后 Binding 會偵聽實現(xiàn)了這個接口的對象的 PropertyChanged 事件。這個對象更新屬性時，clr屬性中set中主動觸發(fā)了此事件，然后Binding偵聽到此事件，更新UI元素。
  如果他又追問binding監(jiān)聽了這個事件是怎么取到數(shù)據(jù)，并傳遞給UI，通知UI變化的？我還要研究一下這個問題。
  這個也比較簡單，因為就是事件訂閱，然后通過反射取數(shù)據(jù)源的值。

  internal class MyBinding
  {
  	/// 
  
  	/// 這一般是UI元素的屬性
  	/// 
  	public DependencyProperty dependency;
  	public PropertyPath path;
  	/// 
  
  	/// 一般是UI元素
  	/// 
  	public DependencyObject dependencyObject;
  	public object source { get; set; }
  
  	public MyBinding( DependencyObject dependencyObject, DependencyProperty dependency, object source, PropertyPath path)
  	{
  		if (source is INotifyPropertyChanged inpc)
  		{
  			inpc.PropertyChanged += new PropertyChangedEventHandler(OnPropertyChanged);
  		}
  		this.source = source;
  		this.dependency = dependency;
  		this.path = path;
  		this.dependencyObject = dependencyObject;
  	}
  
  	private void OnPropertyChanged(object? sender, PropertyChangedEventArgs e)
  	{
  		//數(shù)據(jù)源可能又多個屬性被綁定，檢查是不是綁定的那個屬性發(fā)生了變化
  		if (e.PropertyName==path.Path)
  		{
  			dependencyObject.SetValue(dependency, sender.GetType().GetProperty(e.PropertyName).GetValue(sender));
  		}
  	}
  }
  

  我來測試一下

  TextInfo textInfo;
  public MyBindingTest()
  {
  	InitializeComponent();
  	textInfo = new TextInfo() { Text = "TextInfo" };
  	MyBinding myBindin = new MyBinding(this.text, TextBlock.TextProperty, textInfo, new PropertyPath("Text"));
  }
  
  private void btn_Click(object sender, RoutedEventArgs e)
  {
  	textInfo.Text = "newValue";
  }
  

  
  不同之處在于wpf的綁定時基于弱事件而我這里是 += 。我的 MyBinding 類沒有繼承 MarkupExtension ，所以沒法被xaml解析。但這里暫時不研究了。

• 第三個沒答上來的問題，Redis是怎么緩存的 ，這問到我的知識盲區(qū)了。我下來去網(wǎng)上搜了一下。Redis緩存有3種模式

  • Cache Aside（旁路緩存）: 旁路模式在讀取取時，優(yōu)先取緩存，沒有再取數(shù)據(jù)庫并刷新緩存。寫數(shù)據(jù)時則更新數(shù)據(jù)庫，再刪除舊緩存。
    這個模式其實我們MemoeyCache做緩存時也是這么干的，只是忽略了寫的操作，不知道這叫旁路模式，給緩存設(shè)置了過期時間就完了。這種模式缺點是存數(shù)據(jù)和刪除緩存之間時間段內(nèi)讀的數(shù)據(jù)和實際的不一致。
  • Read/Write Through（讀寫穿透） 的改進(jìn)是搞了緩存中間層，代替應(yīng)用訪問數(shù)據(jù)庫。再中間層中進(jìn)行數(shù)據(jù)庫讀寫。并且在寫數(shù)據(jù)的時候，以事務(wù)的方式更新緩存和數(shù)據(jù)庫，避免數(shù)據(jù)不一致。缺點是更新數(shù)據(jù)庫這段時間，其他讀緩存的阻塞了。
  • Write Behind Caching（異步緩存寫入） 在讀寫穿透的基礎(chǔ)上取消了事務(wù)，寫數(shù)據(jù)時優(yōu)先更新緩存，并在之后異步的更新數(shù)據(jù)庫，這樣解決了寫數(shù)據(jù)這段時間里，讀緩存阻塞的問題。但缺點是寫入數(shù)據(jù)庫之前有人訪問數(shù)據(jù)庫的話，數(shù)據(jù)實際是不對的。

• 第四個沒答上來的問題是webform和mvc的優(yōu)缺點 ，說實話，我兩者都沒怎么用過。對webform的了解限于知道開發(fā)起來像winform，有服務(wù)端組件和視圖狀態(tài)。開發(fā)起來很快。缺點是WebForms傾向于生成較為笨重的HTML和ViewState，這可能會導(dǎo)致頁面加載速度慢，而且調(diào)試復(fù)雜，不靈活。但我們實際用webform的時候都是一般事件處理程序 ashx+aspx.cs后臺事件+ajax 突過去得了，沒想過這玩意。也許我該做個demo看看了。
  MVC里面我還是第一次接觸到路由，這玩意確實比原來的webform那個路由方便。還有是實現(xiàn)了視圖和模型關(guān)注點分離�？梢砸欢ǔ潭壬锨昂蠖朔蛛x。其優(yōu)點對于不熟悉的人同時也是缺點。
  不管怎么說，這兩個框架都是表現(xiàn)層框架，主要精力還是集中在UI上。

• 面試觀點
  我和同學(xué)說了這事，他說我碰到的面試可能是喜歡聽聽你的知識面，然后挑著問的類型，掌控方在我手里。而不是那種面試官需要明確面試者掌握了哪些知識，固定提問的類型。要發(fā)散思維，展示你的知識面。
  他問了你很多自學(xué)的東西，這種記得不牢固是正常的。
  還有，問你工作經(jīng)歷那里讓你繼續(xù)說是感覺還好，應(yīng)該繼續(xù)下去�？梢曃铱偨Y(jié)的不夠，反而說不下去了。
  他問你現(xiàn)在的加班情況，是考慮你能不能適應(yīng)。像我這種回答人家未必會考慮。
  關(guān)于工資，金蝶寫的是15-30K，像你這種3-5年的應(yīng)該18-20K。但是我現(xiàn)在這家奇葩公司月薪才8900啊，就算加年終獎也才一萬，我怎么敢想。而且我之前幾年一直沒考慮過離職，也不知道自己在人力市場上應(yīng)該要多少，我說不出口。

追加

• 前后端分離是什么意思
  看了 @過錯 的評論，我上網(wǎng)去搜了一圈�？偨Y(jié)出這樣一段話。

  職責(zé)分離并非一個具體的設(shè)計模式，而是一種設(shè)計原則
  職責(zé)分離（Separation of Concerns，SoC）雖然不是嚴(yán)格意義上的設(shè)計模式，但它是軟件工程中的一種重要設(shè)計原則或思想。
  它指的是將一個軟件系統(tǒng)分解為不同的部分，每個部分解決特定的任務(wù)或關(guān)注點，從而降低系統(tǒng)的復(fù)雜性并提高可維護(hù)性。
  具體來說，職責(zé)分離強調(diào)以下幾點
  單一職責(zé)原則（Single Responsibility Principle，SRP）：一個類或模塊應(yīng)該專注于實現(xiàn)單一的功能或職責(zé)。這樣做不僅使得代碼更加清晰和易于理解，而且在需要修改時也可以降低影響范圍，減少引入錯誤的可能性。
  職責(zé)分離的實現(xiàn)可以依賴于多種設(shè)計模式，例如：
  MVC（Model-View-Controller）：將應(yīng)用程序分為模型（數(shù)據(jù)和業(yè)務(wù)邏輯）、視圖（用戶界面）和控制器（處理用戶輸入和調(diào)度任務(wù)），實現(xiàn)了職責(zé)分離和代碼重用。
  MVVM（Model-View-ViewModel）：在WPF和其他現(xiàn)代UI框架中使用的一種模式，通過數(shù)據(jù)綁定將視圖（View）與視圖模型（ViewModel）分離，使得UI設(shè)計和業(yè)務(wù)邏輯分開。（這確實和 @過錯 所說不差）

  前后端分離看起來是符合單一職責(zé)原則的軟件設(shè)計