[圖解] 如何發佈行動應用程式
從 2012 年開始，我就從事行動應用程式開發（主要是 iOS App），至今已超過 10 年。當有人想知道我做什麼工作時，我必須短時間內說明清楚，只是一直沒找到好的描述方式，能讓外行的親友理解。
遇到神人做了這張圖，簡單描繪出我這些年來的工作日常～😎
行動應用程式發布過程的典型階段：
- 註冊與開發
- 建置和測試
- 品質保證
- 內部審核
- 應用程式商店優化
- 應用程式提交至商店
- 發布
Posts tagged ‘development’
初學工程師偏好開發 Web 或 App
雖說我的立場是偏好開發 App，也已經有 10+ 年經驗，但還是想分析一下，對於初學者來說，如何做選擇會比較恰當。
大概在 2010 年前後，我有短期開發網頁應用程式，確實上手門檻較低，不需要額外硬體或軟體支援，便可以馬上寫簡單的程式。
但其實，若我一天有 48 小時，我會希望 Web 和 App 都能開發～😛
最終，我選擇 App 開發，那會是最貼近生活的一種開發工作。
（繼續閱讀…）成為 App 工程師需要注意的四件事
一個月前，有位公職人員來信詢問，想知道一些關於 App 工程師職務的議題，在此我便以 10 年左右的經歷，來整理出主要可以參考的方向。
我是個從還是個資訊工程學系研究生時，就決定開始寫 iOS App，一寫至今，已經超過十個年頭，當時 Apple 才剛釋出 iOS 6，現在已將要發佈 iOS 17。
經過十個年頭，我依然堅持走這條路，因為這工作實在太好玩了，執行力夠強的話，一個人就可以完成一個 App，實在很符合我的個人特質－自幹。
智慧手機與平板電腦日益普及，程式語言和開發工具與時俱進，讓研發的過程更有效率，最後成果的體感越來越友善且優異。我陸續學習原生 Objective C、Swift，甚至嘗試跨平台 Xamarin、Ionic。如今更是期待 Flutter 能有長足的進步與發展。這樣一來，我想要同時開發 iOS 和 Android 就能輕鬆實現啦～😄
論技術能力我沒有到極強，只要能應用在產品與專案上，任何技術都能接納，特別是面向使用者，我追求 UI/UX 盡可能做到極致。🤗
（繼續閱讀…）什麼是 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 階段，為什麼呢？介於混亂與穩定之間，可有效率發散與收斂研發效能！🤠
（繼續閱讀…）[圖解] 專案計畫與實際
這次執行的區塊鏈平台產品，沒有足夠時間可以完整進行：分析、設計、實作、測試、釋出。
看到下方這張時程圖－專案計畫與實際，發覺我們正面臨的狀況，正好只有兩個月的時間，就要釋出給大眾使用，全部時程都擠在一起，這樣成果品質是不會太好的⋯⋯
我想主要原因在於，我們接手前人所寫的解決方案，尚未了解此 Code Base 架構與品質，就率先決定產品推出日期。
當我們人力陸續到位，能夠開始部署，才陸續遇到問題，光是要將缺陷給修正就要花點時間，再來還要新增需求。時間有限之下，需要有所取捨，如此就會造成混亂，每次局部測試一直遇到狀況，修正後還是會偶發狀況，表示整個系統是相當不穩定。
我主要心力放在 App 開發，我所在乎的後端，就是期待 API 能正確運作。於是我要先走一步，提早研究將來會使用到的技術。
期待接下來的時程能順利囉～🤪
[iOS] 更新推播憑證 (Renew Push Certificate)
又到了一年一度更新推播憑證的時候！因為先前僅有初次產出推播憑證經驗，但沒有更新推播憑證的經驗，以為會有多難，沒想到就跟初次一樣的步驟。🧐
發現舊有的憑證無法更新期限，那麼就如同第一次建立新的推播憑證吧！此次推播憑證更新：2020/10/05，期限：2021/11/04，有效期間為13個月。
廣告
廣告
安裝Xcode空間不足
一如往常，在Apple釋出iOS 14後不久，身為開發者的我就會更新Xcode 12（每年更新一個版本號），不過這次遇到奇妙的問題，明明筆電的可用空間大於軟體容量，安裝時居然還會跳出「空間不足」，而且也沒說不足多少，使得我必須不斷清理出空間，像是移除鮮少使用的軟體，甚至刪除前同事帳號裡的非必要的檔案，來下載Xcode 12。🧐
廣告
在App Store上看Xcode 12容量有11.2G，我騰出15G可用空間應該就足夠了才是，不過就是提示空間不足。
廣告
直到我硬擠出30G可用空間，還是給我裝傻空間不足⋯⋯😭
[Git] Branch and Merge (分支與合併)
最近要一口氣地將所有產品做完支援Layout API的功能，我特別善用Git的Branch (分支)功能，也就是把每一個開發目標都開個Branch，單純只記錄一個開發目標的變更，如圖：
Source Tree真是個好工具，可以將Branch以不同的顏色表達！
當每個開發目標都完成增修後，就可以開始一步一步來Merge (合併)，如圖：
儘管我是一個人在開發產品，然而我不馬乎地開Branch，就有機會碰到Conflict (衝突)，此時可來練習如何排除此問題，之後再遇多人協同合作的開發模式，就不必手忙腳亂囉～
使用指令也相當簡單：
- 分支：git branch
- 合併：git merge
逍遙文工作室 
HappyMan・迴響