摘要：上次的訪談，介紹了下可愛的依云醬，回憶傳送門。這里簡單地介紹下龍女仆，全名小林家的龍女仆，為什么介紹這部劇呢因為設計獅顏值同學也安利了這部。劇情簡介在獨身又勞累的小林劃重點一名程序員身邊突然出現(xiàn)的穿著女仆服裝的美少女托爾。

上次的訪談，介紹了下可愛的依云醬，回憶傳送門。不知看了上期訪談的小伙伴對依云醬有什么印象，清蒸就一個印象：可愛?？蓯鄣娜撕褪挛锟偸鞘艽蠹覛g迎的，比如，可愛的 Gakki，被 SF 前端小姐姐親切地稱呼為老婆，當然喜歡可愛事物的不止是前端小姐姐，還有清蒸認識的其他程序員 -- 豪大大、傳奇老師等等，今天的訪談的社區(qū)用戶也是一個喜歡可愛事物，混跡 ACG，給他灌一個稱謂：在 ACG 界混的最好的 developer，在 Coding 界混的最好的 ACGer，不服來戰(zhàn)。

有請本期嘉賓：mcfog ?

作為本期的嘉賓，mcfog 兄弟走個流程，先來個自我介紹下吧

大家好，我叫 mcfog，現(xiàn)居上海，悶騷傲嬌屬性，{技術(shù)|動漫|游戲}宅，本身是全棧工程師，近兩年主要做后端方向。比起解決純技術(shù)問題，更擅長的還是抓業(yè)務和技術(shù)的結(jié)合點，語言方面按照個人經(jīng)驗和水平來排的話 PHP >= JavaScript > CSS > 其他吧

清蒸認識幾個程序員都是自帶二次元屬性的，貌似 mcfog 個人主頁也打了一個 acg 標簽，最近可有追新番？有什么推薦嗎？

年紀大了已經(jīng)從追新番退化成追完結(jié)了，今年一月番質(zhì)量實在高，導致現(xiàn)在看四月番都挑不出幾個感興趣的呢，一月番給萌豚推薦「龍女仆」和「加百列」，給非萌豚推薦「昭和」（第一季沒看務必補上）和「獸娘動物園」吧。

這里簡單地介紹下「龍女仆」，全名「小林家的龍女仆」，為什么介紹這部劇呢？因為 SF 設計獅 -- 顏值同學也安利了這部。

劇情簡介：在獨身又勞累的小林（劃重點：一名程序員）身邊突然出現(xiàn)的穿著女仆服裝的美少女托爾。長著犄角和尾巴的她，有著正如龍娘一樣的身姿。說是被喝醉酒的小林邀請到家中來的托爾，在一陣手足無措中居然開始作為小林家的女仆工作…

不知道 mcfog 有沒有收藏什么手辦，可以放幾張照片讓清蒸舔舔屏嗎？

手辦坑太大太深，我完全沒有跳坑的膽量…平時也就弄點小小的周邊宅物，比如這種，如字面意思的天天舔。

我司的前端小姐姐最近沉迷農(nóng)藥不可自拔，不知道 mcfog 你是否也是身中農(nóng)藥之毒？除了農(nóng)藥之外，你更傾向玩哪類游戲呢？

啊，同事都已經(jīng)開農(nóng)藥聯(lián)賽了，被帶著前兩天下載了試玩了，已經(jīng)卸載。從分類上我即使不算 core gamer，至少也是最接近核心的那一撥類型的，一個游戲沒有背后的世界觀、文化背景，同時又沒有真正意義上的競技價值的話，我是完全提不起勁的。哦，只有競技價值的因為我手殘所以也提不起勁

除此之外我的狩獵范圍倒還挺廣泛的，各種各樣的主機掌機游戲基本都有玩，按照 MRU 來算最近最常玩的大概是家里玩屁股和 FIFA，路上玩火紋和塞爾達吧。

我逛了你的個人主站，首頁效果非?？犰?，你的個人主站搭建過程中用到了哪些技術(shù)呢？

