這一個月
正確的來說應該是這兩個禮拜
依舊如火如荼地進行翻寫原生的工作
上個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可接受的版本
只有不斷地修練
才能讓每次的遺憾變少
也讓自己的孩子越來越可愛
留言列表
