如何与认为框架对性能有影响的同事进行沟通

当常见的响应是一个笼统的声明，例如“ jquery”时，如何出售“我们应该使用jQuery，因为它的高度优化和跨浏览器兼容”或“实体框架很酷，因为它简洁并且可以自动处理我们的模型”这样的想法表现不佳”还是“当我们只需要10个实体时，表中的实体就会带来12列”？

我是一个务实的人，倾向于相信我通过经验开发的公理（除非出现明显的减速，否则它不是性能问题）。我不知道另一个极端是否适合某个特定的“类别”，而在没有其他证明之前，一切都是性能问题……甚至在这里开始沟通。

给他们带来困难的事实！

例如，存在针对ORM和JS框架的性能基准。最重要的是，所有框架和ORM在其主页上都有很好的卖点。

阅读您的评论后，我相信您的问题不是正确的技术，而是那些拒绝学习新技术的人。

我以前遇到过这个问题，人们想重新发明轮子。我通常向他们解释，如果我们花时间完善重要的东西，而不是完善下面的东西，我们可以使产品更好，更精致。另外...我的意思是说，有一个原因可以使用框架，而如今，性能实际上已不再是一个大问题。可靠性更为重要，如果框架具有良好的评价/评估，那么它们可能比任何人都可以即时弥补的可靠性更高。

每个人似乎都不同意您的同事，但我认为，如果除了理解他的观点之外，没有其他原因，您应该认真对待他的论点。当您需要框架或它们实际提供优化时，我坚定地相信框架，但我也相信，在某些情况下，过度依赖框架会导致开发疲软。

我认为您应该从解决同事错误的角度出发而不是从解决问题的角度出发，而应该从正在考虑的框架的使用会缩短开发时间，性能，维护等角度来解决问题。

我总是尽量记住使用正确的工具来完成正确的工作。我不需要一个12磅的雪橇（jQuery）来钉一个钉子来悬挂图片（图像交换）。但是，如果遇到挂有需要铁路尖峰钉在墙上的图片的情况，我最好准备好要放的雪橇。

他是对的，有开销

但是，假设框架的开销大于手工编码的解决方案的假设可能是不正确的，即使它是正确的，开销也可能不大。

提出测试：

• 你们俩都写一些现实但相对较小的东西
• 你使用jQuery（或其他），他什么也不能使用
• 测量两件事：
  1. 你们两个都花多长时间编码解决方案（假设您的编码技能是等效的）
  2. 每个解决方案执行（完整生命周期）需要多长时间

有机会，会有一个小的开销与框架- 非常小-但一个巨大的 [！和调试在它需要的代码多久差异的解决方案

然后您的朋友可以与事实争论，而不是与您争论

注意：要做好抵抗的准备；很多时候，对框架的回退都是用技术术语来表达的，但实际上是“在这里未发明”或“我不想学习其他工具”的烟幕。

提醒您的车轮革新同事，他正在做的事情是各种过早的优化。他怎么知道在证明这些框架会引起问题之前，这些框架对性能造成了不可接受的影响。同时，由于必须做的所有额外工作，您的相互生产力肯定会下降。

当您不使用其中一些省时且经过考验的巨大框架时，如何解释性能对项目交付时间的影响呢？

一种选择是告诉他，他要负责性能调优-如果可以显示出性能问题！或者，如果您有足够的资源，请构建两个概念证明：您使用jQuery构建您的概念，以及您想要的所有其他内容。他可以使用自己的手动超快系统构建自己的系统。不要让这种情况持续超过几天（这是概念验证），而要看看谁在最后表现更好。

当然，正如其他人所提到的，请为论证的两面都提供一些实际数字和性能概况。

首先，他可能适合您的具体情况。

既然您似乎无法让他看看您的观点，那么您需要做得更好以说服他。

你们两个在“构建”和“购买”之间的两个不同点上。这是一条很长的线。左侧是“构建”中的SpaceX，它必须构建整个行业。在右侧，在“购买”中，您已将所有IT功能完全外包给了IBM，HP等，而企业根本不进行编码。你们两个在中间，相距约2毫米。你们俩都必须说服管理层，您对框架和orm之类的“构建与购买”之类的方法（通过“购买”，我的意思是“非内部构建”）符合公司的最佳利益，长期以来-术语。如果将Twitter外包给IBM，Twitter将会死亡。他们自己滚了。考虑一下。

无论哪种方式，管理人员都需要离开高尔夫球场，进入那里并完成工作。

对于ORM来说，答案是“只有以这种方式编写查询，对于SQL来说，可以说相同”。正如其他人所说，困难的事实就是您所需要的。

另外，请问一些具体问题以探究他的话-“能否给我一个JQuery无法执行的示例，因为那不是我的经验”。

第三种选择是一个明智的老开发人员向我提出的建议，无论如何都只包含“事物”（假设它没有不好的问题）。

寻求批准只会导致答案为“否”。将其放到那里，然后您可以要求他们指向特定区域，并让他们告诉您问题出在哪里。

“嘿，这个EF代码只会从该表中带回2个所需的数据项，这是什么问题”等。

显然，在继续使用此方法之前，您需要对自己和所使用的工具充满信心！:-)

很好地拒绝这样的库是愚蠢的，有时是自大的。产品时间花费在这些上以及它们背后的思想使得拒绝它们简直是多余的。

尽管您需要比较并超越软件的需求，但这可能是您的同事是正确的，而这是设计的一部分。可能是ORM或ActiveRecord解决方案在很大程度上是矫kill过正，或者相反，该软件需要真正耦合的DB解决方案，而ORM不会削减它。

每次设计软件时，考虑这些因素都很重要。

对于客户端库，我不得不说这是愚蠢的，因为您总是可以找到适合您需求的框架。就像我之前说过的，有什么比经过战斗验证的框架更好？

让他从所有跨浏览器问题中解脱出来，他将就如何使用框架方面向您表示愿意。

顺便说一句，我曾经有一个老板，他没有对框架负责。我只是向他展示了发出ajax请求而不是一次又一次地复制函数（这是一个愚蠢的想法）是多么容易，他不知道如何编写代码。