小團(tuán)隊(duì)一般 10 人左右，其中常常是技術(shù)最牛的人做架構(gòu)師(或 TL)。所以，架構(gòu)師在廣大碼農(nóng)中的占比大概平均不到 10%。

[[338951]]
圖片來(lái)自 Pexels

 

而架構(gòu)師也可以分為初級(jí)、中級(jí)、高級(jí)三檔，江湖上真正高水平的軟件架構(gòu)師就更少了。

所以，大部分(超過(guò)九成的)碼農(nóng)干上許多年，還是做不了架構(gòu)師，這是什么原因造成的呢?

什么是架構(gòu)師?

寫代碼和做架構(gòu)是兩個(gè)不同的事情。什么是架構(gòu)師，架構(gòu)師要做什么事情，為什么 Java 的領(lǐng)域里，會(huì)更注重架構(gòu)師?

很早很早之前，我對(duì)于架構(gòu)的概念一點(diǎn)都不理解，依稀記得，架構(gòu)( architecture)這個(gè)詞，來(lái)自于建筑領(lǐng)域。

這對(duì)于我這個(gè)沒(méi)寫過(guò)幾行代碼的人來(lái)說(shuō)，瞬間就有了一種“不明覺(jué)厲”的崇拜感。

架構(gòu)，感覺(jué)好厲害的樣子，從名稱上來(lái)說(shuō)，好像是設(shè)計(jì)根骨，設(shè)計(jì)底層，設(shè)計(jì)最核心的東西的人。

架構(gòu)師，一定很 NB，我什么時(shí)候能成為架構(gòu)師呢?

后來(lái)懂了一點(diǎn)點(diǎn)代碼，去寫增刪改查，更是體會(huì)不出來(lái)架構(gòu)的概念，不就是 SQL 語(yǔ)句嗎?

明明 DBA 更厲害啊，做各種的慢 SQL 優(yōu)化，所有的 SQL 都要讓 DBA 審核，DBA 對(duì)于 MySQL，或者是 Oracle 的各種性能調(diào)憂很厲害，而熟悉業(yè)務(wù)的開(kāi)發(fā)人員又常常能寫出幾萬(wàn)行的 SQL 語(yǔ)句。

我看到這些頭都要炸了好么?所以，到底什么是架構(gòu)?

整個(gè)系統(tǒng)只有一個(gè) Web，Spring MVC+Spring+Hibernate 搞定一切，開(kāi)始做需求分析，實(shí)際上就是設(shè)計(jì)表結(jié)構(gòu)而已，剩下的就是查查查，改改改，刪刪刪。

直到某天，我知道一個(gè)詞，緩存。

緩存這玩意兒，在很早之前學(xué)習(xí)各種基礎(chǔ)課程的時(shí)候，了解過(guò)一些，一級(jí)緩存，二級(jí)緩存什么的，LRU 我好像也懂一點(diǎn)點(diǎn)，但是，在系統(tǒng)里，緩存算是什么?

在公司里，那個(gè)架構(gòu)師，畫了一張圖，告訴我們，這臺(tái)機(jī)器上，放了一個(gè) Memcache，然而我們都不懂，他只解釋了一句，這個(gè) Memcache 是緩存。

我的第一個(gè)困惑就是，所有的請(qǐng)求都要再次轉(zhuǎn)發(fā)到另一臺(tái)機(jī)器上，把數(shù)據(jù)取出來(lái)，單個(gè)請(qǐng)求可能不算什么，每天有幾十萬(wàn)次請(qǐng)求，這中間的損耗不大么，為什么不把 Memcache 放到本地機(jī)器上呢?

他沒(méi)解釋，只告訴我說(shuō)，不大，Memcache 就是要放在另一臺(tái)機(jī)器。

在當(dāng)時(shí)，我不清楚內(nèi)網(wǎng)和外網(wǎng)的差別，也不清楚訪問(wèn) Memcache 的請(qǐng)求倒底是需要多少 MS，更不理解，把 Memcache 放在和業(yè)務(wù)層一臺(tái)機(jī)器，或者是分開(kāi)放的差別倒底是什么。

但這個(gè)問(wèn)題一直困惑著我，簡(jiǎn)單來(lái)說(shuō)，這其實(shí)算是一點(diǎn)點(diǎn)架構(gòu)師要做的事情的萌芽，一個(gè)系統(tǒng)中，如果拆解出來(lái)了很多模塊，倒底應(yīng)該部署在哪些機(jī)器上?架構(gòu)師會(huì)解決這些問(wèn)題。

