忙碌的四月天

依然是打CODE天

不知不覺又一個月過去了

看到上一篇網址就慚愧

作業系統的書買了之後

沒有翻開幾次幾次

因為都在趕加班專案阿阿阿~

 

雖然說是趕專案

其實也沒有遇上什麼大困難

比較有問題的

仍舊是串接signalR的部分

有一個Double的欄位

後端直接給Nan

原本用xamarin的C#接起來沒問題

但是在swift裡面

不論是用String?,Double?

甚至是Data?等nullable的型別

都無法解析

 

最後最後是查到

在用jsonDecoder解析資料前

必須加上nan的例外狀況

才能成功把把jsonString轉為物件

不過這個之後應該也不會遇到了啦

真的是太雷了

 

除了加班專案

平時上班的案子也是如火如荼的進行中

其中一個比較忙的

應該就是重構專案了

 

要重構的程式

原本只有接台指期貨日盤的資料

也就是每天8:45-13:30的交易資料

新的需求是接夜盤訊號

也就是每天的15:00-5:00的交易資料

 

這支App就是當初我們四個新人

在一起完成的最後一個案子

雖然當初那時候我是寫Android

不過資料結構是雙平台一起討論出來的

所以iOS的程式碼看起來

和當初的Android架構差不多

 

 

差不多一樣可怕...

 

 

這個專案在上架之後

有給其他同事接手過一陣子

據他的說法是看了頭很痛

改A壞B是常態

最後通常都只能用折衷的方式

把新功能加上去

 

但是這次新增夜盤的功能

就不是用折衷的方式就可以加上去的了

包括整個App的資料流程

畫面上日夜盤的切換

這些當初設計時沒有考慮到的問題

一一浮出檯面

 

望著雜草叢生的static欄位

以及乍看意義不明

但是拿掉就會crash的lock

動輒上千行的class

還有各種「神秘」的資料流

剛開始要重構時

其實還滿無力的

 

但是畢竟看過三四個其他專案

多少有一點長進

一樣靜下心來

把程式碼讀過一兩遍後

決定往三個方向改進

1. 拿掉原本的static物件,改用dictionary存日夜盤資料

2. 拆分資料中心,不要把資料全部存在一個class

3. 封裝Chart圖邏輯,把畫圖的方法抽成一個class

 

既然重構是一條漫漫長路

避免一改之後就build不起來的窘境

因此我並沒有刪掉原本的程式碼

而是用新增的方式

把原來的畫面蓋過去

待重構完成之後

再把舊的程式碼一次清掉

 

重構的第一個重點

就是把資料結構從原本的static

改成用早盤晚盤為Key值的dictionary

除了欄位不用重複兩倍之外

也同時解決多執行緒的問題

原本的lock幾乎都可以拿掉

程式也不會再閃退

 

第二點的資料中心拆分

過去是全部都放在一起

而且還是用static存

也就是四個主頁面的資料

都放在同一個class

新的寫法就把每一個頁面資料

獨立成一個class

避免後人找code找到眼花撩亂

 

第三點就是封裝Chart圖邏輯

因為這支App是投資軟體的關係

有需多功能通常跟Chart圖脫離不了關係

包括查價線

圖的伸縮,滑動,以及連動等等邏輯

原本全部散在頁面的ViewController裡面

真的是很不好

 

就像家裡的客廳

擺滿了亂七八糟的衣服或是鍋碗瓢盆

雖然沒有它們生活的確會出問題

但是擺在外層就感覺有礙觀瞻

 

於是這一次重構就把相關邏輯封裝在一個class裡面

在封裝的同時

也改變了Chart圖的計算邏輯

原本是把新資料加入data

再使用notifyDataChange去刷畫面

但是這樣邏輯就會變得很複雜

因為必須考慮到回補和即時資料的先後順序

而且還必須加上一堆lock

非常不好維護

也就是另外一個同事說的

改A壞B

 

所以新的寫法

選擇相信手機效能

只要收到新的資料

就是產生一個全新的data

讓畫面全部重刷

 

原本還擔心效能問題

不過實測之後發現

這樣的loding對於手機來說

還算輕鬆寫意

所以就改成這種寫法

 

重構真的還滿舒服的

就跟大掃除一樣

把東西整理歸位

把不要的垃圾清一清

看完整個身心舒暢

 

我也是在這一次的重構中

深刻體會到

對於程式來說

什麼語言不是最重要的

核心還是背後的抽象化概念

如何去設計資料結構或是流程

並且避免反直覺

一看就會起疑的code

才是工程師要追求的

 

另外一個即將上架的案子

一樣如火如荼

據PM的說法

老闆對於這支app的期待是突破天際

所以做起來就格外慎重

(當然每一支app我都很慎重啦)

 

不過也是因為趕上架的關係

專案的需求改動非常頻繁

通常沒有太多時間思考

就會把功能硬做上去

有時候甚至連註解沒有寫幾句

因為其實自己都知道這種急就章的寫法很糟糕

像是閃電的巢狀if else

相似度87%卻沒抽成共用的程式碼

不加註解就一定看不懂的邏輯

太多太多

感覺自己重構一支程式的同時

又在搞砸另外一支程式

 

這樣一個月下來

驚覺自己開始會心浮氣躁

即使完成許多功能也沒有很開心

因為知道code的瑕疵其實很多

 

這時就想起之前主管說的話

他不在乎看到髒code

而是在乎看到髒code會採取什麼行動

不過現在也只能加上滿滿的TODO

待專案第一版上架後

第二版加入新功能前

再慢慢把技術債還掉

不然到時候CodeReview就要信用破產了


 

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 李家豪 的頭像
    李家豪

    李家豪的部落格

    李家豪 發表在 痞客邦 留言(1) 人氣()