分类 思考控 下的文章

团队与创造的平衡


“安德来了之后,我们必段保持一个巧妙的平衡。要让他保持一定程度的孤立,使他创造性不至于消失,否则他就会和这儿的整个团体融合在一起,我们会失去他的天赋。同时,我们也必须确定他有足够的能力去领导别人。”
                                                                    — 《安德的游戏》作者:奥森·斯科特·卡德

上面的引述是《安德的游戏》一书中安德刚进入战斗学校时,格拉夫中校与安德森的对话中的一段内容。这段文字显然触动了我的神经,因为在现实的生活和工作中,我也有与格拉夫中校相似的体会。

* 团队就像一个大熔炉

以前听说过军队就是一个大熔炉,再烂的材料似乎都能被锻炼成精兵。有一定道理,但我们也看到了子弟兵们的“歪风邪气”,想必也是熔炉锻造的结果了。也就是 说熔炉将材料的属性,无论好与坏都或多或少的在每个个体上有所体现了。这样一来,如果原料都是优质的,优点通过团队这个熔炉就能充分传播,形成优良的团队 作风和习惯。相反,优劣程度不一的材料经过熔炉的锻造,最终结果是谁的属性站了上风,那就要看谁的属性更加强势了。但由于人的惰性、喜欢安逸等与生俱来的 “特点”,人更容易选择“下坡路“。这好似地球上的风,起到削峰填谷的作用,在外界条件一成不变的情况下,团队走向“平庸”,优秀成员的创造力渐渐萎靡, 思维之火花逐渐熄灭。创造力变成了墨守成规,因循守旧和固步自封。就像安德眼中的战斗学校中的一些战队和指挥官那样。

* 站在第三方的视角观察团队运作与成员创造力

“不知庐山真面目,只缘身在此山中”。很多时候,由于深处团队之内,团队的Leader也往往无法发现团队中正在发生的负面变化 – 逐渐失去创造力,渐渐地不再有新点子、新想法、新工具,新实践。大家也许依旧忙碌,但总感觉缺点啥。要想发现这些变化,团队Leader或成员要学会跳出 圈圈,去站在第三方的视角观察团队运作,嗅一嗅团队内部发酵出来的bad smell。就像书中天才少年安德那样在每次战斗比赛结束后或旁观时,都会站在敌方的角度去分析战斗策略应用是否得当。另外识别出团队内那些善于发挥创造 力的成员是十分重要的,他们是团队的火车头,他们引领着团队的前进步伐,他们的发挥决定着团队的先进性。就像书中的阿莱、比恩、丁.米克等人那样。

* 主动为创造力的保持制造空间、寻找平衡

在影视剧或现实生活中都有这样的案例:那些秉复异常,极具创造力的家伙往往无视规矩,独来独往,与团队看起来并非那么和谐默契。现在看来这是他们自己建立 的一种自我空间,他们可能站得更高,看得更远,不愿经历“团队熔炉”锤炼而丧失部分自我,尤其是其独辟奚静,与现存习惯不符或相悖的创造思维,他们要与团 队保持一定距离,走在团队的前面。而我们的确需要这样的人。

书中格拉夫中校是一位懂得主动为创造力的保持制造空间和寻找平衡的好伯乐,甚至在安德未进入战斗学校之前就定下了教学策略:让安德保持一定的孤立,以保持 其创造性。他是每个团队Leader都应该学习的榜样。对于团队内那些具有创造力的组员,我们要主动给他们提供创新萌芽的空间和土壤,尽量保证不要被团队 的某些Bad smell侵入,让创造展现出原汁原味。

在崇尚“团队合作”的今天,一切有悖团队习惯的行为可能都会被认为是不专业的、不胜任的。提出一个打破团队“习惯”的所谓创造性实践,很可能会被认为对团 队以及团队领导的挑衅,导致团队内部出现裂痕。这更需要我们学会主动在创新和团队之间寻找平衡,去化解团队内部的不信任和猜疑。让团队看到创新的威力,让 创新更多结合团队的实际情况。

* 重构团队

