请教一个关于多人开发中代码规范和风格统一的问题

[niuhejun]

现有一个物流公司信息表

开发人员A，根据需求写了一个获取支持上门提货的物流公司列表的方法Function1；
开发人员B，根据需求写了一个根据关键字模糊匹配支持上门提货的物流公司方法Function2（string userinput）；

其实这两个方法完全可以利用重载携程function1();function1(string userinput);

还有的时候A写了一个获取支持上门提货的物流公司名单（只包含物流公司名称）F1；
同时B又写了一个获取持之上门提货的物流公司名单（包含物流公司名字和地址）F2；

这两方法其实也出现了冗余；

最后导致整个业务逻辑混乱，毫无头绪。有些需求的方法没有，或者不全，有些又各种冗余。我们现在的开发模式
是，每个人负责一个功能模块，从数据交互到业务逻辑都是一个人来做。人一多，后果就是业务逻辑太混乱了


求各位给出个主意。个人考虑过用接口提前定义好各种方法，直接继承来实现。但问题是，又不可能考虑全面。

[MicrosoftCenterOfHN]

正如你提到的，不可能在一开始设计的时候就把所有的问题考虑全面。 所以，一开始的时候我们只能尽可能的去做一个好的设计。然后在开发的过程中去不断的微调，重构（Refactoring)。你们可以在做Code Review的时候发现你所提到的问题，然后去重构，实现重用，避免冗余。 有一本专门讲重构的书，很不错，你可以去看一下。

[wangnaisheng]

开始的时候做好详细设计还是能避免一些问题的，当然也不能什么都想到是吧。后期也可以改进。

[以专业开发人员为伍]

我不想直接回答你的这个问题，因为你这种情况不是一两年造成的，改变它也需要一些长期积累的东西的支持。 有两个东西是与你这种情况息息相关的： 1. 典型的小作坊、学生气的开发习惯，动不动就只知道“按照需求界面进行简单的分解，然后就知道给下级人员压任务，而管理人员自己不懂设计和开发”。管理人员应该负责反复地修改设计、沟通、教育训练，即使在关键时刻重构重要的框架，管理人员也可以带头很快地（例如3天）彻底调整好。如果是小作坊，习惯于把界面“分解”一下然后就去做了，然后1、2个月之后开两三次会议一帮人才对每一个实干的人实现的结果说三道四，长此以往，你在描述问题是你就不会去分析自己的设计问题，而只会把问题推给下面开发人员，说他们怎么怎么“乱写接口”。 2. 你自己说“考虑过用接口提前定义好各种方法，但问题是，又不可能考虑全面”这也是一种借口，也是习惯造成的。谁设计接口时去保证“考虑全面”了？这说明你学的是“精通abcdefg字母表”，然后到用的时候才发现原来“只会被字母表是不会写英文作文的”，发现理论跟实践差的太远。 就你描述的那个问题，结合你（做为他们的领导）的情况，我认为function1和function2都是必要的，你不应该去管他们。如果你发现“业务逻辑混乱，毫无头绪”，请先让你自己把业务逻辑梳理清楚、理出头绪”，并且你带着他们两个人分别花1、2天时间写出设计文档并进行一次联合讨论，这样你就有威信评论人家“业务逻辑是否清楚、是否有头绪”的问题。而人家已经写的function1和function2，你应该保证2个月内不要随便给人家删除掉。 做领导的一个起码的素质就是：你要预先把“道道”给人家说清楚、并且背书。如果你没有先帮人家弄清楚，人家做错了，你应该认为是自己的错误，而不是人家的错误。

[以专业开发人员为伍]

另外，不要把自身设计和领导上的“大”问题，扣帽子说成是开发人员的“代码规范、缺少洁癖”问题。如果你带领的好，就算是你让他们各自发挥，一个团队不出3个月也会写出整齐漂亮、结构分明（并且高明）的程序。否则，可能做不出什么稍微高明一点的设计，反而各自内斗，整天纠结什么“编码规范”这种东西，可争来争去地都不是在争论什么能够让大家都明白和服气的重要问题，都是一些鸡毛蒜皮的、看似只是个别不太懂开发的人树立“权威”而“压任务给别人”的那种问题。

[泡泡龙]

楼上 +1

[jimil]

不客气地说，你问的问题20分，你不觉得少了点吗？乘以10都嫌少啊，哥们，你要知道你问的是一个组建团队必需要做的工作，甚至于超过项目经理和技术经理的范围问题，哎。 以前接触过一个阿三的开发人员，感触挺大，虽然灵活性不如我们，但这方面他们做的是比我们中国做得要好，我从他身上学到很多。

[smthgdin_020]

在底层模块和高级模块之间，可以加个门面，高层模块调用底层模块都通过这个门面。 这样的好处就是：1.调用的方法集中显示，以后重构方便，合并，重载等等都可以很方便实现；2.调用方法集中显示，对于不同调用者来说，可以在一个统一的地方查找是否有需要的方法，有则直接使用，没有则添加。

[smthgdin_020]

代码规范是需要的，但是有时也要适当照顾编程习惯，大体上结构清晰，风格接近就一般可以了。 另外设计尽可能要做细，做周全，这样以后开发会减少很多反复，重来，项目管理上可控性更高，风险更低。

[bwangel]

对于团队Leader,自己要把把握全局，掌握项目整体框架。 根据软件工程的规范，把每个基层开发人员对整个项目的影响仅限于他自己的一亩三分地。

[smthgdin_020]

其实一定的风格统一和代码规范是需要的。但是很多公司往往忽视这个，造成一个部门都多个风格，甚至1个项目组有2,3个风格。 风格统一和代码规范，不同人写出来的程序可读性基本一致或者接近，这样对于新人做过1个模块后，在接触别人代码，别的系统代码的时候，无论开发还是维护都会更快上手，精力更多放在其他方面。好的代码规范，编程习惯也可以减少bug的产生，减少开发人员和测试人员的的时间成本。好的代码规范，可以提高程序性能。

[MikeCheers]

其实 我觉得这个问题很好 阿三的代码规范 值得我们借鉴 民间传说 阿三的代码都跟一个模子刻出来似的 大家都循规蹈矩的 呵呵 个人不评价好与不好(又会被喷) 有机会 你可以参考一下小日本的详细设计文档(当然 也有不好的 看你运气) 会惊讶的 设计之初 除了没实现方法 基本都有了 综合考量 取其精华 去其糟粕 当然 我主要想说的是 这些问题 应该尽量在设计之初去解决 去决策 这个真不是一朝一夕可以做到的 需要大量的实战经验积累 空想都是白扯 这是一方面 另一方面 在没有达到很多经验的时候 就需要借鉴 多学习别的项目经理 架构师的经验 多交流 少走弯路 不要担心会出现这样的问题 定期去重构 整合代码 优化架构 这些都是非常有效的 更重要的是 在这个过程中 能够积累很多的经验 要把每一次重构经历都铭记于心 累积经验 懂得如何提升的人 最后就成为了大牛 有些人 也是经常重构 重构完了 就完了 甚至是被迫重构 只是当作任务去完成 最后 还是小弟 再有 就是 如果你是项目经理 架构师 或者Team Leader 要懂得分享与灌输 中国人比较小气 总担心自己的东西 分享出去 就被别人拿走了 其实 不然 分享得多了 团队提升了 收获是副产品 随之而来的 无法拒绝的 灌输也很重要 你要让你的Team理解你的思路 明白你的意图 这样 你会发现 重构的工作会慢慢减轻 何乐而不为呢 你是希望整天埋头重构代码呢 还是沏上一杯茶 洞察一下行业发展呢 都希望是后者吧 啰嗦得有点多 献给那些将要或已经成为项目经理的同学们

[niuhejun]

引用 6 楼 jimil 的回复:

不客气地说，你问的问题20分，你不觉得少了点吗？乘以10都嫌少啊，哥们，你要知道你问的是一个组建团队必需要做的工作，甚至于超过项目经理和技术经理的范围问题，哎。 以前接触过一个阿三的开发人员，感触挺大，虽然灵活性不如我们，但这方面他们做的是比我们中国做得要好，我从他身上学到很多。

大哥，只有30分啊

[niuhejun]

引用 4 楼 sp1234 的回复:

另外，不要把自身设计和领导上的“大”问题，扣帽子说成是开发人员的“代码规范、缺少洁癖”问题。如果你带领的好，就算是你让他们各自发挥，一个团队不出3个月也会写出整齐漂亮、结构分明（并且高明）的程序。否则，可能做不出什么稍微高明一点的设计，反而各自内斗，整天纠结什么“编码规范”这种东西，可争来争去地都不是在争论什么能够让大家都明白和服气的重要问题，都是一些鸡毛蒜皮的、看似只是个别不太懂开发的人树立“权威”而“压任务给别人”的那种问题。

