还剩2页未读,继续阅读
文本内容:
谁有代码的修改权代码开发者整个团队管理资料首先对程序员做一个调查你是否允许团队其他成员修改你的代码?大概大多数人会回答不想(允许),原因
1.如果他们修改错了,算谁的?
2.他们修改我的代码可能会违反我的最初意图但是我想,代码不应该属于你个人的,应该属于你的团队,所以你的代码应该可以被其他人更改原因
1.如果客户在验收阶段发现错误,无论这个错误是谁写的,这个错误都属于开发这段代码的团队;
2.如果其他人修改你的代码而违反你的最初意图,那就说明整个团队并没有对技术框架、业务流程和实现方法达成一致,所以其他人修改代码时才会和最初的意图不一致再做一个调查如果你在开发,或修改错误的过程中,你发现一个错误,这个错误在其他人开发的代码中也可能存在,你会怎么办?A.就修改我自己的B.修改完我自己的后,向team leader说明(发送邮件)C.主动检查所有相关代码,向team leader说明,团队商讨解决方案后按方案执行D.主动检查所有相关代码,如果问题简单,直接修改;如果问题复杂,向team leader说明,团队商讨解决方案后按方案执行我想有很多人会选C或D(我想选D的人会比较少)我觉得选C是没有问题的,至少我们表面上可以解决问题,但是,我们如何跟踪结果呢?team leader/QC挨个人的查?当然你可能会说,我不知道别人的代码是怎么写的,所以我修改的成本会更大!我想这样的原因还是整个团队对业务框架、技术框架和实现方法是否达成一致所以说,这个问题就变成了我们是否确定整个团队对业务框架、技术框架和实现方法是否达成一致?在项目团队中这些信息的共享是十分重要的,团队成员必须在同一个工作平台下以前公司的经理整天挂在嘴边的一句就是please doubleconfirm yourpartners areon thesame pagewith you.达成一致的好处
1.一个好用,其他流程基本也能好用(至少大框是好用的,结构性错误可以减少),当然,一个错误,其他也会错误;
2.如果团队内对某些抽象业务流程的实现方法达成一致,那么其他人可以使用一致的算法、结构完成类似的业务逻辑;
3.团队内可以互相修改代码;不能达成一致的后果
1.模块间相似业务的实现方法不一致...。