就 impress.js，沒了。看到這個庫感覺蠻來電的就拿來搞了個 about 頁面。最后出入 #/overview 的時候 radial-gradient 配上 transition 的效果我還挺滿意的，發(fā)現(xiàn)我源碼沒貼，最近有空更新一波順便把源碼也傳一下吧，有興趣的關(guān)注 mcfog@github 吧。

你在問題：怎么衡量前端達到了什么水平中談到編碼是我們最不重要的工作，思考，歸納，演繹才是我輩本職，該怎么理解這句話呢？

臺上三分鐘， 臺下十年功。作家把書稿寫到紙上也好，歌手在舞臺上演唱也罷，程序員把程序敲到電腦里編譯調(diào)試也罷，都只是最后出成果的那一下而已。作家書寫的好不好看的是他寫書之前的素材、靈感積累，文筆磨練，歌手歌唱的棒不棒看的是他臺下的練習試唱彩排，程序員也一樣，臺下部分的思考、歸納、演繹這些工作才是日常，你看別人，如果只看上機編程熟練無比代碼寫的又快又好，就像你作為一個外行看作家寫的書感人肺腑，歌手唱的歌余音繞梁一樣，那是外行看熱鬧而已。

最近有個小話題【十年的老代碼，你敢動？】，mcfog 你是怎么看待這個問題的呢？你覺得怎么樣的代碼才是優(yōu)雅的呢？

怎么搞老代碼我還真的在有一次團隊分享里聊過，不過那次路徑是反的，先從好代碼長什么樣聊起，最后才提到的老代碼怎么辦。

大概講一下我的觀點吧，“代碼是給人看”這句話的潛臺詞，其實是代碼除了機器要能運行，符合需求之外，需要包含足夠的信息，比如技術(shù)方面的，你的整體架構(gòu)，你的模塊粒度，解耦的邊界，也包括業(yè)務方面的，哪些東西是經(jīng)常變的業(yè)務規(guī)則(夏季大促滿100減25)，哪些東西是偶爾變的參數(shù)配置(類目樹)，哪些東西是業(yè)務上不會變的核心((訂單金額-代金券) * 優(yōu)惠規(guī)則+運費+支付手續(xù)費=支付金額)

優(yōu)雅的代碼就是這些信息高效而規(guī)則的聚集在一起，我知道我想看你怎么承擔高并發(fā)可以直接看數(shù)據(jù)層到最終落地存儲的過程，想看下單業(yè)務邏輯可以去看下單 service 的校驗方法和下單方法等等

因此我覺得最優(yōu)雅的代碼就是能做到很清晰的分成三部分：

第一部分：“業(yè)務邏輯層”里面的代碼是任何懂英文的人都看得懂的，需求文檔的描述，唯一的區(qū)別就是他真的能運行

第二部分：“規(guī)則引擎層”負責把上一層里的東西落地實現(xiàn)，提供業(yè)務 DSL 能力

第三部分：基礎架構(gòu)層抽象硬件的能力，比如存儲模塊抽象 DB 和緩存的存儲能力，路由模塊抽象網(wǎng)卡的分發(fā)能力，又比如前端組件化后的前端組件抽象了客戶端的交互能力等等

這樣基本能做到“技術(shù)需求”比如提高并發(fā)能力之類的只管第三部分，“業(yè)務需求”如果不突破原有的 DSL 限制，可以只改第一部分，如果有突破，那么先增強第二部分的 DSL 能力，再在第一部分里描述。

我把這種理想狀態(tài)叫做“CODE AS PRD”，代碼即需求文檔，隨便你產(chǎn)品怎么改需求，我都可以不動腦筋地跟上你修改的速度，跟不上算我輸；隨便哪個開發(fā)來接我的項目，我都告訴你這幾個類就是需求文檔，至于他為啥能跑，自己 trace，句號，交接不順利算我輸。

