電商系統二次開發---經驗之談

標籤：

本文簡單介紹了在電商行業，開發企業自有系統，要處理的一些問題與開發工作經驗的一些總結。開發的時候，考慮到了這些問題，開發將會更加順暢，開發出來的軟體將更有生命力。  充分利用原有系統功能，把工作量降低到最小公司的系統是是正在運行中的系統，做二次開發的時候往往是在原有的一些基礎功能上升級，這就要求不能破壞原有的功能邏輯，又要利用好先有的功能，因為要實現某些功能的時候，可能有的功能已經有了。例如，電商平台需要做一個儲值的功能，系統原本就有支付功能，禮券功能，那我們能否可以考慮把兩個功能綜合起來改造一下呢？  站在平台角度上設計、開發，做到模組化、工具化開發系統的時候，有時候需要跳出來考慮，開發的視角，不局限於項目本身，不局限於項目組本身，要站在全域的角度考慮。例如，有這樣一個情境，負責退換貨業務的項目組，需要開發一個功能，退款成功後需要推送一條訊息給APP用戶端，這個時候，可能需要研究一下諸如極光推送，友盟推送之類的第三方解決方案，然後調用第三方API開發相應的功能。無專屬偶，支付組，可能也要做類似的功能，在使用者支付成功後，需要推送一條訊息給APP，提醒一下使用者支付成功了，這個時候，支付組又要研究一下第三方推送的解決方案，做重複性工作了。其實一開始，退換貨組就應該分析到，訊息推送應該是比較通用的功能，完全可以開發一個通用的工具模組、工具，給整個公司的人使用。當然，開發通用模組這種工作，在有的公司可能有專門的架構組開發完成，這裡只是舉個例子而已。  處理代碼積累，重構代碼要相信，需求的變更，是代碼產生臭味，使代碼變的混亂、腐化的根源。特別是持續迭代更新的代碼，有時候為了趕進度，或者為了規避系統產生較大的改動，很容易破壞代碼原有設計，或者的隨意複製黏貼代碼快速實現某些功能，邏輯變得越來越複雜，重複的代碼變得越來越多，代碼最終改不下去了，然後才想起來要整理下代碼，這個時候已經太遲了，可能推到重新來過所付出的成本反而會更低。因此，在開發的時候，要做個有心人，一個小小的最佳化，一個小小的量變，都是為了未來做質變而準備。  各個端相容，各個版本相容公司走的是渠道電商解決方案，開發一個功能的時候，需要考慮到PC官網、安卓端、IOS端、移動T站端、門店系統、ERP系統，這些不同平台如何?，功能如何取捨；移動端同一個平台，開發的時候，還要考慮向低版本相容。各種不同端背後可能有不同的團隊負責，開展一個涉及面很廣的項目的時候，如何更高效地和各個組溝通，如何把握項目的進度，這都是很大的挑戰。  投入產生的控制，系統完善度與進度、項目風險之前的關係的平衡開發一個功能，有時候並不是做得越完善就越好，也不是做得越完美就越好，而是要平衡開發的投入成本和項目帶來的產出，要考慮值不值得你這樣折騰。當然，作為一個純粹的程式員，不考慮資本家的事情的話，做到100%完善、易用是最好的。  可行性、需求、開發、測試、上線、上線後的監控、上線後的效果、後續營運和升級的需求全程跟蹤作為開發人員，在參與項目的生命週期中，電商行業與其他行業有不同的地方，可能在於上線後的監控、效果跟蹤和營運。在電商行業，如果系統出現了問題，很有可能會影響銷售、影響客戶體驗，或者是出現一些漏洞，造成公司損失。因此確保系統穩健運行，不出問題至關重要，在系統上線後，必須做好監控，確保出了問題能夠第一時間發現和處理。系統穩定之後，還需要做效果評估，看開發的功能、做的項目是否帶來了回報 ，效果如何，看有沒有什麼地方需要改進、升級，擷取更大的回報。  讀到最後，讀者可能覺得文章可能是標題黨，這些經驗可能跟電商企業開發關係不是很必然， 也許在任何一家軟體開發的公司都會碰到這些問題，這也許是軟體開發想通的地方吧，但這確實是本人在從事電商行業軟體開發工作只所感，如有不合理的地方，還請指正，如有更多好的經驗和方法，歡迎分享。

電商系統二次開發---經驗之談