酷应用

11个领导行为可能会使您的软件项目陷入困境

百家作者：企业网D1net 2019-03-18 04:59:57

点击上方“蓝色字体”，选择 “设为星标”

关键讯息，D1时间送达！

任何数量的“反模式”都可能破坏软件开发的成果：管理实践在理论上看似合理，但如果积极地坚持，则很少会得到回报。

软件开发人员创建了一个“反模式”的概念，以警告其他人不该做什么。想想旧地图上“此处危险”的标签。无论你做什么，都不要在这里航行。

多年的来之不易的经验归结为如何不去构建代码，如何不去设想架构或如何不去设计数据库架构的简明描述。这些反模式已经变得非常有用，以至于其在开发人员之间传播，并且与描述应该如何操作的功能设计模式一样受到重视。

软件项目管理有自己的“反模式”：看似合理的做法，但来之不易的经验表明，实际上我们不应该这样做。当然，与编写代码相比，运行一个项目和管理一个团队并不是一门科学。一些反模式是彼此的镜像：它们命令你接受同时避开同样的事情。但这些反模式真正要求你做的是适度。太多的想法——不管它有多好——在管理团队方面效果都不理想。

以下内容是软件开发管理的11个反模式。认为这些反模式是看似合理的习惯，但当你管理开发团队时要避免。

“团队中没有自我”的反模式

罗伯特•弗罗斯特(Robert Frost)喜欢说，修建好的围栏能造就好邻居。我们需要自己的空间，开发人员也是如此。人们总是倾向于在一个团队中增加更多的开发人员，希望更多的人手能够使工作变得轻松。但是，最终开发人员之间经常发生矛盾，为更新相同的代码段而争执。突然间，代码审查工作就不断增加，没有人想要逐行检查并合并代码。

微服务架构有许多缺陷，但它却可以为开发人员提供一个呼吸空间。开发人员可以在代码的各个部分独立工作。他们可以提交代码，创建测试并继续推进工作，而无需与其他人员保持同步。将开发人员拆分，并让他们在自己的空间工作，会产生重大影响。

“分而治之”的反模式

当开发人员最终需要让各自的代码协同工作时，让他们分开各自工作的唯一问题开始显现。突然，一个API提供字符串，而另一个API却需要整数。或者，也许一个团队希望数据是在行中，而另一个团队却希望数据是在列中。有很多方法可以解释白板上的简易草图。当然，所有测试都通过了，因为每个小组都用自己的想法为自己的代码编写了测试。

解决方案是更集中的管理和更集中的测试。一些团队指定一些开发人员不断监控集成工作，以确保所有工作尽可能顺利地组合在一起。让零件协同工作与构建各个零件同等重要。让开发人员朝着同一方向前进本身就是一项工作。

“追随你愿景”的反模式

如果我设想将来要设计出一些漂亮和吸引人的代码，并且我有足够预算，那么，我就会聘请一个开发团队来编写代码。每个开发人员都清楚创造性天才的爆发力，他们可以为整个堆栈提供整体愿景。每个开发人员都知道，这之后是一段想象的超能力时期，在这段时期，每个功能似乎都可以在几行代码中完成。我们多少次启动代码编辑器，并开始向这个光明的远景奔跑?

这就是为什么我们需要一种方法——这种方法迫使我们抛开辉煌的梦想，然后详细地勾勒出计划。然后，当我们第二天或下周总结工作时，我们可以认识到这些缺陷。制定计划可能是一项真正的苦差事，但它比调试代码更快。不要只是坐在那低头工作。

“照章行事”的反模式

对于每种方法，都有一些书籍、会议和顾问随时告诉你必须做什么，以及无论如何要避免做什么。他们非常擅长以绝对权威的方式传达这些规则。

麻烦的是，没有什么能完全符合他们的规则。你可以写出几个月的规范，但是当你几乎完成这些规范时，你总会发现一些新的角度或问题。您可以尝试保持灵活性和敏捷性，但是在规划阶段您无法预测较容易解决的一些问题。但总会有问题解决的时候。

最好的管理者会选择一种方法，然后找到预测该方法失效的途径。我们所有人都不能一直这样做，但是当我们这样做时，我们确实感觉已经找到了一种途径。

“信任过程”的反模式

虽然软件开发有其神奇的时刻，即所有事情都按时汇集在一起，但是由于担心破坏这一创造性过程而不跟踪细节工作，这可能会产生一些后果。安装新数据库花了多长时间?该团队何时承诺来重新设计单点登录API?有多少人正在检查代码，以重构上一次Sprint代码编写周期所遗留的技术债?

负责任的人总会列出一长串的障碍、困难和延误工作的问题。领导面临的挑战在于找到一种优雅的方式来观察工作中正在发生的情况，并通过跟踪足够多的细节来做出明智的决策。软件开发的衡量指标可能非常不精确，但只要您不期望过多，这些指标就会让您掌握谁在从事什么工作。

“你无法管理那些不能进行衡量的工作”反模式

这是一句老话，但今天听起来仍不过时，这要归功于人们对数据重要性的日益关注。并不是说，软件的衡量指标不好;只是这些指标没有捕捉到所有正在进行的工作。很久以前，管理人员试图计算开发人员所编写的代码行数，之后，开发人员很快就想出了如何添加额外的注释或其他非功能性的点缀来增加他们的工作量。

