git每个开发人员一个分支_每个开发人员应了解的11件事

git每个开发人员一个分支

Cloud computing opens a world of possibilities for software and developers, but coding for the cloud isn’t necessarily as straightforward as you might think.

云计算为软件和开发人员提供了无限的可能性，但是为云编写代码并不一定像您想的那样简单。

The learning curve for developers can be tricky—especially for web developers unused to working with concepts such as threading and concurrency, latency, asynchronicity and failure tolerance.

开发人员的学习曲线可能会很棘手，尤其是对于那些不习惯使用诸如线程和并发，延迟，异步性和容错性等概念的Web开发人员而言。

Here are 11 things you need to watch out for when you start developing for the cloud.

开始为云开发时，需要注意以下11件事。

合规与治理 (Compliance & Governance)

Legal and operational requirements often dictate the location of your data storage and hosting, and in the cloud it’s no different.  While the abstraction of the infrastructure layer is a huge boon to scalable development, you need to be aware of how your instances and services are provisioned, or you may end up inadvertently sending your data to a country or state that breaches your local privacy laws.

法律和运营要求通常会决定数据存储和托管的位置，在云中也是如此。 虽然基础结构层的抽象对可伸缩开发是一个巨大的福音，但您需要知道如何配置实例和服务，否则最终可能会无意间将数据发送到违反当地隐私法的国家或州。

A cloud service may be supported by multiple data centers in various locations, and there is often no way of knowing where an instance will physically be spawned.  This is easily overlooked given that the whole point of the cloud is to be to some degree location and infrastructure independent, but it can be critical for governance.

云服务可能由位于不同位置的多个数据中心提供支持，并且通常无法知道实例将在何处产生。 鉴于云的整个点在某种程度上与位置和基础架构无关，所以这很容易被忽略，但这对于治理而言至关重要。

容错能力 (Failure Tolerance)

With the potential for so many instances and distributed services, you introduce many more possible points of failure than in a traditional data center hosted application.  Particularly for developers used to runtime interpreted languages like PHP, ASP or ColdFusion, the necessary leap to failure tolerance and asynchronous data can present a difficult learning curve.

拥有如此多实例和分布式服务的潜力，与传统的数据中心托管应用程序相比，您引入了更多的故障点。 特别是对于习惯于运行时解释语言(如PHP，ASP或ColdFusion)的开发人员，在容错和异步数据方面的必要飞跃可能会带来学习困难。

In particular, your application must be architected from the outset to anticipate failure—an instance failing to start, data not arriving in a timely manner or perhaps not arriving at all.  Both your service layers and your UI must cater to this, and provide appropriate mechanisms and user feedback.

特别是，您的应用程序必须从一开始就进行架构设计，以预期失败—实例无法启动，数据无法及时到达或根本无法到达。 服务层和UI都必须满足这一要求，并提供适当的机制和用户反馈。

For example, let’s say you have an application that allows a user to upload a video file for conversion, and you spawn an instance to manage it.  If you code synchronously your application will break should the instance fail to start or a storage mechanism temporarily loses connection.  If on the other hand you architect with queuing and distribution in mind, your app can alert the user to a delay or gracefully failover and allow operation even though the data required may not yet be ready.

例如，假设您有一个允许用户上传视频文件进行转换的应用程序，并且产生了一个实例来对其进行管理。 如果您同步编码，则在实例无法启动或存储机制暂时失去连接的情况下，应用程序将中断。 另一方面，如果您在构架时考虑排队和分配，则您的应用程序可以提醒用户延迟或正常进行故障转移，并允许操作，即使所需数据可能尚未就绪。

服务映射 (Service Mapping)

The nature of the cloud and elastic computing means that unlike the traditional hosting model of fixed network addresses for various services, you won’t know the IP address of an instance in advance, and so your application must be able to work at a high level without being slaved to a physical (or logical) location.

云和弹性计算的本质意味着，与用于各种服务的固定网络地址的传统托管模型不同，您不会事先知道实例的IP地址，因此您的应用程序必须能够在较高水平上运行而不会被奴隶到物理(或逻辑)位置。

This is not so different from proper load balancing or clustering, and can present the same sorts of issues, but those unused to architecting for such environments must take this learning curve into account when moving into the cloud.

这与适当的负载平衡或群集没什么不同，并且可以呈现相同类型的问题，但是在为此类环境进行架构设计时未使用的问题在移入云时必须考虑此学习曲线。

可伸缩性和状态 (Scalability and State)

Horizontal scalability is one of the primary reasons to move to cloud architecture, but it is important to realise that not every application suits this environment.  With no ability to predict instance usage or continuous connection, each request a user makes may potentially be served by a separate instance, and so you must manage the state accordingly.

水平可伸缩性是迁移到云架构的主要原因之一，但重要的是要认识到并非每个应用程序都适合此环境。 由于无法预测实例使用情况或持续连接，因此用户发出的每个请求都可能由单独的实例提供服务，因此您必须相应地管理状态。

工装 (Tooling)

Cloud specific languages are still in their infancy, and developing in familiar languages on a cloud infrastructure can present unique problems.  You may not be able to rely on your IDE as much as you used to—debuggers especially can be problematic, and in some cases non-existent.

特定于云的语言仍处于起步阶段，在云基础架构上以熟悉的语言进行开发会带来独特的问题。 您可能无法像以前那样依靠IDE，尤其是调试器可能会出现问题，在某些情况下甚至不存在。

To those with experience of low level languages or development before the prevalence of high quality tooling this won’t be a new thing, but if you have never debugged an application the “old fashioned way”, now is the time to learn.

对于那些在使用高级工具之前没有使用低级语言或开发经验的人来说，这并不是什么新鲜事，但是，如果您从未以“过时的方式”调试过应用程序，那么现在该学习一下了。

可移植性 (Portability)

This isn’t a problem for everyone, and varies wildly based on the services you use and the nature of your application, but you may find that—once developed for a given cloud infrastructure—your system is no longer portable.  Abstraction is the key here, bearing in mind that the relative infancy of cloud platforms makes adherence to standards even more important.

这不是每个人都遇到的问题，并且会因您使用的服务和应用程序的性质而千差万别，但是您可能会发现，一旦为给定的云基础架构开发了该系统，您的系统将不再具有可移植性。 在这里，抽象是关键，要记住，云平台的初期发展使得遵守标准变得更加重要。

You may discover that various standards are unsupported or partially implemented by your provider, and in such a case developing against this environment will make things difficult should you need to migrate to another service due to pricing, governance or reliability issues.

您可能会发现提供商不支持或部分实施各种标准，在这种情况下，如果由于价格，治理或可靠性问题而需要迁移到其他服务，则针对这种环境进行开发将使工作变得困难。

数据存储 (Data storage)

Traditional software development relies on file and relational data storage more often than not, but these solutions do not scale well in the cloud.  Developers are required to learn new technologies such as NoSQL solutions, big data services and proprietary Platform as a Service (PaaS) APIs.  These new technologies require a fundamental shift in thinking, and present new coding problems traditional software developers may not yet be aware of.

传统软件开发通常更多地依赖文件和关系数据存储，但是这些解决方案在云中无法很好地扩展。 开发人员必须学习新技术，例如NoSQL解决方案，大数据服务和专有的平台即服务(PaaS)API。 这些新技术需要从根本上转变思维，并带来传统软件开发人员可能尚未意识到的新编码问题。

Before you begin architecting for the cloud, make sure you’re up to speed on the use of non relational data storage, big data concepts like Hadoop, HBase, Cassandra and Hypertable, to name a few.  It’s also worth looking into techniques for developing against PaaS services like SalesForce.com, where you rely on an API for data storage rather than directly managing your data.

在开始为云设计架构之前，请确保您快速使用非关系数据存储，例如Hadoop，HBase，Cassandra和Hypertable等大数据概念。 还值得研究针对诸如Salesforce.com之类的PaaS服务进行开发的技术，在这些技术中，您依靠API进行数据存储，而不是直接管理数据。

Remember that at any given time, a user or service request will be served from an unknown instance, so localized storage is no longer possible.

请记住，在任何给定时间，都会从未知实例为用户或服务请求提供服务，因此不再可能进行本地化存储。

费用 (Costs)

In traditional development, it’s not a big deal if you leave the test server running, or run multiple local load tests.  In the cloud however, every CPU cycle potentially costs money, and you need to take this into account with everything you do.  Development processes need to bear in mind CPU hours, bandwidth usages and storage allocation, and so new forms of efficiency are required.

