關于近期技術改造的一些思考

 在過去的差不多一個半月時間裡，有幸參與了訂單清單的翻譯工作，這個工作就做一個事情，将訂單清單的實作由php語言改為java語言（類似于搬運工的工作）。在這個過程中有一些個人的感悟，沉澱下來作為個人的總結。

 個人感悟亦或是總結我覺得主要是分為兩大塊，一塊我稱之為項目把控的反思，另一塊我稱之為技術上的反思。

關于技術改造中項目把控的反思

現狀的分析

• 這裡想強調下前人工作的重要性，我參與的技術改造屬于二期，是以很多問題和隐藏的坑已經被前人很好的解決了，我們能夠站在前人的肩膀上繼續前進。
• 因為有了前人的鋪路，至少在兩點上我們比較有信心，第一是實際方案的選擇上幾乎沿用了技術改造一期定的方案；第二是心理上對技術改造過程中能夠遇到的困難比較樂觀，至少我們能夠遇到的問題不會比一期的更多，類似于有點戰略上要藐視，戰術要重視的意味。
• 實際執行當中至少技術上我們遇到的困難跟我們預估的比較相近，沒有出現預期之外的問題。

跨團隊協作問題。

• 在這個改造過程中，由于依賴的上下遊業務接口同樣需要由php改造為java的實作，是以這裡就需要涉及到跨團隊的協作問題。
• 針對這種跨團隊的協作，我們也借鑒了一期技術改造的經驗，通過前期梳理依賴接口，友鄰團隊專人跟進的方針去實施，這個方案的優點在于友鄰團隊能夠在集中的時間視窗内提供服務。
• 實際過程中還可能遇到前期梳理存在遺漏的依賴接口或者提供的服務接口存在問題，這些都需要與友鄰團隊保持溝通及時回報解決，這個過程中可能會零散地貫穿整個過程。

做好應對突發問題的預期

• 在整個技術改造過程中需要做好應對突發問題的預期，突發問題在實際改造過程指的就是原本已經線上上使用的接口有可能在java中就不好使了。
• 實際遇到的最大的突發問題就是原本java的服務通過rest協定釋出服務線上上使用沒有問題，但是一旦轉為dubbo調用之後，各種不規範的寫法導緻的問題就會爆發，主要集中為基本的對象序列化定義缺失，導緻部分接口需要重新釋出上線。
• 另外，在開發和測試過程中會遇到一些服務不存在預發環境或者預發環境經常性重新開機服務不穩定，針對這種問題我們基本上把這類服務直接直連線上，當然這是有前期條件的，那就是我們的服務都是read類型，是以不存在污染線上環境的可能。

及時做好向上管理

• 這裡主要想強調的是對于這類技術改造的項目，前期我們很難有全面的時間評估，而且大部分技術改造都是按照deadline來倒推時間線，時間點大機率是比較趕的，能做到的就是盡量往前趕，保證deadline之前完成。
• 在保證大deadline的前期下，對于未按照實際排期完成任務的情況，需要及時回報問題做好向上管理，保證雙方得到的資訊是一緻的。

技術改造時間點的選擇

• 對于電商公司，Q3進行技術改造不是一個好選擇，特别在雙11-12期間，事實證明時間會被各種打亂。

關于技術改造中技術上的反思

翻譯和重構的平衡

• 在改造過程中會自然而然遇到是直接搬運代碼還是按照功能重構代碼的靈魂拷問，平心而論直接搬運代碼有辱程式員的底線，而按照功能重構代碼又有時間上的問題，是以建議在兩者取個平衡。
• 在保證時間點的前提下盡量把原來一團麻的代碼進行有限的梳理，至少按照功能塊拆分下保證條理順便保證下代碼的可讀性。
• 強烈建議在模型和視圖(MV)這個原則上，需要在代碼上強行進行隔離，不然你會發現後人會在原本視圖的基礎上耦合進各種模型的内容，導緻代碼腐化的非常嚴重。

新技術和新平台的使用

• 在改造過程中針對具體實作，如果使用新的技術特性能夠節省工作量那麼強烈建議使用，至少在我們改造過程中java8的stream的文法節省了大量的工作量。
• 咨詢下公司内部是否有新的平台能夠幫忙提高自測的能效，如果有那麼同樣強烈建議使用。

往前多想一步

• 在保證改造工作完成的前期下，如果有時間能夠往前多想一步，考慮到這個業務的遷移有可能導緻流量配置設定的遷移以及帶來的影響，可以提前做好方案。
• 備用的方案方案包括流量配置設定需要帶來的機器擴容或者應用的拆分，其實改造隻是第一步，後續帶來的問題會引發一系列的問題同樣值得深思。