最近專案終於上線了，上線當天還算正常，沒出啥大問題，希望以後繼續保持，哈哈，上線前一陣工作特別累，最近腦袋都有點暈，工作累並不是因為工作量大，而是有一些其它主觀上的原因。這裡我想總結下工作累的原因。我會分幾篇來總結，這篇我先來講講和其它小組合作開發專案時，如何約定服務介面。
1:會員預訂的普通訂單，普通訂單的概念需要比較下面兩種訂單。
2:會員預訂的訂單，但這種訂單需要信用卡的擔保，即預訂時先會凍結使用者信用卡的部分金額。
3:會員預訂的訂單，這種訂單需要信用卡預訂，費用直接從使用者信用卡中扣除。
之所以給大家描述了專案的具體內容，是因為在這三種訂單在取消的過程中，無論是從使用者介面上還是取消的邏輯上都大有區別，例如信用卡擔保的訂單，在取消成功後，需要告訴使用者解凍的金額，信用卡預付的訂單，因為預付是直接扣款，所以免費取消是有條件的，即有有某些情況下，取消時需要扣費。針對這種扣費的訂單，就需要準確,清楚的提示使用者扣費的金額等資訊。例如在使用者訂單列表頁的取消提示視窗：
第一：普通取消訂單：
請於年月日:00前取消訂單
第二：預付訂單
2023年月日:00前免費取消；
14:00—:00之間扣款取消
我這邊屬於介面的呼叫者，對方屬於服務介面的開發者，針對上面取消時需要用到的資料，我當時的郵件部分內容如下：
第一:如何取訂單物件是否會產生罰金?
第二:如果有罰金是部分罰金還是全額罰金?
第三:如果有罰金,罰金數從哪個屬性上取?
第四:產生罰金的條件,例如什麼時間之後取消會產生罰金。
大家能否看出上面的內容有可能會有什麼不妥的地方嗎？
小結：沒有明確的給出以什麼樣的標準來判定是否有罰金。如果我告訴對方罰金大於0為標準，什麼時候不返回罰金，介面方面就不會有上面的問題出現了。
2:服務的介面最好由客戶端及服務端共同定義：服務端的資料是給客戶端用，但最好是客戶端明確的告訴服務端需要哪些資料，我們可以詳細到傳入的引數，返回的物件的所有屬性內容及詳細描述。我們這次開發時，這些資料均是服務端來定義，這樣的結果就是，給出的資料有的不完全滿足客戶端需求，有的給出了客戶端可能根本用不上。所以在後期的開發中，經常是客戶端開發到一定程度，發現還有資料無法獲取，這時又需要找服務端商量如果處理，這一來一去的，導致介面相當不穩定，對雙方的時間都是一種考驗。
由客戶端來約定服務介面的另外乙個好處：當服務端沒有提供真正的介面時，我們可以自己定義的介面內容，編寫乙個假的介面，當真正的服務開發完成後，客戶端只需要修改服務層的呼叫方式即可，大大減少了和服務端的依賴。介面資料結構的定義，如果有客戶端參與，那麼在開發時，就會針對返回物件的資料意義非常清楚，例如：
//////
agency信用卡擔保金額
///
public
decimal
vouchamount
//////
預付金額
///
public
decimal
prepayamount
//////
什麼日期
///
public
intxdate
//////
x小時///
public
string
xhour
//////
從幾點開始
///
public
intfromhour
//////
到幾點///
public
inttohour
//////
罰金///
public
decimal
amercement
3:約定服務介面內容的同時，一定不要忘記還是約定服務介面的提交時間，因為服務介面的開發質量以及進度直接影響客戶端的開發質量以及進度。由於本次開發過程中，我們兩個開發對業務邏輯都有一定的陌生，導致介面的開發出現了延時，這也直接影響了專案的正常提交以及測試環節，由於缺少介面聯調時間(介面聯調時間就是指測試介面返回資料的正確性的時間)，導致專案提交測試部門測試時，出現很多低階錯誤。
總結：上面寫的有點亂，但我個人認為對自己以後的工作還是有非常大的幫忙，專案經驗的不斷總結才能避免下次工作**現同樣的錯誤。
專案一（驅動開發經驗總結）
微控制器中的看門狗 watchdog timer 實際是乙個定時器電路，其輸入端稱為餵狗，中斷輸出端連線到系統復位。它的主要功能是定期檢查程式在晶元中的運 況，且其中斷優先順序為最高端。實際應用 在程式的主函式的while函式中新增餵狗語句。void main void 在中斷函式中，不要新增whi...
如何架構乙個ios專案 個人經驗總結
搞ios開發整整2年多 一直都是寫 為了某個功能去寫 從來沒有仔細的考慮過 如何架構乙個專案 現今天 總結一下 架構乙個專案的基本流程 專案分為三層 ui層 bll 層 common層 ui層 做什麼？首先我會建立乙個 baseviewcontroller類 裡面會做一些比較基礎的 標題 左butt...
組織專案討論會的經驗總結（一）
為了更有效的進行團隊溝通，不定期的召開討論會成了第一選擇，但是如何組織討論會才會更有效率呢？這可能是專案管理中經常遇到的問題，也是我一直在思考的問題。在實踐中，通過與團隊進行多次討論會後，我認為可以從以下幾方面著手。1 召開討論會之前，提前告知大家討論的議題，讓大家有個基本的準備 2 討論會開始時，...