项目人员的沟通语言

最近在啃Eric Evans的《领域驱动设计》。Eric Evans是DDD的创始人,这本书成书于2003年。这一点就挺有意思,现在主流编程思想,差不多都是在1995-2005这个时间段提出的,这些创始人的年龄也差不多。Martin Fowler, Kent Beck, Eric Evans,分别开创了Agile、XP、DDD,是软件开发着实绕不过的三座大山。

先说文档

字节有一个特点,文档特别多,所以自从入职以来,我对文档这种协作工具的思考从来都没有停止过。正好Eric Evans在书中也再次提到了XP对待文档的方式和自己对这种方式的看法,因此,在此结合我自己的想法,总结一下。

XP对待文档的方式是很特别的,他们旗帜鲜明的追求没有文档。

  • 针对基于文档的沟通,推崇口头沟通是替代文档的最好方式;

  • 而针对基于文档的方案和模型等,他们追求用代码本身当做文档,代码本身就是最好的文档

    • 业务逻辑的处理代码客观反应了模型;
    • 单元测试和集成测试,可以代替系统的功能文档;
    • 而客户编写的验收测试,可以代替系统的外部文档。

没有文档,自然也就不存在了模型与代码不一致的问题。而且,代码不仅代替了文档,而且代码的自描述性,也替代了注释的作用。

Agile与XP一脉相承,也引入了大量XP的实践,但是相对XP要温和一些。Agile仍然反对使用文档进行协作,但已经不是完全反对文档的存在的。在口头沟通的基础上,Agile允许我们事后补充一定的文档。

在DDD中,Eric Evans阐述了他对技术文档的看法。他也同样认为,在代码中已经反映过的东西,就不需要再存在文档。文档应该作为代码的补充,从侧面去解释技术方案。

再说图表

UML图,同样是一个很有争议的话题。对应于本文的主题,从UML的名字(统一建模语言)就可以看出,UML的诞生试图以非常规范的模型来作为项目中所有角色(包含领域专家、研发、测试、产品等)的共同沟通语言。这种思路太过绝对,同时,用模型图来作为统一的沟通语言,一致有很强的争议,这一定程度上导致了UML的失败。如今,除了时序图、用例图等少量图表以外,大部分的UML图都鲜有使用。

我与在外企工作的很多同学沟通过,在Google,Microsoft,Amazon,Hulu,Facebook等等公司,UML几乎是从来不使用的。有少量的同学会在日常沟通中使用一些比较随意的UML图来表达自己的想法,但部门对此完全没有要求。这与Eric Evans在DDD这本书中的思路是一致的,UML适合在一些日常的沟通中表达观点,在部分需要非常精细描述的场景中,作为一种统一的沟通语言。虽然叫做UML,但是实际上大家在绘制的时候是很随意的,不用按照标准来。我也很喜欢绘制这种图,既能借助于UML的表达优势,实际上又不受UML的条条框框所束缚,只追求把自己的思路表达清楚。

即使是在技术设计文档中,这些外企也以文字为主。只有在特别重要且细节的地方,可能会补充一个时序图;或是在语言难以描述清楚需求的地方,补充一个用例图。原因很简单,绘制完善的UML图真的非常费时费力,所以大家往往选择在技术设计会议上在白板上画画比较随意的图,讲清楚就可以了。最终实现的代码也会反映这种设计,因此再补充一份完备的文档显得没有必要。

但是,有一个场景下,UML图得到了大量的使用,就是演讲。如果运气好,你的系统获得了巨大的成功,需要到国际技术大会传授经验;或者你的项目被选做技术标杆需要在公司内部分享,需要一个PPT;或者你只是单纯想在博客上介绍一下这个系统。这些时候,UML就起到作用了。他们都有一个共性,就是你需要给团队外的成员讲解你们系统的运作方式。在这样的场景中,UML确实非常有用,而且因为你跟外部接触的时间不会特别长,文档不会特别多,也不会有很多的交流机会,所以UML的标准性也非常重要。万一你画的不是特别标准,在团队中你们有的是机会当面解释,而外人就永远不知道你什么意思了。

这不妨碍UML在国内非常吃香。因为用UML做的PPT非常好看,显得很高大上,所以真的有很多IT公司让下属搞这种设计拿去给领导汇报。具体是哪些公司就不多说了。

当然,我也不是说国内公司搞UML的都是形式功夫。有许多人确实比较喜欢UML,喜欢用UML搞设计。说到底,这只是一种个人偏好。而我过去的经验和我寻访顶级IT公司的经历,让我个人站在少使用UML这一边。

总结一下,uml主要两种作用。第一是作为沟通的语言。在这种场景下,太过严谨是一种败笔,更加随意的白板写写画画更加合适。第二,作为文档来解释系统。在团队内部,这种作用被代码的自解释完全取代;在团队外部才能发挥其作用。

我个人一直在外企风格的公司工作,对于详尽的文档、详尽的注释、详尽的图表这种东西确实敬而远之,更喜欢当面口头沟通、代码自解释、白板上随意绘制的设计图表。但我也确实并不排斥其它的观点,在合适的时机、合适的场景,选择合适的工具才是最重要的。

发表评论

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