不胜感激，谢谢指点。

[niuhejun]

引用 11 楼 mikecheers 的回复:

其实 我觉得这个问题很好 阿三的代码规范 值得我们借鉴 民间传说 阿三的代码都跟一个模子刻出来似的 大家都循规蹈矩的 呵呵 个人不评价好与不好(又会被喷) 有机会 你可以参考一下小日本的详细设计文档(当然 也有不好的 看你运气) 会惊讶的 设计之初 除了没实现方法 基本都有了 综合考量 取其精华 去其糟粕 当然 我主要想说的是 这些问题 应该尽量在设计之初去解决 去决策 这个真不是一朝一夕可以做到的 需要大量的实战经验积累 空想都是白扯 这是一方面 另一方面 在没有达到很多经验的时候 就需要借鉴 多学习别的项目经理 架构师的经验 多交流 少走弯路 不要担心会出现这样的问题 定期去重构 整合代码 优化架构 这些都是非常有效的 更重要的是 在这个过程中 能够积累很多的经验 要把每一次重构经历都铭记于心 累积经验 懂得如何提升的人 最后就成为了大牛 有些人 也是经常重构 重构完了 就完了 甚至是被迫重构 只是当作任务去完成 最后 还是小弟 再有 就是 如果你是项目经理 架构师 或者Team Leader 要懂得分享与灌输 中国人比较小气 总担心自己的东西 分享出去 就被别人拿走了 其实 不然 分享得多了 团队提升了 收获是副产品 随之而来的 无法拒绝的 灌输也很重要 你要让你的Team理解你的思路 明白你的意图 这样 你会发现 重构的工作会慢慢减轻 何乐而不为呢 你是希望整天埋头重构代码呢 还是沏上一杯茶 洞察一下行业发展呢 都希望是后者吧 啰嗦得有点多 献给那些将要或已经成为项目经理的同学们

谢谢

[害羞的大叔]

引用 3 楼 sp1234 的回复:

我不想直接回答你的这个问题，因为你这种情况不是一两年造成的，改变它也需要一些长期积累的东西的支持。 有两个东西是与你这种情况息息相关的： 1. 典型的小作坊、学生气的开发习惯，动不动就只知道“按照需求界面进行简单的分解，然后就知道给下级人员压任务，而管理人员自己不懂设计和开发”。管理人员应该负责反复地修改设计、沟通、教育训练，即使在关键时刻重构重要的框架，管理人员也可以带头很快地（例如3天）彻底调整好。如果是小作坊，习惯于把界面“分解”一下然后就去做了，然后1、2个月之后开两三次会议一帮人才对每一个实干的人实现的结果说三道四，长此以往，你在描述问题是你就不会去分析自己的设计问题，而只会把问题推给下面开发人员，说他们怎么怎么“乱写接口”。 2. 你自己说“考虑过用接口提前定义好各种方法，但问题是，又不可能考虑全面”这也是一种借口，也是习惯造成的。谁设计接口时去保证“考虑全面”了？这说明你学的是“精通abcdefg字母表”，然后到用的时候才发现原来“只会被字母表是不会写英文作文的”，发现理论跟实践差的太远。 就你描述的那个问题，结合你（做为他们的领导）的情况，我认为function1和function2都是必要的，你不应该去管他们。如果你发现“业务逻辑混乱，毫无头绪”，请先让你自己把业务逻辑梳理清楚、理出头绪”，并且你带着他们两个人分别花1、2天时间写出设计文档并进行一次联合讨论，这样你就有威信评论人家“业务逻辑是否清楚、是否有头绪”的问题。而人家已经写的function1和function2，你应该保证2个月内不要随便给人家删除掉。 做领导的一个起码的素质就是：你要预先把“道道”给人家说清楚、并且背书。如果你没有先帮人家弄清楚，人家做错了，你应该认为是自己的错误，而不是人家的错误。

[exception92]

个人考虑过用接口提前定义好各种方法 这样想不是很对，因为你不知道要面临要写什么样的方法？根据怎么样的业务传什么样的参数？这些都是未知的，个人感觉 还是在开发过程中多沟通，至于提交的代码或者方法，函数之类的，对于其它成员要有提示，一旦有了提示，可以其它人也需要这个方法，经过商讨，会有个比较完美的接口或者方法供双方调用。

[showjim]

业务逻辑函数能有多复杂？能有几行代码？这种鸡毛蒜皮的小事不值得关注。 否则就是架构设计与支撑类库设计的问题了。