2017.9.17, 深圳, Ken Fang

我們搞軟體開發的, 應該要有些 “指標” 來驅使著我們自己能不斷的持續改進；永遠的朝著 “完美” 的聖殿前進⋯

@ 平均需編寫多少行的程式碼, 才能完成一個特性或服務的開發？
@ 平均需花費多少的時間, 才能修復一個缺陷或運維事故？
@ 外部使用者平均需花費多少的時間, 才能感受或認同程式碼的價值？

我想, 有追求的開發的人員, 都會在每個季度、每個年終, 用這三個指標來 “度量” 自己；驅動著自己, 深度的思考著：

@ 用函數語言程式設計, 使得程式碼由 “呼叫的結構” 轉換為 “堆疊的結構” , 是否會更好？怎麼做會更好？平均開發完一個特性的程式碼行數, 會不會更少？怎麼做會更少？程式碼更簡潔了, 但又能同時使程式碼, 更具有可讀性？

@ 用 Cloud Native 的架構, 使得產品的架構由 “單一”、 “中央集權”, 轉換為 “分散式” 、“地方分權”，怎麼做會更好？關鍵技術 : 分散式事件的處理, 該怎麼做, 才能使得每個服務的 “邊界” 是有價值, 有意義的？使得每個服務不僅能 “持續” 的提供價值, 卻又能 “不會” 影響到其他服務的運作？更重要的是：使得每個服務有 “自愈” 的能力；使得產品的運維的事故, 真的可用 “罕見” 來形容, 使得運維事故修復的時間, 真的可用 “極短” 來形容。

@ 用團隊恊作, 將 “使用者體驗” 在需求分析、軟體設計時, 便已融入到軟體開發的思維當中；該如何做, 使得使用者能在 “最少的互動” 下, 就能完成工作? 該如何做, 才能使得外部的開發人員, 在呼叫 “最少” 的 API 、關注 “最少” 的 API 引數下, 就能完成開發？

當我們能運用了有效的度量指標, 我們才能真正的明白, 為何需在:
@ 程式語言
@ 程式設計方式
@ 軟體架構
@ 團隊協作上, 持續改善？

“能持續改善的開發人員、有追求的開發人員, 是值得被尊重的, 是值得被珍惜的。”