概述

言之有物，論之有據(jù)才是有效的交談。

我們是工程師，我們的理想是做出完美的產(chǎn)品，我們希望人類能夠通過我們的產(chǎn)品來改變某種生活習(xí)慣。在很多情況下我們都在默默的付出，為商務(wù)人員對客戶的售后提供強(qiáng)力而有效的技術(shù)保障?？赡苁且?yàn)槲覀兞?xí)慣了默默的奉獻(xiàn)，平時沒有注意過與人交流，故而會出現(xiàn)自己明明知道的東西卻說不出來的情況。我們是曾經(jīng)努力過，我們是做出許多傲人的成績，但是如果我們不能說出來，別人會知道嗎？難道能讓別人去猜我們是什么樣的人？

默默的付出其實(shí)就是在閉門造車，我們要把自己的想法的打算說出來，我們要告訴產(chǎn)品經(jīng)理我們隊建設(shè)良好應(yīng)用的看法。我們要告訴領(lǐng)導(dǎo)，我們對架構(gòu)的設(shè)計。我們要告訴其它工程師，我們對代碼的想法。或許你真的是才華橫溢，但如果連介紹自己都不會，沒人會看好你。我們是工程師，不是程序員也不是碼農(nóng)，我們需要為自己的閉門造車打開一扇窗戶。

本文主要是以我親身的經(jīng)歷，從發(fā)言者的角度來探索該如何去發(fā)言，如何表達(dá)出內(nèi)心的想法。本文也是我對自己犯過的錯的反思。

問題

我們勤奮努力，我們有理想有追求，我們認(rèn)為做比說更重要，但是我們無法完美的表達(dá)自己，我們的辛苦幾乎不被人理解。

層次

層次就是對具體事物的抽象，想要有效的表達(dá)你的思想。不要再試圖向業(yè)務(wù)人員/客戶或與項(xiàng)目不相干的人員介紹你的代碼，他們只關(guān)心功能。我曾經(jīng)試過向客戶從技術(shù)角度來解釋我所負(fù)責(zé)的項(xiàng)目的優(yōu)勢，我告訴他以我們的的系統(tǒng)經(jīng)過預(yù)編譯，多級緩存等策略優(yōu)化后，我們的系統(tǒng)能夠在雙機(jī)環(huán)境下吞吐量達(dá)到300?？蛻糁换貜?fù)了我:"xx公司的系統(tǒng)并發(fā)能達(dá)到5000。"聽見客戶這么說我真的想給他解釋清楚在雙機(jī)條件下涉及到大數(shù)據(jù)分析的時候，我們無法使用內(nèi)存存儲全部數(shù)據(jù)，所謂的并發(fā)5000真的是不可能，xx公司肯定是在騙人。

工程師都知道，系統(tǒng)訪問一次數(shù)據(jù)庫都需要幾十至數(shù)百毫秒，何況我們業(yè)務(wù)的要求每次核心操作都需要操作數(shù)十次數(shù)據(jù)庫中的數(shù)據(jù)。先不說應(yīng)用進(jìn)程與數(shù)據(jù)庫進(jìn)程之間的通信損耗，單是磁盤尋址時間就是現(xiàn)代服務(wù)器無法克服的性能瓶頸。但是我們能告訴客戶嗎？即便花上一兩個小時給客戶分析明白為什么說300就是極限，為什么5000是騙人又有什么意義呢？客戶關(guān)心的只是業(yè)務(wù)，只要能在保證數(shù)據(jù)精準(zhǔn)無差的前提下把功能給實(shí)現(xiàn)了，這就是合格。

一個項(xiàng)目有技術(shù)層次的理解，有業(yè)務(wù)層次的理解，有對細(xì)節(jié)方面的理解，也有對整體流程的理解。我們要給項(xiàng)目進(jìn)行一個抽象，分別建立出業(yè)務(wù)層，架構(gòu)層，代碼層和核心功能層，簡要介紹層。當(dāng)遇到一個圈外人只想知道這個項(xiàng)目能干嘛的時候，我們只需要給別人簡單的說一下簡要介紹層的知識。例如當(dāng)一個從沒用過微信的人問你微信可以干嘛，你就應(yīng)該回答他：“微信是一個實(shí)時聊天工具，可以免費(fèi)的跟朋友進(jìn)行聊天，通話與視頻。”可以試想一下如果你拿業(yè)務(wù)層的知識來回答：“微信可以發(fā)表情，表情是一種比聊天更好玩的交流方式?？梢越ㄈ毫?，可以發(fā)朋友圈，朋友圈是。。?！?，這樣對方一定很疑惑。如果你直接回答：“微信是一個C/S架構(gòu)的，有數(shù)萬臺服務(wù)集群提供服務(wù)，擁有2億用戶高性能高可用的應(yīng)用。。。”對方一定會直接懵了。

