thing_10

Choose Your Tools with Care

Modern applications are very rarely built from scratch. They are assembled using existing tools — components, libraries, and frameworks — for a number of good reasons:

• Applications grow in size, complexity, and sophistication, while the time available to develop them grows shorter. It makes better use of developers’ time and intelligence if they can concentrate on writing more business-domain code and less infrastructure code.

• Widely used components and frameworks are likely to have fewer bugs than the ones developed in-house.

• There is a lot of high-quality software available on the web for free, which means lower development costs and greater likelihood of finding developers with the necessary interest and expertise.

• Software production and maintenance is human-intensive work, so buying may be cheaper than building.

However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind:

• Different tools may rely on different assumptions about their context — e.g., surrounding infrastructure, control model, data model, communication protocols, etc. — which can lead to an architectural mismatch between the application and the tools. Such a mismatch leads to hacks and workarounds that will make the code more complex than necessary.

• Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The greater the number tools the worse the problem can become.

• Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow out of control very quickly. The application may end up looking as if it was all written in XML plus a few odd lines of code in some programming language. The configurational complexity will make the application difficult to maintain and to extend.

• Vendor lock-in occurs when code that depends heavily on specific vendor products ends up being constrained by them on several counts: maintainability, performances, ability to evolve, price, etc.

• If you plan to use free software, you may discover that it’s not so free after all. You may need to buy commercial support, which is not necessarily going to be cheap.

• Licensing terms matter, even for free software. For example, in some companies it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code.

My personal strategy to mitigate these problems is to start small by using only the tools that are absolutely necessary. Usually the initial focus is on removing the need to engage in low-level infrastructure programming (and problems), e.g., by using some middleware instead of using raw sockets for distributed applications. And then add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecast.

By Giovanni Asproni
现代应用程序很少是从头开始构建的。它们是使用现有的工具（组件、库和框架）组装的，原因有很多：
应用程序的规模、复杂性和复杂度都在增长，而可用于开发它们的时间却在缩短。如果开发人员能够集中精力编写更多的业务领域代码和更少的基础设施代码，那么他们就可以更好地利用时间和智慧。
广泛使用的组件和框架可能比内部开发的组件和架构有更少的错误。
网上有很多高质量的免费软件，这意味着开发成本更低，找到具有必要兴趣和专业知识的开发人员的可能性更大。
软件生产和维护是人力密集型工作，因此购买可能比构建更便宜。
然而，为您的应用程序选择正确的工具组合可能是一项需要思考的棘手业务。事实上，在做出选择时，你应该牢记以下几点：
不同的工具可能依赖于对其上下文的不同假设，例如，周围的基础设施、控制模型、数据模型、通信协议等，这可能导致应用程序和工具之间的架构不匹配。这种不匹配会导致黑客攻击和变通方法，使代码变得更加复杂。
不同的工具有不同的生命周期，升级其中一个工具可能会变得极其困难和耗时，因为新功能、设计更改甚至错误修复可能会导致与其他工具不兼容。工具数量越多，问题就越严重。
有些工具需要相当多的配置，通常是通过一个或多个XML文件进行配置，这些文件很快就会失控。应用程序最终可能看起来像是用XML加上一些编程语言的奇数行代码编写的。配置的复杂性将使应用程序难以维护和扩展。
当严重依赖特定供应商产品的代码最终在几个方面受到它们的约束时，就会发生供应商锁定：可维护性、性能、发展能力、价格等。
如果你打算使用免费软件，你可能会发现它毕竟不那么免费。你可能需要购买商业支持，这不一定会很便宜。
许可条款很重要，即使对于免费软件也是如此。例如，在一些公司，使用根据GNU许可条款许可的软件是不可接受的，因为它具有病毒性，即使用它开发的软件必须与其源代码一起分发。
我个人缓解这些问题的策略是从小处入手，只使用绝对必要的工具。通常，最初的重点是消除参与低级基础设施编程（和问题）的需要，例如，通过使用一些中间件而不是为分布式应用程序使用原始套接字。如果需要，可以添加更多。我还倾向于通过接口和分层的方式将外部工具与我的业务领域对象隔离开来，这样我就可以在必要时更改工具，只需付出少量的痛苦。这种方法的一个积极副作用是，我通常最终会得到一个较小的应用程序，它使用的外部工具比最初预测的要少。
作者：Giovanni Asproni