[The Effective Engineer 筆記] Invest in Iteration Speed

這篇是 Execute 底下的第一章，說明迭代（iteration）速度的重要性。迭代指的是，code 從 commit 到 deploy to production 的過程，更廣義的迭代可以說，從有 idea 到 idea in production 的過程，因此，不管是技術的部分，或是非技術（人）的部分，都應該考慮

Continuous Deployment 持續交付

本章一開始，作者說明了Continuous Deployment (CD)的重要性，每當有小改動便 push to production，並利用完善的 test coverage（unit test/integration test/regression test）來確保正確性。這麼做有兩個好處，第一、加速開發的時間，傳統的開發流程可能需要QA手動測試，當很多功能需要deploy的時候，bottleneck便在QA的測試，用CD就可以省去這個步驟。第二、當有bug 或 business metric 被影響的時候，可以馬上發現問題，快速的roll back 到前一個穩定的版本。Facebook 的文化，Move fast and break things，也是在說明CD或快速迭代的重要性

舉一個常見的例子，假設今天我們要改變一個database table 的 schema，你需要

1. 創新table
2. 把資料同時寫到兩個table
3. 把舊table 的資料搬到新table
4. 讀new table 的資料
5. 刪掉舊table

全部的步驟可能需要4～5個release，假設每個release 都要花一個星期，那整個migration 就要花一兩個月。如果用CD，每個release可能就幾個小時，便可以大大地縮短時間

每次改動一點點，並不代表客戶會看到還沒完成的功能。我們可以使用A/B test的概念，把同一個功能的改變藏在同一個 tag 下面。譬如說，有新的功能A，我們用tagA表示，功能A便在tagA下面，當A功能全部開發完成，我們在慢慢把流量ramp up 到 tagA下面。可以先把1%的user 導到功能A，再慢慢上升到100%，這時還可以收集數據，或是看看你的資源(CPU, RAM等等)夠不夠。我們公司(Indeed)有自己的工具叫 Proctor 在做這件事，Nextflix 也發了一篇文章在講他們如何使用A/B Test

投資在省時間的工具

If you have to do something manually more than twice, then write a tool for the third time.

一個好的工具可以讓你的 impact 倍增，同時也省下許多時間。假設今天你的工具可以幫你一天省下10分鐘，一個星期便省下50分鐘，一個月便是200分鐘。再假設有5個組員使用這個工具，也就是一個月幫團隊省下1000分鐘。作者提到當初他在Google 的時候，compile C++ code 要花20分鐘以上，後來Google決定在這方向做了一些努力，使 copmile time 少了3~5倍。這麼一來，release cycle 大幅縮短，每個在Google 的C++工程師都省下大量的時間，效率大幅提高。這也是為什麼像是Google, Facebook 都有專門的組在寫 internal tool

另外像是，使用有提供 interactive programming environment 的語言來測試一些小功能、hot code reload、continues integration 都是可以省時間的工具

最後要考慮的是，如何說服別人使用你的工具。假設現在已經有類似的工具，但你的工具更適合你的團隊，要怎麼降低轉換工具的成本，是不是可以設計成一個 configuration change 讓使用這個新工具更方便

減少 debugging 和 validation 的時間

身為一個工程師，大部分的時間其實都花在debug 和驗證你的功能，如何設計一個 minimal debugging/validation workflow 來減少這兩件事件要花的時間便變得很重要

假設你在分析網頁，你要分析的東西離home screen 很遠，需要點擊很多次，你可能還需要過濾掉一些東西、或是設一個data range。你可以遵照一般使用者的流程慢慢點，但更好的方法是，把這些參數直接設在URL裡，讓你可以跳到那個頁面，產生你要的報告

或是假設你在A/B test 你的產品，呈現出來的東西會按照使用者的browser’s cookies 不同而不同。你可能hardcode 一些 condition statement 來測試，當測試的時候，根據你所寫的語言，可能在每次測試的時候都要 recompile。或者你也可以寫個 internal tool，讓你可以把cookie 當成一個value ，這樣在測試的時候就不用每次都重新compile

當你每次都在做相同的步驟來debug 或是 validation 的時候，可以先停下來想想，有什麼方法可以簡化這些步驟，讓你直接跳到最重要的部分

熟悉你的程式環境

這章主要在講如何省下每天操作的時間，例如

1. 用 version control 來追蹤變化
2. compile, build code
3. 跑 unit test
4. reload 網頁
5. 測試expression 的結果
6. 查某個功能的文件
7. 跳到函數的定義
8. reformate code
9. 找到誰叫過這個 function
10. rearrange 桌面視窗
11. 跳到file下面的某個地方

這些基本操作可能會做上萬次，每次省下一點點時間累加起來就很可觀，作者建議

1. 精通你所用的IDE，可以問問比你有效率的組員，可不可以在旁邊看他如何開發，學習他用的shortcut
2. 學習至少一個high level 的語言，例如python, ruby
3. 熟悉 unix shell command，grep sort uniq wc awk sed xards find 等等
4. 盡量使用鍵盤，用滑鼠比較浪費時間
5. 自動化你需要手動的workflow，可以使用 shell script, browser extension 等等
6. 在 interactive interpreter 測試
7. 只跑跟你的改動有關的 unit test

Non-engineering 的 bottleneck

除了engineer bottleneck，non-engineer bottleneck 也很重要。第一個常見的bottleneck，dependency on other people。有可能是PM搜集需求的很慢、或是其他組沒有完成預計中的功能，通常這是 misalignment of priorities 的結果。也就是組與組、工程師與PM溝通不良的結果。第二個常見的bottleneck，obtaining approval from a key decision maker，通常是公司的executive 級的人物。第三個常見的bottleneck，review processes that accompany any project launch，可能是 QA要驗證，或是reliability review from performance team，或是法律上要由 legal team review。這些都是對於一個project launch來說常見的bottleneck。最重要的一點，always communication, and plan ahead，過度的溝通也好過沒有溝通

premature optimization is the root of all evil 過早最佳化是萬惡的根源

有鑒於每個project的bottleneck 都不盡相同，找出你最大的瓶頸便是第一步。有可能是你需要更多的工具、或是你的新功能依賴在別的組、需要公司高層的同意、或是一些公司的流程。找到以後，再嘗試對他最佳化

本章小記

1. 寫工具來縮短開發流程
2. 設計 minimal debugging workflow
3. 熟悉你在用的任何工具與快捷鍵
4. 溝通的重要性
5. 先找到bottleneck，再 optimize