后來(lái)，到了搜狐之后，我突然間發(fā)現(xiàn)了我之前學(xué)到的東西，在搜狐的技術(shù)大神面前，直接被轟成渣。

負(fù)載均衡是什么?熱備又是什么?穿透 DB 是什么意思?怎么我取數(shù)據(jù)庫(kù)里取一個(gè)值，數(shù)據(jù)庫(kù)里沒(méi)有，這種空數(shù)據(jù)的請(qǐng)求會(huì)把 DB 打垮?我還要把這些為 Null 的請(qǐng)求單獨(dú)緩存起來(lái)?本地緩存做為一級(jí)緩存，Memcache 做二級(jí)緩存?

“對(duì)緩存來(lái)說(shuō)，最關(guān)鍵的設(shè)計(jì)就在于失效策略是什么。”大神鎮(zhèn)定的看著我。我很惶恐，感覺(jué)能把失效策略設(shè)計(jì)出來(lái)，很不容易。

不同的應(yīng)用場(chǎng)景，對(duì)于緩存的要求不一樣，對(duì)實(shí)時(shí)性的要求也不一樣。榜單這種一天更新一次的，每天晚上定時(shí)生成一次就好了。

后臺(tái)更新，但是要注意，一定要直接生成，直接切換，不能讓前端用戶訪問(wèn)的時(shí)候，再去生成。

對(duì)于名字這種東西，用戶改完之后，必須立刻更新緩存，包括本地緩存和遠(yuǎn)程緩存。

這算不算架構(gòu)中的一部分，根據(jù)不同的應(yīng)用需要，去設(shè)計(jì)不同的策略，同時(shí)把這些場(chǎng)景規(guī)范化，成為一整個(gè)團(tuán)隊(duì)都要去遵循的標(biāo)準(zhǔn)?

我不知道，我只知道，能 Hold 住團(tuán)隊(duì)里所有人的那個(gè)人，技術(shù)一定非常 NB，團(tuán)隊(duì)里的每一個(gè)人，都會(huì)質(zhì)疑，如果你 Hold 不住全場(chǎng)，怎么能推行下去?

當(dāng)時(shí)近 30 的技術(shù)團(tuán)隊(duì)里，每一個(gè)都是神一樣的存在啊，誰(shuí)能 Hold 住 30 多個(gè)神。

而且，原來(lái)不應(yīng)該把所有的代碼放到一個(gè) Web 里，原來(lái)分布式是這么回事兒，原來(lái)一個(gè)系統(tǒng)，是由多個(gè)子系統(tǒng)構(gòu)成的，原來(lái)還要分層，原來(lái)封裝和抽象是這么個(gè)意思。

Web 層是一層，通?？梢酝ㄟ^(guò) LVS 部署兩臺(tái)到三臺(tái)，或者是更多的，Service 一層用來(lái)處理業(yè)務(wù)邏輯，緩存層用來(lái)扛并發(fā)，一定要藏在 Service 里面。

Controller 調(diào)用 Service 的時(shí)候，并不需要知道數(shù)據(jù)到底從哪來(lái)的，每一個(gè) Service 使用什么樣的緩存策略，完全不需要 Controller 層知道。

對(duì)于大型應(yīng)用來(lái)講，MySQL 只能用做是持久化，MySQL 的單條訪問(wèn)速度并不查，只是在并發(fā)能力太差，扛不住。但是，有可能數(shù)據(jù)量過(guò)億啊?

過(guò)億怎么辦?是用分庫(kù)，還是分表?讀寫分離要不要做?一臺(tái)服務(wù)掛一臺(tái)數(shù)據(jù)庫(kù)，哪些數(shù)據(jù)庫(kù)應(yīng)該放在一個(gè)實(shí)例里，哪些應(yīng)該單獨(dú)拆出去?每臺(tái)服務(wù)器的配置是什么?

我大概知道一點(diǎn)點(diǎn)，架構(gòu)師要做哪些事情，他就是要把這些大的骨架定好，然后我們?nèi)ヌ畛淅锩娴膬?nèi)容。如果骨架定歪了，其余團(tuán)隊(duì)必然跟著歪。

