coding的時光總是過得特別快

一個月又匆匆過去啦

從這個月開始

手機組內用TFS進行專案管理

檢驗大家的工作進度

扣除掉一小時的「溝通時間」

每人每天總共有七個小時

兩周為一期的Sprint

總工時為70小時

百分之六十拿來做需求

剩下的則是維修bug以及精進技術

Sprint的第一天

就是開單預估工時

我這一期的主要任務

是把一個Xamarin的專案

套上公司template專案的架構

翻寫回原生Swift

當初以為不用重新思考邏輯架構

加上套用template的code

速度應該會很快

工時就估滿少的

沒想到卻嚴重超時

主要原因是卡在一些愚蠢的錯誤上

像是http request發不出去

檢查了半天

才發現是info.plist沒有設定網路權限

另一個卡很久的問題

就是codable 和 encodable

因為它們在IDE上的顯示的顏色

和class一樣

再加上繼承後不用實作任何方法

我就誤以為它們是class

在父類繼承encodable

但是子類並不會具有encodable的特性

因此在進行json轉物件的解析時

出來的值永遠為預設值

也是花了好久

最後才發現是這個原因

導致無法接到正確的資料

想建議以後組內都要寫一些防雷筆記

不然在一些基本問題上面卡很久

真的是很浪費生命

雖然被愚蠢的bug卡住很煩

不過看到前輩漂亮的code

還是滿開心的

從最基本的class拆分

建立資料的快取

還有寫泛型方法

以及使用extension的技巧等等

就像研究了很多遍的拳法劍譜

終於看到有人活靈活現的使出來

真的會打從心底讚嘆

當然更重要的就是模仿以及學習

除了翻寫原生專案

另外一個主要的需求就是接推播

其實步驟還滿麻煩的

必須申請推播憑證

(還分沙盒和正式版)

交給後台的同仁後

再使用測試程式進行推播

和PM驗收時

常常發現android收到推播了

iOS的推播卻不見了

具體原因為被apple斷線

但為什麼會被斷還不確定

而iOS推播格式也不盡相同

有一次後台退版

發送的推播格式有變

但是前端並沒有跟著改格式

仍然去解析舊的欄位

然後就閃退了

心得就是推播真的滿容易出錯的

必須要非常小心

這個月要修的bug

依舊是各種閃退問題

包括nuget套件版本過舊

用新的格式，解析到殘存的UserDefalt

http 請求的資料回來後

發現原本請求的頁面被消滅了等等

解bug除了耐心和了解程式邏輯

更重要的是從發生的時機

反推最可能的原因

能夠準確的重現bug

通常答案也就不遠了

當了工程師之後

才了解為什麼描述閃退情況

對於解bug這麼重要

Spring中精進的時間

主要是組內的code Review

除了觀摩正確的寫法

更多的是提醒彼此

不要犯下相同的錯誤

比如說把unix time轉成字串後比大小

雖然很幸運的這一次比對了

但是換一個環境編譯可能就不一樣了

還有資料結構的邏輯

不應該依附在畫面元件

例如把股票的key值

放在button tag上面  

解bug的時候

不應該發生null時 

就給他return

而是要找到源頭問題

做完需求後解bug

解完bug做需求

2019年第一個月就這麼過去了

緊接著就是農曆新年

主管跟每位工程師進行年終面談

問到如何知道自己進步

主管說其實有滿多方法的

最簡單的就是設立目標

如果不知道目標在哪

試著放大自己的優點

或是改正自己的缺點

也是一種進步

再不然就是想想

什麼會讓自己退步

當出現這種情況的時候

就要留意

剛起步的路上

可能自己有很多疑惑徬徨

甚至不必要的擔心

主管說有時候行動比擔心更有用

做就對了

期望今年的自己

能夠改掉這個擔心的壞習慣

(但還是會擔心改不掉)