mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
translated
This commit is contained in:
heguangzhi
parent
78abe8a55b
commit
33901e1834
@ -1,74 +0,0 @@
|
|||||||
heguangzhi Translating
|
|
||||||
|
|
||||||
[#]: collector: (lujun9972)
|
|
||||||
[#]: translator: ( )
|
|
||||||
[#]: reviewer: ( )
|
|
||||||
[#]: publisher: ( )
|
|
||||||
[#]: subject: (How to use multiple programming languages without losing your mind)
|
|
||||||
[#]: via: (https://opensource.com/article/18/11/multiple-programming-languages)
|
|
||||||
[#]: author: (Bart Copeland https://opensource.com/users/bartcopeland)
|
|
||||||
[#]: url: ( )
|
|
||||||
|
|
||||||
How to use multiple programming languages without losing your mind
|
|
||||||
======
|
|
||||||
A polyglot environment is a double-edged sword, bringing benefits along with complexities that may threaten the organization.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
With all the different programming languages available today, many organizations have become digital polyglots. Open source opens up a world of languages and technology stacks developers can use to accomplish their tasks, including developing and supporting legacy and modern software applications.
|
|
||||||
|
|
||||||
Polyglots can talk with millions more people than those who only speak their native language. In software environments, developers don't introduce new languages to achieve specifc ends, not to communicate better. Some languages are great for one task but not another, so working with multiple programming languages enables developers to use the right tool for the job. In this way, all development is polyglot; it's just the nature of the beast.
|
|
||||||
|
|
||||||
The creation of a polyglot environment is often gradual and situational. For example, when an enterprise acquires a company, it takes on the company's technology stacks—including its programming languages. Or as tech leadership changes, new leaders may bring different technologies into the fold. Technologies also fall in and out of fashion, expanding the number of programming languages and technologies an organization has to maintain over time.
|
|
||||||
|
|
||||||
A polyglot environment is a double-edged sword for enterprises, bringing benefits but also complexities and challenges. Ultimately, if the situation remains unchecked, polyglot will kill your enterprise.
|
|
||||||
|
|
||||||
### Tricky technical tongue-twisters
|
|
||||||
|
|
||||||
Where there are multiple different technologies—programming languages, legacy tools, and up-and-coming technology stacks—there is complexity. Engineering teams spend more time wrestling to retrofit programming languages with licenses, security, and dependencies. At the same time, management lacks oversight on code compliance and can't gauge risk.
|
|
||||||
|
|
||||||
What happens is that enterprises have varying degrees of programming language quality and high variability in tooling support. It's hard to become an expert in one language when you're required to work with a dozen. There's a big difference in skill level between a person who speaks French and Italian fluently and a person who can string a few sentences together in eight languages. The same is true for developers and programming languages.
|
|
||||||
|
|
||||||
The difficulties only increase with the addition of more programming languages, leading to a digital Tower of Babel.
|
|
||||||
|
|
||||||
The answer is not to take away the tools your developers need for the job. Adding new programming languages builds their skill base and empowers them with the right equipment to fulfill their craft. So, you want to say "yes" to your developers, but as more and more programming languages are added to the enterprise, they impose a drag on your software development lifecycle (SDLC). At scale, all these languages and tools can kill the enterprise.
|
|
||||||
|
|
||||||
There are three main issues enterprises should pay attention to:
|
|
||||||
|
|
||||||
1. **Visibility:** Teams come together for a project, then disband. Applications are released and never updated—why fix what's not broken? As a result, when a critical vulnerability is discovered, the enterprise may not have visibility into which applications are affected, which libraries those applications contain, or even what languages they were built with. This can result in costly "exploration projects" to ensure the vulnerability is properly addressed.
|
|
||||||
2. **Updating or coding:** Some enterprises centralize the updating and fixing function in a single team. Others require that each "pizza team" manage its own development tools. In either case, the engineering team and management pay an opportunity cost: rather than coding new features, these teams are constantly updating and fixing libraries in their open source tools since they move so quickly.
|
|
||||||
3. **Reinventing the wheel:** Since code dependencies and library versions are constantly being updated, the artifacts associated with the original build of an application may no longer be available when a vulnerability is found. As a result, many development cycles are wasted trying to recreate an environment in which the vulnerability can be fixed.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Multiply each programming language in your organization by these three issues, and what started out as a molehill suddenly looks like Mount Everest. And just like a mountain climber, you won't survive without the proper equipment and tools.
|
|
||||||
|
|
||||||
### Finding your Rosetta Stone
|
|
||||||
|
|
||||||
A comprehensive solution that serves the needs of the enterprise and its individual stakeholders in the SDLC is in order. Enterprises can create this solution using these best practices:
|
|
||||||
|
|
||||||
1. Monitor code running in production and respond based on risk of flagged components (e.g., common vulnerabilities and exposures components) used in your applications.
|
|
||||||
2. Receive regular updates to keep code current and bug-free.
|
|
||||||
3. Use commercial open source support to get help with programming language versions and platforms that are near end-of-life and not supported by the community.
|
|
||||||
4. Standardize specific programming language builds across your enterprise to enable consistent environments across teams and minimize dependencies.
|
|
||||||
5. Set thresholds for when to trigger an update, alarm, or another kind of event based on dependencies.
|
|
||||||
6. Create a single source of truth for your package management; this may require the assistance of a knowledgeable technology provider.
|
|
||||||
7. Get smaller build distributions with only the packages you need, based on your specific criteria.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Using these best practices, developers can maximize their time to create more value for the enterprise instead of doing basic tooling or build-engineering tasks. This will create code consistency in all environments in the software development life cycle (SDLC). It will also create greater efficiency and cost savings as fewer resources are needed to maintain programming languages and package distributions. This new way of operating will make the lives of both technical staff and management easier.
|
|
||||||
|
|
||||||
--------------------------------------------------------------------------------
|
|
||||||
|
|
||||||
via: https://opensource.com/article/18/11/multiple-programming-languages
|
|
||||||
|
|
||||||
作者：[Bart Copeland][a]
|
|
||||||
选题：[lujun9972][b]
|
|
||||||
译者：[heguangzhi](https://github.com/heguangzhi)
|
|
||||||
校对：[校对者ID](https://github.com/校对者ID)
|
|
||||||
|
|
||||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|
||||||
|
|
||||||
[a]: https://opensource.com/users/bartcopeland
|
|
||||||
[b]: https://github.com/lujun9972
|
|
||||||
@ -0,0 +1,89 @@
|
|||||||
|
heguangzhi Translating
|
||||||
|
|
||||||
|
[#]: collector: (lujun9972)
|
||||||
|
[#]: translator: (heguangzhi)
|
||||||
|
[#]: reviewer: ( )
|
||||||
|
[#]: publisher: ( )
|
||||||
|
[#]: subject: (How to use multiple programming languages without losing your mind)
|
||||||
|
[#]: via: (https://opensource.com/article/18/11/multiple-programming-languages)
|
||||||
|
[#]: author: (Bart Copeland https://opensource.com/users/bartcopeland)
|
||||||
|
[#]: url: ( )
|
||||||
|
|
||||||
|
How to use multiple programming languages without losing your mind
|
||||||
|
======
|
||||||
|
|
||||||
|
如何使用多种编程语言而又不失理智
|
||||||
|
======
|
||||||
|
|
||||||
|
多语言编程环境是一把双刃剑，既带来好处，也带来可能威胁组织的复杂性。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
如今，随着各种不同的编程语言的出现，许多组织已经变成了数字多语种组织。开源打开了一个语言和技术堆栈的世界，开发人员可以使用这些语言和技术堆栈来完成他们的任务，包括开发、支持遗留和现代软件应用。
|
||||||
|
|
||||||
|
与那些只说母语的人相比，通晓多种语言的人可以与数百万人交谈。在软件环境中，开发人员不会引入新的语言来达到特定的目的，也不会更好地交流。一些语言对于一项任务来说很棒，但是对于另一项任务来说却不行，因此使用多种编程语言可以让开发人员使用合适的工具来完成这项任务。这样，所有的开发都是多语种的；这只是野兽的本性。
|
||||||
|
|
||||||
|
|
||||||
|
多语种环境的创建通常是渐进的和情景化的。例如，当一家企业收购一家公司时，它承担了公司的技术堆栈——包括其编程语言。或者，随着技术领导的改变，新的领导者可能会将不同的技术纳入其中。技术也有过时的时候，随着时间的推移，增加了组织必须维护的编程语言和技术的数量。
|
||||||
|
|
||||||
|
|
||||||
|
多语言环境对企业来说是一把双刃剑，既带来好处，也带来复杂性和挑战。最终，如果这种情况得不到控制，多语言将会扼杀你的企业。
|
||||||
|
|
||||||
|
### Tricky technical tongue-twisters
|
||||||
|
### 狡猾的技术绕口令
|
||||||
|
|
||||||
|
如果有多种不同的技术——编程语言、遗留的工具和新兴的技术堆栈——就有复杂性。工程师团队花更多的时间努力改进编程语言，包括许可证、安全性和依赖性。与此同时，管理层缺乏对代码合规性的监督，无法衡量风险。
|
||||||
|
|
||||||
|
|
||||||
|
发生的情况是，企业有不同程度的编程语言质量和工具支持的高度可变性。当你需要和十几个人一起工作时，很难成为一种语言的专家。一个能流利地说法语和意大利语的人和一个能用八种语言串成几个句子的人在技能水平上有很大差异。开发人员和编程语言也是如此。
|
||||||
|
|
||||||
|
|
||||||
|
随着更多编程语言的加入，困难只会增加，导致数字巴别塔的出现。
|
||||||
|
|
||||||
|
|
||||||
|
答案是不要拿走开发人员工作所需的工具。添加新的编程语言可以建立他们的技能基础，并为他们提供合适的设备来完成他们的工作。所以，你想对你的开发者说“是”，但是随着越来越多的编程语言被添加到企业中，它们会拖累你的软件开发生命周期(SDLC)。在规模上，所有这些语言和工具都可能扼杀企业。
|
||||||
|
|
||||||
|
|
||||||
|
企业应注意三个主要问题:
|
||||||
|
|
||||||
|
|
||||||
|
1. **可见性:** 团队聚在一起进行项目，然后解散。应用程序已经发布，但从未更新——为什么要修复那些没有被破坏的东西？因此，当发现一个关键漏洞时，企业可能无法了解哪些应用程序受到影响，这些应用程序包含哪些库，甚至无法了解它们是用什么语言构建的。这可能导致昂贵的“勘探项目”，以确保漏洞得到适当解决。
|
||||||
|
|
||||||
|
2. **更新或编码:** 一些企业将更新和修复功能集中在一个团队中。其他人要求每个“比萨团队”管理自己的开发工具。无论是哪种情况，工程团队和管理层都要付出机会成本:这些团队没有编码新特性，而是不断更新和修复开源工具中的库，因为它们移动得如此之快。
|
||||||
|
|
||||||
|
3. **重新发明轮子:** 由于代码依赖性和库版本不断更新，当发现漏洞时，与应用程序原始版本相关联的工件可能不再可用。因此，许多开发周期都被浪费在试图重新创建一个可以修复漏洞的环境上。
|
||||||
|
|
||||||
|
|
||||||
|
将你组织中的每种编程语言乘以这三个问题，开始时被认为是分子的东西突然看起来像珠穆朗玛峰。就像登山者一样，没有合适的设备和工具，你将无法生存。
|
||||||
|
|
||||||
|
|
||||||
|
### 找到你的罗塞塔石碑
|
||||||
|
|
||||||
|
|
||||||
|
一个全面的解决方案可以满足 SDLC 中企业及其个人利益相关者的需求。企业可以使用以下最佳实践创建解决方案:
|
||||||
|
|
||||||
|
|
||||||
|
1. 监控生产中运行的代码，并根据应用程序中使用的标记组件(例如，常见漏洞和暴露组件)的风险做出响应。
|
||||||
|
2. 定期接收更新以保持代码的最新和无错误。
|
||||||
|
3. 使用商业开源支持来获得编程语言版本和平台的帮助，这些版本和平台已经接近尾声，并且不受社区支持。
|
||||||
|
4. 标准化整个企业中的特定编程语言构建，以实现跨团队的一致环境，并最大限度地减少依赖性。
|
||||||
|
5. 根据相关性设置何时触发更新、警报或其他类型事件的阈值。
|
||||||
|
6. 为您的包管理创建一个单一的真相来源；这可能需要知识渊博的技术提供商的帮助。
|
||||||
|
7. 根据您的特定标准，只使用您需要的软件包获得较小的构建分发。
|
||||||
|
|
||||||
|
使用这些最佳实践，开发人员可以最大限度地利用他们的时间为企业创造更多价值，而不是执行基本的工具或构建工程任务。这将在软件开发生命周期( SDLC )的所有环境中创建代码一致性。由于维护编程语言和软件包分发所需的资源更少，这也将提高效率和节约成本。这种新的操作方式将使技术人员和管理人员的生活更加轻松。
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
via: https://opensource.com/article/18/11/multiple-programming-languages
|
||||||
|
|
||||||
|
作者：[Bart Copeland][a]
|
||||||
|
选题：[lujun9972][b]
|
||||||
|
译者：[heguangzhi](https://github.com/heguangzhi)
|
||||||
|
校对：[校对者ID](https://github.com/校对者ID)
|
||||||
|
|
||||||
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||||
|
|
||||||
|
[a]: https://opensource.com/users/bartcopeland
|
||||||
|
[b]: https://github.com/lujun9972
|
||||||
Loading…
Reference in New Issue
Block a user