**訂單繳費服務
近期因爲項目要新接入一個第三方的繳費服務，在整個項目完成的過程中，遇到了一些問題，當然最後項目安然上線。但是由於是第一次接觸到第三方的接口和服務，因此確實體會還比較多，具體的技術細節上也接觸到一些新的工具，感覺很興奮。
此文主要從項目業務實現的角度，討論個人對於項目優化的一些想法，具體的技術細節，會另外單獨去寫文。
- 第三方對接，大家好纔是真的好
- 是否還有其他的實現方式？
- 關於項目開發的效率–文檔和封裝框架的使用
- 關於開源項目的使用
- 技術的意義就是完成業務的開發？
第三方對接，大家好纔是真的好
Third-party interface, every part being good is genuine good!——from me
之前在開發項目的時候，有涉及到內部不同部門和業務團隊的接口調用，但是大部分情況下，因爲還算是在一個體系之內還都算比較順利。然而這次接入的是一個第三方的服務提供商， 明顯的在溝通的成本上要遠遠大於內部的接口調用。很多很簡單的事情，其實都反覆的溝通了多次，回頭想想，其實也沒有什麼特別困難的點，其實都是溝通的效率太低了。
開發過程中，雖然有完整的文檔，但是先後還是重複溝通的其中一些具體的細節：通信報文的加密解密方式 、報文報頭和報體的格式約定規則 、關於具體約定規則的含義 、關於聯調的環境配置問題等。雖然整個項目開發的時間還算充裕，但是確實溝通佔了很大一部分。看來在這方面，咱們這邊應該思考下，這溝通方式還是很重要的一個因素，如果這個溝通的效率很高了，開發的工期應該還能更短一些。
關於這一點，從我自己的角度來說的話，有一些值得反思的地方。本人決定對自己提出一定的要求，希望以後能從自身的提升將這類問題對項目的影響降到比較低的水平：
1. 提高對三方文檔的重視程度，保證閱讀後對技術細節完全理解
2. 在提問題之前，一定按照文檔完成一個完整流程的demo
3. 對於第三方提供的demo一定要理解透，無論基於哪種開發語言
是否還有其他的實現方式？
Don’t be so serious, this is just brainstorm.——from me
這一部分主要是想思考一些，關於項目實現方式的效率問題。主要的角度就是考慮吹毛求疵，以便能探求和思考不同的實現方式對於計算機計算資源的利用率。
本次**訂單繳費服務，採用的是windows服務的形式實現，並採用定時跑任務的形式去對付款訂單進行處理。該服務包含兩個job，一個job定時3分鐘，另一個6分鐘。假定在日常上班時間和晚上休息時間，一整天24小時，其中至少有凌晨5-6小時的時間，該服務佔用的資源是無意義的。雖然每單次處理佔用的資源並不多，但是幾個小時的計算機資源如果積累起來，用作其他有實際意義的用途，也算是用的其所了。
按照最優的情況，就是用戶在下訂單的過程中，根據用戶的下單之後，分配商家後，直接調用服務，然後訂單即可直接根據返回的第三方接口狀態直接確定訂單狀態（這裏還涉及到一個商家分配邏輯和兼容其他第三方接口的問題，這裏只考慮最優效率，不考慮兼容）。如果這樣的情況，則需要在商家分配之後，根據用戶請求的參數，動態進行判定，然後調用具體的服務接口，此處本項目的商家分配，由於歷史原因，十分的複雜，個人認爲已經到了需要考慮解耦的情況了，目前單個類的代碼行數已經上千了。
此種情況下，只有用戶在下單時，纔對接口的調用進行觸發，因此，不存在windows服務在閒時進行運轉的資源浪費問題（當然，因爲該第三方服務是實時反饋訂單受理情況，因此可以採用這種思路）。
總結下來，如果提高效率和爲了以後長久的項目發展以及維護，有以下幾個事情需要做：
1. 商家分配服務功能解耦
2. 將可以實時反饋的商家處理訂單加入解耦後的具體實現模塊
3. 將不可實時反饋的商家訂單處理加入消息隊列處理
關於項目開發的效率–文檔和封裝框架的使用
Everything is software, all problems are caused by human——from me
在整個項目業務代碼開發的過程中，我遇到了幾個問題，事後想起來，個人確實受到了這些影響導致了效率的降低。1. 公司之前負責和第三方對接的另一個業務負責開發，告知他們的文檔有錯誤，對接口提供方發表了一些個人的看法，之後我的印象就是第三方不靠譜；2. 在本公司內部開發的過程中，沒有強行的要求開發文檔和相關規範，業務開發團隊各自分離，交接出去的成本很高 3. 公司內部的封裝框架有底層方法不完整，這次項目就出現了實現功能相同，但是因爲實現方式的不同，導致我們引用的時候，一個方法正常，另一個無法正常使用的情況。
項目在這樣的情況下，目前業務團隊相對比較穩定的情況下，問題並沒有特別的顯現。但是一旦出現業務的老人和新人的交接，或者團隊開發任務的調整，則會出現對業務模塊的熟悉時間和維護效率的問題。這樣繼續下去的直接後果就是，負責某一個模塊的開發的工程師對自己的業務模塊越來越熟悉，這個人如果離職，其原本負責的工作，交接和維護工作就成爲一個坑。而對於這個問題，在上一家公司，本人就深有體會，各種坑。
對於這樣的情況，個人認爲重構的工作可以穿插在日常開發的工作中。具體的改善方法，可以從以下幾個方面入手：
1. 技術總負責人，將手中的維護和開發任務逐步分散，重點抓各個模塊的代碼規範和重構工作。
2. 完善公共框架，並逐步的推進各個業務團隊，替換零散的方法，保證代碼重用率和安全問題。
關於開源項目的使用
Free software is software that respects your freedom and the social solidarity of your community. So it’s free as in freedom.——from Richard Matthew Stallman
其實關於開源項目的使用這點，更多的是我個人的體會。個人覺得目前項目中使用的開源技術和各種，已經遠遠的超過之前上一家公司的情況，感覺效率提高了不止一點。目前個人已經習慣性的在處理一個具體的業務實現時，首先想到的就是開源第三方框架的使用，這個對我個人來說是一個非常重要的改變。
在本項目的使用過程中，我接觸到了以下幾種開源的框架的使用：log4net, Topshelf, BouncyCastle, Quartz.Net, NOPI等。雖然公司的大神前輩可能覺得沒什麼，但是我再實際的開發過程中，用到這些框架的感覺，就是強烈的相見恨晚的樣子。而且，在這過程中，個人也逐漸的開始瞭解和學習這些開源框架的原理和底層，隨後就是各種對大神的膜拜。
個人決定設立一個遠大的目標：
1. 希望在自己感興趣的NLP領域，實現自己的開源項目。
2. 逐步的深入到開源社區，並儘量參與到相關工作中。
希望不久的將來可以實現自己的目標。
技術的意義就是完成業務的開發？
Any sufficiently advanced technology is indistinguishable from magic.——ArthurC.Clarke
我覺得上面的一句話已經足夠表達我的觀點了。並非所有領域都有機會可以隨心所欲的幻想，然後憑藉自己的雙手，去實現整個所有的一切。然而，我堅信，科學和技術是最有效的工具，不過，如果你是一個自己給自己設限制的人，那對不起，你也許聽不懂我在說什麼。
科學和技術都是可以從前人的文字和經驗學習的信息，然而也並非所有人都可以成爲馮諾依曼，成爲費恩曼，成爲錢學森，成爲比爾蓋茨，成爲喬布斯，成爲謝爾蓋。
這世界，除了眼前的苟且，還有詩和遠方。
完。