（扯的好像太遠了）最后關(guān)于處理老代碼的問題，我有上中下三策和一個核心關(guān)注點：

下策曰忍，應該不用解釋

中策曰滴水穿石，在大致掌握了需求和系統(tǒng)的全貌以后選擇一個點來擊穿，比如先重構(gòu)用戶體系，那就先把非用戶體系的需求擱著在原有體系中維護，而把用戶體系構(gòu)建一個新的，好的新模塊替代掉。一個常見的穩(wěn)妥辦法可以先不動數(shù)據(jù)結(jié)構(gòu)也不動寫入邏輯，先接管讀取邏輯，再一點點改寫數(shù)據(jù)的邏輯，因為讀取邏輯已經(jīng)接完，此時同時變動數(shù)據(jù)結(jié)構(gòu)風險也比較小。

上策曰自動化測試，讓你疼的代碼多半沒有完善的測試覆蓋，所以你不敢改，所以先搞自動化測試體系，這讓你即使因為項目時間壓力無法大規(guī)模重構(gòu)，也有基礎的安全繩拉著你不摔落懸崖。只要是被測試基本覆蓋的模塊，重構(gòu)起來負擔自然小很多，結(jié)合中策按業(yè)務拆分循序漸進、結(jié)合SOA微服務設計思路，一夜跨入現(xiàn)代化時代不是夢

核心關(guān)注點：你必須接受老代碼最重要的優(yōu)勢：it works。雖然是老代碼，但那是生產(chǎn)上運行的，千錘百煉的老代碼。做任何事情之前，都和你的QA部門作好溝通和計劃。專業(yè)的程序員是一定不會號稱“重構(gòu)基礎架構(gòu)”結(jié)果搞出一堆生產(chǎn)問題的

mcfog 前東家 ifaclub 是主打金融類產(chǎn)品，可以談下你加入團隊的初衷嗎？以及產(chǎn)品開發(fā)過程中使用的技術(shù)棧嗎？

作為本科生加入騰訊，初始職級實在太低(后來已調(diào)高)，升級路太遠，前老板拉我創(chuàng)業(yè)，項目當時看也有很好的機會，于是就去了…

技術(shù)棧的話，標準的 LNMP，Redis 這些之外，我們選擇了 RabbitMQ 來做消息隊列，除了活躍度、生態(tài)、性能等因素以外，主要看中他在數(shù)據(jù)一致性方面相對可靠。

金融類產(chǎn)品都相當注重數(shù)據(jù)的安全、可靠性，你們團隊是如何確保數(shù)據(jù)的安全性的呢？

編碼角度來說，做好兩件事：貫徹防御式編程風格，產(chǎn)生任何副作用(寫數(shù)據(jù)也好，請求外部接口也罷)前一定完整檢查所有前提。完善日志體系，確保所有關(guān)鍵節(jié)點的日志，做好日志的收集歸納等自動化工作，持續(xù)優(yōu)化告警體系，小心不要讓告警數(shù)量超出一定范圍，頻繁的告警盡快整理方案系統(tǒng)性解決

還有就是架構(gòu)角度和 QA 角度的支持了，完善的監(jiān)控告警體系，備份體系，測試和自動化測試的用例覆蓋等等

當然，線上問題是防不勝防的，“亡羊補牢”也是非常重要的環(huán)節(jié)，在出現(xiàn)生產(chǎn)問題，解決之后的總結(jié)，尋找同類問題，重構(gòu)系統(tǒng)，也是我們能把整個系統(tǒng)越做越好的重要方式

在PHP開發(fā)中，選擇合適的框架有助于加快軟件開發(fā)，而你在文章【如何挑選PHP框架？】 中談到要從團隊、項目、框架本身等三個方面考慮，可以從框架本身的基本素質(zhì)談一談 Yii 和 Laravel 嗎？

就我個人的角度，向未來看，Yii2 和 Laravel 都是即將過時的框架了，可能大家覺得我有些狂妄，但我是基于非常理性的總結(jié)思考得出這個結(jié)論的

