Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.
Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...
My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.
Encryption's always been the prototypical example of this. But it extends to other areas as well.
Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.
It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.
Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.
"What functionality should always be third-party?"
None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.
Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.
Going third party is a decision that should be made based on
Cost of going third party vs cost of doing it in house
Development time required placed against deadlines (ie, it might be cheaper inhouse, but your development timeline might not allow it regardless)
Ease of integration, debugging, maintenance, upgrade paths - it may be that you can develop something that will "do the job, but barely" inhouse vs not much more money for something that will take care of you for years to come
Ease/cost of testing and proving - security packages are notoriously difficult to test well
However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.
In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.
But "What functionality should always be third-party?" None. There's always an exception.
I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.
It depends. Is there a 3rd party library available that suits your needs and most importantly, the language and/or API you work with. Then go for it.
If you have reasons to do your own version, make sure it's not just "not invented here". Also, if you haven't had an in depth look at the market's top five leading products for whatever you need, you haven't done your job thoroughly enough. There are good chances you will find what you are looking for, and even if you can't use it, you still learn something even from the library descriptions. At the minimum you will learn which features you would need and which you don't. If you also get the source code to one of the libraries, this should be your preferred choice over a competing library with no source code but possibly more features.
The area where I have consistently used third party controls was charting. It is a fairly common problem to have to chart some batch of data and the third party controls are mature and trustworthy.
当然，有时我们做这类事情时甚至不考虑将其视为组件购买。 稍微发挥一下想象力，您可以包括 .NET 框架、SQL Server、Windows API 等。
I guess the answer depends upon the usage. If you are developing for profit, you would be likely to buy in components if the cost of using the component vs the cost of developing it results in more profit. This is particularly the case with large components when you do not have the in-house expertise to produce them.
A couple of good examples that I have used are the Infragistics controls and Dundas charts. Although we could have created these in-house, the costs in terms of time and lost opportunity would be huge compared to buying a couple of licenses.
Of course, sometimes we do this type of thing without even considering it as a component purchase. Streching the imagination a little, you could include the .NET framework, SQL Server, the Windows API, etc.
There is not a definitive answer to this question because just like anything else in software development it depends on the situation. I would say that if the following 3 items are true than you shouldn't think about doing it yourself...
If it's not core to your business or expertise.
If someone else has written it for you and it is being used in widespread communities.
If it meets your needs and requirements or it can be extended to meet your requirements fairly easily.
This question is the inverse of the question: what software should you create?
Which is obviously silly.
For both there is no one answer, it depends on the needs of your business. Do you need to build a better search engine for the entire internet? Almost certainly not. But if you are Google in the late 90s, you do. 3rd vs. 1st party is just a matter of which office you work in, every 3rd party is a 1st party to themselves.
If all you need is good enough: use something off the shelf.
Either you'll create something lower quality or you'll waste money and effort on something that doesn't matter that much, or both.
If it's the foundation of your business: build it yourself.
If you can build something better, and you can build a business out of that better thing, then do!
Don't forget that the time is a big issue for writing all things by your hand, it is not that you cannot do that but the problem comes from your customers or company they always want to find the fastest way to build their system. But if you have a non-profit project you can try building things by yourself. For e.g you can use JQuery or Dojo as your ajax toolkit if you are writing web applications and you want to set some ajax functionality, it will take time to build those things by your hand :)
But you also must be careful when using a third-party libraries, you must trust them because they can contain malicious code, or they are very poorly written and can cause you headache.
Your own encryption function? dont even think about it but I think you probably meant some kind of wrapper for existing functions.
3rd party component advantages: Alot of functionality
Fully tested (hopefully!)
Doesnt take time to develop so can be cheaper (but..)
Disadvantages
Is it really flexible enough for that next akward customer requirement
Distribution can be expensive
Ties you into 3rd party company which can be a pain when they make a new release to fix bugs
You dont learn to do the task yourself
Whether you use a third party component is going to depend on your application and the requirements. Something like graphing is going to take ages to get right so would be a good third party component to use.
Anything that is outside your core business is a good candidate for third party solutions. You want to spend your development time creating that core functionality that is unique(ish) and can not be purchased and used in a cost effective manor.
For example, lets look at web gridview control. Can you develop and extend a gridview yourself? Sure you can, but to develop, code, and test you grid view is going to take X amount of time and resources, which you can translate in to dollars. Now you have factor in reoccurring costs for support, maintenance, and bug fixes.
Now lets use the arbitrary amount I remember reading in some mag about the average US developer making $40 per hour including their benefits. There are whole web control suites available for around another approximated $800 per developer license. If your developer spends more than say 25 hours total on this one control, you could have purchased a whole suite and spent 5 hours integrating and testing.
Now hopefully I didn't get too confusing there, but the general gist is if you can buy it off the self it will probably save time and money, and instead focus on things you can't get off the self which are usually your money makers.
I'd say for writing boiler plate code, or redundant code which is copy and paste almost every time should be done through a library. For me, validation code almost always has me making stupid mistakes, because it's boring. Spring.NET is amazing for this. I'm so glad my boss encouraged me to try it.
seems you have all the answers you need, but i would just like to throw my opinion in here along with everyone else's. clients pay you to make applications that work specifically for them, and that's usually why they go to you; something they need isn't found in any other product on the market. thus, your focus should be on developing that specific part they need.
undoubtedly your application will need to do other things as well. maybe it will need to connect to a database, or encrypt certain lines. this is where third-party libraries come into play. you don't want to waste time writing a new driver for a database, or a new encryption scheme that might have holes you don't have time to test. you want to use the ones that already exist, and have been extensively tested and optimized.
remember, the faster you finish, the less they will have to pay. this makes them happy and want to come back to you. this also means you make more because even though they pay less, you can work on more projects, which means more money.
in conclusion, you should rely on third-party libraries in miscellaneous modules.
发布评论
评论（15）
大多数时候加密应该是第三方的，除非您从事销售加密系统的业务。
据我了解，这几乎就是阿特伍德先生的观点，你的核心业务不应该是第三方，所以可能没有什么东西应该始终是第三方......
Encryption should be third party most of the times, ...unless you're in the business of selling encryption systems.
Which is pretty much Mr. Atwood his point as I understood it, your core busines shouldn't be third party, so there's probably nothing that should always be third party...
我的经验法则是使用（或至少考虑）第三方来处理业务核心目的之外的任何事情。
加密一直是这方面的典型例子。 但它也延伸到其他领域。
在开发过程中编写用于故障排除的日志记录代码与编写用于监视生产系统的日志记录代码完全不同。
这一切都是为了选择哪些开发领域能够真正为您的项目增加价值。 使用第三方的东西可以消除该组件不完整/有缺陷等的风险。 但随之而来的风险是它可能不如您所需要的那么灵活。
另一个例子是为网站开发整个网络论坛，此时您可以以更便宜的价格购买解决方案。
My rule of thumb is to use (or at least consider) third-party for anything that's outside the core purpose of your business.
Encryption's always been the prototypical example of this. But it extends to other areas as well.
Writing logging code for troubleshooting during development is entirely different than writing logging code used for monitoring production systems.
It's all about choosing which areas of development actually add value to your project. Using third-party stuff removes the risk that that component is incomplete/buggy/etc. but comes with the risk that it may not be as flexible as what you need.
Another example would be developing an entire web forum for a website, when you can buy a solution for much cheaper.
“哪些功能应该始终由第三方提供？”
没有任何。 在讨论本质上的工程决策时，总会有例外或特殊情况来推翻“总是”的过分使用。
此外，几乎永远不应该根据给定的“功能”做出选择第三方的决定。 不存在这样的完美库，您无需去其他任何地方即可获得该类型的功能。
是否选择第三方是一个决定，应根据
但是。 有些事情确实很难相信进入内部会更好。 例如，您可以编写 OpenGL 和 DirectX 的竞争对手，并且在某些应用程序（科学计算等）中，有充分的理由考虑这样的路径。 但一般来说你不会梦想到这一点。 尽管它是“免费的”，但它仍然是第三方依赖项，并且您可能会因为一个仅影响您如何使用这些图形语言的错误而陷入困境。
换句话说，存在一些极其复杂或难以证明/测试的东西，这些东西几乎总是应该交给第三方。 安全是另一回事。 不要编写自己的哈希算法，除非您 1) 确实疯狂并且 2) 至少有 3 个极好的商业理由这样做。
但是“哪些功能应该始终是第三方的？” 没有任何。 总有例外。
-亚当
"What functionality should always be third-party?"
None. there is always an exception or special case to overrule the egregious use of "always" when discussing an essentially engineering decision.
Further, the decision to go third party should almost never be made on basis of a given "functionality." There is no such thing as such a perfect library that you never need go anywhere else for that type of functionality.
Going third party is a decision that should be made based on
However. There are some things where it's really tough to believe that going in house is better. For instance, you can write a competitor to OpenGL and DirectX, and in certain applications (scientific computing, etc) there are good reasons for considering such a path. But in general you wouldn't dream of it. Even though it's "free" it's still a third party dependency, and you could end up on the skids because of a bug which only affects how you use these graphics languages.
In other words, some incredibly complex or hard to prove/test things exist which should almost always go to a third party. Security is another one. Don't write your own hashing algorithm unless you are 1) certifiably crazy and 2) have at least 3 excellent business reasons to do so.
But "What functionality should always be third-party?" None. There's always an exception.
-Adam
我完全同意加密应该尽可能由专家来完成。 它还应该是开源的，并且经过了大量的同行评审。
I fully agree that encryption should only be done by experts whenever possible. It should also be open source and have undergone a good deal of peer review.
这取决于。 是否有可用的第 3 方库可以满足您的需求，最重要的是，满足您使用的语言和/或 API。 然后就去做吧。
如果您有理由制作自己的版本，请确保它不仅仅是“不是在这里发明的”。 此外，如果您还没有深入了解市场上排名前五的领先产品来满足您的需求，那么您的工作就做得不够彻底。 您很有可能找到您正在寻找的东西，即使您不能使用它，您仍然可以从库描述中学到一些东西。 至少您将了解哪些功能是您需要的，哪些是不需要的。 如果您还获得了其中一个库的源代码，那么与没有源代码但可能有更多功能的竞争库相比，这应该是您的首选。
It depends. Is there a 3rd party library available that suits your needs and most importantly, the language and/or API you work with. Then go for it.
If you have reasons to do your own version, make sure it's not just "not invented here". Also, if you haven't had an in depth look at the market's top five leading products for whatever you need, you haven't done your job thoroughly enough. There are good chances you will find what you are looking for, and even if you can't use it, you still learn something even from the library descriptions. At the minimum you will learn which features you would need and which you don't. If you also get the source code to one of the libraries, this should be your preferred choice over a competing library with no source code but possibly more features.
我一直使用第三方控件的领域是图表。 必须对一批数据进行图表化是一个相当普遍的问题，并且第三方控件是成熟且值得信赖的。
The area where I have consistently used third party controls was charting. It is a fairly common problem to have to chart some batch of data and the third party controls are mature and trustworthy.
我想答案取决于用途。 如果您的开发是为了盈利，如果使用组件的成本与开发组件的成本相比可以带来更多利润，那么您可能会购买组件。 当您没有内部专业知识来生产大型组件时，尤其如此。
我使用过的几个很好的例子是 Infragistics 控件和 Dundas 图表。 尽管我们可以在内部创建这些，但与购买几个许可证相比，时间成本和失去的机会将是巨大的。
当然，有时我们做这类事情时甚至不考虑将其视为组件购买。 稍微发挥一下想象力，您可以包括 .NET 框架、SQL Server、Windows API 等。
I guess the answer depends upon the usage. If you are developing for profit, you would be likely to buy in components if the cost of using the component vs the cost of developing it results in more profit. This is particularly the case with large components when you do not have the in-house expertise to produce them.
A couple of good examples that I have used are the Infragistics controls and Dundas charts. Although we could have created these in-house, the costs in terms of time and lost opportunity would be huge compared to buying a couple of licenses.
Of course, sometimes we do this type of thing without even considering it as a component purchase. Streching the imagination a little, you could include the .NET framework, SQL Server, the Windows API, etc.
如果您购买它的成本比构建它的成本低，并且购买的功能满足您的业务需求，那么就购买它。
If you can buy it cheaper than you can build it, and the bought functionality meets your business requirements, then buy it.
这个问题没有明确的答案，因为就像软件开发中的其他任何事情一样，它取决于具体情况。 我想说，如果以下三点是正确的，那么您就不应该考虑自己做……
There is not a definitive answer to this question because just like anything else in software development it depends on the situation. I would say that if the following 3 items are true than you shouldn't think about doing it yourself...
这个问题与以下问题相反：您应该创建什么软件？
这显然是愚蠢的。
对于这两者没有一个答案，这取决于您的业务需求。 您需要为整个互联网建立一个更好的搜索引擎吗？ 几乎可以肯定不是。 但如果你是 20 世纪 90 年代末的 Google，你就会这么做。 第三方与第一方只是您在哪个办公室工作的问题，每个第三方都是他们自己的第一方。
您要么会创造出质量较低的东西，要么会在无关紧要的东西上浪费金钱和精力，或者两者兼而有之。
如果您可以构建更好的东西，并且您可以利用更好的东西建立业务，那就去做吧！
This question is the inverse of the question: what software should you create?
Which is obviously silly.
For both there is no one answer, it depends on the needs of your business. Do you need to build a better search engine for the entire internet? Almost certainly not. But if you are Google in the late 90s, you do. 3rd vs. 1st party is just a matter of which office you work in, every 3rd party is a 1st party to themselves.
Either you'll create something lower quality or you'll waste money and effort on something that doesn't matter that much, or both.
If you can build something better, and you can build a business out of that better thing, then do!
不要忘记，对于用手写所有东西来说，时间是一个大问题，并不是说你不能这样做，而是问题来自于你的客户或公司，他们总是想找到最快的方法来构建他们的系统。 但如果您有一个非营利项目，您可以尝试自己构建东西。 例如，如果您正在编写 Web 应用程序并且想要设置一些 ajax 功能，那么您可以使用 JQuery 或 Dojo 作为您的 ajax 工具包，那么您需要花一些时间来手动构建这些东西:)
但是在使用第三种方法时您也必须小心-party 库，你必须信任它们，因为它们可能包含恶意代码，或者它们写得非常糟糕，可能会让你头疼。
Don't forget that the time is a big issue for writing all things by your hand, it is not that you cannot do that but the problem comes from your customers or company they always want to find the fastest way to build their system. But if you have a non-profit project you can try building things by yourself. For e.g you can use JQuery or Dojo as your ajax toolkit if you are writing web applications and you want to set some ajax functionality, it will take time to build those things by your hand :)
But you also must be careful when using a third-party libraries, you must trust them because they can contain malicious code, or they are very poorly written and can cause you headache.
你自己的加密功能？ 甚至不用考虑它，但我认为您可能指的是现有函数的某种包装器。
3rd 方组件优点：
很多功能
全面测试（希望如此！）
不需要时间开发，所以可以更便宜（但是..）
缺点
它真的足够灵活以满足下一个棘手的客户需求吗
分销可能会很昂贵
将您与第 3 方公司联系起来，当他们发布新版本来修复错误时，这可能会很痛苦
您不需要学习自己完成任务
您是否使用第三方组件将取决于您的应用程序和要求。 像绘图这样的东西需要很长时间才能正确，因此将是一个很好的第三方组件。
Your own encryption function? dont even think about it but I think you probably meant some kind of wrapper for existing functions.
3rd party component advantages:
Alot of functionality
Fully tested (hopefully!)
Doesnt take time to develop so can be cheaper (but..)
Disadvantages
Is it really flexible enough for that next akward customer requirement
Distribution can be expensive
Ties you into 3rd party company which can be a pain when they make a new release to fix bugs
You dont learn to do the task yourself
Whether you use a third party component is going to depend on your application and the requirements. Something like graphing is going to take ages to get right so would be a good third party component to use.
核心业务之外的任何事物都是第三方解决方案的良好候选者。 您希望花费开发时间来创建独特的核心功能，并且无法以具有成本效益的方式购买和使用。
例如，让我们看一下 Web gridview 控件。 您可以自己开发和扩展 gridview 吗？ 当然可以，但是开发、编码和测试网格视图将花费 X 量的时间和资源，这些时间和资源可以转化为美元。 现在，您需要考虑支持、维护和错误修复的重复成本。
现在让我们使用我记得在一些杂志上读到的任意金额，美国开发人员平均每小时赚取 40 美元，包括他们的福利。 整个 Web 控制套件的价格约为每个开发人员许可证 800 美元。 如果您的开发人员在这个控件上花费的时间总计超过 25 小时，您本可以购买一整套套件并花费 5 小时进行集成和测试。
现在希望我没有太困惑，但总的要点是，如果你可以从自己那里购买它，它可能会节省时间和金钱，而是专注于你无法从自我那里得到的东西，通常是你的钱制造商。
Anything that is outside your core business is a good candidate for third party solutions. You want to spend your development time creating that core functionality that is unique(ish) and can not be purchased and used in a cost effective manor.
For example, lets look at web gridview control. Can you develop and extend a gridview yourself? Sure you can, but to develop, code, and test you grid view is going to take X amount of time and resources, which you can translate in to dollars. Now you have factor in reoccurring costs for support, maintenance, and bug fixes.
Now lets use the arbitrary amount I remember reading in some mag about the average US developer making $40 per hour including their benefits. There are whole web control suites available for around another approximated $800 per developer license. If your developer spends more than say 25 hours total on this one control, you could have purchased a whole suite and spent 5 hours integrating and testing.
Now hopefully I didn't get too confusing there, but the general gist is if you can buy it off the self it will probably save time and money, and instead focus on things you can't get off the self which are usually your money makers.
我想说，编写样板代码或几乎每次都复制和粘贴的冗余代码应该通过库来完成。 对我来说，验证代码几乎总是让我犯愚蠢的错误，因为它很无聊。 Spring.NET 在这方面非常出色。 我很高兴我的老板鼓励我尝试一下。
I'd say for writing boiler plate code, or redundant code which is copy and paste almost every time should be done through a library. For me, validation code almost always has me making stupid mistakes, because it's boring. Spring.NET is amazing for this. I'm so glad my boss encouraged me to try it.
看来你已经有了你需要的所有答案，但我只想在这里和其他人一起发表我的观点。 客户付钱让你制作专门为他们工作的应用程序，这通常就是他们去找你的原因； 他们需要的东西在市场上的任何其他产品中都找不到。 因此，您的重点应该是开发他们需要的特定部分。
毫无疑问，您的应用程序还需要执行其他操作。 也许它需要连接到数据库，或加密某些行。 这就是第三方库发挥作用的地方。 您不想浪费时间为数据库编写新的驱动程序，或者可能存在您没有时间测试的漏洞的新加密方案。 您想要使用已经存在的、并且已经过广泛测试和优化的。
请记住，您完成得越快，他们需要支付的费用就越少。 这让他们很高兴并想回到你身边。 这也意味着你赚得更多，因为即使他们付的钱更少，你也可以从事更多的项目，这意味着更多的钱。
总之，您应该依赖各种模块中的第三方库。
seems you have all the answers you need, but i would just like to throw my opinion in here along with everyone else's. clients pay you to make applications that work specifically for them, and that's usually why they go to you; something they need isn't found in any other product on the market. thus, your focus should be on developing that specific part they need.
undoubtedly your application will need to do other things as well. maybe it will need to connect to a database, or encrypt certain lines. this is where third-party libraries come into play. you don't want to waste time writing a new driver for a database, or a new encryption scheme that might have holes you don't have time to test. you want to use the ones that already exist, and have been extensively tested and optimized.
remember, the faster you finish, the less they will have to pay. this makes them happy and want to come back to you. this also means you make more because even though they pay less, you can work on more projects, which means more money.
in conclusion, you should rely on third-party libraries in miscellaneous modules.