這時(shí)候有了一系列的問(wèn)題，第一個(gè)，Controller 和 Service 之間，Service 和 Service 之間，應(yīng)該通過(guò)什么調(diào)用?

RMI，這是惟一的選擇。用 Thrift，或者是 ProtocolBuffer，或者是 Rest 實(shí)現(xiàn)的 RPC?

這是架構(gòu)師要考慮的事情，如果是用 RMI，我們是要自己實(shí)現(xiàn)，還是要找找是否有好用的開(kāi)源的框架，在其他的系統(tǒng)里被證明了是有用的?

大神們花了兩周的時(shí)間，對(duì)當(dāng)時(shí)流行的開(kāi)源框架過(guò)了一遍，最終選定了 Tuscany，到現(xiàn)在我都覺(jué)得設(shè)計(jì)精美，完暴 Dubbo 的東西，真的是一點(diǎn)都不想切到 Dubbo 上去，畢竟“曾經(jīng)滄海難為水，除卻巫山不是云”。

直到最近幾年微服務(wù)興起的時(shí)候，我還是同樣的目瞪口呆，這跟 2009 年搜狐當(dāng)時(shí)做白社會(huì)的架構(gòu)比起來(lái)，優(yōu)勢(shì)倒底在哪里?

差別好像沒(méi)有那么大啊，而且 Tuscany 實(shí)現(xiàn)的更完美，只是使用的時(shí)候要有更強(qiáng)的約束，因?yàn)?Tuscany 太強(qiáng)大了，強(qiáng)大到有一點(diǎn)點(diǎn)重，必須要做簡(jiǎn)化。

而且，Tuscany 的開(kāi)發(fā)團(tuán)隊(duì)不怎么維護(hù)了，白社會(huì)當(dāng)時(shí)做的東西，還是大神花了兩周的業(yè)余時(shí)間寫了一個(gè) Scallop，增加了 Tuscany 的負(fù)載均衡的功能。

但是，到底用什么，不用什么呢?除了 Tuscany，還討論過(guò)要不要用 Hadoop，要不要用 ActiveMQ，要不要用 Erlang。

每一個(gè)技術(shù)框架的選擇，都經(jīng)過(guò)討論，驗(yàn)證，測(cè)試，最終在全團(tuán)隊(duì)里推行。

[[338952]]

 

這是否也是架構(gòu)師的職責(zé)?這個(gè)架構(gòu)師太厲害了，他需要從前到后都要懂，他需要制定關(guān)鍵的技術(shù)細(xì)節(jié)，他需要給出最佳實(shí)踐，他需要了解業(yè)界所有流行的解決方案。

他需要去猜測(cè) Facebook 怎么解決問(wèn)題的，Twitter 怎么解決問(wèn)題的，Google 怎么解決問(wèn)題的，這些解決方案可不可以拿過(guò)來(lái)，也同樣適用于我們自己的場(chǎng)景。

他需要精通分布式，Nginx 或者是 F5，微服務(wù)，緩存，持久化，消息隊(duì)列，他需要熟悉所有這些技術(shù)細(xì)節(jié)里的最常用的解決方案，不能有遺漏，也不可以過(guò)度設(shè)計(jì)。

他決定的不是他一個(gè)人喜歡的風(fēng)格，他決定的就是整個(gè)團(tuán)隊(duì)，在項(xiàng)目死亡之前都必須遵循的規(guī)范，現(xiàn)在的團(tuán)隊(duì)成員，和未來(lái)的團(tuán)隊(duì)成員，都必須遵循的體系，而且，如果在未來(lái)，這些架構(gòu)體系有不合理的地方，那就麻煩大了。

這樣的架構(gòu)師，還要肩負(fù)著一個(gè)重大的使命，修復(fù)開(kāi)源軟件的 Bug。

在很早之前，我一直誤以為開(kāi)源軟件是很厲害的很 NB 的東西，我一直以為這是完美的，很久很久之后，才明白，所謂的完美，都是用血和淚塑造而來(lái)的。

不經(jīng)過(guò)各種各樣的驗(yàn)證，環(huán)境，使用的測(cè)試，很難達(dá)到一個(gè)上線標(biāo)準(zhǔn)的穩(wěn)定，即便是上線了，也有可能會(huì)出現(xiàn)之前完全預(yù)料不到的問(wèn)題。

可是，如果你選擇了這個(gè)框架，出了問(wèn)題，誰(shuí)去解決?

