緣起
話說，程式員的成效是否是一個重要的話題？誰應該關心？是度量程式員的管理者還是程式員自己？
話說，大家在大談google如何，回到座位又繼續撸測試用例的時候，那些熟悉的資料準備動作、校驗動作，然後是斷言動作，有沒有讓人想吐的感覺！
我10年的時候，幹了一件現在看來不靠譜的事情，就是把一個子產品的代碼測試覆寫率撸到了80%，接手的時候是30%的樣子。為了撸，我讓其中一位研發同學隻補測試，補了一周。有人說了，單純追求覆寫率是不對的，誠然！我在11年還整理過一個内部文檔，如何做單元測試，不能為了測試而測試。但在哪個曆史時期，我還是做了【正确】的選擇，如果是一個拖了整個系統後退的子產品owner，有何面目談品質！！！
我在品質系列文章中不經意有裝x嫌疑，高大威猛；其實誰沒有不堪回首的過去，那些血淋淋的過往需要回首對視呢？
<a href="https://yq.aliyun.com/articles/64647?spm=5176.8091938.0.0.oom6h1">大話軟體品質穩定性</a>
念念不忘，或有回響。
卓有成效的程式員
【卓越成效的程式員】是若幹程式員系列書籍我比較喜歡的一本，類似的還有卓越程式員密碼【the developer's code】等。【卓越成效的程式員】高明之處是不僅僅給出原則，還大談工具和代碼，這如同諸多雞湯文在【布道】的層面之下【實戰】幹貨，可操作性強。這2天，重溫了一下這本書給出的諸多原則，有些體會姑妄言之。
四大原則
四大原則是加速原則、專注原則、自動化原則和規範性原則。
加速法則
加速法則，就是能加快我們工作的一切的東西。
launchy 加載器，http://launchy.net/download.php#windows
比如系統啟動，最近一位同僚做了一個熱部署插件，解決容器在自測中啟動的成本消耗。
比如記住ide快捷鍵
專注法則
工作當中，專注可以很大的提高工作效率。
排除幹擾，隔離（帶耳機、如設定專注編碼時間段）
關掉不必要的提示
搜尋優于導航，比如我想找一篇資料
搜尋可以使用本地搜尋，比如google桌面搜尋。
自動化法則
自動化法則是把能自動化的一切都自動化掉
不要重複發明輪子（輪子太多，亂花迷眼是又一話題；追求新輪子，又是技術人貪嗔癡的表現之一，熱愛技術但忘掉了要解決的問題域）
建立本地緩存
使用rss訂閱我們需要的資訊
建構工具
用rake執行常見任務
ps：最近望神搞了一個eclipse插件解決了看起來很簡單的一個問題，就是配置環境init。在一個新的space中load 配置，可以擁有你想要的java、maven、junit、checkstyle等一系列設定的内容。當然從頻度來說，這屬于低頻，但仍然可以自動化掉。越高頻的行為越應該優先實作自動化。
關于發明輪子，有另外一個觀點，就是基于提升技能的目的。不妨去做一下，對于問題域會有更深入的了解。
規範性法則
規範很重要，這個可以減少不一緻
使用版本控制
使用标準的建構伺服器
資料遷移，ruby on rails裡的migration就很贊
關于文檔：錯誤的文檔很糟，盡量生成所有的技術文檔
資料庫結構 schemaspy可以生成資料關系圖；開源的staruml可以生成類圖結構
減少重複，重複是軟體開發中最大的阻力
關于文檔的問題
關于要不要文檔，文檔寫多少？
張逸老師如是說【文檔方面目前個人覺得靠譜的做法是整理成思維樹，标注定義，關鍵描述，關鍵詞，關聯詞，詳細文檔link。對新人來講更容易找到切入點，快速了解項目或系統全貌，已經可能與自己未來工作相關的上下文（内涵，外延）是什麼。傳統的文檔管理方式往往使新人在浩如煙海的文檔中迷失】
孫老師提出：負責業務層的同學必須同步文檔，否則會遭到移動用戶端兩個組前端使用者層，開放商家層，内部管理層的投訴。我們最近就吃過這虧，有一個伺服器同學寫了一個接口文檔，大概是一個參數，他定義的時候說的給的是 bool，但是沒給事例，結果 ios 用的 yes 傳的，安卓用的是 true，把 ios 的 yes 翻譯過來就是 1 在判斷的時候 1 和 true 是不相等的，因為類型都不一樣，伺服器的人和安卓對接完以為就 ok 了，結果上線了才發現有這個問題。
我的淺見：
關于文檔，項目研發過程中的關鍵文檔需要保留和管理，比如需求和系分文檔。這些是逐漸堆積的過程中文檔。
一個系統/平台，需要有core文檔，比如領域模型、主體架構等，由于這部分文檔更新并不頻繁，可以定期維護。
用例即文檔，驗收測試及接口測試等保持穩定，是研究細節和使用者場景的入手點。
活文檔：接口文檔通過接口聲明生成，接口聲明對于每個參數都會有說明。批量接口，會給出資料量的limit，代碼中也會進行防禦；采用swagger，在swagger editor中，我們可以基于yaml文法定義我們的restful api，然後它會自動生成一篇排版優美的api文檔，api修改之後，api文檔會随之而修改。
關于yagni
yagni(“you ain’t gonna need it”)
你不會需要它，如無必要，勿增複雜度。
根據cunningham & cunningham的wiki頁面所說： 即使你非常确信将來你需要某個特性，也不要現在就去實作它。在很多情況下，你會發現或許最終你不需要它了，或者是你真正所需的特性與你之前預計的有很大的出入。遵循yagni實踐有兩個主要原因： 你節約了時間，因為你避免了編寫最終證明不必要的代碼。 你的代碼品質更高了，因為你使代碼不必為你的“推測”所污染，而這些“推測”最終可能或多或少有些錯誤，但此時這些錯誤已牢牢地依附在你的代碼中了。
martin fowler進一步表示，當我們在考慮推定特性時，很有可能我們是錯的。在這種情況下，推定特性一個很明顯的成本就是整個建構過程的成本，也就是對這個在當下沒有用處的特性進行分析、編碼以及測試所耗費的精力。他同時表示，假設我們對這個需求的了解恰好是正确的，但即使在這種比較理想的情況下，建立這個推定特性同樣會帶來兩種巨大的成本。第一種成本是軟體價值的延誤成本，第二種成本是延續這一特性所帶來的成本。
關于yagni的思辨
如果對一個問題有2個解決方案，明明第二個解決方案更好【擴充性增強】，而實作成本相差無幾，難道我要墨守此原則嗎？
以我們團隊的2個case來說明這個問題。第一個case是去年接到一個錢包積分的需求，經過分析，我們的設計不僅僅實作錢包積分，而是實作了商戶通用積分的生命周期管理。因為後者有擴充性，并從業務嗅覺上依稀感受到未來或許有這樣開放的必要。經過評估，實作成本沒有增加太多，我們就果斷采取了商戶通用積分的實作方案。過了1年，果然，類似的需求來了...
第二個case，我們在14年底規劃了一個券平台，解決此前各種紅包、優惠類業務的煙囪架構的問題。這個平台的提出是基于若幹需求背後的核心領域抽象，在8、9年前做紅包系統的時候，是萬不能想到的。也就是說對于問題域的本質認知，随着業務發展而發展，延遲設計決策是非常重要的，而把握這個度很難，沒搞好，新裝修的房屋不到2年就能翻新。
結論：yagni并非不做預設計，而是在成本、複雜度之間做權衡。光聰奉英傑為師，對于英傑非常崇拜。曾向我表示，英傑師關于yagni的觀點與我有些近似。如果未來一個預期中的變化發生，而要付出的成本可能很大，我們眼前需要建立一些機制（比如抽象、限制）應對它。注意，隻是建立機制，實作層面仍然按目前剛剛好的功能實作，除非你找到額外複雜度非常小的方案能把預期的變化也覆寫了，那麼just do it！
定期檢查阻礙，運用四大法則
如果說技術債是背在身上的猴子，總有一天會壓得你喘不過氣來；那麼自發的提升研發過程的效能就是更好的追求。發揮程式員的三大美德，輕裝上陣，讓工作變得不一樣。我們采取的是團隊自發定期組織各種小沙龍，發現行徑中的阻礙的模式，最近的一次沙龍收到10餘條issue。比如下面這一條
分享者簡介：
<b>于君澤，</b>花名右軍，螞蟻金服成都研發中心技術團隊建立者之一，先後負責或參與過轉賬業務、賬單類業務、社群支付、開發平台、支付平台、資金核算平台、類營銷類支付工具的建設；之前有數年電信業務研發經驗，設計bss | oss | 針對性營銷等平台。
本文轉載自微信公衆号 中生代技術 freshmantechnology