在向別人介紹你你自己或你的產(chǎn)品之前，首先你要對要介紹的內(nèi)容根據(jù)聽眾的需求進(jìn)行抽象，抽象的方法就是盡量講些讓聽眾能夠清晰理解的，盡量少用專業(yè)名詞。當(dāng)然恰當(dāng)?shù)氖褂脤I(yè)名詞更能說明你的專業(yè)性。

條理

條理不清晰是一個貶義詞，意思是說一個人說話天馬行空，無跡可尋。條理不清晰就意為著可能你滔滔不絕的長篇大論過后，聽眾都不知道你在說什么。

以你工作中都是如何進(jìn)行性能優(yōu)化這個話題為例。你可能不假思索的就可以回答：

• 首先我會優(yōu)化慢SQL，因?yàn)樵诂F(xiàn)在系統(tǒng)中一般情況下性能瓶頸都是出現(xiàn)在數(shù)據(jù)庫上，所以第一步先優(yōu)化SQL。
• 代碼上的優(yōu)化，如不要在循環(huán)中寫異常捕獲等具體優(yōu)化方法。
• 看系統(tǒng)中有沒有長時間阻塞的線程，優(yōu)先進(jìn)行去鎖優(yōu)化，如果實(shí)在需要保證線程安全，那就盡量使用輕量級鎖，讀寫鎖，注意重入鎖等作為優(yōu)化策略。
• 其次根據(jù)實(shí)際需要設(shè)置大小合適的堆空間，然后選擇合適的垃圾收集算法（如注重響應(yīng)時間就選擇CMS或G1）。

上述回答的確是一般的優(yōu)化方法，你能回答以上的答案可以證明你確實(shí)做過性能優(yōu)化，知道一般的優(yōu)化點(diǎn)在哪里，但是這么講解著實(shí)有不妥之處。當(dāng)我們要回答一個問題時，我們首先需要知道在哪會發(fā)生這個問題，然后尋找問題發(fā)生的原因，最后再提出解決方案，動手解決問題。性能優(yōu)化和我們在生活中遇見的大多數(shù)問題一樣，沒有什么固定程序的解決方案。

還回到上個問題上面，當(dāng)我們發(fā)布性能優(yōu)化的論述時，如果按照以下步驟可能有條理點(diǎn)：

• 當(dāng)項(xiàng)目不再能滿足性能需求時，首先我們需要找到性能的瓶頸點(diǎn)?？梢酝ㄟ^linux的top命令分析一下各個服務(wù)器的主要瓶頸是在cpu上、內(nèi)存上還是I/O上。

• 首先是應(yīng)用服務(wù)器，如果瓶頸在CPU上，首先定位最耗資源的進(jìn)程，借助jvm的一些工具如JProfiles，jvisualvm等工具我們還可以將問題定位到代碼上。然后再詳細(xì)分析哪些操作造成了高密度的CPU運(yùn)算，嘗試是否有優(yōu)化的余地。

• 如果系統(tǒng)CPU阻塞時間比很大且I/O負(fù)載過高，則首先去分析這個負(fù)載是來自于磁盤還是網(wǎng)卡，則嘗試尋找降低阻塞原因，找到硬件資源瓶頸，然后使用NIO等技術(shù)降低系統(tǒng)阻塞。

• 如果系統(tǒng)內(nèi)存占用很大，則需要定位具體進(jìn)程。如果占用內(nèi)存過大的是我們的應(yīng)用，則需要查看JVM堆空間設(shè)置，看是否是堆空間設(shè)置不合理或者使用了大量的直接內(nèi)存而沒有釋放。

• 如果還沒定位到問題，則嘗試分析JVM中的線程快照，看是否有死鎖或長時間持有互斥鎖的線程，并嘗試優(yōu)化這些。

• 接著才是垃圾回收策略的等虛擬機(jī)參數(shù)級的優(yōu)化。

• 若問題在以上應(yīng)用服務(wù)器優(yōu)化思路下沒有優(yōu)化空間，或者優(yōu)化后也無法滿足性能需求，可以考慮布置集群或給集群增加機(jī)器。

