同一專案開發多個品牌
工作上即將進行同一專案開發多個品牌，可以怎麼開始比較恰當，於是就跟夥伴阿遠分析主要可能的做法與其優劣。🤔
.
在更改一個程式碼專案來適應不同品牌時，選擇直接複製專案開發或是開分支修改都有其優缺點。哪種方式更適合取決於專案的維護策略、程式碼的複雜性和團隊的工作流程。
（繼續閱讀…）Posts tagged ‘project’
萬年老系統
萬年老系統是非常誇張的說法，我寫 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 能正確運作。於是我要先走一步，提早研究將來會使用到的技術。
期待接下來的時程能順利囉～🤪
[Git] Branch and Merge (分支與合併)
最近要一口氣地將所有產品做完支援Layout API的功能，我特別善用Git的Branch (分支)功能，也就是把每一個開發目標都開個Branch，單純只記錄一個開發目標的變更，如圖：
Source Tree真是個好工具，可以將Branch以不同的顏色表達！
當每個開發目標都完成增修後，就可以開始一步一步來Merge (合併)，如圖：
儘管我是一個人在開發產品，然而我不馬乎地開Branch，就有機會碰到Conflict (衝突)，此時可來練習如何排除此問題，之後再遇多人協同合作的開發模式，就不必手忙腳亂囉～
使用指令也相當簡單：
- 分支：git branch
- 合併：git merge
[iOS][Xcode] 專案自定義變數 (Project User Defined Variable)
為了避免上架時把開發的東西誤上傳，那麼一開始最好就定義好Debug和Release，其實Debug和Release在Xcode中已有定義，包版本釋出預設就是Release，而開發的時候透過Xcode編譯到手機，預設則是Debug，不過其實可以改成Release來測試，如此方便！
透過Xcode可以讓專案自定義變數 (Project User Defined Variable)，這樣一來就算忘了有什麼是測試還是正式，都不用擔心會上錯啦～
[iOS] 視覺化專案相依關係 (Dependency Visualizer)
去年11月底，剛熟悉公司專案，想知道整個專案的至今的狀況如何，其中一個方式就是了解程式碼相依程度，我找到一個相當不錯的視覺化專案相依關係的工具，會透過網頁以互動的方式呈現。
我在GitHub上找個開源專案，透過模擬器編譯成功後，成功開啟網頁來玩泡泡～
從main開始進入AppDelegate。
[iOS] 專案檔案數遞增
本週輪到我第二次「文字探討」，這一次我分享進階除錯技巧，關於Xcode和LLDB。首先我表明為何需要學習進階除錯技巧，因為我們公司開發產品，歷時一年五個月，專案檔案數遞增有目共睹，我特別透過Git回溯各時期的版本，來指令算出專案有多少個檔案。
檔案數隨著時間呈現性成長！
為何要查詢專案檔案數？這跟編譯時間有很大的關係呀！
[圖解] Git Flow
過去五年做接案模式的工作，我只會使用非常簡單的Git來版本控制，偶爾才會有同事或夥伴協同合作開發。如今我踏入開發自有產品的環境，必須跟另外兩位前輩工程師合作，此時Git操作就變得更加重要！如何在同一個專案上增修，同一時間不會影響到彼此的任務，做得好就是一門藝術！
Git版本控制有非常多好用的功能，端視專案需求來使用，所以沒有一定的規則！若是同時有多人開發，2010年有個可以當作公版的Git Flow可遵循。現在我參與自有產品開發，大致上就是以上圖的模式來操作。
[圖解] 理想與實際的軟體架構
理想與實際會有非常大的差異，在軟體界更是尋常可見！可是因為軟體並非實際的物品，所以通常不易讓「外行人」了解！不過當你看到這張圖解理想與實際的軟體架構，就能大概知道開發一個軟體將有哪些狀況會發生。
此圖取自IT狗的俄羅斯方塊，很高興這張圖寫實地描繪出我所經歷過的狀況ＸＤ～
軟體界所謂的規格(Specs)，以我過去的經驗來看，大致只有在初期開發時管用，新的技術、新的需求、新的人事物⋯⋯都會影響啊～
我常笑說，我寧願從無開始打造，也不想要去維護他人遺留下來的「毒（技術債）」。
逍遙文工作室 
HappyMan・迴響