软件开发的浪费
I switched into a programming life from a more traditional career path. Just a taste of programming was all it took. Years of study and summer jobs intended as ramps into a fulltime position — all just swept aside by something involving hours in front of a screen, staring at pages of strange symbols.
我从更传统的职业道路转入编程生活。 仅需编程即可。 多年的学习和暑期工作打算逐步升为专职职位，所有工作都被屏幕前数小时的工作所取代，盯着奇怪符号的页面。
Programming has been good to me. There has been plenty of intellectual challenge and relatively good income. In more recent years I’ve been able to work remotely. Reducing the hours spent in traffic jams and the flexibility to look after the smaller life emergencies has been great.
编程对我一直很好。 智力挑战和收入相对较高。 最近几年，我已经能够远程工作。 减少交通拥堵的时间，以及在较小的紧急情况下进行照看的灵活性非常好。
It took me a while to realize that “remotely” is a synonym for “mobile”. That small epiphany sent me on a trip through the Pacific, Australia, South-East Asia and India. My office consisted of a laptop and an Internet connection and finding the latter was rarely a problem. I managed to visit places that I had always been curious about, but had never really conceived of how I might get there. Looking up from a page of code to check what was happening on a beach in Sri Lanka had a slightly surreal quality about it. There are no regrets about veering off that traditional path.
我花了一段时间才意识到“远程”是“移动”的同义词。 那小小的顿悟使我到太平洋，澳大利亚，东南亚和印度旅行。 我的办公室由一台笔记本电脑和一个互联网连接组成，找到后者几乎不是问题。 我设法参观了我一直好奇的地方，但从未真正想到过如何到达那里。 从代码页中查找以查看斯里兰卡的海滩上发生的事情，它的质量有些超现实。 改变传统道路毫无遗憾。
As part of a recent project I got to work on something that I really enjoy — messaging. That serves here as a catch-all term for technologies such as RPC, HTTP request, Protobuf and JSON. Most people see this kind of work as the coding of specific APIs and the messaging technology used as incidental to that goal. Professionally that’s the correct thinking but personally I have an inverted experience — the messaging is the focus and the API is incidental.
作为最近项目的一部分，我必须从事我真正喜欢的事情-消息传递。 这在这里是RPC，HTTP请求，Protobuf和JSON等技术的统称。 大多数人将这类工作视为特定API的编码和用于该目标的消息传递技术。 从专业上讲，这是正确的想法，但就我个人而言，我的经验是相反的-消息传递是重点，API是附带的。
To me, messaging is the essential magic needed for multi-processing, network software and cloud services to exist. Framing it in that way makes it sound more important but there is justification to that. There were a range of technologies that needed to come together before we had the operational environment we have now — IEEE 802, TCP, sockets, the Internet and the smartphone — and messaging is just one piece. But it’s also the piece that bridges the world of what software needs to do and what networks actually provide. It’s where features and functions of software, such as “CreateUser” or “StartDailyHousekeeping”, become blocks of bytes on a network transport.
对我来说，消息传递是存在多处理，网络软件和云服务所需的基本魔术。 以这种方式进行构图使其听起来更重要，但这样做是有道理的。 在拥有我们现在的运行环境之前，需要整合多种技术-IEEE 802，TCP，套接字，互联网和智能手机-并且消息传递只是其中的一部分。 但是，这也是将软件需要做什么和网络实际提供什么联系起来的桥梁。 在这里软件的特征和功能(例如“ CreateUser”或“ StartDailyHousekeeping”)成为网络传输中的字节块。
That is quite a leap. At the top is a request, often involving an instance of a “struct” or “class” written in a language like Golang, Python or C++. At the bottom are one or more network blocks containing a representation of that instance, using an encoding such as JSON. There is a significant semantic gap between those two points.
那是一个很大的飞跃。 顶部是一个请求，通常涉及用诸如Golang，Python或C ++之类的语言编写的“结构”或“类”的实例。 在底部是一个或多个包含该实例表示形式的网络块，使用诸如JSON的编码。 在这两点之间存在很大的语义鸿沟。
A rich variety of traps and pitfalls wait for anyone who ventures into that gap. Consider issues such as portable time representation, floating point accuracy across different programming languages and versioning of messages. Think about how you might solve such issues and at the same time deliver a software API that is simple and intuitive. Oh — and don’t forget session management.
各种各样的陷阱和陷阱正在等待任何冒险进入这一鸿沟的人。 考虑诸如可移植时间表示，跨不同编程语言的浮点准确性以及消息版本控制等问题。 考虑一下如何解决此类问题，同时提供简单直观的软件API。 噢，别忘了会话管理。
Session management is part of the machinery that is activated when networking software goes awry. Combining it with the restarting of processes and software recovery gives us high availability, and high availability is golden. Anything less than high availability for a large scale cloud service is likely to be stressful and in the extreme cases, commercially fatal. So, while solving the more obvious issues associated with moving application data across a network transport and ensuring that implementation details do not pollute the application code, don’t forget that it all has to perform flawlessly as a stressed service rebuilds itself.
会话管理是网络软件出现问题时激活的机制的一部分。 将其与流程的重新启动以及软件恢复相结合，可以为我们提供高可用性，而高可用性是黄金。 大规模云服务的任何高可用性都可能带来压力，在极端情况下，这会对商业造成致命影响。 因此，在解决与跨网络传输移动应用程序数据相关的更明显的问题并确保实现细节不会污染应用程序代码的同时，请不要忘记，当压力很大的服务自身重建时，所有这些操作都必须完美执行。
If you have any intellectual energy left over then also consider that there are established tools and techniques that might need to go. The most glaring example of this is the RPC model of operation. This is a technology that kicked off in the 80s founded on the idea that a procedural approach to distributed computing was the way to go. That was a simplification playing to the audience of the time.
如果您还有剩余的智力，那么还请考虑可能需要使用已建立的工具和技术。 最明显的例子是RPC操作模型。 这是一种在80年代开始的技术，其基础是要采用分布式过程的过程方法。 这对当时的听众来说是一种简化。
Procedural thinking does not fit comfortably with networks and multi-tenanted cloud services, which are profoundly asynchronous. It imposes constraints that inevitably result in bottlenecks or ugly workarounds. A client connection to a RabbitMQ message broker is limited to one active RPC at a time — it is not possible to send a new request before a response to the previous request has been received.
程序性思维与深度异步的网络和多租户云服务不太适合。 它强加了约束，这些约束不可避免地导致瓶颈或丑陋的解决方法。 与RabbitMQ消息代理的客户端连接一次仅限于一个活动的RPC —在收到对先前请求的响应之前，不可能发送新请求。
Sure — open more connections. But immediately you are managing multiple network connections when the actual need was concurrency of requests. Network connections involve system-level resources. In a busy system those resources might be scarce and acquiring one of those resources may be a slow process. Note that this usage experience was specific to a particular RabbitMQ client library and to a particular time. Even at that time, the relevant RabbitMQ documentation discouraged the use of RPC.
确定-打开更多连接。 但是，当实际需要是请求并发时，您将立即管理多个网络连接。 网络连接涉及系统级资源。 在繁忙的系统中，这些资源可能稀缺，而获取这些资源之一可能是一个缓慢的过程。 请注意，这种使用体验特定于特定的RabbitMQ客户端库和特定的时间。 即使在那时，相关的RabbitMQ文档也不鼓励使用RPC。
The deeper truth is that projects continue to use the RPC feature of RabbitMQ because it fits the legacy culture of procedural tools and procedural thinking. Fully asynchronous software is considered difficult and often restricted to certain areas where it cannot be avoided. There are benefits to this stratgey but there have been too many projects where potential features or functionality have been scuttled by the lack of asynchronous underpinnings. So, add to the difficulties of messaging the significant cultural inertia that exists around procedural versus asynchronous software.
更深层的事实是项目继续使用RabbitMQ的RPC功能，因为它符合程序工具和程序思想的传统文化。 完全异步的软件被认为是困难的，并且通常局限于无法避免的某些领域。 这种策略可以带来好处，但是有太多的项目由于缺乏异步基础而破坏了潜在的特性或功能。 因此，增加了消息传递方面的困难，即程序和异步软件之间存在着巨大的文化惰性。
The enduring discomfort for me is that the work we have done in this space is not that good. It’s fragmented and there is no common direction. A large, distributed solution will include multiple messaging technologies such as HTTP requests, Protobuf messages over RabbitMQ connections and perhaps proprietary JSON messages over TCP. The result is that software internals are pulled in different directions by the client code associated with each of those technologies and is also polluted by networking details.
对我来说，持久的不适是我们在这个领域所做的工作不是那么好。 它是零散的，没有共同的方向。 大型的分布式解决方案将包括多种消息传递技术，例如HTTP请求，RabbitMQ连接上的Protobuf消息以及TCP上可能的专有JSON消息。 结果是，与这些技术中的每一种相关联的客户端代码会将软件内部结构拉向不同的方向，并且还会被网络详细信息污染。
During software operation messages arrive over one connection and cause zero or more sending operations over further connections. In the worst cases the related code can involve ad-hoc marshalling and data conversions, e.g. where a value arrives as a string and must be converted to an integer before departure. This flavour of code is both tedious to write and fragile in nature. Actual application code becomes lost in the milieu.
在软件操作过程中，消息通过一个连接到达，并在其他连接上导致零个或多个发送操作。 在最坏的情况下，相关代码可能涉及临时编组和数据转换，例如，值以字符串形式到达并且必须在离开前转换为整数。 这种代码风格既繁琐又编写又易碎。 实际的应用程序代码在环境中丢失了。
More importantly the chances of a particular component being portable from one project to the next are low. Take the example of an email service that provides a common email sending operation. Other components within a system connect to the service and submit the message content and recipients. The service is configured with the mail account details such as authentication information and perhaps a default “from” address, necessary to complete an SMTP session. Clients can focus on what needs to be sent and to whom, while the service takes care of the rest. All mail originating from the system is manifestly from that system.
更重要的是，将特定组件从一个项目移植到下一个项目的机会很小。 以提供通用电子邮件发送操作的电子邮件服务为例。 系统中的其他组件连接到服务并提交邮件内容和收件人。 该服务配置有邮件帐户详细信息，例如身份验证信息以及可能是完成SMTP会话所必需的默认“发件人”地址。 客户可以集中精力处理需要发送给谁的内容，而其他服务则由该服务负责。 来自系统的所有邮件显然都来自该系统。
The problems start when you try to drop that email service into another project. The service has proved itself useful and reliable and there is an opportunity to leverage the development effort. However, the chances of a successful relocation into a completely different messaging eco-system are low. Changing the service to integrate it with the local messaging produces a different software product.
当您尝试将该电子邮件服务放入另一个项目时，问题就开始了。 该服务已证明自己有用且可靠，并且有机会利用开发工作。 但是，成功迁移到完全不同的消息传递生态系统中的机会很小。 更改服务以将其与本地消息传递集成会产生不同的软件产品。
Now consider a different service. An alarm service is created that accepts alarm events and takes responsibility for delivery of notifications to configured parties. It allows for multiple communication mechanisms for delivery of alarm events to those parties, including push notifications, SMS and email.
现在考虑其他服务。 创建了一个警报服务，该服务接受警报事件并负责将通知传递给已配置的参与方。 它允许多种通信机制，用于将警报事件传递给那些各方，包括推送通知，SMS和电子邮件。
The alarm service needs to “find” the particular email service within the particular system that it happens to be running in. Manual configuration of a network address within the alarm service is one strategy but it’s a low quality strategy that becomes more blatantly so as the collection of services needing to “find” each other becomes larger. Push notifications and SMS capability should also exist as independent software components meaning that there are now three network addresses to maintain in the alarm service.
警报服务需要“发现”恰好在其中运行的特定系统中的特定电子邮件服务。在警报服务中手动配置网络地址是一种策略，但是它是一种低质量的策略，因此变得更加公然。需要彼此“查找”的服务的集合会更大。 推送通知和SMS功能也应作为独立的软件组件存在，这意味着警报服务中现在需要维护三个网络地址。
A proper solution to this problem is a service discovery function, where components publish the services they provide and interested parties subscribe to those same services. When a service is published the function sends notifications to all relevant subscribers. The notification includes address information so that the subscriber can connect to the publisher.
解决此问题的合适方法是服务发现功能，其中组件发布它们提供的服务，而有关方面则订阅这些相同的服务。 发布服务后，该功能会将通知发送给所有相关的订户。 该通知包括地址信息，以便订阅者可以连接到发布者。
The introduction of a common messaging eco-system and a standard mechanism for service discovery has a profound effect on the software project landscape. Suddenly there is a basis for component-level reuse and an ability to automatically self-configure, courtesy of service discovery. The benefits include reduced project development times and improved system reliability (just quietly, service discovery also helps with the implementation of session management). Sadly, this is not the landscape we work in.
引入通用消息传递生态系统和用于服务发现的标准机制对软件项目前景产生了深远影响。 突然之间，存在组件级重用的基础，并且能够根据服务发现自动进行自我配置。 好处包括减少项目开发时间和提高系统可靠性(悄悄地，服务发现还有助于实现会话管理)。 可悲的是，这不是我们工作的环境。
There are plenty of reasons why we have the current situation — the most immediate being that messaging is typically incidental to the “real” work. It’s difficult to do quality work when the focus lies elsewhere. Others include competition between programming languages and the cultural resistance to truly asynchronous software.
我们之所以会遇到这种情况，有很多原因-最直接的是，消息传递通常是“真实”工作附带的。 当重点放在其他地方时，很难进行高质量的工作。 其他因素包括编程语言之间的竞争以及对真正异步软件的文化抵制。
For the software professional the result of all this is messy. From what encoding you should be using (i.e. JSON vs XML) through to what message broker should be added to your solution (i.e. NATS or RabbitMQ) there is a long list of choices to be considered. The subsequent decisions are difficult because the contenders can be so different it can be like comparing apples and oranges. Then comes the job of gluing it all together, knowing full well that you solved many of the same problems in the previous project and that large portions of it are likely to be repeated in the next.
对于软件专业人员而言，所有这些结果都是混乱的。 从应使用的编码(即JSON与XML)到应将哪种消息代理添加至解决方案(即NATS或RabbitMQ)，都有很长的选择要考虑。 随后的决定是困难的，因为竞争者可能是如此不同，就像比较苹果和橙子一样。 然后是将所有内容粘合在一起的工作，充分了解您已经解决了上一个项目中的许多相同问题，并且很大一部分可能在下一个项目中重复。
Software projects harbour a pattern of repetition and waste. Something is needed to disrupt that pattern — tools and techniques that target interoperation and prove their usefulness from project to project.
软件项目具有重复和浪费的模式。 需要某种方式来破坏这种模式-以互操作为目标并证明其在项目之间的有用性的工具和技术。
We need that combination of a common messaging eco-system and service discovery. If these goals seem unrealistic then consider the achievements of NMEA and the CAN bus.
我们需要将通用消息传递生态系统与服务发现结合起来。 如果这些目标似乎不切实际，请考虑NMEA和CAN总线的成就。
The marine industry did it first courtesy of NMEA which refers to both the National Marine Electronics Association and various communications specifications. Those specifications are the reason that folks in boats can buy products as diverse as anemometers, GPS receivers and autopilots and have them interoperate from out of the box. This is the case even where the products come from different vendors.
航海业首先是由NMEA提出的，NMEA涉及美国国家航海电子协会和各种通信规范。 这些规范是乘船人可以购买诸如风速计，GPS接收器和自动驾驶仪之类的各种产品，并使其开箱即用地互操作的原因。 即使产品来自不同的供应商，也是如此。
It’s a plug-and-play arrangement that the developer community can only dream about. An autopilot from Raymarine will happily consume the direction information from a Lowrance heading sensor, to maintain a set course. With a Garmin GPS receiver present the autopilot can follow a series of waypoints, steering a course around known hazards.
这是开发人员社区梦dream以求的即插即用安排。 Raymarine的自动驾驶仪会愉快地消耗Lowrance航向传感器的方向信息，以维持设定的航向。 配备Garmin GPS接收器后，自动驾驶仪可以遵循一系列航路点，绕过已知危险路线。
The automative industry came along second with the CAN bus or Controller Area Network. The motivations were similar just for a different mode of transport. Onboard diagnostics for the CAN bus have been mandatory for vehicles sold in the US from as early as 1996.
自动化行业紧随其后的是CAN总线或控制器局域网。 动机只是针对不同的运输方式而已。 自1996年以来，在美国销售的车辆必须对CAN总线进行车载诊断。
Diagnostic tools that plug in to your family car are widely available and cheap. They provide a convenient window into the operational status of the various components distributed around your vehicle such as mirrors, seats, widows, door locks and lights. Depending on the design brief for your car, there may also be information on the engine, transmission, security systems, and climate control.
插入家用汽车的诊断工具广泛可用且价格便宜。 它们提供了方便的窗口，可查看分布在车辆周围的各种组件的运行状态，例如后视镜，座椅，寡妇，门锁和照明灯。 根据您汽车的设计简介，可能还会有有关发动机，变速箱，安全系统和气候控制的信息。
The software community is perfectly capable of producing the equivalent of what the NMEA and CAN bus communities have done about interoperation of networked components. The scope for our equivalent would actually be smaller. Both NMEA and CAN bus specifications cover the physical and link layers (note that the later versions of NMEA have adopted the CAN bus for those layers), whereas we have no need to venture below the network transport layer (i.e. TCP).
该软件社区完全有能力产生与NMEA和CAN总线社区所做的等同于网络组件互操作的等同功能。 我们的等效范围实际上会更小。 NMEA和CAN总线规范都涵盖了物理层和链路层(请注意，较新版本的NMEA在这些层上都采用了CAN总线)，而我们无需冒险进入网络传输层(即TCP)之下。
There is no point in waiting for a specification to emerge from a standards organization such as ISO or the ITU. Such a specification needs to come from the industry to be eventually ratified by those organizations. There is no point in waiting for a specification to emerge from one of the power players of the industry such as Microsoft, Apple, Google or Netflix. There would be no commercial benefit to the organization involved and the chances of such an effort producing a specification untainted by commerical strategizing seems low. That issue is only exacerbated with the idea of a consortium of industry players.
没有必要等待ISO或ITU等标准组织提出规范。 这样的规范需要来自行业，最终由那些组织批准。 毫无疑问地等待该规范的出现，例如微软，苹果，谷歌或Netflix等行业的强者之一。 所涉及的组织将不会有商业利益，并且做出此类努力以产生不受商业策略影响的规范的机会似乎很小。 这个问题只会随着行业参与者联盟的想法而加剧。
The solution needs to come from us. We are the group of professionals who have turned complex designs into usable services, we know what is involved and we know the parts that are repeated from project to project.
解决方案必须来自我们。 我们是将复杂的设计转变为可用的服务的专业人员团队，我们知道所涉及的内容，并且知道各个项目之间重复的部分。
One of us needs to create the software industry equivalent of NMEA and the CAN bus.
我们其中之一需要创建相当于NMEA和CAN总线的软件行业。
翻译自: https://medium.com/@scott.woods/software-projects-and-wasted-hours-5ce760efc914
软件开发的浪费