解释一个概念:早期显示代码会让它更清晰吗?

+1到斯蒂恩,因为真的,这才是最重要的。

但是,这取决于你在做什么。你的“概念”是什么?

• API(如mapreduce)?

展示API的代码,不要浪费人们的时间在实现代码上,这并不重要-“嘿,看看我是如何迭代你的输入的!太聪明了。不。没人在乎。如果你的API很好,它就会被使用,没有人会在意它的代码有多粗糙。

• 产品(如facebook)?

显示代码?没人在乎。甚至facebook也不在乎(如果他们在乎,为什么要使用php?我是个孩子。用一个半完整原型的演示让他们大吃一惊,这个原型做了一些不好的事情,但是展示了它是多么的棒。

• std::sort 例行公事)?

很多人可能对看内脏感兴趣。尤其是在这上面的人。所以,当你得到一些有用的东西时,发布代码或者白皮书。这不是“我的twitter克隆会很可爱,看看我的微博有多酷” TruncateTo140Chars() 函数为!”。另一方面,您可以通过显示算法(在代码或伪代码中)快速获得有关新实现方法的反馈。您可以展示基准测试,这比“这段代码应该更快,因为我比零少做一个”。

照顾 关于。如果你的用户希望看到代码,只需要担心代码(通常不是这样)。

我喜欢概念证明这种不扯淡的方法。只要把他们的脚吹下来,证明它是有效的。

这取决于受众和产品的性质。如果受众和/或产品被认为是“技术性的”,那么就考虑呈现代码。但是,你应该让它成为演讲的一个组成部分,而不是全部。

我不认为尽早显示代码是很有用的。”我们的技术人员总是以展示我们新的技术细节和想法为荣。然而,使用这些产品和技术的人只关心他们能用它完成什么。他们通常不会分享您对技术的热情,在本例中是代码。

我的建议是坚持一个更普遍的方法,解释为什么它是有用的,以及它将如何使他们的生活更好。再加上一个汽车比喻:人们想知道它有多大马力,而不是内燃机是如何工作的!

但是,这些实现细节可能会让您的同事感兴趣!

人们害怕批评,当它已经编码,它更容易(和更便宜的)废纸模型,然后真正的东西。

当向其他开发人员展示一个概念时(如果他不明白的话),在纸上画出不同的类并展示它们之间的关系。如果你们都知道语法,UML在这里可能很有用。

否则,如果你有时间,我会说,用一个完整的实现把它们吹走:-)

利益相关者控制你想要提供什么功能(尽早发现这一点是提供有利可图/有用的东西的关键)。

但是为了提高代码质量,如果在正确的时间进行代码评审,那么代码评审是非常强大的。我的经验是,在迭代快结束的时候这样做是最划算的。在执行代码评审的最佳时间方面,您的里程数可能会有所不同(初级开发人员需要尽早评审,而高级开发人员通常需要等到以后再评审)。