“江湖郎中”这个词让人联想到那些戴着圆顶礼帽、留着浓密胡须、身穿定制细条纹西装的老头,他们兜售装满“包治百病”液体的瓶子。虽然几个世纪前很流行,但江湖郎中这个职业现在已经消失在历史的长河中。如今,江湖郎中的描述已经扩展到人类医疗保健之外。例如,在科技界,江湖郎中式的解决方案可以用来描述防病毒软件或某种流行的软件开发流程。
在当今引入业务开发团队的、最被“过度推销为灵丹妙药”的方法论中,Scrum 就是其中之一,它是几种 敏捷 软件开发方法之一,并被引入作为简化流程的一种方式。Scrum 已经成为一种根深蒂固的方法,它有自己的圣经,即 敏捷软件开发宣言,以及每日的虔诚仪式(又称 Scrum 会议)。
虽然 Scrum 在 90 年代早期开发时可能更有意义,但多年来情况发生了很大变化。初创公司和企业的工作人员分布在许多国家和时区,这使得员工更难共享办公室。随着我们的劳动力世界不断发展,我们的软件开发方法也应该随之发展。
当今的开放技术
初创公司和企业正在以开放技术的理念为基础创立,甚至更多成熟的企业实体,包括微软,也都在 拥抱一切开放事物。Matt Asay 在 描述当前的事态 方面做得很好。
十年前,一家新的开源公司或项目还是新闻。现在已经不是了。开源在移动领域占据主导地位,Android 在智能手机和平板电脑领域都取代了看似不可战胜的 iOS。开源也在云领域占据主导地位,除了 Azure 之外,每个重要的云平台都是使用开源构建的。甚至 Azure 也将开源技术视为其平台上的头等公民。开源在大数据领域也占据主导地位,Hadoop 和 NoSQL 技术是管理世界数据爆炸的主要力量。
2015 年的开源无处不在。每个从现代技术中受益的人,可能也在以某种方式从开源解决方案中受益。当您考虑到国际开发者群体为世界上最流行的开源项目做出贡献时,您不禁要问,他们如何在没有管理者、会议和代码冲刺的情况下取得成功?当我开始研究开源项目是如何取得成功的时,我意识到它们共享一套原则,这些原则可以被认为是开放式开发方法的信条。
开放式开发方法的信条
代码质量
作为开放式开发方法的一部分,代码质量至关重要。每次编写代码时,您都应该问自己关键问题:
- 这段代码是否易读?
- 这段代码是否可测试?
- 这段代码是否模块化?
- 这段代码是否经济高效?
提出的每个问题不仅对您有益,而且对您的团队也有益。当您以一种身处半个地球之外的另一位开发人员可以坐下来立即开始工作,而无需提出任何问题的方式编写代码时,您就是在帮助提高团队的效率。同样,当您确保您的代码是可测试的时,您会大大减少团队可能遇到的障碍数量。通过模块化,您向您的团队展示的代码既易于维护,又有可能为另一个项目回收利用。最后,经济高效的代码可以为每个人——从您的团队和未来的贡献者,到客户和最终用户——节省时间和金钱。
文档
开发人员不一定喜欢记录他们的代码——这不是秘密。此外,当他们受到像 Scrum 这样的系统的急诊室流程的影响时,即使他们想记录他们的代码,他们也可能没有时间,因为业务部门确定的优先级通常会优先考虑。您将编写的最重要的文档是您的高质量代码,但这还不够。考虑那些不了解代码的人,以及那些既没有时间也没有意愿阅读所有代码的人。当您的团队专注于适当地记录您的项目时,您正在为您的代码做与流行的电视节目 制造的原理 为其观众所做的事情相同的事情,即解释您项目的复杂性,并以更易于理解的方式将其带给更广泛的受众。
测试
在一个地理位置分散的团队中,您可能无法实时获得帮助,采用测试优先的代码方法可以让您更独立地工作,并减少障碍。可测试的代码有很多好处值得考虑。让我们来看看 Tim King 的 12 条技巧 列表,该列表来自 Perl Shop:
- 单元测试证明您的代码确实有效。
- 您获得了一个低级别的回归测试套件。
- 您可以在不破坏代码的情况下改进设计。
- 与不进行单元测试相比,进行单元测试更有趣。
- 它们展示了具体的进展。
- 单元测试是示例代码的一种形式。
- 它迫使您在编码之前进行计划。
- 它降低了错误的成本。
- 它甚至比代码审查更好。
- 它几乎消除了编码员的瓶颈。
- 单元测试使设计更好。
- 它比不进行测试编写代码更快。
讨论
在讨论您的项目和方向时,每个人都应该有发言权。永远不要忽视营销协调员、客户经理和非编码设计师。一切都可以公开讨论,当每个人都可以在无需通过指挥链的情况下相互访问时,一些最巧妙的想法和解决方案就可以被发现。
虽然资深开发人员可能会因为他们的专业知识而在讨论中占据主导地位,但永远不要忽视拥有不同、新鲜想法的新开发人员。TODO 组织开源行为准则 概述了一个项目社区的一般期望,我们在参与团队讨论时也可以考虑这些期望:
- 友善和耐心。
- 热情欢迎。
- 体谅他人。
- 尊重他人。
- 谨慎选择措辞。
- 努力理解我们为何意见不合。
透明度
赢得用户信任、促进社区参与以及提高项目的安全性和稳定性传统上被认为是项目成功路线图上的独立目标。但是,当您的团队拥抱开放式开发方法的透明度时,所有这三个目标都可以同时实现。
从发布项目的源代码到公开问题跟踪器,再到提供对内部流程和沟通的深入了解,项目的热情对于任何接触到它的人来说都是显而易见的。当用户和开发人员可以访问这些资源时,您的团队不仅会找到许多愿意贡献的人,还会获得社区更大的尊重和接受。透明度是一种强大的营销和工作工具。
异步性
随着初创公司、企业和开源项目将工作负载分配给世界各地的开发人员,维持像 Scrum 这样的软件开发流程所期望的某种同步水平变得困难。对于某些团队来说,维持每日 Scrum 会议是不现实的,当您有五位开发人员分布在五个不同的国家时,您可以排除结对编程的可能性。当今的软件世界在异步性中蓬勃发展,遵循开放式开发方法的团队也可以如此。
如果有人有问题,他或她可能会发送电子邮件或在开发者论坛上发帖,并期望他们的消息不会立即得到回复。那么,提出问题的开发人员会停止他们的工作吗?不一定。由于需要自力更生和适应性强,开发人员可以修改他们的期望,专注于代码质量,加强他们的文档,并提高他们的技能。
民主
除了在项目社区内进行公开讨论和分享想法外,社区成员还应参与决策过程。当决策由闭门董事会会议、高管或经理(我称之为单点故障)做出时,通常带有狭隘和有限的观点。当每个人都参与决策过程时,包括最终用户或客户,否则无法识别的潜在问题更有可能在成为问题之前得到解决。
共同构建开放式开发方法
与其只允许我自己或少数人开发这种方法,我更相信这个过程应该像任何其他开源项目一样开放和包容。
可能有一些我遗漏的优先事项,或者需要理顺的点,所以请 在 GitHub 上加入我,我将在那里继续讨论,并致力于创建一套精美的指南,使所有规模的开发团队都能取得成功。
49 条评论