鄭曄老的1x程序員工作法學習筆記

10x程序員工作法

by:鄭曄老師

問題

忙碌原因

• 本質複雜度(Essential Complexity)

  • 問題本身複雜

• 偶然複雜度(Accident Complexity)

  • 選用方法不當, 導致複雜度上升

事實

• 大部分程序員忙碌解決的問題，都不是程序問題，而是由偶然複雜度導致的問題

解決

• 減少偶然複雜度引發的問題, 讓軟件開發工作有序、高效地進行; 優秀程序員的開發效率是普通程序員的 10 倍

如何思考

思考框架

• 要訣

  • 1、現狀

    • where are we?

  • 2、目標

    • where are we going?

  • 3、實現路徑

    • how can we get there?

• 需求開發思考

  • 爲什麼要做這個特性，他給用戶帶來怎樣的價值
  • 什麼樣的用戶會用到這個特性，他們在什麼場景下使用，他們又會怎樣使用它？
  • 達成這個目的是否有其它手段？是不是一定要開發一個系統？
  • 這個特性上線之後，怎麼衡量它的有效性？

• 原則步驟

  • 1、以終爲始: 工作的一開始確定好真實目標
  • 2、任務分解: 找到實施路徑
  • 3、溝通反饋: 解決與人打交道出現的問題,保證信息對稱
  • 4、自動化: 解決與機器打交道出現的問題

10x工作法原則

1、已終爲始

• 1、已終爲始:如何讓努力不白費？

  • 以結果導向思考模式

    • 遇到事情，倒着想，先想結果是什麼樣子; 反直覺思維

  • 想象的共同體

    • 任何事物都要經過兩次創造：一次是在頭腦中的創造，也就是智力上的或者第一次創造（Mental/First Creation），然後纔是付諸實踐，也就是實際的構建或第二次創造（Physical/Second Creation）

      • 其實工作中很多問題, 是第一次創造沒有做好,就進入第二次創造。第二次創造成本很高, 所以需要如第一次創造上花功夫。如圖紙上構思各種細節, 做產品先做原型文檔再交付, 先定義接口樣子再進行開發。

  • 對做軟件的人來說，我們應該把“終”定位成做一個對用戶有價值的軟件，能夠爲別人帶來價值，自己的價值才能體現出來

• 2、完成了工作, 爲什麼還不滿意？

  • 案例

    • 程序員小李的開發工作完成經常讓項目經理老張不滿意

    • 爲什麼?

      • 理解的鴻溝:對"終"理解存在分歧

    • 怎麼辦？

      • 彌合差異,“完成” 標準定義(DoD)

  • 完成的定義(DoD: definition of done): 什麼叫完成?

    • DoD 是一個的思維模式，是一種儘可能消除不確定性，達成共識的方式

  • DoD怎麼用

    • 1、DoD 是一個清單，清單是由一個個的檢查項組成的，用來檢查我們的工作完成情況，確保你不遺漏任何事情

    • 2、DoD 的檢查項應該是實際可檢查的

    • 3、DoD 是團隊成員間彼此彙報的一種機制

      • 當我們有了 DoD，做事只有兩種狀態，即“做完”和“沒做完”

  • 在做任何事之前，先定義完成的標準， 杜絕理解鴻溝

