: : 推 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