scribble

Xujiajun Blog

About Blog Email GitHub

17 May 2014
hammers and nails

part 1

我过去领导过架构组。架构组的人在2002年的时候,疯狂迷上了UML和设计模式,人手一本《COM本质论》和《设计模式》。我手下有一个新手,就处处是类,处处是抽象,处处是封装,处处是分离,尽量使代码高内聚低耦合。但是这样的的代码太麻烦,他花费了大量的时间,他看自己的代码赏心悦目,别人看他的代码云里雾里,不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂,不知道他为什么这样写代码,怪异的很。本来,这位想达到可维护性,可阅读性,却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到:有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解,而UML设计者却认为UML可以描述一切。就这个道理,要理解你的代码还要去读懂《设计模式》,这要求太高了吧。

所幸这位新手自己都每次写的累,慢慢的也就懒了,觉得确实需要分离的时候就分离,觉得没什么必要的就懒得做了。用他自嘲的话说就是:被磨平了。其实,依我看,他现在这个代码状态才是刚刚好,即照顾了设计扩展,又照顾了实用。真正的纯OO,纯设计模式,可能只存在于教学和科学,而不在于我们的商业软件开发。我们作为商业开发,强调的是叫座的基础上叫好,所以折中方案是必须的,客户和我们自己两相宜就OK,是否符合正宗,就不在我们的商业开发管理范畴了。

这位新手还写了大量的注释。在每个源代码文件头都写上几月几号,XX创建的,这个原代码文件主要是干什么的,还画蛇添足的写上版权所有,公司名称。好像这个代码要开源,或者可能会被其他公司窃取了好表明公司版权。甚至每个函数都写了注释,每个参数是什么意思,每个参数可能出现的值代表什么意思,都写的一清二楚。久而久之,也懒的维护了。代码改动了,参数扩展了,参数状态值有了变化,注释说明却没有跟着改动,让后来看代码的人老误解,还不如不写这些注释。

我告诉他:做事不能走极端。要么全写注释,要么不写注释,都是不对的。我只在我认为要小心的地方,或者我自己都觉得很难理解懂的地方我才写注释。否则,我自己都可能会过段时间理解错了。如果某段代码我看看就能看懂,我就不写注释了。咱们做企业管理软件,深入技术又没有,只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽然说理解能力不同,我能快速理解了的未必有新手能够理解,但是你看看我的代码你就明白了。(摘自 《走出软件作坊:代码那些事儿》)

part 2

有一部分所谓的架构师,技术超深厚,框架堪比Spring之类,但自己一个人闷头写框架不断优化,力竭使用最先进的技术思想,希望把最豪华的设计模式融进去,希望把OSGi融进去,希望把AOP融进去,全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢,还是在满足个人技术幻想呢,还是在实验呢?到底在干吗?价值在哪里?

还有的人不会推广自己的框架。不善言辞,就幻想着技术总监能够通过行政命令让大家必须用框架,能不自己写代码就不自己写代码,能交给框架做的就交给框架做。但技术总监号召完了,大家仍然我行我素,各自开发为政,让框架开发者很孤单。

还有的人也不会推广自己的框架,沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如何应用,但自说自话,满口自己最得意的词汇,听得业务功能开发人云山雾罩。大家问些问题,如这样的业务开发难题,框架怎么解决?于是,框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不能答应客户这种变态的需求,而业务开发员说这就是现状。框架开发员说你可以这样这样,业务开发员说这样太麻烦,框架开发员立刻还口这还麻烦?于是双方各执一词,框架也没推广成功。

我手底下有个框架开发员。他的技术渴望很强烈,为了技术难题攻克,可以不吃不睡。并且技术敏感度很强,学习也快。所以当时我感觉他是个程序员的料,就把他拉到我的手下。

但是有个问题,他写出的框架代码,在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹,但是他却给大家N根不同长度不同粗细不同材质的木棍,N个不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期,而且也让使用人感觉没多大帮助。使用起来复杂,而且还得配置这个配置哪个,需要注意的地方太多。业务开发组的同事就不愿意用,还不如把代码自己直接写死了得了。超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能,但你没有拿出来。就耽误人家进度。你多次拿不出来,人家业务开发组还不如自己开发一个呢,求人不如求己。

我最后警告他:如果你认为自己技术够牛,那么你必须证明你能很快做出来。如果你认为自己技术够牛,最好能牛到,只提供一个函数就解决了他们的问题。别这个代理类,那个聚合类,这个唯一实例类。最好连参数也没有,大家调用一下写一句代码就OK。甚至你做的好,大家都不用调用你的代码,你可以包含在基础框架中,你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛,那么在业务功能需求发生变化的时候,你能够保证接口不变的情况下还能适合变化,这才你够牛。别让业务开发组的人跟着你也得改他们自己的代码,那样的设计就很烂了。

小伙听了我的话。进度保证,代码接口简洁。(摘自《走出软件作坊:走钢索的人》)


Til next time,
Xujiajun at 07:39

scribble

About Blog Email GitHub