主要是項目中一些落地經驗和記錄

技術人員、開發人員

• 大部分程式員真的不善於溝通，經常會顯得很保守；
• 他們技術上的困惑、誤解乃至鬱悶都很難直接的表達清楚；
• 他們對自己的錯誤“印象”很深；
• 他們內心是希望提高、改進，出自各種目的，也包括為了輕鬆點或者“牛逼”點，這屬於優點；
• ORM已經是一種現實的基礎能力；

推進者

• 類似技術經理和技術組長這種直接面對程式員的職位必須有技術要求，如果發現他們不符合要求，需要警惕；
• 技術和設計理念的推進者必須有技術能力支持；
• 推進者無需成為心理專家，但要有從代碼中發現問題的能力（並非bug，是員工在技術上存在的缺陷和問題或者原有技術棧的痛點）；
• 在落地這個環節上，團隊就是是需求方，程式員就是領域專家，請保持尊重並勇於面對；
• 尊重傳統，團隊中已有的名詞如果沒有重大衝突不要輕易變更，可以作為落地領域的領域語言基礎；
• 推進的目的是效率和質量，團隊外部的壓力也通常來自這裡，而團隊內部還會有其他想法，需要考慮如何平衡內外，保持一定的彈性；
• 推進不能影響進度，分步推進，給團隊一些消化時間；
• 如果不能說明新東西能解決的實際開發問題，不要推進；
• 推進者需要更多付出
• 如果失敗，除非有著買彩票中大獎的運氣，“奇葩成員的奇葩行為導致失敗”不是理由；
• 自用系統是更好的切入點

從Application開始

• 名詞不重要，有時介面服務之類的更容易被接受；
• 流程組裝
  大部分程式員對流程都很有概念，大部分客戶對流程的進度都很感興趣，然而很多情況下流程出於各種原因（能力、事務需求）會被藏在業務邏輯的處理之中或者被“順手”處理了，很多時候組裝甚至會發生在前端站點；
  提供一個總覽式的統一的流程組裝位置，難度最低、最安全、最直觀、最簡單；
• 事務時機
  通常事務會發生在流程處理的某個或某幾個環節上，所以在流程組裝時提升事務處理時機就會變的比較自然；
• 儘量滿足前端站點的一些需求
  前端的需求變化非常多，需求方對於需求變化有著自己的考慮， 很多時候他們會認為前端變化比較簡單；
  很多時候為了保證業務邏輯處理沒有過大的變化，會“支付”一些前端需求；
  有些需求變化實際上會涉及到一些流程節點（技術層面）的調整甚至流程的重新組裝，這種是需要儘量滿足的；
• 流程組裝能夠消化一部分需求變化，事務時機能夠引導程式員更好的思考存儲；
• 即使不引入其他任何概念，一個結構良好的易讀易用的日誌系統是必須的；

業務邏輯 Domain

• IO類的處理儘量分離；
• 如果要處理歷史寶藏，if switch哥倆好放最後；
• 倉儲對ORM的隔離不是必須的；
• 復用範圍定在本項目之內；
• 如果你的項目已經複雜到需要隔離查詢， 有可能的話拉一把；查詢端也已經消化了一些需求了；
• 不要一個人處理
• 管理後臺對業務線、某些寫入需求應在此處理，註意區分與前端需求的異同；
• 時間、時刻，同步、非同步
• 根據具體項目確定粒度原則
• 註意緩存

基礎設施、框架

• 雲端通常沒有宣傳的那麼可靠；
• 網路永遠都是問題；
• 監控是分佈的頭等大事；
• Redis這種功能多的容易被接受；
• 只要有合適的場景，MQ非常容易被接受；
• 穩定壓倒一切；
• 數據需要清理；
• 框架以支持服務為主，限制性的東西不要多
• 安全
• 時間時鐘