• 3、接到需求， 要先做哪些事情

  • 案例

    • 程序員小李開發完登錄演示小王認爲還需要增加驗證碼功能

    • 原因

      • 不同的需求描述方式,影響對需求的理解，信息的傳遞會衰減，你不可能把你理解的信息 100% 傳遞給另外一個人，而這中間，如何傳遞，也就是如何描述將直接決定衰減的比例
      • 很多軟件開發基於功能列表, 列表規定程序員要做功能,程序員"照單抓藥"寫代碼, 不理解功能背景和使用場景, 這樣導致不能理解全局。
      • 這種功能列表式的需求描述方式，將一個完整的需求敲成了碎片。 只有所有功能全部開發完成，對接在一起的時候，纔是“破鏡重圓”的時刻。但此時會有很多意料之外的事情
      • 根據這種基於功能列表的需求描述，每個組在安排工作的時候，都會按照自己的理解進行功能排列。如果多團隊協同, 可以想象由多糟糕

  • 解決

    • "用戶故事"的方式描述需求

      • 站在用戶的角度完全描述出使用場景

      • 故事樣子

        • 標題: 故事要幹什麼

        • 概述: 簡述這個故事主要內容

        • 詳述:詳細地描述這個用戶故事的完整流程，包括操作流程、用戶界面等信息。

        • 驗收標準: 正常使用的流程是怎樣的，以及各種異常流程系統是如何給出響應的，這是程序員常常會欠缺的思考。即:正常場景,異常場景

          • 驗收標準非常重要的一環是異常流程的描述
          • 驗收標準給出了這個需求最基本的測試用例，它保證了開發人員完成需求最基本的質量

  • 角色轉變

    • 理想狀況:pm用戶故事方式完全描述出業務需求, 程序員專注在業務技術實現上
    • 現狀: pm不能完全描述, 環節缺失,
    • 因此需要,扮演不同角色的時候，我們的思考模式是不同的
    • 先扮演好產品經理的角色，多花點時間把驗收標準制定好，再回到開發人員的角色上去寫代碼。畢竟，最好維護的代碼是沒有寫出來的代碼。

  • 用驗收的標準看需求是否明確

• 4、從持續集成角度看開發

  • 集成本是寫代碼的一個環節

• 5、產品經理不靠譜, 你該怎麼辦?

  • 用精益創業的視角衡量產品特性的有效性

  • 辦法

    • 我們必須要有自己的獨立思考，多問幾個爲什麼，儘可能減少掉到“坑”裏之後再求救的次數
    • 以終爲始。我們是要做產品，那就需要倒着思考，這個產品會給誰用，在什麼場景下怎麼用呢？
    • 軟件開發的主流由面向確定性問題，逐漸變成了面向不確定性問題。

  • 精益創業

    • 解決

      • 面向不確定性創造新事物
      • 讓人們開始理解價值創造與浪費之間的關係

    • 總結

      • 創造價值是每個人都能理解的，但減少浪費卻是很多人忽略的

      • 精益創業就是在儘可能少浪費的前提下，面向不確定性創造新事物

        • 既然是不確定的，那你唯一能做的事情就是“試”

        • “開發（build）- 測量（measure）- 認知（learn）”這樣一個反饋循環

        • 當你有了一個新的想法（idea）時，就把想法開發成產品（code）投入市場，然後，收集數據（data）獲取反饋，看看前面的想法是不是靠譜

          • 得到的結果無非是兩種：好想法繼續加強，不靠譜的想法丟掉算了。不管是哪種結果，你都會產生新的想法，再進入到下一個循環裏。在這個反饋循環中，你所獲得的認知是最重要的，因爲它是經過驗證的。在精益創業中，這也是一個很重要的概念：經過驗證的認知（Validated Learning）

      • 精益創業提出一個非常重要的概念，最小可行產品，也就是許多人口中的 MVP（Minimum Viable Product）。簡言之，少花錢，多辦事

      • 默認所有需求都不做，直到弄清楚爲什麼要做這件事。

• 6、解決了很多技術問題，爲什麼依然在"坑"裏？

  • 更大範圍內尋找"終"

  • 程序員總喜歡用技術去解決一切問題，但很多令人寢食難安的問題其實根本不是問題。之所以找不出更簡單的解決方案，很多時候原因在於程序員被自己的思考侷限住了。

  • 不同角色工作真正的差異在於上下文的差異。在一個局部上下文難以解決的問題，換到另外一個上下文甚至是可以不解決的。所以說無論單點有多努力也只是局部優化，很難達到最優的效果

  • 角色的差異

    • 不同角色工作上真正的差異是上下文的不同

      • 雖然寫的代碼都一樣，但你看到的是樹木，人家看到的是森林，他更能從全局思考
      • 我並不是靠技術能力解決了問題，而是憑藉對需求的理解把這個問題繞過去了
      • 而能想到問這樣的問題，前提就是要跳出程序員角色思維，擴大自己工作的上下文
      • 當你對軟件開發的全生命週期都有了認識之後，你看到的就不再是一個點了，而是一條線

    • 工作的上下文不同，看到的維度差異很大

      • 單一維度的思考，在多維度思考者的眼裏幾乎就是漏洞百出的

  • 擴大自己工作的上下文，別把自己侷限在一個“程序員”的角色上