以上幾條只是簡要的說明了應(yīng)用服務(wù)器的優(yōu)化思路，對于數(shù)據(jù)庫服務(wù)器和緩存服務(wù)器，根據(jù)他們不同的業(yè)務(wù)需要有專屬的優(yōu)化方案，本文不再對此作出詳細(xì)討論。當(dāng)我們要向聽眾去介紹一個方案或設(shè)計時，可以依照先定位問題，再分析問題，最后再提出解決方案，實(shí)施方案的過程來逐步的展現(xiàn)我們的思想。在這種條理下我們的私立也鞥更加清晰，不至于因漫談而忘記重點(diǎn)。

總結(jié)

剛剛說到了條理，我們怎么能讓我們演講時更有條理呢？想要有條理就要善于總結(jié)，并且將總結(jié)作為一種習(xí)慣。只有經(jīng)過總結(jié)后的語言才能更有條理，除非你有很高的演講技巧，否則不要將總結(jié)的時間放到你將要說話前一刻，不然你在演講前的緊張會讓你根本無心總結(jié)。

為演示總結(jié)的好處，我在這里提問一個簡單的問題，什么樣的代碼才是好代碼？

作為工程師，你一定有自己的衡量代碼好壞的標(biāo)準(zhǔn)，不知你是否總結(jié)過這個問題？ 假如你沒有總結(jié)過，這個問題你可能這么回答：

• 可擴(kuò)展性
• 易讀性
• 架構(gòu)，符合項(xiàng)目需求
• 代碼不要太冗余
• 整體的風(fēng)格保持統(tǒng)一
• 好性能

當(dāng)然你可能有回答出其他的特性，我們暫且拋開，我這邊有幾條經(jīng)過總結(jié)后可能更好的答案：

• 領(lǐng)域驅(qū)動，完全滿足需求，可測試
• 整潔規(guī)范，注釋清晰，可讀性高
• 簡單高效，邏輯清晰，性能優(yōu)秀
• 善于抽象，層次合理，避免重復(fù)
• 高內(nèi)聚，低耦合，易于擴(kuò)展維護(hù)

事實(shí)

事實(shí)勝于雄辯！再好的理論如果沒有實(shí)例的支撐也只是空談。

比如我們上面所說到的“總結(jié)”這一節(jié)里，我們總結(jié)了幾條好代碼的標(biāo)準(zhǔn)，乍一聽好像很有理，但仔細(xì)想又空無一物，這種情況出現(xiàn)的原因就是我們沒有拿出事實(shí)論證，沒有實(shí)例去支撐。對于“簡單高效，邏輯清晰，性能優(yōu)秀”這條，我們可以進(jìn)行一個舉例說明。假如我們以前使用100行代碼才能完成一個Excel文件導(dǎo)出的代碼，而現(xiàn)在我們只需要10行代碼就能完成這項(xiàng)工作，那么這10行代碼相對來說就是好代碼。

對于其它幾條所涉及的事實(shí)，這邊不再一一講述，如果你對此有興趣，可以翻看一下spring的源碼，看看spring是如何的設(shè)計成“高內(nèi)聚，低耦合，易于擴(kuò)展維護(hù)”如何層次合理。

故而當(dāng)我們需要表達(dá)時，說出理論總結(jié)后，或者在總結(jié)前，盡量的拿出具體事實(shí)來為自己的總結(jié)做一個證據(jù)，讓別人對你的觀點(diǎn)深信不疑。

最后

在文章的背后我還是要說明，我們是工程師，應(yīng)當(dāng)以知識為重。所有的交流都在我們具有業(yè)務(wù)知識或技術(shù)知識的前提之下，所以不可因鍛煉交流放棄知識學(xué)習(xí)。你會什么很重要，把你的知識或者知識轉(zhuǎn)化的產(chǎn)品分享出來同樣重要。

引用

在寫作本文的受過一位阿里的不知名的前輩的提點(diǎn)，為為在此謝過。今天必是我在成為架構(gòu)師之路上邁出的又一關(guān)鍵步伐。

關(guān)于

本項(xiàng)目和文檔中所用的內(nèi)容僅供學(xué)習(xí)和研究之用，轉(zhuǎn)載或引用時請指明出處。如果你對文檔有疑問或問題，請在項(xiàng)目中給我留言或發(fā)email到
weiwei02@vip.qq.com 我的github:
https://github.com/weiwei02/ 我相信技術(shù)能夠改變世界 。