※ 引述《qrtt1 (null)》之銘言： : : ========================================================= : : 前幾天有人提到做國科會 open source 計劃的, 應該被要求必須使用這種 : : 工具來訓練參與者加強團隊合作的訓練. : 使用版本控制最基本的效果就是： : 即使只有一個開發者也不會在多次修改的版本裡迷路。 : 特別是有多個工作地點和佈署環境的情況。 : 舉個例子來說， : 您可能會在某次 demo 前，把程式佈署到某台機器 : 但發現一個小 bug 順手修了一下。 : 若沒有版本控制，您需要再把檔案複製回去，或記錄應修改的部分。 : 像我如此腦袋不靈光的開發者，肯定會忘都忘結果遺漏了修改。 : 在沒有版本控制的情況下，多人多次修改會使得開發更加痛苦。 : 這個例子說明，在尚未學習較進階的版本控制技巧之前， : 您就會得到避免遺失重要修改，或覆蓋重要內容的優勢。 : 版本控制工具提供還能給我們什麼？ : 撇開使用技術的層次不談，透過每日 diff 的 review : 可以控制整個 team 產生 code 的品質。 謝謝您的回應. 問題是 version control 的軟體應該不少, 要推廣是否該指明 某種 open source program 來使用. 為了品質或是減少不必要 的麻煩, 使用的人是否能感受到必須使用這個工具 ? : 無論在格式上，設計上，前後比較一下就知道這樣修改 : 是不是合理的，可接受的。 : 這有時是 refactor 方向錯誤或 pattern 誤用的問題， : 有時可能是寫了沒有實際作為的 test case : 配合持續性整合工具，還能定期自動測試這產出的成果 : 是否符合期待，或是系統有沒有產生奇異的行為。 : 此外，在精確地分工之下，能使用版本控制的權限控管機制 : 避免不同功能分區的開發者修改到不應該修改的程式。 : 不過前提需要是理想的 configuration management 才能達到。 如果人不多, 又分很大塊, 很多人都喜歡單幹, 又沒有一個 reviewer 存 在著協助要求時, 這時候這種工具仍然會有效嗎 ? 這類工具能不能逐漸的經由互動, 逼得寫程式者必需要做有效的分工與 授權 ? : : 看見這串討論就是覺得: 假如 L3 對 B 是很重要, B 當然要擔心, 那就要 : : 協調出他負全責去管理維護, 那就變成是要 B 同意才能改. 但 A 會去更 : : 改, 那必然就是 A 會用到, 那 A 的需求規格是甚麼 ? 會與 B 的需求規範 : : 起衝突 ? 這不外乎兩者的需求功能能分割清楚嗎 ? 如果不想協調, 想要省 : : 事各幹各的, 其一就是 A 複製一套 L3 為 AL3 , 再完全 "獨立使用(Read : : only 不能 update 共用的部份)", 也就是併行的兩條路各自分道揚鑣. 另 : : 一辦法就是合併需求找通解, 也就是建立串接項目(共用的部份)前後的分叉 : : (branch)項, 為了確保自己想要的部份不被污染干擾, 那就會建立測試項彼 : : 此讓對方代替自己檢查. 此時的 B 或 A 就只靠設計各自的 test data 來 : : 管理與確保自己部份的正確性, 也就不必凡事親管, 事必躬親的維護. : : 理想的狀況就是一群人用對了工具, 有了正確的用法(有如架構, 機制, 演算 : : 法), 就像一堆散沙病貓坐進有通信協調的坦克, 就自動變成了無堅不摧的豺 : : 狼虎豹. : : 不曉得這個 subversion tool 是不是值得國科會這樣硬推 ? 業界用得很多 : : 嗎 ? 學校該怎麼教育訓練讓學生能挑選工具也能正確使用 ? : 同一個問題有一種以上的解法通常被稱為「詭譎」 : 以 A 的觀點它有想達成的目的 : 以 B 的觀點它有想達成的目標 : 如果他們的想法是相同的，那可能只是語法上的差異。 : 如果並不相同，那麼也許考慮設計上模糊不清的部分。 : 或是不同寫法所接來的邊際效應。 : 甚至，那相牴的一行根本就是其他類別/程式的責任 以聯考的分數志願分發為例. 以選某系的同志願者為一群當開始的處理單位, 還 是以個人的所有志願為一群當開始處理的單位, 解決的步驟就會全然不同. 但最 終的錄取結果應該是相同的. 這就像需要一個 sort program, 假設有兩個人來分 工完成, 但兩人採不同的演算法但又只各做一半, 此時, 這種工具能協助找出兩 者的衝突與無法接續合作的原因嗎 ? --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.4.12