在過去的差不多一個半月時間裏，有幸參與了訂單列表的翻譯工作，這個工作就做一個事情，將訂單列表的實現由php語言改爲java語言（類似於搬運工的工作）。在這個過程中有一些個人的感悟，沉澱下來作爲個人的總結。
個人感悟亦或是總結我覺得主要是分爲兩大塊，一塊我稱之爲項目把控的反思，另一塊我稱之爲技術上的反思。
關於技術改造中項目把控的反思
現狀的分析
- 這裏想強調下前人工作的重要性，我參與的技術改造屬於二期，所以很多問題和隱藏的坑已經被前人很好的解決了，我們能夠站在前人的肩膀上繼續前進。
- 因爲有了前人的鋪路，至少在兩點上我們比較有信心，第一是實際方案的選擇上幾乎沿用了技術改造一期定的方案；第二是心理上對技術改造過程中能夠遇到的困難比較樂觀，至少我們能夠遇到的問題不會比一期的更多，類似於有點戰略上要藐視，戰術要重視的意味。
- 實際執行當中至少技術上我們遇到的困難跟我們預估的比較相近，沒有出現預期之外的問題。
跨團隊協作問題。
- 在這個改造過程中，由於依賴的上下游業務接口同樣需要由php改造爲java的實現，所以這裏就需要涉及到跨團隊的協作問題。
- 針對這種跨團隊的協作，我們也借鑑了一期技術改造的經驗，通過前期梳理依賴接口，友鄰團隊專人跟進的方針去實施，這個方案的優點在於友鄰團隊能夠在集中的時間窗口內提供服務。
- 實際過程中還可能遇到前期梳理存在遺漏的依賴接口或者提供的服務接口存在問題，這些都需要與友鄰團隊保持溝通及時反饋解決，這個過程中可能會零散地貫穿整個過程。
做好應對突發問題的預期
- 在整個技術改造過程中需要做好應對突發問題的預期，突發問題在實際改造過程指的就是原本已經在線上使用的接口有可能在java中就不好使了。
- 實際遇到的最大的突發問題就是原本java的服務通過rest協議發佈服務在線上使用沒有問題，但是一旦轉爲dubbo調用之後，各種不規範的寫法導致的問題就會爆發，主要集中爲基本的對象序列化定義缺失，導致部分接口需要重新發布上線。
- 另外，在開發和測試過程中會遇到一些服務不存在預發環境或者預發環境經常性重啓服務不穩定，針對這種問題我們基本上把這類服務直接直連線上，當然這是有前期條件的，那就是我們的服務都是read類型，所以不存在污染線上環境的可能。
及時做好向上管理
- 這裏主要想強調的是對於這類技術改造的項目，前期我們很難有全面的時間評估，而且大部分技術改造都是按照deadline來倒推時間線，時間點大概率是比較趕的，能做到的就是儘量往前趕，保證deadline之前完成。
- 在保證大deadline的前期下，對於未按照實際排期完成任務的情況，需要及時反饋問題做好向上管理，保證雙方得到的信息是一致的。
技術改造時間點的選擇
- 對於電商公司，Q3進行技術改造不是一個好選擇，特別在雙11-12期間，事實證明時間會被各種打亂。
關於技術改造中技術上的反思
翻譯和重構的平衡
- 在改造過程中會自然而然遇到是直接搬運代碼還是按照功能重構代碼的靈魂拷問，平心而論直接搬運代碼有辱程序員的底線，而按照功能重構代碼又有時間上的問題，所以建議在兩者取個平衡。
- 在保證時間點的前提下儘量把原來一團麻的代碼進行有限的梳理，至少按照功能塊拆分下保證條理順便保證下代碼的可讀性。
- 強烈建議在模型和視圖(MV)這個原則上，需要在代碼上強行進行隔離，不然你會發現後人會在原本視圖的基礎上耦合進各種模型的內容，導致代碼腐化的非常嚴重。
新技術和新平臺的使用
- 在改造過程中針對具體實現，如果使用新的技術特性能夠節省工作量那麼強烈建議使用，至少在我們改造過程中java8的stream的語法節省了大量的工作量。
- 諮詢下公司內部是否有新的平臺能夠幫忙提高自測的能效，如果有那麼同樣強烈建議使用。
往前多想一步
- 在保證改造工作完成的前期下，如果有時間能夠往前多想一步，考慮到這個業務的遷移有可能導致流量分配的遷移以及帶來的影響，可以提前做好方案。
- 備用的方案方案包括流量分配需要帶來的機器擴容或者應用的拆分，其實改造只是第一步，後續帶來的問題會引發一系列的問題同樣值得深思。