架構(gòu)師，他要開(kāi)源碼，理解這些開(kāi)源框架的思路，然后去找有可能產(chǎn)生問(wèn)題的地方，再去修復(fù)他。

我一直都覺(jué)得，能看懂別人寫的代碼的人，都是神。某段時(shí)間我去看一個(gè) Heritrix，看的我神清氣爽，各種層出不窮的繼承，各種抽象類，連著三天我欲仙欲死，更加堅(jiān)定了我死也不要，也不允許其他人在項(xiàng)目里使用繼承的決心。

但是 Heritrix 從外表看起來(lái)特別牛，他的抓取策略也很 NB，用的分布式抓取的解決方案非常輕巧?？墒俏椅覍?shí)在是不想再去讀一次了，在當(dāng)時(shí)不讀不行，資料太少。

那么，一個(gè)架構(gòu)師，要對(duì)這些源碼都了解么?又或者是，他必須具備，需要他去讀源碼，他就必須讀源碼，而且去優(yōu)化的能力?這大概比提前懂源碼，更神奇。

因?yàn)槭怯袝r(shí)間要求的啊，簡(jiǎn)單來(lái)講，他需要在一個(gè)有效的時(shí)間內(nèi)，去弄懂所有的底層的東西，說(shuō)句實(shí)在話，當(dāng)有同事嘲笑我都沒(méi)有完整的看過(guò) TCP/IP 協(xié)議詳解的時(shí)候，我真的是無(wú)話可說(shuō)的。

對(duì)于特別底層的東西，我確實(shí)了解的不夠多，可是架構(gòu)師們不一樣。

[[338953]]

 

架構(gòu)師需要懂業(yè)務(wù)么?

有了這些，就可以稱之為架構(gòu)師了么?架構(gòu)師需要懂業(yè)務(wù)么?

是不是就可以每天看技術(shù)，寫底層框架(比如我們?cè)瓉?lái)在搜狐用到的 DAL，數(shù)據(jù)訪問(wèn)層，用起來(lái)簡(jiǎn)直是神器的東西)。

沒(méi)有不懂業(yè)務(wù)的架構(gòu)師，所有的架構(gòu)，都依賴于業(yè)務(wù)。所有的架構(gòu)師，也必須要去寫業(yè)務(wù)代碼，不把自己設(shè)計(jì)的東西，用在真正的項(xiàng)目里，恐怕他們自己都不會(huì)知道，這種架構(gòu)設(shè)計(jì)的合理性在哪里。

在某團(tuán)購(gòu)公司上市之前，他們的 CTO 拿出來(lái)了他們的架構(gòu)圖給我看，在給我看之前，所有的技術(shù)術(shù)語(yǔ)都一樣，但是當(dāng)我認(rèn)真看了架構(gòu)圖之后，我的困惑......

為什么 Memcache 要放在 Controller 層被調(diào)用?不應(yīng)該是放到 Service 層嗎?

怎么會(huì)出現(xiàn)你說(shuō)的，一個(gè) Serivce 負(fù)責(zé)維護(hù)的數(shù)據(jù)，也有可能被另外的 Service 去更改的情況?

每一個(gè) Service 對(duì)數(shù)據(jù)的操作，必須是獨(dú)立的啊，除了這個(gè) Service，其他的任何服務(wù)都決不允許直接更改 DB 啊。

而且，怎么 Service 拆分了，DB 不拆分呢?這樣的話，壓力大的 DB 會(huì)把全站拖跨的啊。

那張架構(gòu)圖我看到之后，感覺(jué)自己的認(rèn)知被突破了，原來(lái)可以這么做，原來(lái)同樣的，類似的技術(shù)選型，可以做出來(lái)如此艱難的東西?

就在我以為這其實(shí)就差不多是架構(gòu)師的全部的時(shí)候。在最近一段時(shí)間，我突然間發(fā)現(xiàn)了一個(gè)問(wèn)題。

為什么有的人代碼寫的這么爛，很多寫死的代碼，一點(diǎn)兒靈活性都沒(méi)有，更沒(méi)有規(guī)范，完全就是堆壓。

為什么有的人根本不知道怎么去抽象，并不清楚怎么樣積累成公共組件，為什么他們改一個(gè)問(wèn)題，通常會(huì)引出更多的問(wèn)題?

