一位核心 PM 在團隊貢獻與卓越影響
Uka 在 2023/02 加入團隊，我跟她共事時期 2.5 年。我們團隊從 2022/02 草創時期，至今公司人員近 40 位同仁，而開發團隊成員（含 App 工程師、Web 工程師、後端工程師、專案/產品經理、測試工程師、維運工程師等等）約 20 位。😳
.
（繼續閱讀…）Posts tagged ‘工作’
面試 Flutter 技術能力
2024 下半年，公司將要進行重大開發案，需要引進更多人力來支援，於是 App 需要招募 1-2 名工程師。為了讓面試有效率地進行，我提前準備一些題目，並視情況在面試過程中提問。
當前應徵者的背景大多是寫原生的 iOS 或 Android 工程師，僅有約 1/10 的面試者有寫 Flutter App 經驗。於是就必須考量面試者並沒有 Flutter App 開發經驗，將改提問其他跟跨平台開發相關的議題。
此文章僅提供面試者有 Flutter App 開發經驗，且有原生 App 開發經驗的情況可供參考。🙂
我本身從 2012 年開始研發 iOS App，而在 2021 年接觸 Flutter 開發 App (iOS & Android)，公司在 2022 年全面以 Flutter App 取代原生 App。Flutter 在開發大部分應用已與原生 App 有同水平的成果，而在開發過程之效率則遠勝於原生。
（繼續閱讀…）關於站立會議 (Stand-up Meeting)
有一次 Retro Meeting，某群夥伴們討論到我們的每日站立會議（Stand-up Meeting）似乎已流於形式，感覺上是個可有可無的會議，也就是說就算沒有每天進行立會，並不會影響產品開發的進行。然而，真的是這樣子嗎？
我們立會至今已進入第三個年頭，一開始是使用 Trello 記錄工作任務，後來採用 Jira 更適合敏捷開發流程。起初報告模式是以「任務」為主，選到該任務就由相關人士來報告，比如要做登入或註冊功能，相關的前後端工程師就會依序報告；現在改以「人士」為主，輪到該人士報告，會將其所有任務簡潔報告出來，譬如我要在今日完成登入功能，明日開始製作註冊功能。
在一個規模完整的團隊中，立會對每個角色來說意義不大相同，在此就幾個問題來探討 Stand-up Meeting：
- 為何需要 Stand-up Meeting？
- 為何有人覺得不需要 Stand-up Meeting？
- 以不同角色看待 Stand-up Meeting 會有何優缺點？
- 為何有人認為 Stand-up Meeting 流於形式？
- 如何讓 Stand-up Meeting 變得有趣？
Rescue Time 救援時間
我們人的一生，至少有三分之一的時間是在工作，總會想要知道工作期間是否有效率。於是可透過偵測所使用軟體的時間，來辨別每個時段是否正在努力工作中，亦或是被其他事物干擾。😀
成為 App 工程師需要注意的四件事
一個月前，有位公職人員來信詢問，想知道一些關於 App 工程師職務的議題，在此我便以 10 年左右的經歷，來整理出主要可以參考的方向。
我是個從還是個資訊工程學系研究生時，就決定開始寫 iOS App，一寫至今，已經超過十個年頭，當時 Apple 才剛釋出 iOS 6，現在已將要發佈 iOS 17。
經過十個年頭，我依然堅持走這條路，因為這工作實在太好玩了，執行力夠強的話，一個人就可以完成一個 App，實在很符合我的個人特質－自幹。
智慧手機與平板電腦日益普及，程式語言和開發工具與時俱進，讓研發的過程更有效率，最後成果的體感越來越友善且優異。我陸續學習原生 Objective C、Swift，甚至嘗試跨平台 Xamarin、Ionic。如今更是期待 Flutter 能有長足的進步與發展。這樣一來，我想要同時開發 iOS 和 Android 就能輕鬆實現啦～😄
論技術能力我沒有到極強，只要能應用在產品與專案上，任何技術都能接納，特別是面向使用者，我追求 UI/UX 盡可能做到極致。🤗
（繼續閱讀…）App 產品歷經十年的挑戰與困難
我想是可以分享的時候了～
2019 年我進入一家 2009 年成立的公司，是以 Web 起家，2012 年開始研發 App，據傳當時僅有一為 App 工程師，同時要寫 iOS 和 Android，這讓聽到的我感到不可思議，一方面佩服該工程師偉哉之處，一方面擔心若該工程師發生意外，有人能夠接手處理嗎？🤔
我接手 iOS 專案時，已經不再是由一人同時研發兩平台，所以我能專注在我熱愛的平台 iOS，首先評估當前專案狀況。
iOS App 歷代開發者接手時間
- 第四人：2019/09 就是我～🙃
- 第三人：2017/04
- 第二人：2014/03
- 第一人：2012/07
接手別人寫的專案有好處嗎？有～但壞處也不少喔！
好處是不必再想架構，基本上照著前人已制定好的架構繼續做即可。
若有新的功能，則視情況發展自己的邏輯架構。
壞處則是首先要熟悉前人的程式邏輯，我必須瞻前顧後，確定不會影響舊有功能為前提，才能繼續開發新的功能。
由於 App 已有久遠歷史，專案有數量眾多檔案與複雜邏輯，每次編譯會花費 1-5 分鐘不等（端視筆電規格與有無快取）。
有可能踩到前人不小心埋的坑，導致增修功能後，產生不預期的問題，甚至可能難以除錯。
Scrum 與 Sprint
工作多年，一直有聽說跑 Scrum 與跑 Sprint，但一直不曉得真正的規則是什麼？覺得新創公司的開發步調就是種跑 Scrum，但好像又相差甚遠。🤔
終於，這次新創團隊，某位翔大在前公司有跑 Scrum 的經驗，從無到有建立起來整套流程，據說他為了履行 Scrum 的真實義，甚至還因此讓上司覺得跑 Scrum 是個阻礙⋯⋯
我想，引進新的管理辦法，確實會讓原本順暢的工作流程受到干擾，也就是原本跑得流暢的工作程序，會出現窒礙難行的狀況。除非公司能夠承受變動過程的成本，如此推動跑 Scrum 才有機會成功～
我認為，須根據公司成長階段來實施 Scrum，初步可分為
- 0-1 草創
- 1-10 混沌
- 10-100 穩定
比較適合的是 1-10 階段，為什麼呢？介於混亂與穩定之間，可有效率發散與收斂研發效能！🤠
（繼續閱讀…）升級 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・迴響