最近看了一本書，叫做 《The Effective Engineer》，中文名翻譯過來大概就是《高效率工程師》這種吧。收益良多，決定寫一下讀書筆記，因為書里面的 Engineer 大部分指的就是從事開發(fā)的程序員，所以后面我多數(shù)會用研發(fā)，程序員來表示了。

選擇正確的思維模式

關(guān)注高杠桿率事項

阿基米德曾經(jīng)說過『給我一個支點，我能翹起地球』，當然，這話他到底說過沒有，我們先不糾結(jié)，這里要表述的意思很明確，就是杠桿的力量。對于高效率來說，可以用如下的公式來表示：

杠桿 = 產(chǎn)生的影響力 / 投入的時間

作為一個工程師，要做高效率的事情，自然將事情做到高杠桿率，做法就可能有三種：

1. 減少完成這件事情的時間
2. 提升這件事情的影響力
3. 切換到另一個有更高杠桿率的事情上

上面列出來的幾個方法，已經(jīng)非常的直白容易實施了，譬如對于數(shù)據(jù)庫的優(yōu)化，我們可以這么做：

1. 使用更好的工具來定位性能問題，如常用的 perf，VTune 這些，減少定位性能問題的時間。
2. 深刻的理解 workload，知道哪些請求是高頻率的，或者哪些請求是最消耗資源的，解決這些大頭問題。
3. 發(fā)現(xiàn)搞不定，讓業(yè)務(wù)去調(diào)整代碼，譬如加個索引啥的，短期不做無謂的優(yōu)化了。

優(yōu)化學習方式

俗話說，活到老，學到老，我們其實需要不斷的學習，不斷去提升精進自己。不過要接受這個，首先得讓我們具備成長型思維。大家應(yīng)該的聽說過固定型思維和成長型思維，沒有的話可以看看《終身成長》這本書，大概了解一下。總的來說，就是我們需要構(gòu)建一個成長型的思維模式，如何做這個，網(wǎng)上其實有很多方式，譬如：

1. 承認并且接受自己的不完美
2. 勇敢的面對挑戰(zhàn)，視挑戰(zhàn)為機會
3. 嘗試不同的學習策略
4. 。。。。。。

當有了成長型思維之后，下一個要做的就是投資我們的學習率。大家應(yīng)該都聽過復利，在投資的早期，收益其實是很低的，但隨著時間的推移，收益率會越來越高。其實學習也是類似的情況，所以越早學習，學得越多，后面學習新的東西就會越容易。

當然，對于工作的我們來說，最好的做法就是能在工作中學習，如果我們能加入一個快速成長的公司（譬如 PingCAP），你在里面能接觸各種各樣有挑戰(zhàn)的事情，能快速的學習成長。如果一個公司里面有很多牛人（再一次，譬如 PingCAP），你也可以通過從他們身上學習到很多事情，譬如你可以看他們寫的代碼，或者讓他們幫你去 review 你的代碼，或者你的設(shè)計，這些都是能提升自己的方式。

當然，在工作之外，其實也是需要學習的，雖然很多人講究生活和工作的平衡，但有時候，我還是希望大家能在業(yè)余時間多花時間來提升自己。我們可以多看幾本書，多學習一門新的語言，這些都是能讓我們變成一個更高效工程師的方式。

習慣優(yōu)先排序

當我們開始關(guān)注高杠桿事情之后，自然會面對事情優(yōu)先級的問題。這方面其實相關(guān)的書籍也不少，譬如著名的《高效能人士的七個習慣》這本書，就把事情分成了四象限：

• 象限 1 - 緊急 + 重要
• 象限 2 - 不緊急 + 重要
• 象限 3 - 緊急 + 不重要
• 象限 4 - 不緊急 + 不重要

我們自然要盡量去避免做象限 3 和 4 的事情，但有時候，我們會大量的精力去處理象限 1 的事情，但實際，我們最應(yīng)該放精力的是象限 2，也就是重要不緊急的事情，這樣才能讓我們長期成長。

另外，在做事情的時候，我們還會面臨一個問題，就是拖延，人都是有惰性的，要戰(zhàn)勝惰性，有一個簡單的方法可以試試，這個就是 if-then，如果我們要進行一項任務(wù)，可以在它之前設(shè)定一個場景開關(guān)，也就是如果發(fā)生了什么事情，那我就應(yīng)該干這項任務(wù)了。這樣沒準能戰(zhàn)勝拖延了。

執(zhí)行，執(zhí)行，執(zhí)行

投資迭代速度

只有跑的更快，才能學習的更快，在這個世界上，唯一不變的只有變化。對于程序員，或者 team，或者公司來說，要讓自己的效率更高，一個很重要的點就是：『工欲善其事必先利其器』。

工具對程序員的重要性毋庸置疑，但恰恰很多程序員忽略了工具的重要性，他們疲于開發(fā)，總覺得自己寫得多就代表著效率高，但實際確是在不斷的給自己挖坑。

PingCAP 可以算是一個非常重視工具的公司，我們相信能自動化用工具去解決的，絕對不依靠人力來弄，這樣才能保證整個研發(fā)團隊的高效率。譬如，我們研發(fā)了 Chaos 自動化測試平臺，幫我們發(fā)現(xiàn)不少穩(wěn)定性問題，引入了 Fuzzing 工具，來保證 SQL 的 logic 都能正確處理，這些工具很好的保證了我們整個產(chǎn)品的快速迭代。

那么對于程序員來說，除了有意識的要重視起工具，一些簡單的方法也可以嘗試：

1. 更好的熟悉 IDE 的快捷鍵，畢竟打字的速度還是比移動鼠標快多了
2. 學至少一門高級的腳本語言，來簡化自己很多流程化工作。
3. 熟悉并且掌握 shell，尤其是數(shù)據(jù)處理，通過 shell 比自己手工來搞方便太多
4. 。。。。。。

當然，程序員不能只盯著自己的技術(shù)，在其他方面，也需要提升，只有全面發(fā)展了，才可以迭代的更快。這里可以看看《軟技能：代碼之外的生存指南》這本書，來學習如何提升自己的軟技能。

測量我們想提升的事項

如果我們要迭代，一個自然的問題，就是如何衡量我們的迭代是有效的。這里，就可以使用最常用的辦法 - metrics。

大家在做性能優(yōu)化的時候，通常也會在一些關(guān)鍵的地方加上 metrics，然后通過 metrics 來衡量優(yōu)化是否有效果，對于我們自己也是一樣。當然，我們要先選對 metrics，畢竟錯誤的 metrics 反倒是會讓我們變得更加不高效，譬如如果我們用每周工作時長來衡量一個程序員的產(chǎn)出，那么最后就會變成大家為了看起來產(chǎn)出高，而在工作的時候混日子，拖時間。要選擇一個正確的 metrics，通?？梢躁P(guān)注以下幾個指標：

1. 最大影響，就跟優(yōu)化一樣的，我們通常會首先關(guān)注開銷最大的地方。
2. 可執(zhí)行，也就是這些 metrics 的提升真的是因為我們的努力而變化的。
3. 可反應(yīng)，這些 metrics 能很直觀對變化給與正負反饋。

當我們有了計劃，有了 metrics，自然就可以去執(zhí)行，去實施，不過需要注意的是在實施的時候也需要時刻知道事情的進展，別偏離方向。我們可以使用工具來記錄，譬如對于我們自己系統(tǒng)，可以使用 Prometheus 來保存 metrics，這樣我們就能知道整個歷史的變化了。

不過最重要的一點，就是記錄的數(shù)據(jù)一定要是真是的，錯誤的數(shù)據(jù)甚至比沒有數(shù)據(jù)還要糟糕，因為這可能會讓我們進行錯誤的決策。

更快，更頻繁的去驗證我們的想法

要迭代的更快，一個必要的事情就是要更快的去驗證我們的想法。這里有一個詞，叫做 MVP - Minimum viable product，也就是最小化的可行產(chǎn)品。我們需要很多小的工作，來收集數(shù)據(jù)，從而驗證我們的假設(shè)和目標。

要對產(chǎn)品迭代，通常一個比較好的做法就是進行 A/B testing，同時建立起來完善的反饋循環(huán)，讓我們知道每一次決定是不是對的。

增強我們項目評估技能

對于工程師來說，還需要鍛煉的一個能力就是項目評估技能，程序員向來喜歡高估自己的能力，低估事情的復雜度，項目時間通常預估不準，導致項目延期。所以我們需要使用更加精確的預估手段來推進項目，下面是一些可行的方案：

1. 將項目拆分成更加細粒度的任務(wù)，
2. 基于任務(wù)實際會耗時多久來評估，而不是基于我們或者其他人覺得要花多久時間
3. 基于概率統(tǒng)計來評估，而不是基于最好的情況來
4. 讓實際做任務(wù)的人來進行評估
5. 使用多種方式來評估同一個任務(wù)
6. 通過歷史數(shù)據(jù)來驗證評估是否合理
7. 使用時間窗口來限制任務(wù)的時間
8. 允許其他人來質(zhì)疑我們的評估

最后，無論我們選擇了什么方案，一點需要注意的是，一定要給未知的東西預留時間，也就是要給自己留點 buffer，隨時應(yīng)變。

