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

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