如今，一些管理者将任务分配了一些抽象的“点数”，然后在一个季度或一年结束时计算这些点数。但首先，找出合适的点数几乎和解决问题一样困难。最核心的团队要求开发人员以点数来竞标工作，让他们相互竞争，以寻求更准确的评估。这对团队友情或合作毫无帮助。

最大的危险是，开发人员会避免去接最难或最难以预测的工单，因为他们知道这些工单会使他们陷入困境，在季度末或年末他们将无法得到足够的点数。解决方案是不要过分相信这些指标。如果愿意，跟踪这些点数，但不要将它们视为价值的绝对衡量标准。

“愚蠢的协调一致是小智慧的骗人伎俩”反模式

开发人员需要自由。如果你问他们，他们会直截了当告诉你，他们不希望有人限制其创新能力和影响其设计优秀的新代码。

问题在于，如果让开发人员在他们自己的设备上工作，则他们将朝不同的方向推进。这就是我们需要一些标准的原因。让代码具有一致性的优点很容易理解。如果代码的模式和视觉节奏是可预测的，则代码更具可读性。

可以自动执行一些最佳解决方案。一些代码编辑器(例如Atom)会使用规则来重新格式化所有代码，以符合规定的规则。(另请参见ESLint。)这样可以避免开发人员担心一些标准的细节，同时确保结果足够清晰。

“标准将拯救你”的反模式

软件标准现在风靡一时。每个新开发人员通常都会遇到更全版本的编码规则。例如，Airbnb平台的JavaScript代码规则版本就很受欢迎。

但标准往往会激起愤怒和怨恨，给开发人员另一个进行争执的理由。他们喜欢在代码审查过程中抨击这些标准，为那些最小的和无关紧要的问题反复说某些行的代码。例如，Airbnb平台的某个人花时间思考并编写有关在代码中插入空格的规则。必须在大括号内插入一个空格(19.11)，但禁止在方括号内(19.10)插入空格。如果你认为开发人员不会花时间为琐事而争执，那么你就没有注意到这一点。他们喜欢使用“标准”这个词，因为非标准代码可能会让每个人都死于像埃博拉这样的病毒。

许多这些所谓的标准纯粹是为了美观，对代码执行速度或代码是否能得到正确答案都没有任何影响。编译器或解释器会忽略额外的空格。您可以做的最糟糕的事情就是大胆推行一些标准，但这些标准对运行代码的质量几乎没有影响。所有关于空格位置的美学讨论都只适用于人类，其目的是阻止人们过多地争论。如果您要推行一些标准，请让标准简单易于遵循，并且只关注具有实际意义的细节。

“简化堆栈”的反模式

在代码库中使用某些规则的最简单方法之一就是坚持使用一种语言，且仅使用一种语言。一切东西都是一致的，每个人都可以轻松阅读。每个所聘用的人都具有相同的语言技能，每个人都相处融洽。

这是一个很好的想法，遵循该想法是有道理的。棘手的问题是，当你想要打破这些规则时，该怎么做。总会有一些新的库或功能丰富的开源代码完全符合您的要求——但它却是用另一种语言编写的。

如果你很严格，你会维护代码库的纯度，但代价是牺牲快速而高效地完成某些工作。最后，用户不会阅读任何代码。他们只关心代码的功能。有时，在代码库中容忍一些差异是有意义的——如果这可以让用户满意的话。这种挑战在于，知道何时进行妥协是值得的。

“让开发人员选择工具”的反模式

克里斯(Chris)喜欢新的函数语言，更严格和更多类型检查则更好。帕特(Pat)希望编写几乎是机器代码的低层代码。鲍勃(Bob)喜欢上一个标题中的所有内容。

他们都能和睦相处吗?不!哦，在一个流程图中看起来很简洁的微服务架构中，可将来自许多不同语言的代码整合在一起。许多语言可以转换为在JVM或JavaScript引擎上运行的东西，从而可以将每个人喜欢的语言链接到一个大的blob中。

在全新项目开始时，具有灵活地语言选择能力，将使您更受欢迎。当Kotlin语言的忠爱者离开团队，然后PHP语言的死忠接手了他们无法阅读的代码时，问题就出现了。即使你可以让团队具备合适的技能，如果JavaScript程序员需要查看用Swift编写的代码，则他们会发现自己在沼泽中跋涉。

要注意，不要过于开放和包容。

“积极性是成功的关键”反模式

为什么我旁边的那个家伙写了两倍长的代码，而不是添加一个可在一行中就实现功能的标准库?因为老板在git存储库中添加了一个tripwire软件包，强制对库目录所添加的任何内容进行额外审查，并且那些负责审查的人被认为是反复无常的混蛋。

几个星期之后，我看到同一个人巧妙地提出，将工单分成多个部分，可获得价值两倍的“点数”，这个“点数”是一种虚拟奖励，每个人都在努力积累，以证明他们的工资是合理的。他精通于拉取请求，支持工单和敏捷性指标。

因此，尽管激励团队对于软件项目的成功至关重要，但找出真正能激励你开发人员的东西，这可能是一个谜中之谜。我们可以尝试将开发人员集中起来，并让他们交付客户最终想要的东西，但开发人员也有自己的想法。他们比我们更了解这些工具。我们最好是来培养一种伙伴关系，并努力培养他们对大局的理解。然后，我们期盼他们能尽最大努力将抽象目标转化为数百万行整洁、经过测试且相对无错误的代码。

（来源：企业网D1net）

如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1Net投稿 投稿邮箱：editor@d1net.com