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