软件开发中的大忌——闷声发大财

2022-12-06 01:12

先讲一个真实案例。

小明被领导委任负责一个提高组里一款WebApp性能的任务，他查了资料以后发现缓存JavaScriptbundle是一个经常提到的改进，便决定从这里入手。几周以后，缓存有了，配套的监控面板也有了，小明天天盯着上面的数据，但是1个多月过去了，中间修修补补好几次，性能的提升却并不是很明显。

于是老板建议他给大家分享一下目前的情况，小明schedule了一个会议并邀请了所有的stakeholder，结果会议上就有人指出他的方案并不能从根本上解决性能瓶颈，同时指出后端API的高延迟才是最大瓶颈。小明这才恍然大悟，只能照着新的思路重新开始。

对于这个失败的案例，里面固然有research不到位的原因。但是设想一下，如果小明在最开始就把自己的想法告诉大家而不是先自己闷头干一个多月，结果是不是完全就不一样了？

在软件开发中，项目早期的曝光度（early visibility）是非常重要的。Early visibility意味着更早的反馈（early feedback），也就意味着更早发现问题，解决问题。我们中国有句老话叫做闷声发大财，不鸣则已，一鸣惊人。

这在软件开发中是非常危险的，特别是对于那种单人驱动的项目来说，一个人埋头苦干而其他人却蒙在鼓里可能会导致两个严重后果：

项目被推迟交付。

越是复杂的项目，后期调整的难度越大。你做了一大半最后发现有问题，推倒重来，白白浪费那么多时间，项目自然延期，对客户、团队和你自己都是很大的负面影响。

Technical debt (技术债务）的堆积。

大家有没有过这种经历，组里的某个同事在做一个项目然而你对他的思路全然不知，然后有一天他突然发了一个巨大的CR (Code review), 里面各种不符规范的写法和糟糕的设计，你告诉他这些都不符合组里的coding standard，他却说马上要deadline了，修改的成本太高，必须要尽快上线。

你没办法只能先approve，于是technicaldebt就从这里开始堆积了，你发现你们永远没有时间来重构这段垃圾代码，因为总是有更重要的活。

不仅如此，相关的其他feature还必须保证和它兼容，于是越来越多的bad practice被迫出现在你们的代码库里，最后变成几乎完全不可逆的代码“屎山”。

一个项目成功的关键，是早点让人们看到你在做什么，并支持你这么做

那么我们如何贯彻early visibility呢？

定期追踪项目进展。

对于重要的，耗时较长的项目，定期召集大家跟进是很有必要的，不管是会议、邮件还是其他形式，你需要让所有stakeholder知道以下信息，这样你们可以迅速做出调整，比如向上面争取更多时间，改变优先级等等。

如果你想搞一个新项目，请提前征求上级的意见。

阐明这个项目可以带来多少收益，需要多少时间，得到肯定的答复后再行动。千万不要有“我要给老板一个惊喜”的想法，自作主张。

开始写代码前先发送一份设计文档（Design doc）。

它不需要很正式，不一定需要各种fancy的流程图，有时候甚至一封email就行。此外，设计文档并不是只在设计新系统的时候才用，只要是具有一定规模和复杂度的任务都适用。

就拿开头小明的性能提升项目为例，app目前的性能指标如何？有哪些瓶颈？对应的改进措施，预期收益，action items和ETA都可以被记录在设计文档中。关键是清晰阐述你的思路并让人们理解你要做什么。

不要忘了与你的上游（upstream）和下游（downstream）沟通。

我们经常需要使用别人已经写好的库，调用其他的service来为我们服务。在做决定用哪个库之前，我们需要咨询它的技术支持这个东西能不能够满足我们所有的使用场景，如果不能，是否有workaround?

反过来，如果我们的服务会被其他组使用，那我们做改动之前需要让他们知道我们的计划。这种上下游之间的visibility不仅可以规避开发中的兼容性问题，还可以给双方足够的时间计划，过程中提出的一些问题也可以给双方带来额外的启发。

发Code review的时候，先发一个小的CR验证你的写法是对的。

我把这种方式称为“探照灯”。它其实是一个你整个feature中某一个模块的实现草稿，它的好处是你可以及早发现代码的问题，并一次性把收到的feedback应用到这一模块的所有其他类似的地方。

比如，你需要用React开发一个页面的新功能，那么你可以先发一个CR，里面只包含了一个组件，但是包括了其需要的全部内容，比如styling，数据请求，状态管理等等。这样任何关于这个CR的反馈都可以被应用到之后所有其他组件上，相当于为其他组件树立了一种规范。

相反，如果你第一个CR里就写了10个组件，那同样的feedback你都必须把10个组件全部修改，直接浪费了10倍的时间和精力。你可以对每个模块都采用这样的“探照灯”方法，直到整个feature完成。

我们在coding interview的时候，都知道第一件事是clarification，然后告诉面试官自己的想法，面试官认可后才动手写代码。

这其实就是early visibility的一种体现。我们要将这种工作方式运用到每一次任务中，这让你和你的组员避免日后花额外的时间精力来弥补因为缺乏及时沟通导致的损失，让项目得以更安全、顺利地推动，最终deliver results。

多花10%的时间在前期沟通，让后面90%的工作收益，何乐而不为呢？

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。

来源: qq