Crashlytics ANR
最近我負責的產品 App 流量大增（至少成長十倍），各種崩潰數據也跟著多了起來，尤其是 Android App，出現了一堆我壓根沒見過的問題，畢竟過去十年我都在做 iOS App，這下子得趁這一波學習一下啦～
我在 Firebase Crashlytics 後台上見到一些議題，先截個圖來看看多麽嚴重刺激！？😃
Archive for the ‘工作’ Category
App 產品歷經十年的挑戰與困難
我想是可以分享的時候了～
2019 年我進入一家 2009 年成立的公司，是以 Web 起家，2012 年開始研發 App，據傳當時僅有一為 App 工程師，同時要寫 iOS 和 Android，這讓聽到的我感到不可思議，一方面佩服該工程師偉哉之處，一方面擔心若該工程師發生意外，有人能夠接手處理嗎？🤔
我接手 iOS 專案時，已經不再是由一人同時研發兩平台，所以我能專注在我熱愛的平台 iOS，首先評估當前專案狀況。
iOS App 歷代開發者接手時間
- 第四人：2019/09 就是我～🙃
- 第三人：2017/04
- 第二人：2014/03
- 第一人：2012/07
接手別人寫的專案有好處嗎？有～但壞處也不少喔！
好處是不必再想架構，基本上照著前人已制定好的架構繼續做即可。
若有新的功能，則視情況發展自己的邏輯架構。
壞處則是首先要熟悉前人的程式邏輯，我必須瞻前顧後，確定不會影響舊有功能為前提，才能繼續開發新的功能。
由於 App 已有久遠歷史，專案有數量眾多檔案與複雜邏輯，每次編譯會花費 1-5 分鐘不等（端視筆電規格與有無快取）。
有可能踩到前人不小心埋的坑，導致增修功能後，產生不預期的問題，甚至可能難以除錯。
[圖解] 2022 年科技業衰退追蹤
身為資訊軟體工作者，會時常關注國內外企業的聘僱狀況，來了解當前產業景氣狀況。🤓
2022 後半年，發現有好多裁員新聞，但是一直都很難去了解整體狀況。偶然間在臉書粉絲團發現特別的網站，會統計大企業公開裁員新聞，圖解做得非常好理解，我們一起來看一下吧～
這是每個月裁員數量統計，數字越大就長得越高。
有在一些平台群體中聽聞，在該企業宣布要裁員，在該企業的員工上班會忐忑不安，直到結果出爐，才稍做喘息。
（繼續閱讀…）什麼是 Scrum 團隊？
目前我們研發團隊已經跑了兩個 Sprint，想要陸續來了解一些跟 Scrum 有關的定義和規則。
原本以為【敏捷開發】可以加速開發，畢竟叫做【敏捷】，但查了網路文章，有經驗人士分享，結果根本就不是啊⋯⋯🤪
這讓我對敏捷開發幻滅，身為我這種生產力極高的工程師說，實際跑才兩個 Sprint 就發現，此模式是會拖慢我開發效率的⋯⋯不過還是希望習慣此開發模式之後，會逐漸加快吧～
這次就來理解什麼是 Scrum 團隊？
看了這張圖，就能了解 Scrum 團隊包含哪些角色，目前看起來 Scrum Master 和 Product Owner 相當重要，我們團隊是由有三年跑 Scrum 研發經驗的工程師翔所領導。趁這時候聽話照著做，肯定能學到許多！😎
我們工程師有 Web、iOS、Android、Flutter、Backend、Architect、DevOps 等。而設計師、需求者（市場、業務、產品等）等不在我們 Scrum 團隊中。
（繼續閱讀…）
Scrum 與 Sprint
工作多年，一直有聽說跑 Scrum 與跑 Sprint，但一直不曉得真正的規則是什麼？覺得新創公司的開發步調就是種跑 Scrum，但好像又相差甚遠。🤔
終於，這次新創團隊，某位翔大在前公司有跑 Scrum 的經驗，從無到有建立起來整套流程，據說他為了履行 Scrum 的真實義，甚至還因此讓上司覺得跑 Scrum 是個阻礙⋯⋯
我想，引進新的管理辦法，確實會讓原本順暢的工作流程受到干擾，也就是原本跑得流暢的工作程序，會出現窒礙難行的狀況。除非公司能夠承受變動過程的成本，如此推動跑 Scrum 才有機會成功～
我認為，須根據公司成長階段來實施 Scrum，初步可分為
- 0-1 草創
- 1-10 混沌
- 10-100 穩定
比較適合的是 1-10 階段，為什麼呢？介於混亂與穩定之間，可有效率發散與收斂研發效能！🤠
（繼續閱讀…）萬年老系統
萬年老系統是非常誇張的說法，我寫 iOS App 是從 iOS 6 開始，至今 2022 年已邁入 iOS 16，若說是老系統，應該頂多 16 年啦～😀
實際上現在公司的產品，是從 2016 年開始（看程式檔案有年份），還是使用 Objective C 開發，至今邁入第七年，我發現是有四個工程師陸續接手研發，因為有看到作者名字和程式風格。
因為我一直是開發 iOS App，所以一個月內我就對大部分的功能流程熟悉，包含串接後端 API 部分，只要有使用到的 API，一定給他測個成功和失敗案例。
目前公司後端工程師數量遠超過前端，畢竟後端模組至少有 10 個吧～假如 iOS 和 Android 勉強算兩個模組，可見後端複雜度之高～🤪
稍微了解 API 後，我明白後段相依性很大，想要在舊有錯綜複雜邏輯下往上加功能，肯定會有一些出乎意料之外的狀況。讓我想起萬年老系統那張圖～很是貼切呢！
總之，且戰且走，我們採滾動式開發～盡可能不要讓前端拿到有問題的 API 就好啦！😜
若有朋友需要開發 App，歡迎來找我喔～
[圖解] 專案計畫與實際
這次執行的區塊鏈平台產品，沒有足夠時間可以完整進行：分析、設計、實作、測試、釋出。
看到下方這張時程圖－專案計畫與實際，發覺我們正面臨的狀況，正好只有兩個月的時間，就要釋出給大眾使用，全部時程都擠在一起，這樣成果品質是不會太好的⋯⋯
我想主要原因在於，我們接手前人所寫的解決方案，尚未了解此 Code Base 架構與品質，就率先決定產品推出日期。
當我們人力陸續到位，能夠開始部署，才陸續遇到問題，光是要將缺陷給修正就要花點時間，再來還要新增需求。時間有限之下，需要有所取捨，如此就會造成混亂，每次局部測試一直遇到狀況，修正後還是會偶發狀況，表示整個系統是相當不穩定。
我主要心力放在 App 開發，我所在乎的後端，就是期待 API 能正確運作。於是我要先走一步，提早研究將來會使用到的技術。
期待接下來的時程能順利囉～🤪
Macbook Pro M1 Pro Benchmarks
三月初拿到全新筆電，忍不住就想要來比較效能差異。先前跟朋友借 Macbook Pro M1 2020，性能已相當優越；此刻公司配給 Macbook Pro M1 Pro 2021，想必然性能更升一級，那麼量化後會有多少差異呢？
升級 Macbook Pro 硬體
此文撰寫於２０２１／０９
最近發覺我手上的 Macbook Pro 2015 年的筆電，狀況越來越多，一開始我還能適應，不過最近狀況頻繁發生，於是審慎思考是否該換新的 Macbook Pro，畢竟未來狀況無疑會越來越多且頻繁～😳
為什麼狀況會越來越多且頻繁呢？
廣告
1. 為了開發最新最前衛的 App，勢必要跟著最新最前衛的技術走，於是將隨著時間更新 MacOS 和 Xcode，這兩者規格持續會有某大程度提升，也因此會更操硬體。每次我更新 MacOS 後，便明顯感受到，點擊頁面（Xcode 和 Chrome 等軟體）會延遲比上個 MacOS 更久。比如，過去可能是 0.1 秒反應時間，現在會提高為 0.2 秒，甚至更久。
2. CPU、Memory、Disk 使用率將會逐漸升高，一方面是軟體升級，一方面是硬體折損，一來一往，每經過一年，硬體的負擔將越來越重，而且運行的體感將越來越卡頓。其實就跟 iPhone 每經過一年，升級 iOS 後的體感極其類似。
我手上公司機 Macbook Pro 2015 狀況大致上如下：
1. 硬碟空間不足，僅有 128GB
2. 記憶體不夠，僅有 8GB
3. CPU負擔重，僅是 2.7GHz 雙核心 Intel Core i5
參考：https://support.apple.com/kb/SP715?locale=zh_TW
公司太省了吧⋯⋯😬影響到我的產能變低、錯誤變多，那可就萬萬不可啦～跟大家建議一下，要是公司連工具設備都不肯更新，可能就要另謀出路，因為工作後續衍伸的問題，都會從此誕生～不信？讓我們繼續看下去～
（繼續閱讀…）
逍遙文工作室 
HappyMan・迴響