耗時近兩個月才完成售後系統的構建附帶上對商品狀態的完全重構。之前由於商品狀態上有售後狀態的問題，導致重構難度極大。好幾次我都因而覺得找不到這套東西的突破口而抓狂。但是能完成這個專案對於我來說也意義重大，做任何事情都會要先踩坑後來才會了解哪些地方有坑。做重構和設計新系統並行這件事情本身就需要極大的耐心，這也是讓我感觸最深的一點。沒有仔細的思考邊界條件，沒有耐心的進行解耦就不會有被重構系統的新生。
上面莫名其妙就先雞湯了一波，可能是被這種專案折磨得太慘的怨念爆發。。。。下面就分兩部分對我在整個專案進行推進的時候遇到的難題進行一一分析和總結：
重構部分：
1. 重構系統的話，一定要考慮到以前系統的傳參邏輯。另外如果還涉及到有洗資料的需求的話，最好在新系統上線並行之前把資料洗一遍。這樣的話可以保證類似於自增id這樣的字段連貫。避免了以前**裡面有一些類似於order by id 這樣的**出現不應該有的錯誤。
對於重構乙個系統來說，如果這個系統很大無法一次性全部替換掉，或者中間有很多需要洗資料的情況存在的話，可能兩套系統會並行一段時間是最常見的情況之一了。這樣既能保證新系統現有功能可以穩定執行一段時間，也能保證避免使用過於激進的一口氣全部替換系統引起的系統不相容，資料不一致，前後系統邏輯改動太大導致很多細節問題的集中爆發。到時候可能真是加班乙個通宵夜無法解決完所有問題，還會冒著系統停機的風險，得不償失。
另外第二點裡面談到的乙個打注釋tag的方法是我在重構系統的時候摸索出來的乙個有效搜尋新**的方法。因為我們給**取名字的時候往往會有很多重複的情況存在，在定位自己最新改動**方便直接在**裡面檢視除了求助於git這樣的工具，直接搜尋自己打的注釋tag也能方便的幫你定位到你的最新修改。
3. 在重構系統或者在寫已經有一些邏輯的地方做新的設計，一定不要侷限於以前設計者的想法，要跳出來重新看待需要些什麼欄位做更詳細的設計，想得更周全。這個在**被review的時候感受特別深，因為最先做的是兩套系統並行，所以很多**其實都是依照著以前的系統邏輯來寫的，就是為了在以前系統執行的時候，能把最新的資料寫入到新建的表裡面去，為後面整體資料遷移做準備。但是當在設計最新的系統的時候，你不僅需要考慮到老系統的字段要全部能存能解析，還要考慮到有了新系統之後，老系統哪些地方的特判，或者邏輯發生了變化。站在新系統成型之後的邏輯角度去思考，可以幫助我改掉以前的一些特判或者是再無意義的判斷。更好的完成新系統的構建。 千萬不要再侷限於老系統的思路，去構建新系統，既然要重構，肯定就是要解決以前麻煩的地方和痛點。不然可能沒有解決太多問題，還把自己繞進去。
4. 每次重寫功能或者重構 都應該刪除掉沒有使用的功能的**。否則下次再進行重構的時候簡直寸步難行。這個體驗主要還是以前老**給的，因為以前特別多的老**就是被重構之後，沒有地方引用了，也不刪除乾淨。變數名字跟我新系統這邊特別相近，邏輯什麼的絞在一塊兒特別難處理，搜尋起來特別費勁。這次重構為了不再給後面人留坑，刪了特別多以前的老**。
5. 資料遷移涉及到 建立時間更新時間之類的東西。並且自增長id會被破壞。排序資料的時候最好用create_time資料遷移只要能遷移create_time 就不會破壞原來的**。這一點跟上面第二點裡面提到的有點像，所以平時order_be的時候可以考慮使用create_time。
6. 在遷移的時候如果會有很多中間狀態的話，遷移可能無法一步到位。而且在跑資料遷移的時候一定不能掉以輕心，一定要真實的測試幾次，如果上線再出問題 那可真是要了親命。所以要多考慮線上正在發生的事情會不會跟遷移這件事情本生產生衝突。這個也是。。。。一把鼻涕一把淚的訴說。因為商品狀態本來本身就有許許多多的狀態正在進行，那個指令碼考慮到了這件事情進行遷移，把各個對應不同狀態的商品狀態上對應的售後狀態都對映上了，然後一切看似都很成功。遷移完了之後發現，雖然新系統可以正常跑了，但是舊的商品上的狀態卻永遠停留在了原地，無法再走向完結了。。。。。這個大坑導致了未來一兩個星期都在斷斷續續的手動改這些狀態。所以在遷移的時候一定要仔細耐心，多思考邊界條件，多思考線上正在發生的事情。專注的想這些事情，做好規劃可以幫你在完成操作之後，更少的修改bug。
7. 千萬不要輕易重構別人的**，特別是在你許可權還不夠的情況下。除非你對整個系統極其了解，可以即使不看以前**也能再造一套這樣的系統。當然如果你可以做到這樣，那麼我還是建議你不要重構了，直接重寫吧。這個可以說是本次感受最最最深的點。因為既然你要重構**，踩坑，那麼多多少少都可能會出一些bug。特別是在以前的**還寫的不是那麼優雅的情況下。或者邏輯混亂的情況下。現在重構就是為了造出擁有更優雅的邏輯和結構的**。那麼如果你對這套系統還沒有那麼深的理解，你最好主動承認能力不夠。如果你覺得可以挑戰一下(我就是這樣)那麼一定要仔仔細細把控好每個細節。許可權不夠指的是，你對**最終走向何種級別算是完結沒有話語權，而且沒有辦法自己控制**的合併提交和bug修改。這會給你的重構工作帶來巨大壓力和不便，所以也要三思而後行。
其他感受部分：
1. 在進行表或者重要變數命名的時候，先參考著名前輩級產品有沒有類似描述。命名很重要。其他感受部分很多，也是平時編碼時候需要注意的所以都在一起寫了。另外鑑於交易系統的併發性，書寫**的時候都要特別注意處理併發的問題，該上樂觀鎖的時候打上樂觀鎖，該用悲觀鎖的時候就用悲觀鎖。2. 寫**的時候也要考慮一下在測試環境下 能不能盡可能相容。
3. 考慮有更新的資料庫的地方一定要充分考慮併發會造成的同時發生的問題是否能夠絕對避免,一般在使用orm獲取到當前值更新之後，一定要返回self本身，如果重新get值樂觀鎖將會毫無意義。
4. 在考慮這種有一定保密型單子的時候，一定要事先考慮好加密的東西，並且用unique欄位來保證。例如訂單號，服務單號，最好不要使用自增id，如果要使用自增id也不要在應用層面暴露這個自增id。可以做乙個加密演算法，把這個加密後的訂單id 和自增id都存在訂單表裡面，這樣查起來也方便，也不會在應用層暴露真實資料。
5. 需要快照的地方比方說一張表上要能取到所有資訊的時候，儲存的資訊一定要存全。不能拿個id跑到以前的地方去取。
6. 以後寫測試不要一邊介面一邊測試，而是將所有介面和東西都弄好之後再補充測試，否則稍有改動要改測試 非常耗時 成本非常高。
7. 掃瞄之前建立的資料庫以及其欄位，能最快速度的了解業務邏輯和功能。
8. 以後像類似需要json序列化欄位的時候 即使是空，也應該使用空的字典obj，這樣能進行平滑的loads字典判斷 而不是如果是空的話需要特殊的判斷。
9. 檔案命名也要注意單複數啊。
10. 兩個人在進行同步合作的時候 開乙個 分支跟上對方的分支 然後要測試 使用rebase 合併之後上傳到測試伺服器進行測試。這樣可以時刻保證擁有兩方最新的**，而且刪除方便不用大量rebase。
11. 每次都需要做的重要操作最好抽象到乙個 每次都要呼叫的函式裡面，這樣就不用到處找該函式的入口了
12. 在寫const的時候注意，其實const也可以寫函式來計算想要的東西。只要計算的是常量都沒有什麼問題。
13. 在呼叫第三方api 如退款的時候沒有辦法進行本地事物保證的時候，一定要先操作 最後呼叫。
14. 併發 併發問題 一定要考慮好，多伺服器 同時 負載均衡的時候太容易出現併發情況了。
15. 做東西之前多思考邊界條件。
16. 耐心。
最後 耐心！
以上。
售後系統構建和商品狀態重構經驗與總結
耗時近兩個月才完成售後系統的構建附帶上對商品狀態的完全重構。之前由於商品狀態上有售後狀態的問題，導致重構難度極大。好幾次我都因而覺得找不到這套東西的突破口而抓狂。但是能完成這個專案對於我來說也意義重大，做任何事情都會要先踩坑後來才會了解哪些地方有坑。做重構和設計新系統並行這件事情本身就需要極大的耐心...
vue獨立構建和執行構建
概念 有兩種構建方式，獨立構建和執行構建。它們的區別在於前者包含模板編譯器而後者不包含。模板編譯器 模板編譯器的職責是將模板字串編譯為純 j ascript 的渲染函式。如果你想要在元件中使用template選項，你就需要編譯器。模板字串 template el 提供乙個在頁面上已存在的 dom 元...
如何使用Phantom系統構建和維護軟體測試環境
我們假設乙個軟體測試部門或者測試小組，有60臺測試用pc，軟體測試人員需要在各種windows系統 各種不同的軟體配置環境下對公司的軟體產品的各個版本進行測試。假設公司的軟體測試環境網路拓撲如下 採用phantom 系統構建軟體測試環境需要如下配置 1 管理器配置 phantom 標準版管理伺服器 ...