有些时候,我们需要牺牲团队,保持创造。那些无丝毫创造力的团队就像活锁(livelock)一般,大家都在忙,但make no progress。对于这类团队,应该施加一定的外部条件,打破团队“和谐”的状态。也许重构是一个很好的办法。将那些之前富有创造力但“彻底融入”团队 的成员分离出来,给予独立空间,尝试重新激活。至于其余成员,打乱重组未尝不是一个好方法。

这篇文章可能会引发争议。就像格拉夫对安德的训练方法那样,有赞成,也有恶评。

再谈那些代码中的“中国式”命名

近期博客访问量提高了不少,分析了下原因,发现是有几篇近期写的文章被某个好心网友提交到dbanotesStartup News上了。与此同时,一些反馈也随之而来。从反馈来看,《那些代码中的“中国式”命名》一文似乎受到了更多的关注,或许是文章标题比较容易引起好奇的 缘故吧。但文章的本意仅是想阐述一些事实罢了,并没有“哗众取宠”的意思。网友的观点也促使我重新对“中国式”命名做了反思。

* “中国式”命名的普遍性

我曾天真地希望该问题只是我们项目中的个例,但现实是“沮丧”的。看到评论中几个网友都反馈“中枪”,说明该命名方式似乎是普遍存在于中华大地程 序员们的代码库中的。

中国式命名归跟结底是文化差异性和表达方式的问题,就和Chinglish一样。由于中式词汇、语法结构已经成为了我们的潜意识一部分,存在与大 脑的核心层,每当 我们要命名或表达一个事物时,大多数人首先在大脑中展现的是这个事物的中文拼写方式、中文语法的结构,其次才可能是英文的(对于第一外语是英语的人),如 果想不出正确的英文名并且懒得去求 谷哥,那么该事物在程序代码中就很可能以“中国式”的命名而存在着。

* 不是所有Chinglish都是English

在再次谈“中国式”命名之前,我们先要搞清楚:“不是所有Chinglish都是English”。

Chinglish刚出现的时候,标准英语的支持者认为Chinglish是垃圾,是错误的表达,无法被接受,对其进行抨击。但万事万物都有一个 接受的过程。今天来看,越来越多的选词达意准确的Chinglish词汇以及表达方式正在被国人接受甚至被以英语为母语的人所接受而成为 English,比如近年来的热词:geilivable(给力),再比如很早之前就接受的"long time no see"等。

作为人类的优秀语言,无论是英文还是中文,都具有很强的开放性和包容性。随着时代的变迁,新生事物的出现,词汇与表达方式都是在语言间相互渗透, 相互补充的。比如随着近些年中国航天事业的迅猛发展,尤其是神舟飞船的多次成功发射,标准英语中接纳了“中国宇航员”这个词 汇:taikonaut;再比如很可能于明年被收录到牛津英语词典中的”Tuhao(土豪)”、 “Dama(大妈)”和“Hukou(户口)”等。而近些年来,一些外词的音译中文词汇也被加入汉语词典了,比如博客 (blog)、粉丝(fans)等。

但不是所有Chinglish都可以被接受而成为English的。Chinglish是良莠不齐的,那些完全错误的、让人啼笑皆非的词汇和表达 方式现在不会被接受,以后也是不会被接受的。比如下面这两个典型的错误:

    杯子 – Cup son
    开水房 – Open Water House

* 用Chinglish != "中国式"命名

既然“中国式”命名是普遍存在的,那是否是合理的呢?在上一篇文章中,我个人将其归类为bad smell一类,现在的观点依旧如此。

有人不禁要问:既然有些中国式英语(Chinglish)都能被老外所接受,那“中国式”命名为何不可呢?

我的答案如下:在代码中使用已经被老外接受了的Chinglish词汇,实际上与使用地道英文词汇本质上是相同的,算不上“中国式”命名;这里的 “中国式”命名仅针对我在上一篇文章中提到的那些命名方式,当然包括那些并未被广泛接受的Chinglish词汇和使用方法。

* 对"中国式"命名的态度

网友观点:“认真你就痛苦了”。
我倒不是这么想的。既然我们认为命名在编码过程是重要的、困难的,我们就更是要认真对待,在这方面我们有些时候真得较较真儿。我想这也是专业性的 一种体现。

