自我剖析

今天发生了一件事,和同事对某个功能的封装发生了一场小争论,他认为应该把这个功能封装成两个方法,以下是他的观点:

代码一旦出现岔路型变量,证明封装有问题(如这个里的 is_group_by);

对于使用者,这样的封装并没有透明化 “是否用 group by 逻辑” 对于之后的维护者,这类的方法势必两个分支会有不共用的逻辑,最终会导致一个大方法出现;

从两个角度考虑方便与否,一个是使用者,对于用参数还是用两个方法,使用者都需要知晓,使用者成本一样。对于可读性,多一个分岔路标变量会影响代码可读性,对于可维护性而言,分岔逻辑势必意味着大函数的出现;

  1. 永远不要断言未来,变的时候会去考虑改吗,这是一个明日复明日的问题,终有一个明日改不动了;
  2. is_group_by 可读性就好了吗.
而我的观点很简单:
  1. 不想新增新方法;
  2. 其它已经使用的地方不需要有改动.
在这记录一下我内心的想法:
  • 其实我是很赞同他的观点的,因为我内心是明白什么是好的设计,什么是差的设计。
  • 开始我也是那样想的,但由于要改动的地方太多,太麻烦,所以选择了简单的方式。
  • 以下这个想法不排除有推卸责任的嫌疑:你不能既让我在短时间里去实现业务逻辑,还要求一个很高的设计(搞什么,我现在写这篇稿子的时候,也开始觉得有推卸责任的嫌疑了)。
由今天的事引申
  • 不要在意别人在你背后说的话, 是真的不在意。

  • 除了上一条外,好的建议就要听。

Published by

发表评论

电子邮件地址不会被公开。 必填项已用*标注