软件开发团队管理杂谈

最近在研究 Groovy 时想起了一些管理上的经验，所以就写下来跟大家分享一下。

Groovy 是一个弹性很高的语言，并且同样一个动作可以有很多种写法。不过以开发团队管理者的角度来看，对于这样的语言导入团队其实是一种很大的挑战。在开发团队运作过程中，产出的源代码并不是只有撰写的人才会接触到，为了确保源代码的质量会进行 Code Review，或是为了工作的负载会有不同的开发人员接手进行源代码的调试或维护。

所以为了维持开发流程的顺畅，源代码的一致性就相对地重要，而维持一致性常见的手法就是订定团队的 Coding Convention。然而，像这样具有很大弹性的语言，在订定 Convention 时不容易拿捏订定的准绳。如果订得太具体、详细了，有些成员觉得琐碎记不住或是觉得麻烦而配合度不高；但订得太抽象又会在实作上有很多的例外而流于形式，或是在 Code Review 时因解读不同产生争议。

另外还有一个对管理者来说很头大的问题，就是要如何让 Convention 的内容成形。要导入团队没有经验的语言，在订定 Convention 时大多还是求助于外援。如果是具有历史的语言，在资料的搜集上可能相对容易一些。但是如果是年轻的语言，可供参考的资料并不多，有可能会需要投入时间及人力来达成。但是要形成一份可发挥功效的 Convention，通常要对语言的规格有一定程度的了解，并且对于应用在实际开发工作上可能遭遇的问题做出考量，或是针对团队的习性进行微调。这是会产生可观的人力时间成本，是否要投入会是一个很煎熬的抉择。

在 “隐藏的机会成本不管有多巨大都会被牺牲” 的现实面之下，大多只能无奈的选择可以展现绩效的方案。“且战且走” 会是常用的选项之一，也就是借由专案经验的累积来逐步形成 Convention 的内容。其后遗症可想而知，导入初期的专案里源代码的写法百家争鸣、每一个 Convention 阶段的专案源代码撰写风格都不尽相同。回头去改过去专案的源代码不符合帐面上的成本效益，放着不管又要承受着成员接手意愿不高，或是系统修改时出错可能性较高的风险。

另外一个衍生的问题是，“且战且走” 初期一般就是订定几个原则性的抽象大纲，期望开发人员能够依循大纲的精神来自我要求，以提高程式产出的质量。残酷的现实是总会遇到有一部份自我中心的开发人员，其抱持的心态觉得源代码打得愈少效率愈好，并引以为豪。不仅是在写法上极尽所能地精简，同时在命名上也是能缩写就缩写，有惯例用惯例、没惯例就自己订。当成员间源代码撰写方式看法相左时，这样的成员能沟通的还算好，花点时间就是了。最糟糕的情况是遇到自视甚高、缺乏同理心的，不论如何沟通都依然坚持己见，并且还在团队中造成 “破窗效应”。

就像前面提到的，源代码在一个团队里会需要看的又不是只有 Compiler。源代码本身也是一种文件，易读性是一个很重要的质量指标。从变量、函式的命名、源代码的排版、指令的排列顺序、空白行的使用到程式区块的分配，都应该要隐含着 “导引阅读源代码人员理解程式逻辑” 的效果。

从效率的角度来看，节省掉的打字时间是可以省个几分钟。不过现在的 IDE 都够成熟，自动完成大多都是基本的功能，靠 IDE 的功能就算是命了一个很长名字的变数，真正需要打完全名的机会根本微乎其微，能省掉的时间其实很有限。同时，精简的源代码在侦错的操作上很容易出现一个问题是，太多指令同时发生在同一行源代码，单步执行时会不容易有效隔离并观察到出问题指令所造成的影响。但是写出一堆不易理解的程式，除了其他人阅读时要额外多花掉的时间，再加上看错所产生一连串后续修复的时间成本、用户因程式运作错误所付出的成本，绝对超过省下的那几分钟。

有经验的老手应该都清楚，缮打源代码的时间其实占开发一套系统的比例不算高，大多数的时间还是花在规划和构思系统的流程与架构。执着在打字的效率上其实是不够理性的行为表现，甚至 “争论源代码写法” 所产生的时间成本都高于 “照规定要求完成工作” 的时间成本。

有人可能会认为这是个小事、问题不大，加个注释帮助阅读就好了。我想这是一个没有认真写过注释的人才会有的想法，要写出一段能允当表达程式设计意图的文字，其实是很花时间的一件事。随手写下的简短注释，往往有一个很常见的经验是 “在过一段时日再回头去看时，文字比源代码还难了解”；或是注释只是在重复程式执行的动作，看源代码和看注释的效果一样。如果是这样的注释，与其浪费时间在打这些字，还不如回头去好好地把源代码变得更易读。

当然，有很多人会觉得以目前的软件从业环境，很多的源代码都是在急就章的时程下产出或是用过就丢。与其花心思在这种枝微末节上，还不如早打完早收工去享受人生。这是每一个人对于工作的态度，没有所谓对错的问题，端看你想要让你的工作成果是精品还是平价品。想要打造出精品，差别就在所谓的魔鬼细节里，会需要付出很大的成本吗？我的经验是 “不需要”，只要养成习惯，自然而然的就会展现在工作的成果里！