• 7、爲什麼說做事情之前先要進行推演

  • 沙盤推演, 從軍事指揮室裏學來的大學問
  • 即便已經確定了自己的工作目標，我們依然要在具體動手之前，把實施步驟推演一番，完成一次頭腦中的創造，也就是第一次創造或智力上的創造。這種思想在軍事上稱之爲沙盤推演，在很多領域都有廣泛地應用
  • 通向結果的路徑纔是更重要的
  • 在動手做一件事之前，先推演一番。

• 8、工作可以用數字衡量嗎？

  • 數字化: 一種衡量"終"的方式
  • 一些人說，自己靠直覺就能把事情做好，其實這是一種誤解，因爲那種所謂的直覺，通常是一種洞見（Insight），洞見很大程度上依賴於一個人在一個領域長期的沉澱和積累，而這其實是某種意義上的大數據
  • 設計好測量工作有效性的指標，那麼就可以更有目的性地去工作了

• 9、啓動開發之前, 要準備什麼?

  • 迭代0： 請在開發前準備好

  • 迭代前的清單

    • 需求方面

      • 1. 細化過的迭代1需求
      • 2. 用戶界面和用戶交互

    • 技術方面

      • 1. 基本技術準備

        • 基礎架構選型

        • 數據庫表結構設計

        • 2. 持續集成
          • 構建腳本, 代碼風格檢查，常見的bug模式檢查，測試覆蓋率
        • 3. 測試
          • 把測試當作規範確定下來的辦法就是把測試覆蓋率加入構建腳本

      • 2、發佈準備

        • 數據庫遷移

          • flyway變更版本控制工具

        • 發佈腳本

• 總結

  • 行業最佳實踐

    • DoD，確定好完成的定義，減少團隊內部的理解不一致
    • 用戶故事，細化出有價值的需求
    • 持續集成，通過儘早集成，減少改動量，降低集成的難度
    • 精益創業，減少過度開發不確定性產品帶來的浪費
    • 迭代 0，在項目開始之前，做好一些基礎準備

  • 思維轉變

    • 任何事物都要經過兩次創造

      • 一次是在頭腦中的創造，也就是智力上的或者第一次創造（Mental/First Creation），然後纔是付諸實踐，也就是實際的構建或第二次創造（Physical/Second Creation）

    • 在更大的上下文內發現自己的“終”

    • 通過推演，找到通往“終”的路徑

    • 用可度量的“數字”定義自己的“終”

  • 如何管理上級

    • 第一，管理上級的預期

      • 相當於我把自己看到的問題暴露給上級，讓他選擇

    • 第二，幫助上級豐富知識

    • 第三，說出你的想法

      • 會哭的孩子有奶喫

2、任務分解

• 1、任務分解：按部就班的前提

  • 軟件開發的任務分解

    • 1、一個大問題，我們都很難給出答案，但回答小問題卻是我們擅長的

    • 2、任務分解的粒度: 可執行

      • 不同的可執行定義差別在於，你是否能清楚地知道這個問題該如何解決

  • 大師級程序員工作的祕笈

    • 將任務拆小，越小越好

  • 將大問題拆解成能夠解決的小問題

• 2、測試也是程序員的一部分

  • 開發者也需測試

    • 對於每個程序員來說，只有在開發階段把代碼和測試都寫好，纔有資格說，自己交付的是高質量的代碼

  • 測試驅動開發(TDD)，一種設計挑戰

  • 測試的屬性：A-TRIP

  • 測試種類

    • 人工測試

    • 自動化測試

      • 測試框架最大的價值，是把自動化測試作爲一種最佳實踐引入到開發過程中，使得測試動作可以通過標準化的手段固定下來

    • 單元測試

    • 集成測試

    • 系統測試

    • 驗收測試

  • 測試模型

    • 冰淇淋蛋卷模型

      • 有些情景高層的測試不容易覆蓋到的，所以，還要有一些底層的測試，比如單元測試。在這種情況下，底層的測試只是作爲高層測試的補充，而主力就是高層測試

      • 冰淇淋蛋卷測試模型的人並不多，它是一種費時費力的模型，要準備高層測試實在是太麻煩了， 使用較少

    • 金字塔測試模型

      • 重點就是越底層的測試應該寫得越多
      • 越是底層的測試，牽扯到相關內容越少，而高層測試則涉及面更廣
      • 小事反饋週期短，而大事反饋週期長
      • 當測試金字塔遇到持續集成

    • 雖然冰淇淋蛋卷更符合直覺，但測試金字塔纔是行業的最佳實踐

  • 測試實踐

    • 測試先行開發(Test First Development)

      • 先寫測試後寫代碼

    • 測試驅動開發TDD（Test Driven Development）

      • 開發節湊

        • 紅 - 綠 - 重構

          • 紅，表示寫了一個新的測試，測試還沒有通過的狀態；綠，表示寫了功能代碼，測試通過的狀態；而重構，就是再完成基本功能之後，調整代碼的過程

          • 重構與測試是相輔相成的：沒有測試，你只能是提心吊膽地重構；沒有重構，代碼的混亂程度是逐步增加的，測試也會變得越來越不好寫

            • 因爲重構和測試的互相配合，它會驅動着你把代碼寫得越來越好。這是對“驅動”一詞最粗淺的理解

    • 測試驅動設計

      • 編寫可測試的代碼
      • 我的代碼怎麼寫纔是能測試的，也就是說，我們要編寫具有可測試性的代碼

    • 瀑布開發方法

• 3、需求的拆分:用戶故事

  • 問題

    • 基本上，闖入你腦海的需求描述是主題（epic），在敏捷開發中，有人稱之爲主用戶故事（master story)
    • 絕大多數問題都是由於分解的粒度太大造成的，少有因爲粒度太小而出問題的
    • 用戶故事，它將是我們這裏討論需求管理的基本單位

  • 需求要分解

    • 用戶故事原則

      • 1、Independent，獨立的
      • 2、Negotiable，可協商的
      • 3、Valuable，有價值的
      • 4、Estimatable，可估算的
      • 5、Small，小
      • 6、Testable，可測試的

  • 需求的估算

    • 估算的結果是相對的，不是絕對精確的，我們不必像做科研一樣，只要給出一個相對估算就好
    • 一般來說，估算的過程也是大家加深對需求理解的過程

• 4、優先級管理：做最重要的事情

  • 需求分解之後，最重要的是，排列需求的優先級。優先級的排列方式有很多，我們可以借鑑時間管理的方法，把事情按照重要和緊急的維度進行劃分，得到了四個象限。我們要儘可能把精力放在重要的事情上，而不是把緊急的事情當成優先級排序的方式

  • 確定事情的重要程度, 一種方式就是找回丟失的上下文，如果無法判斷好的辦法, 那就引入外部更大的上下文

• 5、最小可行產品:找到一條可行路徑

  • 產品同樣需要分解，目前在探索產品的不確定性上的最佳實踐是精益創業，而精益創業就包含了將龐大的產品分而治之的方式：最小可行產品（Minimum Viable Product，MVP）。最小可行產品就是“剛剛好”滿足客戶需求的產品

    • 最小

      • 想要在實踐中運用好最小可行產品的理念，就是要用最小的代價找到一條可行的路徑。最小的代價就是能不做的事就不做，能簡化的事情就簡化

      • 我們要做的是驗證一個想法的可行性，甚至不是爲了開發一個軟件，開發軟件只是一種驗證手段。

      • 例子

        • 做產品文檔驗證方向性想法正確性
        • 原型工具做出了相對完整的用戶界面, 驗證使用性
        • 經過多輪測試下來，團隊有了一大堆的用戶反饋，而且是來自真實用戶的反饋。接下來，就是整理這些用戶反饋，決定哪些可以真正的開發出來，這時候，團隊才真正進入到開發階段
        • 迄今爲止，這個團隊驗證了一大堆的想法，而代碼卻是一行都沒有寫，所有花費的工作量都是有針對性的驗證

    • 可行

      • 但從產品可行的角度，我們需要轉換一下思路，不是一個模塊做得有多完整，而一條用戶路徑是否通暢
      • 當時間有限時，我們需要學會找到一條可行的路徑，在完整用戶體驗和完整系統之間，找到一個平衡

  • 程序員經常願意用自己的代碼解決問題，而寫代碼通常是代價非常高的解決方案，它應該成爲最後的產品解決方案

  • 可行的路徑，是一條完整的用戶體驗路徑，至少在用戶眼中是這樣的。我們常常會想給客戶一個完整的系統，但在時間有限的情況下，我們必須學會分解

    • 但從產品可行的角度，我們需要轉換一下思路，不是一個模塊做得有多完整，而一條用戶路徑是否通暢

  • 做好產品開發，最可行的方式是採用 MVP(Minimum Viable Product，MVP)

  • 總結: 小步快跑。搞清楚業務方需要什麼, 最小代價(產品文檔+原型工具)驗證, 找到可行性路徑, 進行開發

