這一個月

正確的來說應該是這兩個禮拜

依舊如火如荼地進行翻寫原生的工作

上個Sprint大概像是整裝

建立專案基本架構

開git，上test Flight

解決一些基本問題後

這一周才開始大步邁前

這次專案是我第三個Swift專案

寫code時

終於可以多考慮程式碼的架構了

而通常好的命名

對於程式碼的可讀性

就佔了一半

所以這一次在命名上

通常都會花比較久的時間

來思考怎樣的命名更清楚

寫起來就像是「散文」一樣

(Swift 官方建議~~)

另外一個花時間的

就是變數應該放在什麼地方

簡單來說就是程式的架構

全域變數能少就少

或是拆分到不同class

並且盡量不要讓資料和邏輯攪在一塊

建立資料中心

等新資料複製到快取後

才用Protocol的方式

通知頁面來資料中心取值

更新畫面

除了程式碼更清楚

也防止多執行緒亂七八糟的問題

而一份swift檔案也不會那麼肥大

日後要擴充也比較有方向

另外一個比較不一樣的地方

就是文件的撰寫

由於手機組之前的程式

大部分都沒有文件

就像一棟蓋好的建築物沒有藍圖一樣

出現問題時總是難以偵錯

尤其是不同人接code

這個問題又更加嚴重

所以主管都要求新的專案

都必須要附上流程圖

其實原本有一點點排斥

因為光寫code就趕不上進度了

何況還要寫文件

但是手頭上除了翻原生的專案

也有維護其他app

所以了解沒有文件的程式碼

難以釐清邏輯的來龍去脈

自然沒辦法培養好感情

只好還是乖乖寫文件

套件的部分選用Lucid Chart

不過都還在試驗階段

沒有硬性規定怎麼畫

不過在畫的過程中

就可以看見程式上的流程瑕疵

雖然不見得是錯誤

但是畫成流程圖就是會覺得怪怪的

雖然是同一份code

可是流程圖就像用另外一個人的角度

來審視整份程式碼

當作者無法用文件清楚描述流程時

更別說其他人來看這份code了

還有一個意料之外的點是

除了新的專案以外

我們也會安排時間

幫舊的文件畫流程圖

發現以前看不懂的程式碼

因為必須要畫流程圖的關係

終於看懂了

就像是聽課和講課的差異

要完整地描述程式邏輯

一定要非常清楚

否則流程圖一看就知道是錯的

算是意料之外的收穫

和文件功能相似

程式碼的註解

也是程式可讀性的一大指標

所以這一次新專案

我也花了很多時間在打註解

畢竟文件是大方向

好的註解才能真正引導使用者

詳細了解程式碼的邏輯

但是俗話說的好

註解會騙你，程式碼不會騙你

之前在修復BUG的時候

太相信註解而沒有實際去測試

才發現程式碼和註解的內容不一樣

上面說程式關閉就會消失

結果某次改版後變成用User Default存

(這個還是PM告訴我的…)

進入公司後

也開發了三四個手機專案

就想起以前大學時期

拍片時老師都會跟我們說

作品就像是我們的孩子

寫程式也是一樣

看著程式碼一行一行增加

功能一個一個完善

就像是看著孩子慢慢長大一樣

即使長得醜了點

或是偶爾耍叛逆閃退

但終究是自己寫的

像是把生命中最精華的歲月

都烙印在code裡面了

記錄了當下走過的痕跡

想當初一年前的這個時候

還在跟HTML,CSS奮鬥

現在已經是在跟Apple奮鬥了

每一次的專案

都會想著如何避免上一次的錯

但又總是會犯下更多不同的錯

程式碼也是一種遺憾的藝術

在dead line的期限下

交出一個自己不滿意

但是PM可接受的版本

只有不斷地修練

才能讓每次的遺憾變少

也讓自己的孩子越來越可愛