南順網絡
如(rú)何一(yī)步一(yī)步走向架構師
成為(wèi)優秀的(de)架構師是大部分初中級工程師的(de)階段性目标。優秀的(de)架構師往往具備七種核心能力:編程能力、調試能力、編譯部署能力、性能優化能力、業務架構能力、在線運維能力、項目管理(lǐ)能力和(hé)規劃能力。
這幾種能力之間的(de)關系大概如(rú)下圖。編程能力、調試能力和(hé)編譯部署能力屬于最基礎的(de)能力。不能精通掌握這三種能力，很難在性能優化能力和(hé)業務架構能力方面有所成就。具備了一(yī)定的(de)性能優化能力和(hé)業務架構能力之後，才能在線運維能力和(hé)項目管理(lǐ)能力方面表現優越。團隊管理(lǐ)能力是最高(gāo)能力，它對項目管理(lǐ)能力的(de)依賴度更大。
基本知識
1.學(xué)會分析源碼
程序員每天都和(hé)代碼打交道(dào)。經過數年(nián)的(de)基礎教育和(hé)職業培訓，大部分程序員都會「寫」代碼，或者至少會抄代碼和(hé)改代碼。但是，會讀代碼的(de)并不在多數，會讀代碼又真正讀懂一(yī)些大項目的(de)源碼的(de)，少之又少。這種怪狀，真要追究起來，怪不得程序員這個群體本身 --它是兩個原因造成的(de):
我們所有的(de)教育和(hé)培訓都在強調怎麽寫代碼，并沒有教大家如(rú)何讀代碼
大多數工作場景都是一(yī)個蘿蔔一(yī)個坑，我們隻需要了解一(yī)個系統的(de)局部便能開展工作，讀不相幹的(de)代碼，似乎沒用
讀源碼三問:“為(wèi)什麽要有這樣的(de)架構”，“他是什麽樣子(zǐ)的(de)”，“他是怎麽工作的(de)”。
那麽阿裏程序員是如(rú)何去(qù)讀代碼的(de)呢(ne)?
2.分布式架構特點及設計理(lǐ)念
首先需要說明的(de)是，分布式系統是一(yī)個複雜且寬泛的(de)研究領域，學(xué)習一(yī)兩門在線課程，看一(yī)兩本書可(kě)能都是不能完全覆蓋其所有內(nèi)容的(de)。介于這篇文章(zhāng)是引導初學(xué)者入門，所以我個人覺得為(wèi)初學(xué)者介紹一(yī)下當前分布式系統領域的(de)全貌，也許比直接推薦論文和(hé)課程更有幫助。當初學(xué)者對這個領域建立起一(yī)個大的(de) Picture之後，可(kě)以根據自(zì)己的(de)興趣，有選擇性的(de)深入不同領域進行進一(yī)步的(de)學(xué)習。
3.為(wèi)什麽微服務會這麽火?
要學(xué)習微服務，首先，我們要了解為(wèi)什麽使用微服務。
代碼難以理(lǐ)解?
構建和(hé)部署耗時長(cháng)，難以定位問題，開發效率低(dī)?
單體隻能按整體橫向擴展，無法分模塊垂直擴展?
一(yī)個bug有可(kě)能引起整個應用的(de)崩潰?
受技術棧限制，團隊成員使用同一(yī)框架和(hé)語言?
那麽如(rú)何解決單體的(de)不足呢(ne)，通過遷移到微服務架構來解決，我們看一(yī)下什麽是微服務。
微服務架構:将單體應用拆分為(wèi)多個高(gāo)內(nèi)聚低(dī)耦合的(de)小型服務，每個小服務運行在獨立進程，由不同的(de)團隊開發和(hé)維護，服務間采用輕量級通信機制，獨立自(zì)動部署，可(kě)以采用不同的(de)語言及存儲。
單體架構整個團隊維護開發一(yī)個大工程及一(yī)個單庫，到了微服務架構，用戶請求經過API Gateway被路由到下遊服務，服務之間以輕量級通信協議進行通信，服務通過注冊中心發現彼此，每個服務都有專門的(de)開發維護團隊，每個服務對應獨立的(de)數據庫，服務獨立開發，獨立部署和(hé)上線。
接下來我們總結下微服務的(de)優點：
易于開發與維護
微服務相對小，易于理(lǐ)解
啓動時間短(duǎn)，開發效率高(gāo)
獨立部署
一(yī)個微服務的(de)修改不需要協調其它服務
伸縮性強
每個服務都可(kě)以在橫向和(hé)縱向上擴展
每個服務都可(kě)按硬件資源的(de)需求進行獨立擴容
與組織結構相匹配
微服務架構可(kě)以更好将架構和(hé)組織相匹配
每個團隊獨立負責某些服務，獲得更高(gāo)的(de)生産力
技術異構性
使用最适合該服務的(de)技術
降低(dī)嘗試新技術的(de)成本
下面就送上學(xué)習架構圖吧(ba)
4.程序員到底要不要學(xué)習JVM
總有人問這個東西好像用不上,于是要不要學(xué)這樣的(de)問題。
然後又總有人擔心一(yī)直搬磚成天做(zuò)些重複沒提升的(de)東西。
如(rú)果你這輩子(zǐ)隻甘心做(zuò)一(yī)個平庸的(de)Java碼農，那麽你完全沒有必要去(qù)學(xué)習JVM相關的(de)知識，學(xué)習JVM對于一(yī)個Java程序員的(de)好處大概可(kě)以概括為(wèi)下幾點:
1.你能夠明白為(wèi)什麽Java最早期被稱為(wèi)解釋型語言，而後來為(wèi)什麽又被大家叫做(zuò)解釋與編譯并存的(de)語言(了解JVM中解釋器以及即時編譯器就可(kě)以回答這個問題);
2.你能夠理(lǐ)解動态編譯與靜态編譯的(de)區别，以及動态編譯相對于靜态編譯到底有什麽好處(JVM JIT);
3.你能夠利用一(yī)些工具，jmap, jvisualvm, jstat, jconsole等工具可(kě)以輔助你觀察Java應用在運行時堆的(de)布局情況，由此你可(kě)以通過調整JVM相關參數提高(gāo)Java應用的(de)性能;
4.可(kě)以清楚知道(dào)Java程序是如(rú)何執行的(de);
5.可(kě)以明白為(wèi)什麽Java等高(gāo)級語言具有可(kě)移植性強的(de)特性。
其實這個問題相當于“為(wèi)什麽C/C++程序員需要學(xué)體系結構與編譯原理(lǐ)?”
話不多說，附上學(xué)習體系圖
5.被我們忽略掉的(de)工程化專題
IT産業行業細分化已經不是一(yī)天兩天的(de)事了。集成技術這件事并不可(kě)恥可(kě)笑，反而是另一(yī)種可(kě)貴的(de)能力。并不是像一(yī)些人形容的(de)那樣，好像批發幾個CPU，拿到華強北就能把自(zì)己的(de)電腦改裝成超級計算機了。
那麽，為(wèi)什麽我們常常會忽略掉工程化這件事的(de)價值呢(ne)?主要的(de)原因，或許是因為(wèi)工程化這件事本身就離(lí)我們太遠。一(yī)個産業工程化的(de)普遍性越高(gāo)，說明這個産業發展的(de)越成熟:産業鏈細分、分工細化、全球化的(de)研發和(hé)生産這些高(gāo)效的(de)工作方式開始出現。而産業成熟也往往代表着寡頭化情況顯著。
在IT産業中，寡頭化出現代表着創業公司減少--沒人再去(qù)用聲勢浩大的(de)發布會講故事、沒人再去(qù)宣傳自(zì)己拿了多少融資。
這一(yī)代中國人自(zì)小的(de)教育不比歐美的(de)STEAM，而是重學(xué)術、輕手藝。我們往往會為(wèi)工科和(hé)産能過剩畫上等号。強大的(de)資本和(hé)技術門檻為(wèi)這些産業蒙上了一(yī)層神秘的(de)面紗，讓普通人很難真正了解到其中技術和(hé)工藝的(de)複雜程度，也就更難明白其中的(de)價值。可(kě)正是因為(wèi)中國的(de)工程化能力，才讓我們有機會走到AI時代的(de)第一(yī)梯隊，而不僅僅是靠學(xué)術研究能力。
另外一(yī)個原因，或許在于我們天生“叛逆心”。超級計算機、手機芯片等等技術門檻較高(gāo)的(de)産業，其背後往往是大企業和(hé)國資科研機構。當評判的(de)對象是他們時，我們似乎更願意相信狗血的(de)商業故事和(hé)陰謀論:比如(rú)科研經費都被教授們吃吃喝喝啦;搞超級計算機就是放衛星其實美日根本不care啦;XX企業的(de)技術都是從創業公司買來的(de)除了會賺用戶的(de)錢啥技術都沒有……
産生這種“叛逆心”的(de)原因太深刻，我們能做(zuò)到的(de)，隻有在這種“慣性思維”出現時先按住自(zì)己奔向鍵盤的(de)手，轉表達欲為(wèi)好奇心，完成自(zì)己了解的(de)義務，再去(qù)行使自(zì)己批判的(de)權利。
附上思維腦圖
6.沒有高(gāo)并發經驗，想進大公司該怎麽辦?
假如(rú)沒有靠譜的(de)公司,接觸不到高(gāo)并發的(de)業務場景怎麽辦?你永遠解決的(de)是小問題，工作10年(nián)技術也未必提升多少。
很多程序員也經常找我說，沒有經驗就沒有靠譜的(de)公司收，沒有靠譜的(de)公司也就沒有經驗，我看了無數的(de)書，自(zì)己做(zuò)了無數的(de)實驗拼命想找個靠譜公司去(qù)深入，但是感覺好難，簡直是個死循環
讀者群的(de)朋(péng)友大家都比較關注高(gāo)并發，原因很簡單，想去(qù)BAT這樣的(de)大公司，你必須要有高(gāo)并發的(de)經驗。今天普及下高(gāo)并發的(de)知識，希望大家對高(gāo)并發有一(yī)個正确的(de)認識。
7.學(xué)習千遍，不如(rú)項目實戰成功一(yī)次
我們在學(xué)習過程中最容易犯的(de)一(yī)個錯誤就是:看的(de)多，動手的(de)少。特别是對一(yī)些項目的(de)整體開發，我們接觸的(de)機會就更少了。
一(yī)次完整的(de)開發，是最好的(de)學(xué)習。它能讓你對整個開發流程有完整的(de)認識，對知識也會有極大的(de)鞏固。更重要的(de)是，你将學(xué)會将理(lǐ)論知識用到實際開發中的(de)方法。
所以無論項目大小，一(yī)定要動手去(qù)進行開發學(xué)習。
項目實戰相信很多程序員都多少會有的(de)，可(kě)是我們這個還要學(xué)習什麽呢(ne)?
那就要看你想不想成為(wèi)一(yī)個架構師了，為(wèi)什麽98%的(de)程序員工作10年(nián)，一(yī)輩子(zǐ)還隻是一(yī)個開發者。程序員們都要想一(yī)想這個問題，我是不是需要提升了。
我認為(wèi)，學(xué)習項目實戰最重要的(de)還是學(xué)習項目管理(lǐ)，作為(wèi)程序員，都應該學(xué)點項目管理(lǐ)。
凡事皆為(wèi)“項目”
項目的(de)兩類屬性(複雜的(de)邏輯，龐大的(de)信息量)
人腦擅長(cháng)的(de)是思考，而不是記憶
成為(wèi)一(yī)個“獨當一(yī)面”的(de)人
獨當一(yī)面是一(yī)個很性感的(de)詞。是否擁有它，對應的(de)職場價值，有着天壤之别的(de)。
所有老闆都喜歡“獨當一(yī)面”的(de)員工，因為(wèi)這是最省心力、最好算賬的(de)模式:給你一(yī)塊資源，給你一(yī)個 title，給你一(yī)個目标，然後你給我打出一(yī)片天地(dì)來。
當你能獨立對一(yī)攤子(zǐ)事情負責，并把它們一(yī)一(yī)搞定，你會擁有大幅度的(de)職場溢價--相應的(de)，其收入回報，也遠非“技術螺絲”可(kě)比了。
如(rú)果你很進取，你會逐漸地(dì):主導一(yī)個小組，一(yī)個部門，一(yī)個家庭，甚至還是城市……而這所有的(de)一(yī)切起點，正是獨立完整地(dì)做(zuò)好一(yī)個項目:你沒有誰可(kě)以依靠，你要對其中大大小小的(de)事務負責，你要對最後的(de)結果。
換句話說，“項目管理(lǐ)”是“獨當一(yī)面”的(de)元能力。在這個過程中，你的(de)意識越發清晰，你的(de)方法論越發成熟，你的(de)信心更加沛，項目越做(zuò)越大。直到某天，你真的(de)有了掌控一(yī)方的(de)封疆大吏。
這就是我們學(xué)習“項目實戰”的(de)終極意義。
或許作為(wèi)程序員的(de)你想提升自(zì)己，卻找不到突破口，公司沒人帶。又或許你已經工作6年(nián)了，卻還是很迷茫，很多知識都還是不懂，也沒有達到自(zì)己期望的(de)一(yī)個職位，薪資。
到這裏，你可(kě)能認為(wèi)文章(zhāng)已經完了，學(xué)完這些就可(kě)以去(qù)BAT大公司做(zuò)一(yī)個架構師，年(nián)薪50W+嗎?
不，你錯了，這些都知識最基本的(de)知識，想要成為(wèi)一(yī)個架構師必須是一(yī)個累積的(de)過程，也是這麽多程序員終其一(yī)生也隻是一(yī)個開發，到年(nián)齡就會被公司辭退。
這些也是架構師必須要了解到的(de)知識。
編程能力
對工程師而言，編程是最基礎的(de)能力，必備技能。其本質是一(yī)個翻譯能力，将業務需求翻譯成機器能懂的(de)語言。
提升編程能力的(de)書籍有很多。精通面向對象和(hé)設計模式是高(gāo)效編程的(de)基礎。初級工程師應該多寫代碼、多看代碼。找高(gāo)手做(zuò)Code Review，也是提升編程水平的(de)捷徑。
編譯部署能力
編譯并在線上部署運行程序是系統上線的(de)最後一(yī)個環節。随着SOA架構的(de)普及以及業務複雜度的(de)增加，大部分系統隻是一(yī)個完整業務的(de)一(yī)個環節，因此，本地(dì)編譯和(hé)運行并不能完全模拟系統在線運行。為(wèi)了快速驗證所編寫程序的(de)正确性，編譯并在線上部署就成了必要環節。所以編譯部署能力是一(yī)個必備技能。
讓盤根錯節的(de)衆多子(zǐ)系統運行起來是個不小的(de)挑戰。得益于SOA架構的(de)普及以及大量編譯、部署工具的(de)發展，編譯部署的(de)門檻已經大大降低(dī)。基于應用層進行開發的(de)公司，已經很少有“編譯工程師”的(de)角色了。但是對于初級工程師而言，編譯部署仍然不是一(yī)個輕松的(de)事情。
性能優化能力
衡量一(yī)個系統成功的(de)一(yī)個重要指标是使用量。随着使用量的(de)增加和(hé)業務複雜度的(de)增加，大部分系統最終都會碰到性能問題。性能優化能力是一(yī)個綜合能力。因為(wèi):
影響系統性能的(de)因素衆多，包括:數據結構、操作系統、虛拟機、CPU、存儲、網絡等。為(wèi)了對系統性能進行調優，架構師需要掌握所有相關的(de)技術。
精通性能優化意味着深刻理(lǐ)解可(kě)用性、可(kě)靠性、一(yī)緻性、可(kě)維護性、可(kě)擴展性等的(de)本質。
性能優化與業務強耦合，最終所采取的(de)手段是往往折衷的(de)結果。所以，性能優化要深谙妥協的(de)藝術。
可(kě)以說，性能優化能力是工程師們成長(cháng)過程中各種技能開始融會貫通的(de)一(yī)個标志。這方面可(kě)以參考之前的(de)博客文章(zhāng)“常見性能優化策略的(de)總結”。市場上還有很多與性能優化相關的(de)書籍，大家可(kě)以參考。多多閱讀開源框架中關于性能優化方面的(de)文檔和(hé)代碼也不失為(wèi)好的(de)提升手段。動手解決線上性能問題也是提升性能優化能力的(de)關鍵。如(rú)果有機會，跟着高(gāo)手學(xué)習，分析性能優化解決方案案例(我們技術博客之前也發表了很多這方面的(de)文章(zhāng))，也是快速提升性能優化能力的(de)手段。
調試能力
程序代碼是系統的(de)靜态形式，調試的(de)目的(de)是通過查看程序的(de)運行時狀态來驗證和(hé)優化系統。本質上講，工程師們通過不斷調試可(kě)以持續強化其通過靜态代碼去(qù)預測運行狀态的(de)能力。所以調試能力也是工程師編程能力提升的(de)關鍵手段。很早之前有個傳說:“調試能力有多強，編程能力就有多強。”不過現在很多編輯器的(de)功能很強大，調試能力的(de)門檻已經大大降低(dī)。
調試能力是項目能否按時、高(gāo)質量提交的(de)關鍵。即使一(yī)個稍具複雜度的(de)項目，大部分工程師也無法一(yī)次性準确無誤的(de)完成。大項目都是通過不斷地(dì)調試進行優化和(hé)糾錯的(de)。所以調試能力是不可(kě)或缺的(de)能力。
多寫程序，解決Bug，多請教高(gāo)手是提升調試能力的(de)重要手段。
在線運維能力
如(rú)果說性能優化能力體現的(de)是架構師的(de)靜态思考能力，在線運維能力考驗的(de)就是動态反應能力。殘酷的(de)現實是，無論程序多麽完美，Bug永遠存在。與此同時，職位越高(gāo)、責任越大，很多架構師需要負責非常重要的(de)在線系統。對于線上故障，如(rú)果不能提前預防以及快速解決，損失可(kě)能不堪設想，所以在線運維能力是優秀架構師的(de)必備技能。
為(wèi)了對線上故障進行快速處理(lǐ)，标準化的(de)監控、上報、升級，以及基本應對機制當然很重要。通過所觀察到的(de)現象，快速定位、緩解以及解決相關症狀也相當關鍵。這要求架構師對故障系統的(de)業務、技術具備通盤解讀能力。解決線上故障的(de)架構師就好比一(yī)個在參加比賽F1的(de)車手。賽車手必須要了解自(zì)身、賽車、對手、同伴、天氣、場地(dì)等所有因素，快速決策，不斷調整。架構師必須要了解所有技術細節、業務細節、處理(lǐ)規範、同伴等衆多因素，快速決斷，迅速調整。
在線運維本質上是一(yī)個強化學(xué)習的(de)過程。很多能力都可(kě)以通過看書、查資料來完成，但在線運維能力往往需要大量的(de)實踐來提升。
業務架構能力
工程師抱怨産品經理(lǐ)的(de)故事屢見不鮮，抱怨最多的(de)主要原因來自(zì)于需求的(de)頻繁變更。需求變更主要有兩個來源:第一(yī)個原因是市場改變或戰略調整，第二個原因是僞需求。對于第一(yī)個原因，無論是工程師還是産品經理(lǐ)，都隻能無奈的(de)接受。優秀的(de)架構師應該具備減少第二種原因所導緻的(de)需求變更的(de)概率。
僞需求的(de)産生有兩個原因:
第一(yī)個原因是需求傳遞變形。從信息論的(de)角度來講，任何溝通都是一(yī)個編碼和(hé)解碼的(de)過程。典型的(de)需求從需求方到産品經理(lǐ)，最終到開發工程師，最少需要經曆三次編碼和(hé)解碼過程。而信息的(de)每一(yī)次傳遞都存在一(yī)些損失并帶來一(yī)些噪音，這導緻有些時候開發出來的(de)産品完全對不上需求。此外，需求方和(hé)産品經理(lǐ)在需求可(kě)行性、系統可(kě)靠性，開發成本控制方面的(de)把控比較弱，也會導緻需求變形。
第二個原因就是需求方完全沒有想好自(zì)己的(de)需求。
優秀的(de)架構師應該具備辨别真僞需求的(de)能力。應該花時間去(qù)了解客戶的(de)真實業務場景，具備較強的(de)業務抽象能力，洞悉客戶的(de)真實需求。系統的(de)真正實施方是工程師，在明确客戶真實需求後，高(gāo)明的(de)架構師應該具備準确判斷項目對可(kě)行性、可(kě)靠性、可(kě)用性等方面的(de)要求，并能具備成本意識。最後，由于需求與在線系統的(de)緊耦合關系，掌握在線系統的(de)各種細節也是成功的(de)業務架構的(de)關鍵。随着級别的(de)提升，工程師所面對的(de)需求會越來越抽象。承接抽象需求，提供抽象架構是架構師走向卓越的(de)必經之途。
市場上有一(yī)些關于如(rú)何成為(wèi)架構師的(de)書，大家可(kě)以參考。但是架構能力的(de)提升，實踐可(kě)能是更重要的(de)方式。業務架構師應該關注客戶的(de)痛點而不是PRD文檔，應該深入關注真實業務。掌握現存系統的(de)大量技術和(hé)業務細節也是業務架構師的(de)必備知識。
項目管理(lǐ)能力
作為(wèi)工業時代的(de)産物，分工合作融入在互聯網項目基因裏面。架構師也需要負責幾個重大項目才能給自(zì)己正名。以架構師角色去(qù)管理(lǐ)項目，業務架構能力當然是必備技能。此外，人員管理(lǐ)和(hé)成本控制意識也非常重要。
項目管理(lǐ)還意味着要有一(yī)個大心髒。重大項目涉及技術攻關、人員變動、需求更改等衆多可(kě)變因素。面臨各種變化，還要在确保目标順利達成，需要較強的(de)抗壓能力。
人員管理(lǐ)需要注意的(de)方面包括:知人善用，優化關系，簡化溝通，堅持真理(lǐ)。
知人善用意味着架構師需要了解每個參與者的(de)硬技能和(hé)軟素質。同時，關注團隊成員在項目過程中的(de)表現，按能分配。
優化關系意味着管理(lǐ)團隊的(de)情緒，畢竟項目的(de)核心是團隊，有士氣的(de)團隊才能高(gāo)效達成目标。
簡化溝通意味着快速決策，該妥協的(de)時候妥協，權責分明。
堅持真理(lǐ)意味着頂住壓力，在原則性問題上絕不退步。
成本控制意味着對項目進行精細化管理(lǐ)，需要遵循如(rú)下幾個原則:
以終為(wèi)始、确定裏程碑。為(wèi)了達成目标，所有的(de)計劃必須以終為(wèi)始來制定。将大項目分解成幾個小階段，控制每個階段的(de)裏程碑可(kě)以大大降低(dī)項目失敗的(de)風險。
把控關鍵路徑和(hé)關鍵項目。按照關鍵路徑管理(lǐ)理(lǐ)論(CPM)的(de)要求，架構師需要确定每個子(zǐ)項目的(de)關鍵路徑，确定其最早和(hé)最晚啓動時間。同時，架構師需要關注那些可(kě)能會導緻項目整體延期的(de)關鍵節點，并集中力量攻破。
掌控團隊成員的(de)張弛度。大項目持續時間會比較長(cháng)，也包含不同工種。項目實施是一(yī)個不斷變化的(de)動态過程，在這個過程中不是整個周期都很緊張，不是所有的(de)工種都一(yī)樣忙。優秀的(de)架構師必須要具備精細閱讀整體項目以及快速反應和(hé)實時調整的(de)能力。這不僅僅可(kě)以大大降低(dī)項目成本，還可(kě)以提高(gāo)産出質量和(hé)團隊滿意度。總體來說，“前緊後松”是項目管理(lǐ)的(de)一(yī)個重要原則。
項目管理(lǐ)方面的(de)書籍很多。但是，提高(gāo)業務架構能力同樣重要。積極參與大項目并觀察别人管理(lǐ)項目的(de)方式也是非常重要的(de)提升手段。
團隊管理(lǐ)能力
不想做(zuò)CTO的(de)工程師不是一(yī)個好的(de)架構師。走向技術管理(lǐ)應該是工程師的(de)一(yī)個主流職業規劃。團隊管理(lǐ)的(de)一(yī)個核心能力就是規劃能力，這包括項目規劃和(hé)人員規劃。良好的(de)規劃需要遵循如(rú)下原則:
規劃是利益的(de)博弈。良好的(de)規劃上面對得起老闆，中間對得起自(zì)己，下面對得起團隊。在三者利益者尋找平衡點，實現多方共赢考驗着管理(lǐ)者的(de)智慧和(hé)精細拿捏的(de)能力。
任何規劃都比沒有規劃好。沒有規劃的(de)團隊就是沒頭的(de)蒼蠅，不符合所有人的(de)利益。
規劃不是本本主義。市場在變，團隊在變，規劃也不應該一(yī)成不變。
客戶至上的(de)是項目規劃的(de)出發點。
就人員規劃而言，規劃需要考量團隊成員的(de)能力、績效、成長(cháng)等多方面的(de)因素。
編輯:--ns868