3、溝通反饋

• 1、信息論的視角看溝通反饋

  • 人生不如意，十之八九！

  • 我們努力地學習各種知識，爲的就是更好地理解這個世界的運作方式，而溝通反饋，就是我們與真實世界互動的最好方式

  • 信息論視角的解釋

    • 因爲每個人經歷見識的差異，造成了各自編解碼器的差異，形成了理解的偏差

  • 改善編解碼

    • 分別是：編碼器，讓信息能輸出更準確；解碼器，減少信號過濾，改善解碼能力；還有編解碼算法，也就是各種來自行業的“最佳實踐”，協調溝通的雙方

• 2、用業務的語言寫代碼

  • 推薦書籍

    • 《程序設計實踐》（The Practice of Programming）

  • 編寫可維護的代碼境界

  • 計算機科學中只有兩大難題：緩存失效和命名

    • 命名難題

      • 名字起得是否夠好，一個簡單的評判標準是，拿着代碼給人講，你需要額外解釋多少東西

      • 代碼到底是給誰寫的？

        • 任何人都能寫出計算機能夠理解的代碼，只有好程序員才能寫出人能夠理解的代碼。
        • 我們寫代碼的目的是與人溝通，因爲我們要在一個團隊裏與人協同工作
        • 人要負責將業務問題和機器執行連接起來，缺少了業務背景是不可能寫出好代碼的。
        • 好的命名修改，但從理解上，這是一步巨大的跨越，縮短了其他人理解這段代碼所需填補的鴻溝，工作效率自然會得到提高

      • 命名，是寫程序中最基礎，也是一個程序員從業餘走向專業的門檻。我以命名爲基礎，給你解釋了寫好代碼的提升路徑。最初的層次是編寫可以運行的代碼，然後是編寫符合代碼規範的代碼

  • 用業務語言編寫代碼

    • 瞭解領域驅動設計（Domain Driven Design，DDD），你可能已經分辨出來了，我在這裏說的實際上就是領域驅動設計。把不同的概念分解出來，這其實是限界上下文（Bounded Context）的作用，而在代碼裏儘可能使用業務語言，這是通用語言（Ubiquitous Language）的作用

    • 推薦書籍

      • 代碼整潔之道

• 3、團隊的溝通：輕量級溝通

  • 頭疼的開會

    • 程序員白天都在開會, 晚上才能靜心寫代碼

    • 開會是爲了解決問題，但真實情況卻是開了會又沒有解決多少問題，這真是一個奇特的矛盾。

    • 凡是效果特別好的會議，基本上都是用來做信息同步的。

      • 例如: 領導宣佈一個事情，大家收到消息， 結束。

    • 會議是一項重量級的溝通

  • 輕量級溝通

    • 改善會議的第一個行動項是，減少參與討論的人數。

    • 第二個行動項是，如果你要討論，找人面對面溝通

    • 如果和大家溝通結果達成一致, 再進行開會

      • 開會的目的不再是討論，而是信息同步：我準備這麼幹了，相關各方已經同意了，知會大家一下，結束。

  • 站立會議

    • 實踐叫站會（Standup）

    • 站會人主題

      • 1、我昨天做了什麼。

        • 是爲了與其他人同步進展，看事情是否在計劃上。一旦偏離計劃，請主動把它提出，這樣，項目經理可以過問，因爲這會涉及到是否要調整項目計劃

      • 2、我今天打算做什麼。

        • 是同步你接下來的工作安排。如果涉及到與其他人協作，也就是告訴大家，讓他們有個配合的心理準備

      • 3、問題和求助

        • 我在過程中遇到什麼問題, 需要請求幫助。
        • 就是與其他人的協作，表示：我遇到不懂的問題，你們有信息的話，可以給我提供一下

    • 注意事項

      • 控制時長(不超過10分鐘)

      • 晨會規模

        • 5-12人是一個恰當的規模

      • 避免做成彙報會

      • 問題複雜,會後討論,不要在會上討論

      • 保持參與人集中精力

        • 毛絨娃娃隨機令牌發言

  • 一些思索

    • 每次會議要有會邀, 討論主題, 相關文檔, 會後同步會議記錄結論
    • 同步溝通(如:開會)，人越少越好。異步溝通的時候，涉及的聽衆越多越好(如:E-mail)

• 4、可視化：一種更爲直觀的溝通方式

  • 關注技術新知識途徑

    • InfoQ

    • ThoughtWorks 技術雷達

      • 技術雷達就是一種將技術信息組織起來的方式。它通過將技術按照“象限”和“圓環”兩個維度進行分類，讓人可以直觀地看到並理解不同的技術所處的發展階段

  • 可視化

    • 在我看來，雷達圖不僅僅適用於組織，也可以適用於團隊

      • 雷達圖是一種很好的形式，不僅可以用在組織技術，還可以用來組織其它信息，比如，讀書雷達。每個公司都可以利用雷達圖的形式組織自己所有的技術，每個團隊也可以利用雷達圖的形式組織自己團隊用到的技術，這樣，方便團隊成員結構化地理解用到技術，也方便新人的學習。

    • 可視化的優勢

      • 因爲人的大腦更擅長處理圖像
      • 處理圖像的速度遠遠快於處理文字

    • 項目管理

      • 看板

• 5、持續集成的關鍵點: 快速反饋

  • 目標: 怎樣快速地得到反饋，以及什麼樣的反饋是有效的。

  • 做好快速反饋，要把本地能做好的事情，在本地做好；也要通過小步提交的方式，加快代碼開發的節奏。什麼是有效的反饋？一是即時的反饋，二是引人注目的反饋。有很多種持續集成相關的工具可以幫助我們達成有效的反饋

  • 想要做好持續集成，還要有一些紀律要遵循

    • 只有 CI 服務器處於綠色的狀態才能提交代碼
    • CI 服務器一旦檢查出錯，要立即修復

• 6、回顧會議：覆盤與改善

  • 安全性檢查，是回顧會議的前提條件

  • 在軟件研發中，許多問題是反覆出現的，很多開發團隊會因此陷入無限“救火”中，解決這種問題一個好的辦法就是覆盤

    • 把過程還原，進行研討與分析的方式，就是覆盤

  • 覆盤，就是過程還原，進行研討與分析，找到自我改進方法的一個方式。這種方式使我們擁有了客體化的視角，能夠更客觀地看待曾經發生過的一切。這種方法在很多領域中都得到了廣泛的應用，比如股市和企業管理

    • 用別人的視角看問題，這就是客體化

  • 覆盤實踐

    • 回顧會議

      • 定期回顧是一個團隊自我改善的前提
      • 做得好的、做得欠佳的、問題或建議
      • 目的: 改善和提升

  • 無論哪種做法，分析問題，找到根因是一個重要的環節。“5 個爲什麼”就是一個常用的找到根因的方式

  • 定期覆盤，找準問題根因，不斷改善

  • 枚舉關注點，選出重點，深入討論，列出行動項，找到負責人

• 7、用戶思維，聆聽賴在用戶的聲音

  • 用戶視角，你需要來自真實世界的反饋

    • 而作爲一個程序員，欠缺用戶視角，在與產品經理的交流中，你是不可能有機會的，因爲他很容易用一句話就把你打敗：“這就是用戶需求。”
    • 由聽產品經理的話，擴大成傾聽用戶的聲音

  • 傾聽用戶聲音。這是開發團隊普遍欠缺的一種能力，更準確地說，是忽略的一種能力。所以，“喫自家的狗糧”這種聽上去本來是理所當然的事情，才被反覆強調，成爲 IT 行業的經典

  • 無論是自己做用戶，還是找機會接觸已有用戶，亦或是沒有用戶創造用戶。只有多多聽取來自真實用戶的聲音，我們纔不致於盲目自信或是偏頗地相信產品經理。誰離用戶近，誰就有發言權，無論你的角色是什麼。

• 8、把事情做在前面：變被動爲主動

  • 遇到問題，最好的解決方案是儘早把問題暴露出來

