解释一个概念：尽早展示代码是否会让代码变得更清晰？
相信这是很多人感兴趣的问题，欢迎大家讨论！ :-)
现在，想象一下您想向您的同事展示未来发展的概念（例如您想要引入的新产品或新技术）。
尽早展示代码是否有意义，还是先展示 PPT？或者你会推荐什么？
I guess this is a question that may interest many, so please discuss! :-)
Now, imagine you want to show people you work with a concept for future development (like a new product or a new technology you want to introduce).
Does it make sense to show code early or would you go with the PPT first? Or what would you recommend?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
给 Stijn +1，因为真的，这才是最重要的。
但是，这实际上取决于您在做什么。你的“概念”是什么？
显示 API 的代码，不要在实现代码上浪费人们的时间，这并不重要 - “嘿，看看我是如何迭代你的输入的！这太聪明了！”。没有。没人关心。如果你的 API 很棒，它就会被使用，没有人关心让它工作的代码有多糟糕。
显示代码？没人关心。甚至 facebook 也不关心（如果他们关心的话，他们为什么要使用 php？我开玩笑！）。半成品原型的演示让他们大吃一惊，虽然有些地方做得很差，但展示了它有多么出色。
很多人可能有兴趣看看内部结构。尤其是SO上的人。因此，当您开始工作时，请发布代码或白皮书。这不是“我的 Twitter 克隆会很甜蜜，看看我的
TruncateTo140Chars()函数有多酷！”。另一方面，您可以通过显示您的算法（以代码或伪代码形式）来获得有关新实现方法的快速反馈。您可以显示基准测试，这比“此代码应该更快，因为我与零进行比较少了一个”要好。请只是制作原型，进行一些您的用户会关心的演示。仅当您的用户希望看到代码时才需要担心代码（通常不是）。
+1 to Stijn, because really, that's all that matters.
But, it really depends on what you're doing. What is your "concept"?
Show the code of the API, don't waste people's time with the implementation code, that's not important - "hey, check out how I iterate over your input! it's so clever!". Nope. Nobody cares. If your API is wonderful, it will get used, nobody cares how crufty the code is to make it work.
Show the code? Nobody cares. Not even facebook cares (if they did, why would they use php? I kid!). Blow their mind with a demo of the half-complete prototype that does a few things poorly, but shows how great it can be.
std::sortroutine)?A lot of people might be interested in seeing the innards. Especially people on SO. So, publish the code, or a whitepaper, when you get something working. It's not "my twitter clone is gonna be sweet, check out how cool my
TruncateTo140Chars()function is!". On the other hand, you can get quick feedback on your new implementation's approach by showing your algorithm (in code or pseudocode). You can show benchmarks, which is better than "this code should be faster because I do one less compare with zero".Please just prototype, get something demo'd that your Users will care about. Only worry about the code if that's what your users want to see (It's usually not).
我喜欢这种没有废话的概念验证方法。只要让他们大吃一惊并证明它有效即可。
I like the no-bullshit approach of a proof of concept. Just blow them off their feet and prove that it works.
这取决于受众和产品的性质。如果观众和/或产品被认为是“技术性的”，那么请考虑呈现代码。但是，您应该将其作为演示文稿的组成部分而不是全部。
It depends on the audience and the nature of the product. If the audience and/or product is considered "technical" than consider presenting code. However, you should make it an integral part of the presentation not the entire thing.
我认为尽早展示您的代码并不是很有用。 “我们”的技术人总是自豪地展示我们新的技术细节和想法。然而，使用这些产品和技术的人们只对他们能用它完成什么感兴趣。他们通常不会分享您对技术（在本例中是代码）的热情。
我的建议是坚持采用更通用的方法，解释为什么它有用以及它将如何让他们的生活变得更好。打个汽车比喻：人们想知道它有多少马力，而不是内燃机如何工作！
然而，您的同事可能会对这些实施细节感兴趣！
I don't believe it is very useful to show your code early. "Us" technical people are always proud to show off our new technical details and ideas. However, people using the products and technologies are only interested in what they can accomplish with it. They will often not share your enthousiasm of the techniques, in this case the code.
My advice is to stick with a more general approach, explain why it's useful and how it will make their lives better. To add a car-analogy: people want to know how much horse-power it has, not how a combustion-engine works!
These implementation-details might however be interesting to your co-workers!
如果真的不是技术人员，那么我发现纸模型效果很好。
当它被编码时，人们害怕批评，废弃纸质模型比废弃真实的模型更容易（也更便宜）。
当向非技术人员展示网站/应用程序的概念时，绘制不同的页面、登录对话框等。
当向其他开发人员展示概念时（如果他只是不明白），在纸上绘制不同的类并显示的关系。如果你们都知道语法，那么 UML 在这里可能会很有用。
否则，如果你有时间，我会说，通过完整的实施让他们震惊:-)
If it really isn't tech people at all, then I have found out that paper models works great.
People are scared to criticize when it has been coded, it much easier (and cheaper) to scrap a paper model then the real thing.
When showing a concept of a website/application to a non tech, draw the different pages, the login dialogs etc.
When showing a concept to a fellow developer (if he just don't get it) draw the different classes on paper and show the relations. UML could be useful here if both of you know the syntax.
Else if you got the time, I would say, blow them away with a full implementation :-)
我同意 rtalbot 的观点。如果观众不是技术人员，也许是未来的用户，或者你的老板，我会用一些图表。也许是用例。向他们展示你可以用它做什么。如果它很小，并且您的朋友很书呆子，请编写一个烟雾和镜子演示。
I agree with rtalbot. If the audience is non-technical, perhaps future users, or your boss, I'd go with some diagrams. Perhaps Use Cases. Show them what you can do with it. If it's small, and your friends are nerdy, code up a smoke-and-mirrors demo.
尽早向客户/利益相关者展示原型，然后在同行中审查代码。
利益相关者控制您想要提供的功能（尽早发现这一点是提供有利可图/有用的东西的关键）。
但为了提高代码质量，如果在正确的时间进行代码审查，其作用将非常强大。我的经验是，在迭代结束时这样做可以提供最大的经济效益。您的里程可能会因执行代码审查的最佳时间而异（初级开发人员需要尽早且经常进行审查，高级开发人员通常可以稍后进行审查）。
Show customers / stake holders the prototypes early, and review the code among peers later.
Stake holders control what functionality you want to deliver (finding this out early is key to delivering something profitable / useful).
But to increase code quality, code reviews are extremely powerful if done at the right time. My experience has been that doing this towards the end of an iteration provides the most bank for the buck. Your mileage may vary in terms of the optimum time to perform code review (junior devs need review early and often, senior devs are usually fine until later).