請大家想想，如果 Composer 對于 PHP 來說是遲到的 NPM，那么對應 Node 生態(tài)的 web 框架勝者是誰？它的特點是什么？如果我們認同 Composer 這樣的包管理依賴管理是先進的，那么未來框架的演化方向必然是遠離 Yii2 和 Laravel 這樣的“全干全包”的框架的

移動端，微服務，SOA 的大趨勢下，未來 php 框架需要支持的場景將會越來越差異化，API 項目不需要路由和模版渲染，中前端項目不需要 DB 訪問抽象，框架的入口從 FPM，Crontab 拓展到隊列 Consumer，Thrift 等 RPC 服務入口等等，單一的單體框架勢必越來越無法滿足這樣的差異化

當然我不是說 Yii2 和 Laravel 會掛，實際上 Yii 從 1 到 2 就已經(jīng)跨了一個世代，但相對 Yii1 是 2008 年的東西了，我相信到 2027 年我們回頭來看當前的 Yii2 和目前的 Laravel4 和 5，一定和我們現(xiàn)在看 CI2 看 Yii1 是一樣的心情和看法

就 Laravel 和 Yii2 兩者之間比較的話，首先就社區(qū)生態(tài)來說，Laravel 完勝（能媲美的也就只有 Symfony 社區(qū)了），這讓 Laravel 在周邊的擴展、模塊等占上風。Laravel 的問題在于，它堆疊了很多的概念，其中不乏真正的好東西，但也有花架子，如果要用，請帶上你的思考，切記生搬硬套。而 Yii 的核心要簡潔明了一些，這讓 Yii 偏向中庸一些，是個非常安全的選擇。

我眼中未來的 PHP “框架”，就概念上就一定和現(xiàn)在的框架有區(qū)別（目前的兩個世代大致是按命名空間和 composer 來劃分的，概念上并沒有本質(zhì)區(qū)別），不再是“全家桶”式的單體框架，而是走向差異化。大概可以分為三類，一類是真正在技術(shù)上（而不是語法糖或是 convention 層面的）提供基礎能力的，比如 Swoole 提供異步、協(xié)程的能力，比如 Zephir（ Phalcon 的底層）提供的非常容易整合系統(tǒng)底層能力和 PHP 上層能力的中間語言

另一類則是真正類似 Express、Koa 這樣的，核心中間件協(xié)議+大量周邊中間件的框架生態(tài)群。目前看來似乎反而是 ZF 家的 Zend-expressive 在這方面稍稍領(lǐng)先，另一個不得不提的是 StackPHP，他們跑的太早，快于 PSR，所以現(xiàn)在面臨永遠用 adapter 繼續(xù)堅持 symfony/http-kernel 體系，還是轉(zhuǎn)戰(zhàn) PSR 體系和 zend-expressive 競爭。目前看來這樣的轉(zhuǎn)變還需要一段時間，我覺得大家也可以和我一起關(guān)注一下這個趨勢。順便，我覺得雖然這波趨勢很明顯地像 Express，但生搬硬套的效果可能并不好，畢竟比起 JS，PHP 在語言層面其實一直在接近“動態(tài)的 Java ”

第三類則是 Drupal，Wordpress 這樣的，帶基礎功能實現(xiàn)的“框架”，快速支持實現(xiàn)相對標準的需求，對這類框架(系統(tǒng))來說，Composer 的出現(xiàn)反而是個很好的機會，可以通過 Packagist 快速形成社區(qū)生態(tài)（而無須像 Drupal、Wordpress 那樣通過商業(yè)公司運作來養(yǎng)生態(tài)），這也是一個“穿越牛熊”的，無論PHP如何演化都會持續(xù)存在的類別