• 9、寫文檔、做分享， 也是一種學習方式

  • 爲什麼不喜歡寫文檔

    • 很多人迴避寫文檔的真正原因是，他掌握的內容不能很好地結構化

  • 將零散的知識結構化，有很多種方式，但輸出是非常關鍵的一環。

  • 輸出的過程，本質上就是把知識連接起來的過程

  • 輸出過程

4、自動化

• 1、"懶惰"應該是所有程序員的驕傲

  • 不要自動化

    • 哪些東西不要自動化
    • 做有價值的事是重要的，這裏面的有價值，不僅僅是“做”了什麼，通過“不做”節省時間和成本也是有價值的
    • 說明一件事，寫代碼之前，先問問自己真的要做嗎？能不做就不做，直到你有了足夠的理由去做

  • 要自動化

    • 在爲別人打造自動化工具的同時，我們自己的工作過程有沒有很好地自動化
    • 而如果我們想擁有打造良好的自動化工具，我們需要對軟件設計有着充分地理解

  • 軟件設計

    • 在軟件開發中，其它的東西都是易變的，唯有設計的可變性是你可以控制的

      • 看源碼，學習的目的是看背後的軟件設計思想，而非軟件本身

    • 不要混淆了設計和實現

• 2、構建腳本: 讓日常開發變得簡單

  • 項目自動化流程

    • 生成IDE工程
    • 編譯
    • 打包
    • 運行測試
    • 代碼風格檢查
    • 測試覆蓋率
    • 數據庫遷移
    • 運行應用

• 3、思考DevOps框架

• 4、持續交付: 一種延伸的"持續集成"

• 5、如何做好驗收測試？

• 6、單一職責:劃分界限

  • 逐步腐化的代碼

    • 功能堆加

    • 低着頭完成了一項任務，而代碼卻變得更糟糕

    • 一個解決辦法

      • 重構

  • 軟件設計

    • SOLID

      • 單一職責原則（Single responsibility principle，SRP）
        開放封閉原則（Open–closed principle，OCP）
        Liskov 替換原則（Liskov substitution principle，LSP）
        接口隔離原則（Interface segregation principle，ISP）
        依賴倒置原則（Dependency inversion principle，DIP）

• 7、分成思維, 是計算機的核心思維

• 8、不同量級的東西不是一回事

  • 評估系統當前所處的階段，採用恰當的技術解決，是我們最應該考慮的問題
  • 作爲擁有技術能力的程序員，我們都非常在意個人技術能力的提升，但卻對在什麼樣情形下，什麼樣的技術更加適用考慮得不夠。採用恰當的技術，解決當前的問題，是每個程序員都應該仔細考慮的問題
  • 用簡單技術解決問題，直到問題變複雜

• 9、領域驅動設計:限定上下文

綜合運用

1、入職新公司, 如何快速進入工作狀態？

• 步驟

  • 1、瞭解業務

  • 2、技術

    • 技術棧
    • 業務架構
    • 內外依賴

  • 3、團隊運作

    • 需求, 產品，向誰彙報

    • 內部活動

      • 站會、 回顧會議、週會、代碼評審、內部分享等

  • 使用“行話”。在交流的過程中，學習一點”行話“。這會讓人覺得你懂行，讓你很快得到信任，儘早融入團隊

• 找到關鍵點，迅速下手

• 由大到小， 由內而外

2、面對遺留系統，如何做？

• 用思考框架對遺留系統

• 步驟

  • 1、瞭解現象和根因

  • 2、確定方案

    • 確定目標
    • 先嚐試重構你的代碼，儘可能在已有代碼上做小步調整，不要走到大規模改造的路上，因爲重構的成本是最低的
    • 保證功能一致唯一靠譜的答案是測試
    • 一方面，建立好領域模型，另一方面，尋找行業對於系統構建的最新理解

• 建議

  • 構建測試防護網，保證新老模塊功能一致；
    分成小塊，逐步替換；
    構建好領域模型；
    尋找行業中關於系統構建的最新理解。

3、如何保證競爭力

• 不斷提升自己的核心競爭力
• 焦慮， 對未來不確定性
• 目標: T型人才， 一專多能 有深度有廣度
• 有了“一專”，“多能”纔是有意義的，否則，就是低水平重複，而這正是很多人職業生涯不見起色的真正原因

總結

少做事,才能更有效的工作

附: 提供md、png、xmind格式筆記地址:
資源地址