Just My Life & My Work

Posts tagged ‘project’

[Git] Branch and Merge (分支與合併)

最近要一口氣地將所有產品做完支援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要同一人才是!因為每個人的邏輯思考不同,若分為三個人接續製作,最後成果極度可能四不像,那可是會大大增加開發成本!

(繼續閱讀…)

標籤雲

%d 位部落客按了讚: