關於版本控管系統的分支(branch)與標籤(tag)的區別

版本控管系統:版本控管係為「建構管理 (configuration management)」的範疇。理論上,關於「分支 (branch)」與「標籤 (tag)」,從觀念上來看在各版控系統應是類似的,只是做法不同罷了。

Suversion vs. Git:雖然兩者常被拿來比較的是,subversion 是集中式的儲庫 (repository),而 Git 則為分散式的。但若從專案管理者的角度來看,要管理的其實只有一個:位於伺服器上的儲庫。即使如 Git 可以有一堆分散式的儲庫,但管理者真正只有管理到例如儲存在 GitHub (or private Git server)上的儲庫。至於開發者在私人的儲庫內,要如何分支與標籤是自己的事,只要最終能提交給專案管理者做合併 (merge)即可。

關於版本控管的分支與標籤說明範例
(點擊圖片鏈接看原圖)圖、關於版本控管的分支與標籤說明範例

    關於分支 (branch):

  • 原則上,任一版本管控系統只有一條主幹,例如 suversion 稱為 trunk,Git 稱為 master。
  • 每一次對開發文件的提交 (commit),可視為是一個節點 (node)。節點會持續隨開發時間推進,並期能達成所設定的里程碑 (milestone)。
  • 如果把主幹的任一節點當成是可能對外發布的釋出 (release),而這些釋出不希望與開發/維護期間的文件相互干擾,則可以另闢其它分支 (branch),可與主幹並行開發並個別維護。主幹與分支(可能多個)盡量將耦合性 (coupling)降低,讓版本釋出與開發維護得以順暢並行。
  • 分支後的開發/維護的節點,最終仍需將修改的文件回到主幹上,此時就必須做「合併 (merge)」的動作。

閱讀全文 »

從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇

如果我是某大軟體公司的主管,要應徵軟體結構性的設計人員 (偏對技術性,而非需求分析),一般的職稱是稱之為 系統設計師 (SD, System Designer),或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等,那麼,我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已,一點意義都沒有。 要背書的話,不如直接給個電腦上網,然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。

我會提供的考題,必然是針對應徵人員 "自我思考推理" 的能力驗證,答案的正確性完全不重要,重要的是你為什麼是這樣表達設計的,能否自圓其說。 具有獨立思考能力的設計師,這才是人才!

所以,我會提供一個如這樣的考題:

Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤,相對來說,一個標籤可以有一到多個書籤。 另外,標籤是不會含有子標籤 (Sub-Tag) 的。

如果我要改良 Google 書籤的設計,希望能再加上 "資料夾 (folder)" 的管理觀念,也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一),而某一個資料夾可以擁有一到多個書籤,同時資料夾也能再包含子資料夾 (Sub-folder)。

同樣類似的應用,可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。

請你利用 UML 類別圖,來表達出關於 書籤、標籤與資料夾的結構關係,並簡單說明你的設計想法。

上述的考題是一個 "需求陳述",應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述,那麼也可以再佐以範例,來解釋什麼是 書籤、標籤與資料夾的概念。

老實說,我是以為,這類的結構設計應該算是很基礎的了,事實上,答案也比想像得意外簡單。 但是,我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員,最直接給我的答案就是說: 這不就是 "複合結構 (composite structure)" 樣式的應用嗎? 不管你說什麼,反正先把設計圖畫出來再說吧。 結果呢,也真的如我所料,表達不出所以然,真的就只是在背書而已。 最大的盲點,就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起,而其實這兩個是一點關係都沒有的;甚至有些還執著在因為 標籤與書籤 的多對多關係,所以又拉出了一個所謂的 "關聯類別 (Association Class)",卻又說不所以然,越弄越複雜。 因為既然是表達想法,所以類別圖自然是表達 概念 (concept)與概念之間 的關係,而至於那個多對多的關聯類別,是在更細節性的規格設計實做階段再來討論即可,太早論及,反而模糊了要突顯的概念。

表達這類結構性的設計圖,要先找出核心的類別是什麼。 在本例中, "書籤 (bookmark)" 即為本文主體,是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連,而是各自與 書籤 建立關係,那麼,這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖:
閱讀全文 »

從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇

我使用 Google 書籤已有一年多餘的時間了,並非是為了好用,而是為了 "可攜性"。 因為我有多臺電腦,而且也常在外面透過筆電或 Vm 上網,也常切換 IE or Firefox Browser,書籤的管理,就變得是一個問題了。 而使用過眾多的書籤管理同步工具,仍是覺得相當麻煩,所以還是回歸到使用最簡單,Google 所提供的書籤管理機制,只要上網登入 Google 帳戶後,就可以存取網路上的書籤,相當便利。

先看看我的書籤是如何規劃的吧,參考下圖。

圖 . Google 書籤的管理規劃-01
(點擊圖片鏈接看原圖)圖 . Google 書籤的管理規劃-01

先瞭解一件事, Goodle 書籤的管理,是沿用 Google 平台傳統的機制,就是利用 TAG (標籤)來組織分類。 Gmail 是如此, Bookmark 也是如此。

所以,我若要 Bookmark 某個遊戲網站的書籤,TAG 大概就是標記如 "Game" 名稱之類的。 那麼當遊戲類的書籤一多的時候,又該如何管理呢? 舉個例,我光是當時玩「魔獸世界」時,保存相關的書籤就有近百個之多,所以你可以同時標記的 TAG 可以有 "Game", "魔獸世界" 兩個;而若是圍棋的書籤則可以標記 "Gmae", "圍棋" 兩個。 當標記的 TAG 越來越多時,你會發現到標籤的顯示會相當凌亂。 若你希望某個書籤雖然是標記成多個 "TAG",但又希望這些 TAG 的顯示有些關聯性,那麼,就可以如我上圖這樣的規劃一般,就是把 TAG 標記為 "Game", "Game_圍棋", "Game_魔獸世界" 這般,這樣的話在書籤的顯示上就能有循序性的列表了。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal