请问如何说服工作 5、6 年的同事不要把两三千行的逻辑写在一个类里？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3176 天前的主题，其中的信息可能已经有所发展或是发生改变。

我毕业快一年了。和另外一个搭档同事都是最近刚入职的新人。之前偶尔代码 Review 的时候发现他很喜欢把逻辑都写在同一个类里，不过注释用中文写得很详尽，所以还是能读的，但我觉得这样不太好，而且以后我们两个可以说是互为相依为命的角色，所以一直想找个机会告诉他。所以趁着这个一个新的模块开始的时候，对模块的整体结构提了一些建议，整个模块可能两三千行代码的规模，建议划分成 4~5 个类来实现，他也同意这样划分在逻辑上是很清晰的，但觉得这样太细了，可能有些过度设计了。他最后坚持要写在一个类里，觉得代码分散在四五个文件里面可以维护，集中在一个文件里面也是可以维护的。我听到这样的想法突然觉得无力反驳，于是作罢了。另外，我们的项目有充裕时间。

事后我也有反省自己，我是不是控制欲太强，太喜欢指手画脚了呢？虽然我心里确实有倾向，也有答案。但还是想来听听前辈们怎么说。

第 1 条附言 · 2016-04-21 08:44:20 +08:00

看来这个问题的确是有争议的。补充一些信息如下：
代码是 C#，模块是作为一个或多个组件附加到场景中的节点上的。
代码拆分后的职能是清晰的而且达成共识了的，我们只是在纠结有没有必要分得这么细。
这个模块对外的主要接口是外部传入入一组比较的复杂的 Model ，然后根据这个 Model 去控制各个 UI 组件的交互和更新，另外我们的分歧也就是指是由一个类来控制所有 UI 组件，还是分解成主从类来控制。

第 2 条附言 · 2016-04-21 10:59:41 +08:00

如果都在一个类里面，随着逻辑的复杂、成员变量的增加，阅读代码的复杂度会呈指数级上升吧？这是否会给后期的维护带来困难呢。还是说通过控制代码质量来防止成员变量的泛滥，或者说使用一种类似于面向过程的思路来防止这种情况的发生。
不过看到各位前辈回答时谨慎的态度，也可以看到这个问题还是值得考量的，我开始还以为这种拆分应该是一种常识呢。看来还是 Native 啊。

代码

模块

逻辑

觉得

27 条回复 • 2016-04-22 09:31:57 +08:00

ShengjiaWANG

2016-04-21 02:22:36 +08:00

不管怎么说，两三千行也实在太多了...

dapang1221

2016-04-21 02:30:24 +08:00 via Android

能把逻辑实现出来而且有注释就行了……个人习惯不同。。
主要是我觉得吧，把一些肯定不会复用的代码重新写进个类里，以及把一个比较连贯的逻辑拆得到处都是代码，这样有时也真挺烦人的……

binux

2016-04-21 02:31:39 +08:00

两三千行不是一个函数的话，还好。
取决于类分开之后，新增一个函数，你们能不能不经过讨论，就函数放到哪个类里面达成共识。
如果不能的话，拆分其实是失败的。

ipconfiger

2016-04-21 02:48:57 +08:00

关键是这个巨型类的功能是否也是一个瑞士军刀一样的大杂烩啊?

hbkdsm

2016-04-21 07:56:01 +08:00 via Android

Rails 里面一个 model 两三千行很常见

qingchengdev

2016-04-21 08:44:49 +08:00

@ShengjiaWANG
@dapang1221
@binux
@ipconfiger
@hbkdsm
谢谢你们的回复，已 Append 更详细的信息。

bk201

2016-04-21 09:24:37 +08:00

看你的 append 我个人觉得这种情况确实拆开好，主要考虑到耦合度。

riverphoenix

2016-04-21 09:28:10 +08:00

我现在超过三百就觉得看不下去了

lincanbin

2016-04-21 09:32:58 +08:00

有 IDE 的快速查找的话其实问题不大。
只要每个方法的行数不要太多就好了。

LINAICAI

2016-04-21 09:36:50 +08:00

传说中的 c 程序员？面向函数编程。。。

LINAICAI

2016-04-21 09:38:25 +08:00

两三千行都写在一个类，如果业务逻辑不能再细分了的话，勉强能接受吧。
但这情况也是很极端的吧

Actrace

2016-04-21 09:42:12 +08:00

要根据程序模块划分！
要根据程序模块划分！
要根据程序模块划分！
重要的事情说 3 次。

anerevol

2016-04-21 09:44:11 +08:00 via Android

感觉拆不拆都行，毕竟功能职责单一。如果有些代码能抽成可以公用的代码的话，是可以分一分的。

22too

2016-04-21 09:44:50 +08:00

只要不是 python 程序就行。（逃

SpicyCat

2016-04-21 09:49:02 +08:00

单个类还好吧，一般编程规约都是规定单个函数不能太长。

yhxx

2016-04-21 09:50:48 +08:00

前几天听说某宝前端要求一个 js 文件不能超过 130 行

dong3580

2016-04-21 09:51:33 +08:00

单个类倒是没问题吧，看是不是在一个方法里；
如果项目比较大，到可以根据业务，或者逻辑划分，

qingchengdev

2016-04-21 10:57:11 +08:00

@lincanbin
@anerevol
@SpicyCat
@dong3580
如果都在一个类里面，随着逻辑的复杂、成员变量的增加，阅读代码的复杂度会呈指数级上升吧？这是否会给后期的维护带来困难呢。还是说通过控制代码质量来防止成员变量的泛滥，或者说使用一种类似于面向过程的思路来防止这种情况的发生。