10x engineers 技術雷達 在過去的幾個月中，10倍工程師一詞受到了密切的關注。一個廣泛傳播的推文討論在實質上建議公司應原諒反社會和破壞性的行為，以留住被認為個人產出巨大的工程師。幸運的是，許多人在社交媒體上都嘲笑了這個概念，但是「明星開發者」的刻板印象仍然普遍存在。根據我們的經驗，偉大的工程師不是因為個人產出而是因為能在優秀的團隊中合作而誕生。打造一支混合不同經驗和背景，但成員才華橫溢的團隊，並為團隊合作、學習和持續改進提供良好的助力，這會是更行之有效的方式。這些10倍團隊行動起來更快，彈性也更強——而無需屈從錯誤的行為。
概述
本質複雜度 Essential Complexity
偶然複雜度 Accident Complexity
選擇正確的做事方法，減少偶然複雜度帶來的工作量； 原則
- 以終為始
- 任務分解
- 溝通反饋
- 自動化
思考框架
- Where are we ?
- Where are we going ?
- How can we get there ?
以終為始
如何讓努力不白費？
任何事情都要經過兩次創造：一次是在腦中，是智力上的創造，然後才是付諸實踐，也就是實際的建置
對做軟體的人來說，我們應該把”終”定位成做一個對用戶有價值的軟體，能夠為別人帶來價值，自己的價值才能體現出來。
tips:設計一個以終為始的項目或示例
DoD 的價值
Definition of Done
User Story
使用情景演繹的方式，完善需求
- 主題
- 概述
- 詳述
- 驗收標準
驗收標準中，非常重要的是異常流程的描述，類似於測試用例中的異常邏輯驗證。
持續集成
研發需要交付的，不是一堆程式碼文件，而是可以運行的軟體或系統。 雖然我們在同一個時代寫程式碼做開發，但在技術實踐層面，不同的團隊卻彷彿生活在不同的年代
精益創業
IT行業中大多數人的專業程度是不夠的。我們必須要有自己的獨立思考，多問幾個為什麼，儘可能減少掉到坑裡之後再求救的次數。
精益創業：面向不確定性創造新事物。精益創業提供給我們的是一個做產品的思考框架，我們能夠接觸到的大多數產品都可以放在這個框架內思考。
build—measure—learn 循環
默認所有需求都不做，直到弄清楚為什麼要做這件事。
坑裡坑外
角色的差異:不同角色工作上的真正差異是上下文的不同。同樣是寫程式碼，有的人看到的是樹木，有的人看到的是森林，能夠從全局思考。
手裡有一把錘子，滿世界都是釘子。
花費很大力氣去解決一個可能並不是問題的問題，常常是很多程式設計師的盲區。
演繹
最後一公里：如果想要達到目標，最後我們要做的是什麼
- 從結果入手，看看最終上線需要考慮哪些因素
- 演繹出一個可以一步步執行的方案，用前面考慮到的因素作為衡量標準
- 根據演繹出來的方案，總結要做的任務 以終為始，但通往結果的路徑更加重要。
量化
洞見（Insight）:依賴於一個人在一個領域長期的沉澱和積累，其實是某種意義上的大數據。
Planning&Prepare
設計自己的迭代0清單
任務分解
銀河系中，有多少與我們相近的文明。德雷克公式： N= R* x Fp x Ne x f1 x fi x l
埃隆馬斯克的火星探測計劃：把一個人從地球送到火星，成本降低100萬倍。
測試
對每個程式設計師來說，只有在開發階段把程式碼和測試都寫好了，才有資格說，自己交付的是高質量的程式碼。 冰淇淋蛋卷測試模型： 費時費力的測試模型
- 手動回歸測試
- 自動化端到端測試
- 集成測試
- 單元測試
- UI
- 服務
- 單元
越是底層的測試，牽扯的相關內容越少，而高層測試則涉及面更廣。 多寫單元測試
TDD 測試驅動開發
測試驅動程式碼：一個static方法示例，如何測試一個static方法，OOP的思想下如何更好的完成。
Test Driven Development
Test Driven Design
編寫可測試的程式碼
大師級程式設計師秘籍
- TDD從而來？
- 《解析極限編程》
- 《測試驅動開發》
將任務分解，越小越好。
任務分解練習
需求：用戶通過輸入用戶名、密碼登陸。
優秀的測試程式碼
一段旅程 A-TRIP
- Automagic
- Thorough
- Repeatable
- Independent
- Professional
砍需求
用戶故事的評價原則：
INVEST
- Independent
- Negotiable 可協商的
- Valuable
- Estimatable
- Small
- Testable
想要管理好需求，先把需求拆小
需求的估算，怎麼做才會比較合理，誤差最小？
推薦書籍
需求管理
需求優先級管理，重要程度、緊急程度
最小代價
MVP：Minimum Viable Product 最小可行產品
溝通反饋
人生不如意，十之八九。
溝通反饋就是改善編碼、解碼以及算法的方式。
編寫可維護的程式碼
任何人都可以寫出計算機能夠理解的程式碼，只有優秀的程式設計師才能寫出人能夠理解的程式碼 ------Martin Fowler
用業務語言編程
領域驅動設計：Domain Driven Design
推薦閱讀 《程式碼整潔之道》—Robert Martin
22 輕量級溝通：為什麼總是在開會
開會是為了解決問題，但真實情況是開了會沒有解決多少問題，卻產生了會議過多的問題
凡是效果特別號的會議，都是用來做信息同步的；效果不好的會議，基本都是用來討論的。
改善會議：
- 減少參會人數
- 當面溝通
- 站立會議
可視化：一種更為直接的溝通方式
技術雷達：結構化學習新知識的方式
快速反饋：如何做好持續集成
- 持續集成監視器，實時顯示持續集成的狀態
- 遇到問題立即響應
復盤
不要被同樣的招數擊敗兩次 復盤的好處：客體化，用別人的視角看問題
復盤：過程還原，進行研討與分析，找到自我改進方法的一個方式。這種方式擁有客體化的視角，能夠更客觀的看待曾經發生的一切。
定期復盤，找準問題的根本原因，不斷改善。
傾聽用戶的聲音
誰離用戶近，誰就有發言權，無論你是什麼角色
多走進用戶
產品經理是用戶需求的傳聲筒
Fail Fast
如果有問題，那就儘早的將問題暴露出來。
越早的暴露問題，解決問題的成本就越低。
結構化學習：會寫文檔
將零散的知識結構化有很多種方式，輸出是非常關鍵的一環。
如何寫好文檔：無他，唯手熟爾。
推薦閱讀
懶惰的天性
做有價值的事是最重要的，這裡的有價值，不僅僅是做了什麼，通過不做節省時間和成本也是有價值的。
從日常工作中的自動化開始，打造自己的自動化利器
給別人打造自動化工具中需要具備的能力：軟體設計
在軟體開發中，其他的東西都是易變的，唯有設計的可變性的可變性是自己可以控制的。
優秀程式設計師的三大美德：懶惰、急躁和傲慢。
項目自動化
將工作過程自動化。
零散的運維知識
將零散的運維知識系統化，怎麼系統化？
持續交付 ≠ 持續集成
如何建置持續交付系統
將部署納入開發的考量
測試驗收
BBD: Behavior Driven Development BBD 測試框架 Cucumber
關鍵一點：將驗收測試自動化
逐步腐化的程式碼
對程式設計師最好的懲罰是讓他維護自己三個月前寫的程式碼
軟體設計原則: SOLID
- Single responsibility principle
- Open-closed principle
- Liskov subsitution principle
- Interface segregation principle
- Dependency inversioni principle 將函數寫短
MVC 封層設計
分層的價值：建置一個良好的抽象
如何使用5萬塊做一個淘寶
推薦書籍《淘寶技術這十年》
不同量級的系統，根本不是一個系統
用簡單的技術解決問題，直到問題變複雜
做好DDD 再談微服務
DDD: Domain Driven Design 領域驅動設計
推薦書籍
如何維護系統
改造遺留系統，一個關鍵點就是，不要回到老路上。
書籍推薦
如何保持競爭力
一專多能，成為T字型人才
在學習區工作和成長。
