Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

Bad smell, Refactor, 冲突

光武说,Bad smell
杭哥说,Refactor

再次与合作者发生冲突。原因是改名。我们的程序包含了很多以数字编号的组件,君英大大开始写的 c++ 程序并没有在文件名和类名上包含编号,我写的 xslt 在文件名和模板名上大量应用编号。现在 c++ 程序交给我做了三天,我把程序重构了一遍,基类当然是按照那个尽量压缩的原则,还有 private virtual 原则,自己感觉很有条理。无数的 helper 函数。protected 其实是 private virtual 的 helper 函数,把函数都放到这个区域,然后整体提取成 helper class 就会让基类更小。比较不爽的是 protected 在提取为 helper class 之前,不能像独立的 helper 函数一样放在 anonymous namespace 里面,很难限制它的用法。言归正传啊,另外一个重构就是改名,把文件名和类名改成和 xslt 一样的风格,因为那个编号本来就属于那个类。另外,类名的单词部分也作了修改,以保持与 xslt 一致。xslt 与 c++ 必须同步,不然维护会很麻烦。这样修改之后,文件名可以方便的在文件管理器或 IDE 中找到,而类名也像 xslt 模板名一样提供了足够的名字空间,只要工程中组件数控制在 100 以内,命名和搜索就不会是很困难的事情。小小的改动是把输出文件的名字改掉了,因为我们在整个工程里只是很小一部分,不能用一个丝毫无法联想到我们的输出文件。一旦出问题,没人知道该来找我们。

冲突就是这么发生了。上次和保川师傅冲突,也是这样的原因,首先是 private virtual,其次是目录结构。问题在于,我是不是一定要这样才能顺利工作。如果看到一个不顺心的名字或者路径,我想谁都会觉得不舒服,例如 typo,这在我眼里是不可容忍的错误。另外,时刻考虑到自己的名字空间会对整个项目中其他人有利。作为一个新手,我觉得我应该坚持这样做,才能有长进,不能因为想到合作者会暂时觉得不习惯,而把改变什么东西的想法抛到脑后。合作者往往比我有经验的多,因此一方面可以容忍我,一方面可以给出更好的意见。(可是检出文件禁止我继续做下去,是比较无情的做法 :()

目前的情况是,我已经修改了文件名和类名,使用 sed 非常快,我不想再改回去了,因为不想在将来,为新的类取名字而绞尽脑汁。想必君英大大也不会费力地把它改回去。anonymouse namespace 的事情,君英大大看来十分反对 helper 函数采用这种方式,而想放回去继续作为 protected。我想既然这样是书上推荐的做法,那么一定不会错。具体的理由我得到书里去抄,反正时刻记住老师的独立演化,再加上逻辑清楚就可以了。有一点可以确定的,anonymous namespace 作用域就是当前源文件,因此不能用在 .h 头文件里面,因此 inline 没有意义。。。。绝对不是变成了 global symbol.

有点问题就是 helper 函数会让维护者学习一阵子。例如几个 private virtual 其实是两个层次,其中一个层次只有一个函数,调用了第二层次的所有函数。在过去的 Direct 1.0 中这种结构导致了非常大的混淆,因为没人会关心基类中,第二层次的默认实现究竟有什么效果。因此,Direct 1.0 中大部分的派生类都是直接对第一层次重载。这样其实是允许的,但是他们同时对第二层次也进行了重载,或者说很不幸的为自己的实现取了与第二层次完全相同的名字,混淆就在这里了。不应提供两个层次的重载? 但是如果不那样做,默认动作的实现就会比较麻烦。采用两层的继承可以很好的解决这个问题,其中一个无法再继承第一层次,然后推荐大家使用这个版本。但是,又有多少人会为了这种维护的好处而冒着“类层次过多”的指责呢? 回到这个工程,我想这个问题不会很严重,即使规模上升到 100 的时候,因为每个派生类的处理内容都非常少,而基类的作用不是一个容器,基类的处理非常重要。后续的维护者一定会去研究基类的每一步的效果。

我是不是太喜欢从技术上的争论/问答中学东西了呢

zonzi 说的对,我是死读书的,并且很顽固。我觉得他很讨厌,因为他吵架时候总是转移话题。他会讨厌我的逻辑,这也是我在 linuxsir 说他不喜欢和我吵架的原因。我为我死读书而自豪啊!

update:
比较严重的问题,是我为什么总是在中途加入项目,而不是从开始就独立做些什么呢,像杭哥儿一样?
君英大大提了个很严重的问题,什么时候重构才会停止? 不过既然他看过了 refactor,那么自然该知道,bad smell 在维护过程中总是会慢慢的,散发出来。
Tags: 软件工程
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments