谁有代码的修改权？代码开发者？整个团队？
2009-03-02 16:32 Yuanyi Wang 阅读(2272) 评论(14) 编辑 收藏 举报
谁有代码的修改权？代码开发者？整个团队？
首先对程序员做一个调查：你是否允许团队其他成员修改你的代码？
大概大多数人会回答：不想（允许）。
原因：
1. 如果他们修改错了，算谁的？
2. 他们修改我的代码可能会违反我的最初意图。
但是我想，代码不应该属于你个人的，应该属于你的团队，所以你的代码应该可以被其他人更改。
原因：
1. 如果客户在验收阶段发现错误，无论这个错误是谁写的，这个错误都属于开发这段代码的团队；
2. 如果其他人修改你的代码而违反你的最初意图，那就说明整个团队并没有对技术框架、业务流程和实现方法达成一致，所以其他人修改代码时才会和最初的意图不一致。
再做一个调查：
如果你在开发，或修改错误的过程中，你发现一个错误，这个错误在其他人开发的代码中也可能存在，你会怎么办？
A. 就修改我自己的
B. 修改完我自己的后，向team leader说明（发送邮件）
C. 主动检查所有相关代码，向team leader说明，团队商讨解决方案后按方案执行
D. 主动检查所有相关代码，如果问题简单，直接修改；如果问题复杂，向team leader说明，团队商讨解决方案后按方案执行
我想有很多人会选C或D（我想选D的人会比较少）。我觉得选C是没有问题的，至少我们表面上可以解决问题，但是，我们如何跟踪结果呢？team leader/QC挨个人的查？当然你可能会说，我不知道别人的代码是怎么写的，所以我修改的成本会更大！我想这样的原因还是整个团队对业务框架、技术框架和实现方法是否达成一致。
所以说，这个问题就变成了我们是否确定整个团队对业务框架、技术框架和实现方法是否达成一致？
在项目团队中这些信息的共享是十分重要的，团队成员必须在同一个工作平台下。以前公司的经理整天挂在嘴边的一句就是：please double confirm your partners are on the same page with you.
当前的软件开发已经远离了英雄时代，一个人已经不可能完成大型项目的开发，团队就是“一损俱损”，但绝不是“一荣共荣”，团队绝对符合短板效应。当然这个道理大家都懂，但是我们更应该在实际行动中有所表现。
达成一致的好处：
1. 一个好用，其他流程基本也能好用（至少大框是好用的，结构性错误可以减少），当然，一个错误，其他也会错误；
2. 如果团队内对某些抽象业务流程的实现方法达成一致，那么其他人可以使用一致的算法、结构完成类似的业务逻辑；
3. 团队内可以互相修改代码；
不能达成一致的后果：
1. 模块间相似业务的实现方法不一致，重复开发、人员不能互相调换、每个模块的共同功能都要重复检查；
2. 代码review时需要预先熟悉
不能达成一致的原因：
1. 没有对业务员做一致的抽象设计；团队内不同模块间即使类似的业务逻辑，处理方式也不一样，团队内的代码当然不能互相修改；
2. 沟通不畅，模块内发现的错误（或变更）并没有在全系统内检查，而是各自修改，久而久之，不同模块的实现方式就不一致了；
达成一致的方法：
对于小项目，这不是一个困难的事情，口头说一下一般就没有多大的问题。
对于大项目，人多事也多的项目，必须建立一套可行的信息发布机制。
我认为最好能有一个统一的信息发布平台，在更改已有信息或添加信息时，可以自动向相关人员发送电子邮件。当然前提是每个人都必须阅读每一封邮件，并需要在团队日会上再次强调。
对于经常忘记读邮件的团队，那就用纸质的信息发布单，看完签字（比较变态，但却是见过）。
强烈不建议使用Word或Excel记录bug信息等需要每个成员都修改的、经常变动的信息，因为这些信息如果没有被及时记录，后补是非常困难的。
实际上，我们的代码一致是团队共享，比如有人离开团队，或在某人休假时发现其代码有重大问题，这时团队中的其他成员必须可以更改其他人的代码。所以莫不如我们一开始就努力的向团队共享代码的目标努力。开发人员也不用担心别人会改坏你的代码，21世纪的代码管理工具都可以记录每一行代码是谁创建的（source safe是20世纪的产品），想找出改坏代码的人还是很容易的。
当你发现一段不好的代码，或感觉其他人代码中，也可能存在类似的错误或变更，请你花费几分钟，检查一下整个团队的代码（如果你有能力且团队中有代码共享的习惯，请你修改他们），你将提高整个团队的客户满意度。
首先对程序员做一个调查：你是否允许团队其他成员修改你的代码？
大概大多数人会回答：不想（允许）。
原因：
1. 如果他们修改错了，算谁的？
2. 他们修改我的代码可能会违反我的最初意图。
但是我想，代码不应该属于你个人的，应该属于你的团队，所以你的代码应该可以被其他人更改。
原因：
1. 如果客户在验收阶段发现错误，无论这个错误是谁写的，这个错误都属于开发这段代码的团队；
2. 如果其他人修改你的代码而违反你的最初意图，那就说明整个团队并没有对技术框架、业务流程和实现方法达成一致，所以其他人修改代码时才会和最初的意图不一致。
再做一个调查：
如果你在开发，或修改错误的过程中，你发现一个错误，这个错误在其他人开发的代码中也可能存在，你会怎么办？
A. 就修改我自己的
B. 修改完我自己的后，向team leader说明（发送邮件）
C. 主动检查所有相关代码，向team leader说明，团队商讨解决方案后按方案执行
D. 主动检查所有相关代码，如果问题简单，直接修改；如果问题复杂，向team leader说明，团队商讨解决方案后按方案执行
我想有很多人会选C或D（我想选D的人会比较少）。我觉得选C是没有问题的，至少我们表面上可以解决问题，但是，我们如何跟踪结果呢？team leader/QC挨个人的查？当然你可能会说，我不知道别人的代码是怎么写的，所以我修改的成本会更大！我想这样的原因还是整个团队对业务框架、技术框架和实现方法是否达成一致。
所以说，这个问题就变成了我们是否确定整个团队对业务框架、技术框架和实现方法是否达成一致？
在项目团队中这些信息的共享是十分重要的，团队成员必须在同一个工作平台下。以前公司的经理整天挂在嘴边的一句就是：please double confirm your partners are on the same page with you.
当前的软件开发已经远离了英雄时代，一个人已经不可能完成大型项目的开发，团队就是“一损俱损”，但绝不是“一荣共荣”，团队绝对符合短板效应。当然这个道理大家都懂，但是我们更应该在实际行动中有所表现。
达成一致的好处：
1. 一个好用，其他流程基本也能好用（至少大框是好用的，结构性错误可以减少），当然，一个错误，其他也会错误；
2. 如果团队内对某些抽象业务流程的实现方法达成一致，那么其他人可以使用一致的算法、结构完成类似的业务逻辑；
3. 团队内可以互相修改代码；
不能达成一致的后果：
1. 模块间相似业务的实现方法不一致，重复开发、人员不能互相调换、每个模块的共同功能都要重复检查；
2. 代码review时需要预先熟悉
不能达成一致的原因：
1. 没有对业务员做一致的抽象设计；团队内不同模块间即使类似的业务逻辑，处理方式也不一样，团队内的代码当然不能互相修改；
2. 沟通不畅，模块内发现的错误（或变更）并没有在全系统内检查，而是各自修改，久而久之，不同模块的实现方式就不一致了；
达成一致的方法：
对于小项目，这不是一个困难的事情，口头说一下一般就没有多大的问题。
对于大项目，人多事也多的项目，必须建立一套可行的信息发布机制。
我认为最好能有一个统一的信息发布平台，在更改已有信息或添加信息时，可以自动向相关人员发送电子邮件。当然前提是每个人都必须阅读每一封邮件，并需要在团队日会上再次强调。
对于经常忘记读邮件的团队，那就用纸质的信息发布单，看完签字（比较变态，但却是见过）。
强烈不建议使用Word或Excel记录bug信息等需要每个成员都修改的、经常变动的信息，因为这些信息如果没有被及时记录，后补是非常困难的。
实际上，我们的代码一致是团队共享，比如有人离开团队，或在某人休假时发现其代码有重大问题，这时团队中的其他成员必须可以更改其他人的代码。所以莫不如我们一开始就努力的向团队共享代码的目标努力。开发人员也不用担心别人会改坏你的代码，21世纪的代码管理工具都可以记录每一行代码是谁创建的（source safe是20世纪的产品），想找出改坏代码的人还是很容易的。
当你发现一段不好的代码，或感觉其他人代码中，也可能存在类似的错误或变更，请你花费几分钟，检查一下整个团队的代码（如果你有能力且团队中有代码共享的习惯，请你修改他们），你将提高整个团队的客户满意度。