當我們評估完成時間之后，需要設(shè)置好清晰的計劃，以及可衡量的里程碑，讓我們盡量走在正確的道路上。這里幾點要注意：

1. 要盡快的減少并且規(guī)避風險，甚至需要先把風險最高的事情搞定
2. 對于從頭造輪子，要保持足夠的警覺
3. 要懂得項目是跑馬拉松，不要再中途就多次沖刺，保持合理的節(jié)奏，當然有時候稍微提速也是可以的

構(gòu)建長期價值

務(wù)實的平衡品質(zhì)

有時候，項目的快速發(fā)展跟品質(zhì)是有沖突的，所以這里我們需要好好的平衡兩者的關(guān)系。

首先，我們需要建立 code review 的文化，不允許大家隨意的增加功能，隨意的合并代碼。雖然這個可能會影響產(chǎn)品進度，但好處不言而喻。在 PingCAP，我們有著嚴格的 code review 流程，一個程序員如果要開發(fā)一個新的功能，他需要提交 RFC，只有 RFC 被通過了，才能進行開發(fā)，當然，他也可以先自己做點原型驗證，讓 RFC 更容易被通過。每個 PR，我們至少需要兩個人 review 并且 approve 才能 merge。

在代碼層面，我們需要鼓勵抽象，使用抽象來封裝復雜的邏輯，保證代碼容易學習，容易使用，容易擴展。代碼的測試一定要跟上，一定要重視自動化測試，這個很多研發(fā)都不喜歡寫測試，覺得那是 QA team 的事情，但恰恰研發(fā)是最應(yīng)該懂測試的。

最小化操作負擔

對于一個產(chǎn)品來說，易用性是非常關(guān)鍵的，我們一定要保證操作的簡單，這點其實 TiDB 還有很大的進步空間，所以非常歡迎大家加入幫助我們一起來改進，如果你有任何易用性上面的問題，歡迎聯(lián)系我。

投資整個 team 的成長

當然，除了要關(guān)注產(chǎn)品價值，整個 team 也是要仔細考慮的，畢竟得先有人，才能做出來產(chǎn)品。要保證 team 不斷的成長，所以我們需要建立一個不錯的工程師文化，主要包括：

1. 不斷的優(yōu)化迭代速度，實施 MVP
2. 自動化，自動化，自動化
3. 對代碼進行正確的抽象
4. 關(guān)注代碼質(zhì)量，強制 code review
5. 建立一個有尊嚴的工作環(huán)境
6. 培養(yǎng)一個持續(xù)學習的文化，并不斷的完善
7. 給自己分配一點做研究的時間，譬如每周 20% 時間，或者通過 hackathon
8. 。。。。。。

寫在最后

好了，說了這么多，我們一直在聊的是高效，上面只是我的一些對照書的簡單總結(jié)。如果你能看到這里，我表示很佩服，因為現(xiàn)在要說重點的東西了。

作為一個程序員，高效是需要融入到自己骨子里面的，但是，很多同學一定會很苦悶到底如何才能變得高效？自然，一個很簡單的辦法就是加入一個高效率的公司。如果一個公司從上到下都是推崇的高效率工程師文化，待在里面，自然也就能潛移默化的變得高效了。很自豪的說，PingCAP 就是這樣一家公司 :-)

不過，這里我還會更進一步，在 PingCAP 里面，有一只神秘的特種部隊，天生是為高效而生的，它的名字就是 Effective Tool Team，簡稱 ET Team，沒錯，這個就是致敬 E.T. 外星人的。

在 ET team 里面，我們立足于使用最少的資源來解決最大的問題，也就是會關(guān)注于杠桿的那個支點。在 ET team，你會：

• 研究不同的測試技術(shù)，譬如 Chaos，F(xiàn)uzzing，Performance regression，來不斷的去提升 TiDB 的質(zhì)量。
• 研究不同的 bot 技術(shù)，讓 PingCAP 的整個工作流自動化運轉(zhuǎn)。
• 研究各種診斷工具，通過開發(fā) ftrace，bcc，eBPF，perf 等工具來讓整個系統(tǒng)的運轉(zhuǎn)在你的面前了無秘密。你甚至可以去 hack Linux 內(nèi)核。
• 參與到 TiDB 的研發(fā)，尤其是涉及到性能，穩(wěn)定性相關(guān)的模塊，你都可以肆意的去貢獻，去完善。
• 任何能提升團隊效率的事情

在 ET team，你可以不斷的去突破你的想象力，我們一直相信『天空才是你的極限！』，如果你愿意加入，歡迎聯(lián)系我 tl@pingcap.com。