从拒绝到接受小黑开发
从拒绝到接受小黑开发
大概是在去年春天吧，我头一回听同事老张提起“小黑开发”。他当时眉飞色舞，说这法子能省多少时间，绕过多少流程。我心里咯噔一下，脑袋里立刻拉响了警报。啥？听着就不太正规，像在灰色地带游走。我几乎是下意识地摆手：“不行不行，咱们做项目，哪能这么干？代码得清晰，流程得规范，这是原则。”
我那会儿觉得，开发就得光明正大，每一步都摆在台面上。所谓“小黑开发”，不就是私下捣鼓、不写文档、绕过测试吗？这种“野路子”产出的代码，将来谁维护？出了问题谁负责？一想到未来可能要接手一堆这样的“暗雷”，我就浑身不自在。我跟老张争论，说这是对团队和项目的不负责。他摇摇头，没再多说，但那眼神里分明写着“你太固执”。
转变发生得很偶然。我们接了个紧急需求，时间紧得让人喘不过气。按部就班走完设计、评审、开发的流程，铁定来不及。团队里弥漫着一股焦躁的气息。那天下午，老张又凑过来，这次他没鼓吹，只是平静地说：“试试看？就用一个小模块，我们控制好范围。”我盯着屏幕上密密麻麻的排期表，第一次，心里那堵坚硬的墙裂开了一道缝。
抱着一种“死马当活马医”的复杂心态，我默许了。我们圈定了一个非常独立、边界清晰的支付状态回调模块。老张和另一个同事快速动了起来，他们在一个独立分支里敲代码，沟通基本靠口头和即时通讯。我呢，就提心吊胆地在旁边看着，像个严格的监工。
你猜怎么着？效果出乎意料。那个模块，在两天内就完成了核心逻辑，并且顺利对接成功。它就像一颗精心计算过的卫星，被发射到主项目这个“大飞船”的预定轨道上，运行平稳。这次经历，让我不得不重新思考。我以前是不是把“规范”理解得太僵化了？在绝对的流程和现实的需求之间，是不是存在一个更灵活的平衡点？
我渐渐明白，我抗拒的其实不是“小黑开发”本身，而是它可能带来的无序和混乱。但如果能给它套上“缰绳”呢？如果把它定义为一种在严格限定条件下的、目标明确的敏捷实践呢？比如，只在处理紧急、独立、业务逻辑相对简单的“边角料”功能时使用；比如，参与者必须经验丰富，且事后必须补全关键文档和注释；再比如，绝对不允许涉及核心架构和主干流程。
观念这么一转，很多事就通了。它不再是一个洪水猛兽，而成了工具箱里一把特殊的手术刀——锋利，有风险，但在熟练的医生手里，处理特定病症时能奇效。关键在于如何定义它的使用场景和规则，也就是我们常说的开发规范。没有规范的“黑”，那是真黑；有了清晰规则的“黑”，或许叫“灰度快速通道”更合适。
现在，我们团队会偶尔采用这种方式，但前提是遵守共同约定的“军规”。它成了我们应对某些极端情况时的备用选项，而不是常规武器。这个过程让我学到，在技术世界里，纯粹的拒绝或拥抱可能都太简单了。更重要的，是去理解一件事物的本质，厘清它的利弊，然后想办法将它纳入可控的体系，让工具为人所用，而不是人被工具带来的标签束缚。从坚决拒绝到有条件地接受，这个弯绕得有点大，但我觉得，值了。