在传统开发中，让测试服务器保持运行状态或运行多个本地负载测试并不重要。 但是，在云中，每个CPU周期都可能会花费金钱，因此您需要将所做的一切考虑在内。 开发过程需要牢记CPU时间，带宽使用率和存储分配，因此需要新的效率形式。

Of course these requirements aren’t necessarily new, but those used to developing on heavy duty servers, high bandwidth connections and local environments can easily become lax in fine tuning things like message size, connection pooling and temporary file writing.  When coding for the cloud, it’s time to dot the i’s and cross the t’s: take care of all the details.

当然，这些要求不一定是新要求，但是那些用于在重型服务器，高带宽连接和本地环境上进行开发的要求很容易在诸如消息大小，连接池和临时文件写入之类的微调方面变得松懈。 在为云编码时，是时候点一下i并越过t的时候了：照顾好所有细节。

测试中 (Testing)

The usual best practice is to test apps on an identical platform to the one that will run in production (or as close to it as you can manage)—but cloud infrastructure makes that exceedingly difficult, and it’s very possible for situations to arise in production that you cannot replicate locally.  Even taking a snapshot of an application at the time of a system event can be problematic, so along with learning new ways to debug you need to be constantly aware that things can work differently in the cloud.

通常的最佳实践是在与将要在生产环境中运行的应用程序相同的平台上测试应用程序(或在您可以管理的尽可能接近的平台上进行测试)，但是云基础架构使这变得异常困难，并且很可能在生产环境中出现这种情况。您无法在本地复制。 即使在系统事件发生时为应用程序快照也可能会出现问题，因此，在学习调试新方法的同时，您需要不断意识到事物在云中的工作方式可能会有所不同。

Take this into account when providing estimates and allocating time for functional or user testing—and especially when attempting to debug and resolve a live issue.

在为功能或用户测试提供估计并分配时间时，尤其是在尝试调试和解决实时问题时，请考虑到这一点。

发牌 (Licensing)

Never make assumptions about the nature of deployment licenses in the cloud—they may surprise you.  More than one development house has been caught short after developing apps and suddenly discovering that the licenses they own for libraries and software entities don’t scale in the cloud, and may produce hidden costs.

永远不要假设云中部署许可证的性质，它们可能会让您感到惊讶。 在开发应用程序并突然发现他们拥有的用于库和软件实体的许可证无法在云中扩展之后，不止一家开发公司陷入困境，并可能产生隐藏的成本。

文档和社区 (Documentation and Community)

Because everything is still so new, you won’t be able to initially find the same level of community help, blogs, documentation and solutions that you’re used to Googling for.  In many cases you may find yourself pioneering even simple functionality in a specific use case, so ensure that you document your work and share as much as possible.

由于一切仍然很新，因此您最初将无法找到与Google一样的社区帮助，博客，文档和解决方案。 在许多情况下，您可能会发现自己在特定用例中甚至开拓了简单的功能，因此请确保记录您的工作并尽可能多地共享。

The body of knowledge available on the net is growing, but it still has a long way to go, and these resources are a valid and important part of what makes up your usefulness as a developer—so don’t underestimate it.

网络上可用的知识量正在增长，但是还有很长的路要走，这些资源是构成您作为开发人员的有用性的有效和重要组成部分，因此请不要低估它。

Altogether, cloud computing is full of promise.

总而言之，云计算充满了希望。

Applications can be built to scale on demand and use only the resources they require, while still being able to compete on the world stage with the same kind of assurance that once only came with deep pockets and big data centers.

可以构建应用程序以按需扩展并仅使用它们所需的资源，同时仍然能够在世界舞台上竞争，而这种保证只有在财力雄厚和大数据中心才出现。

As technologies, languages and developer experience grows, new ways of doing things will emerge in the cloud, and it’s up to you as a developer to seek them out and turn them to your advantage.

随着技术，语言和开发人员经验的增长，新的工作方式将在云中出现，而开发人员则需要将它们找出来并发挥自己的优势。

翻译自: https://www.sitepoint.com/11-things-every-developer-should-know-about-the-cloud-2/

git每个开发人员一个分支