* 到底该如何做?

一句话:尽可能用English(编程界主流文化在欧美,主流语言是英语,这才是根本原因),包括那些广泛接受的Chinglish。纯自造的 “词汇”,比如网友评论中提到的left_kuohao这种中英结合词还是不写为好。

如果有一天中文编程语言成为编程界的主流,那中国程序员也就不用在命名上纠结了。

代码是怎么腐化的

新三年,旧三年,修修补补又三年。
                                                             — 中国俗语。

上面的这句俗语用来形容很多遗留软件系统(legacy software system)的现状是再合适不过了。

今天下午做了一下午的代码评审,对象是一个运行了7年的遗留系统。会上除了几处明显的代码逻辑错误我发言指了出来外,涉及业务流程以及代码设计的问题,我 大多保持沉默。因为我清楚,即便我明确指出问题,可能也得不到修正。也许参与评审代码的其他同事也都知晓这些问题,只是觉得现在还不能去改…。

为何不能去改?回想当年第一版代码出炉时,它是那么的“出淤泥而不染”,而如今它身材臃肿,满身赘肉,千疮百孔,让人无处下手,看起来都不舒服。虽然它依旧能坚持工作,但终会有一天,它会轰然倒地,酿成大错。为何代码会腐化到如此地步?是怎么腐化的?这里谈几点体会。

* 第一版的设计和实现水准

我们知道:设计再完美的系统也终会有腐化的一天,时间才是最可怕的武器,它是一把无情的刻刀,不仅能使人老去,逻辑抽象世界的程序也不能幸免。但是你的程 序设计和实现的越完美,这个衰老和腐化的周期就会越长。一个糟糕的初始设计和实现,只会让系统更早的发霉、腐败直至被替换。我们的这个legecy系统在 最初的代码设计上就给后人留下了许多“糟糕的参照物”,在后人无以伦比的“复制粘贴”的技能下,这些糟糕的设计和实现就像癌细胞一样扩散到系统机体的每个 角落,让你无法重新建立其免疫系统。

* 没有测试做保障,不敢改

系统从诞生的那天起就使用“人肉测试”的方式,而且是粗粒度的系统功能测试。没有白盒的、可重复使用的、自动执行的单元测试集做保障,以致没有人敢对其轻举妄动,一旦出了问题,后果自负。另外人肉测试,精力和成本双重消耗,测试人员“耗”不起啊。

* 缺少崇尚“美”的文化

记得组织第一版企业文化中“美”这个成分还有立足之地的,但后期改版后,我们就再也看不到“美”了。码农们也是一样,在缺少了“俱美”之风的吹拂下,大家 都变得有些“丑陋”了,大家都开始摒弃“美”,认为代码只要能工作即可,美不美不打紧,于是工作就变成了修修补补,系统变得日益臃肿,臭气熏天。

* 进度之忧高悬

很多人会说:“如果给我充足的时间,我会让系统获得新生。但我没有时间,客户那边催的急,只能下次再重构、完善和优化了吧”。从这里不知大家是否看出了:“改善是没有的,下次却是永恒的”这一“道理”。在进度堪忧的情况下,我们多数时候选择了屈服,而不是自己的原则。

* 成本,老板们不得不面对的

“能用即可,新三年,旧三年,修修补补又三年”。如果你和老板谈重构、谈优化,那么这句话就是老板最好的拖词儿。成本永远是悬在老板头上的一把宝剑,老板们不能视而不见。因此,如果你要和老板谈重写遗留系统,那得需要多么强大的魄力和坚定的意志啊。

* 拷贝粘贴,最好的伙伴 or 最大的敌人

相信发明复制、粘贴以及剪切板的那位仁兄无论如何也没有想到,自己送给世界的礼物,竟然被码农们操练的如此熟练,应用在各种场合,尤其是Coding中。代码中充斥着大量重复代码信息,都是拷贝、复制和粘贴的结果,于是乎代码腐败的最大敌人就此出现了。

牢记:“千里大堤,溃于蝼蚁”。下一步该怎么办?去闻闻,你的代码腐化了没有!




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多