為什么他們的代碼里的實(shí)現(xiàn)方案，讓人看完之后恨的牙癢癢，想改又完全不能改，畢竟，正常工作的代碼才是好代碼?

很大程度上是因?yàn)?，很多程序員，不懂的代碼的擴(kuò)展性，不會(huì)面向未來(lái)編程。

[[338954]]

 

怎么叫做面向未來(lái)編程?

一個(gè)好的工程師，在聽(tīng)到需求的時(shí)候，可以根據(jù)自己的業(yè)務(wù)能力，判斷出來(lái)這些需求中，哪些是有可能變化的，哪些是不太可能變化的。

針對(duì)這些變化的內(nèi)容，在編寫的過(guò)程中，不會(huì)寫死，而反復(fù)確認(rèn)不可能會(huì)變化的需求，會(huì)寫的簡(jiǎn)單一些，防止過(guò)度設(shè)計(jì)引起的復(fù)雜度。

簡(jiǎn)單說(shuō)，當(dāng)他拿到需求時(shí)，并不單純是考慮這個(gè)需求怎么實(shí)現(xiàn)，還會(huì)考慮，自己設(shè)計(jì)的架構(gòu)體系，擴(kuò)展性在哪里，在他的眼里，看到的需求會(huì)被分解，折分，然后自己的技術(shù)方案，會(huì)挨個(gè)分解，分配。

在完成設(shè)計(jì)之后，他會(huì)很清楚的知道 ，自己設(shè)計(jì)的系統(tǒng)里，哪些變化是支持的，隨便你改，我只需要改動(dòng)一個(gè)很簡(jiǎn)單的內(nèi)容，哪些是你絕對(duì)不能改的，你要改，我就必須花很大的代價(jià)，特別是在已經(jīng)有線上數(shù)據(jù)的時(shí)候。

而且會(huì)拿著自己的架構(gòu)體系跟 PM 溝通，講清楚。

什么樣的變化是支持的?短信通道是有可能變化的，而調(diào)用短信通道的地方可能會(huì)有點(diǎn)多，所以我必須把短信通道抽象，并封裝在一個(gè)公共接口，如果需要更換短信通道，我可能只需要更改一個(gè)配置文件就好了。

那么什么樣的變化是不支持的?我不需要不停機(jī)就更換短信通道的功能，除非你在后臺(tái)系統(tǒng)中提前配置好，或者是有明確的需要，我做出這么一個(gè)東西出來(lái)。往往在前期，不會(huì)用到，為什么?

在創(chuàng)業(yè)初期，短信通道往往用于用戶注冊(cè)，一旦出問(wèn)題，就是生死問(wèn)題，必須要有一個(gè)備份，運(yùn)營(yíng)商一怒封掉你的通道，很常見(jiàn)。

而重啟一次服務(wù)，在創(chuàng)業(yè)前期，往往沒(méi)有那么嚴(yán)重。所以，這些技能，是不是也應(yīng)該歸納到架構(gòu)師的職責(zé)里去?

架構(gòu)師從開(kāi)始就要考慮選型，從語(yǔ)言開(kāi)始，從業(yè)務(wù)開(kāi)始，要對(duì)這個(gè)領(lǐng)域里的開(kāi)源框架熟悉，了解，要能解決疑難問(wèn)題，要懂安全，要會(huì)備份，要學(xué)會(huì)面向未來(lái)編程，還需要什么?

還需要 DevOps，在持續(xù)集成的年代，在服務(wù)器規(guī)模越來(lái)越大，在云服務(wù)器的年代，在異地存儲(chǔ)，冗災(zāi)，在全球化越來(lái)越快的年代。

運(yùn)維的重要性已經(jīng)到了一個(gè)很核心的程度了。彈性伸縮，自動(dòng)擴(kuò)容，灰度發(fā)布等等等概念，要求，都在沖擊著架構(gòu)師這個(gè)概念的定義。

如果說(shuō)之前的架構(gòu)師，更多的是在系統(tǒng)開(kāi)發(fā)前，現(xiàn)在越來(lái)越偏于系統(tǒng)上線后。

還包括數(shù)據(jù)分析，日志分析，等等等等，對(duì)了，還沒(méi)有提到 NoSQL DB，實(shí)時(shí)搜索，知識(shí)庫(kù)，算法這一系列的東西。

每一個(gè)領(lǐng)域都在細(xì)分，每一個(gè)概念都在深化。簡(jiǎn)單說(shuō)，架構(gòu)師確實(shí)和語(yǔ)言無(wú)關(guān)，但是又絕對(duì)和語(yǔ)言有關(guān)系。

你可以說(shuō)，架構(gòu)師就是在做選型，但是只會(huì)做選型，肯定做不出架構(gòu)師。

Java 更需要架構(gòu)師，因?yàn)樗旧砭褪歉鞣N開(kāi)源框架，不對(duì)這些框架了解的清清楚楚，你很難做出一個(gè)好的選擇，而一旦架構(gòu)被固定，實(shí)際業(yè)務(wù)人員的開(kāi)發(fā)，又會(huì)變的簡(jiǎn)單很多。

[[338955]]

 

中級(jí)工程師的發(fā)展路線

說(shuō)到了現(xiàn)在，我有沒(méi)有講清楚架構(gòu)師是什么?而你，還想要做架構(gòu)師嗎?

反正，我說(shuō)自己是架構(gòu)師的時(shí)候，我的內(nèi)心是羞恥的，我知道 ，我遠(yuǎn)遠(yuǎn)沒(méi)達(dá)到架構(gòu)師的能力。

然后，我曾整理過(guò)一個(gè)中級(jí)工程師的發(fā)展路線。

科班基礎(chǔ)：

• 計(jì)算機(jī)組成原理(洗髓換骨營(yíng))
• 計(jì)算機(jī)操作系統(tǒng)(洗髓換骨營(yíng))
• 計(jì)算機(jī)網(wǎng)絡(luò)(洗髓換骨營(yíng))
• 數(shù)據(jù)結(jié)構(gòu)(洗髓換骨營(yíng))
• 數(shù)據(jù)庫(kù)
• 算法

語(yǔ)言相關(guān)：

• JDK
• 線程
• Set
• Hash
• GC
• ClassLoader
• Lambda

Spring：

• IOC
• Spring
• Spring MVC
• Spring Boot
• Shrio

數(shù)據(jù)庫(kù)：

• MySQL 基礎(chǔ)
• DB 設(shè)計(jì)
• DB 調(diào)優(yōu)
• MySQL 底層架構(gòu)
• idcenter
• 常用工具
• 索引

架構(gòu)：

• 設(shè)計(jì)模式
• 緩存
• 分布式
• Key-Value
• 消息隊(duì)列
• 定時(shí)任務(wù)
• 微服務(wù)
• RPC
• 高并發(fā)
• 性能優(yōu)化

項(xiàng)目規(guī)范：

• 接口定義
• 日志規(guī)范
• 編碼規(guī)范
• 最佳實(shí)踐

運(yùn)維：

• Linux 常用命令
• JVM 常用工具
• Nginx
• Resin
• LVS
• Iptables
• Jenkins
• Ansible
• 容器 Docker
• 監(jiān)控
• CICD

常用算法：

• 一致性哈希
• Gossip
• Paxos
• Spotsig
• HTTPS
• MD5
• Auth2
• Bloom Filte
• 編輯距離
• TrieTree
• Rete

源碼解析：

• Spring
• Redis
• Memcache
• Mybatis
• Log4j
• Maven
• Git

開(kāi)發(fā)流程：

• 敏捷開(kāi)發(fā)

場(chǎng)景解決方案：

• 金融
• 支付
• 電商
• 直播
• 教育
• O2O
• 分銷
• 會(huì)員
• 活動(dòng)
• 秒殺

思維方式：

• 自頂而下
• 分層模式
• 抽象
• 落地
• 推測(cè)
• 驗(yàn)證
• 組件
• 定制
• 生成

為什么很多程序員做不了架構(gòu)師?

最后再說(shuō)一下，為什么很多程序員做不了架構(gòu)師，原因有如下三點(diǎn)：

• 是剛開(kāi)始就么有奔著這個(gè)目標(biāo)去，好比是動(dòng)作變形，反而不好糾正了。
• 是思維沒(méi)能提升一個(gè)臺(tái)階，只局限于具體的編碼，沒(méi)有考慮過(guò)選型，復(fù)用，擴(kuò)展。
• 是身邊沒(méi)有架構(gòu)師的引導(dǎo)和培養(yǎng)，環(huán)境問(wèn)題是一個(gè)很大的問(wèn)題。

作者：暗滅

編輯：陶家龍

出處：https://www.zhihu.com/question/36658435/answer/1304731422