當然實際上 PHP 的生態(tài)演化的速度其實并不快（我覺得適中，Laravel 這樣的速度作為最快的那個夠了，現(xiàn)在不少社區(qū)跑的比Laravel快的，開發(fā)者追的太辛苦），所以目前來看選擇單體框架還是非?，F(xiàn)實的選擇，我心目中一流的選擇，除了 Laravel 和 Yii2 之外，還向大家推薦 Symfony2 和 Slim3 吧，哦，提到 Slim3 也就還應該加上 S 和 L 兩家的派生小弟弟 Silex 和 Lumen。

不知道 mcfog 的新東家是如何的，以及新東家是否還在招兵買馬呢？

實際上在收到訪談的這兩天，我已經(jīng)敲定了離職和新東家，Amino Apps 是業(yè)務在國外，研發(fā)中心在國內(nèi)的移動端興趣社交公司，36kr報道，我們招高級前端和全棧（語言不限，嗯，我這兩天在惡補 python，哈哈），我們走的是精英小團隊的路線，你得有足夠的技術(shù)能力和責任心來多帶帶 cover 一條線。簡歷請發(fā) bWNmb2d3QGdtYWlsLmNvbQ==（補充說明：有關(guān)于郵箱的解釋請看本文的劇場版之硬廣時間）

小劇場之封面設計

（清蒸）：（一本正經(jīng)地咨詢）你有什么想法嗎，對你的封面圖？每個專訪都會設計一個封面圖的
（mcfog）：沒啥特別的想法……（來自清蒸的解讀：總覺得這個省略號隱藏著什么信息…）
（清蒸）：那，我可以用艾斯的背影當元素嗎？
（mcfog）：艾斯是啥
（清蒸）：- -。海賊里面的哥哥啦
（mcfog）：[捂臉]海賊王不算動漫
（清蒸）：(╯‵□′)╯︵┻━┻ 海賊怎么了
（mcfog）：死火海和柯南都不算啦
（清蒸）：（勉強維持的微笑）請舉例說明它們不符合動漫的原因 1 2 3
（mcfog）：（一言不合甩鏈接）民工漫
（清蒸）：（一言不合甩需求）給設計師妹紙寫了一個設計需求

卒

小劇場之硬廣時間

（清蒸）：mcfog 大兄弟，我們給你留了一個廣告位，需要嗎？啤酒花生隨便賣
（mcfog）思考狀
（清蒸）：不要浪費啊，你看看隔壁公子，賣床位招人，現(xiàn)在有一個免費的廣告位預留給你，好好珍惜呀
（mcfog）招聘，眼前一亮
（mcfog）：那就為新東家 Amino 招個人吧，簡歷發(fā)送至：bWNmb2d3QGdtYWlsLmNvbQ==
（清蒸）一臉懵逼：這個郵箱沒給錯嗎？
（mcfog）：郵箱是對的，看不懂的程序員不要[傲嬌臉]

以上，就是對郵箱的解釋，且看且珍惜，祝你們好運~

為什么突然增加了這么一塊內(nèi)容呢？因為清蒸對 mcfog 大兄弟的某些言論深表贊同

我特別想談談“文章”和“筆記”的區(qū)別，前者是你表達一個觀點，描述一種思想的，“一身功力的結(jié)晶”，而后者只是某些知識點的整理記錄。(摘錄自：怎么衡量前端達到了什么水平)

想清楚學習的目的，避免為學而學.比如高并發(fā)，秒殺，架構(gòu)，這些經(jīng)常都是現(xiàn)有業(yè)務接觸不到的東西，學習起來一般兩種目的：要么為了應對面試，要么為了日后業(yè)務發(fā)展，需要的時候能夠頂上（知識儲備）(摘錄自：感覺學PHP開發(fā)網(wǎng)站到瓶頸了，技術(shù)上不知如何突破，希望大神指點推薦幾本書，謝謝！)

下一期的訪談對象是清蒸認識 coding 時間最長的一名程序員：@邊城 ，據(jù)說 97 年開始寫代碼，20 年的碼齡，且看他如何 Coding Twenty Years , Learning Twenty Years。本期訪談到此結(jié)束，下期見~