Just My Life & My Work

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)

為了避免上架時把開發的東西誤上傳,那麼一開始最好就定義好DebugRelease,其實Debug和Release在Xcode中已有定義,包版本釋出預設就是Release,而開發的時候透過Xcode編譯到手機,預設則是Debug,不過其實可以改成Release來測試,如此方便!

透過Xcode可以讓專案自定義變數 (Project User Defined Variable),這樣一來就算忘了有什麼是測試還是正式,都不用擔心會上錯啦~

(繼續閱讀…)

[iOS] 視覺化專案相依關係 (Dependency Visualizer)

去年11月底,剛熟悉公司專案,想知道整個專案的至今的狀況如何,其中一個方式就是了解程式碼相依程度,我找到一個相當不錯的視覺化專案相依關係的工具,會透過網頁以互動的方式呈現。

我在GitHub上找個開源專案,透過模擬器編譯成功後,成功開啟網頁來玩泡泡~

從main開始進入AppDelegate。

(繼續閱讀…)

[iOS] 專案檔案數遞增

本週輪到我第二次「文字探討」,這一次我分享進階除錯技巧,關於XcodeLLDB。首先我表明為何需要學習進階除錯技巧,因為我們公司開發產品,歷時一年五個月專案檔案數遞增有目共睹,我特別透過Git回溯各時期的版本,來指令算出專案有多少個檔案。

檔案數隨著時間呈現性成長!

為何要查詢專案檔案數?這跟編譯時間有很大的關係呀!

(繼續閱讀…)

[圖解] Git Flow

過去五年做接案模式的工作,我只會使用非常簡單的Git來版本控制,偶爾才會有同事或夥伴協同合作開發。如今我踏入開發自有產品的環境,必須跟另外兩位前輩工程師合作,此時Git操作就變得更加重要!如何在同一個專案上增修,同一時間不會影響到彼此的任務,做得好就是一門藝術!

Git版本控制有非常多好用的功能,端視專案需求來使用,所以沒有一定的規則!若是同時有多人開發,2010年有個可以當作公版的Git Flow可遵循。現在我參與自有產品開發,大致上就是以上圖的模式來操作。

(繼續閱讀…)

[圖解] 理想與實際的軟體架構

理想與實際會有非常大的差異,在軟體界更是尋常可見!可是因為軟體並非實際的物品,所以通常不易讓「外行人」了解!不過當你看到這張圖解理想與實際的軟體架構,就能大概知道開發一個軟體將有哪些狀況會發生。

此圖取自IT狗的俄羅斯方塊,很高興這張圖寫實地描繪出我所經歷過的狀況XD~

軟體界所謂的規格(Specs),以我過去的經驗來看,大致只有在初期開發時管用,新的技術、新的需求、新的人事物⋯⋯都會影響啊~

我常笑說,我寧願從無開始打造,也不想要去維護他人遺留下來的「毒(技術債)」。

(繼續閱讀…)

糟糕的API製作

一年前也就是2017/1/27的紀錄,我經手一個幼稚園案子,我以為只要負責開發App的部分即可,所以報價非常的親民,因為對方是我非常好的老闆朋友。不過最後證實,這個案子讓我公司虧錢,時間成本多出3倍,為了斬斷所有牽絆,在卡卡頓頓開發一年後,宣布不再接手維護。

以下就描述我身為軟體架構師觀察到的問題:

API開發

此案不明原因分成三個人⋯⋯

  • A創造規格人(實作原型)
  • B建立架構人(實作雛形)
  • C開發實作人(實作成品)

幼稚園案子.gif

照理說,ABC要同一人才是!因為每個人的邏輯思考不同,若分為三個人接續製作,最後成果極度可能四不像,那可是會大大增加開發成本!

(繼續閱讀…)

[iOS][watchOS] Watch App三個ID設定

三年前(2015年)幫公司製作比特幣查詢用的Watch App,已有開發經驗遇過一些坑,照理說能馬上迎刃而解才是,不過大腦卻沒能及時反應,只好上網打關鍵字求解!

watch apps

問題:

error: WatchKit Extension doesn’t contain any WatchKit apps whose bundle identifiers match “com.happy.watch.watchkit". Verify that the value of WKAppBundleIdentifier in your WatchKit Extension’s Info.plist matches the value of CFBundleIdentifier in your WatchKit App’s Info.plist.

想開發Watch App,需要申請三個ID:

  1. iOS
  2. WatchKit App
  3. WatchKit Extension

這三個ID逐一依賴,怎麼說?3依賴2,2依賴1,缺一不可哪~

(繼續閱讀…)

標籤雲