程序員工做法學習記錄

程序員工做法

---

一、 以終爲始

• 簡而言之：以結果做爲驅動，從結果處思考問題。考慮指定的結果會帶來怎樣的改變，這樣的結果是否符合預期。是否還有其餘更好的結果來替代?

二、DOD（ definition of done）

作事情以前，定義好什麼叫作完成。
例如在工做中，遇到新的開發需求，此時的完成定義爲（站在開發人員的角度）：

一、功能代碼、測試案列編寫完成
二、代碼測試經過
三、數據庫增、改腳本
四、上線環境需求
.....

三、明確需求

接收開發任務時，首先應該明白，需求的各項細節。
例如短信配置：

一、誰來配置？
二、哪些信息能夠配置？
三、.....

四、持續集成

在分模塊開發時，儘量的調短集成周期，如天天一次，這樣能夠避免項目集成過於複雜。

這裏給個人感受更像是在工做中，開發一個需求時，儘可能作到沒完成一個小的階段時，就停下來思考，
目前的結果是否符合預期，同時能夠向負責需求的人員進行報備、溝通，以免雪球越滾越大。

五、擴展上下文

Java中不少框架都是用到了‘上下文’這個概念，‘上下文’顧名思義，便是須要你瞭解一件事情更多的東西，如同故事大綱通常。
工做中，其實也是一樣的道理，你須要瞭解的不只僅是你手中的工做，一樣你須要知道 what you do，當你理解‘上下文’以後，遇到問題，你才能更好的解決，換個角度思考。不識廬山真面目，只緣身在此山中。解決一個問題，有些時候須要的不是技術，是一種藝術。

六、推演 頭腦風暴

作任何事情以前，都應該在頭腦中思考清楚，一步一步，就像在大腦中執行僞代碼通常。我在工做時就喜歡寫一點想一點，這樣不少時候都會推翻重來。在腦中推演一番，不只避免這種無效操做，也會培養出一種良好的習慣，三思然後行！

七、數字衡量一切

作事情的時候憑藉本身的直覺，這是大多數人作事的一種方式，好比我開車，就是憑藉本身的直覺，這樣帶來一個很大的問題，個人駕駛技術很難取得進步。工做生活亦是如此，務必將那些須要提高的方面，儘可能作到能用數字衡量。

例如：在工做中，我常常發表這樣的言論，這樣改動以後，會致使查詢速度極低，可是這種說法自己
其實具有很大的模糊性。低，可以具體化嗎？有數據支撐嗎？等等。已經不少時候，完成一件事情，
能夠用數字來衡量嗎？完成便是100%，沒有99.9%這種說法。