10仔细挑选工具
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.
但是，为应用程序选择合适的工具组合可能是一项需要深思熟虑的棘手业务。事实上，在做出选择时，有几件事你应该记住：
不同的工具可能依赖于对其上下文的不同假设，例如，基础设施、控制模型、数据模型、通信协议等。--- 这会导致应用程序和工具之间的体系结构不匹配。这种不匹配会导致黑客攻击和使代码变得更加复杂变通方法。
不同的工具有不同的生命周期，升级其中一个工具可能会非常困难和耗时，因为新的功能、设计更改甚至错误修复可能会导致与其他工具不兼容。工具越多，问题就越严重。
有些工具需要相当多的配置，通常是通过一个或多个XML文件，这些文件可能会很快失控。应用程序可能最终看起来好像是用XML加上一些用某种语言编写的诡异代码组成的。配置的复杂性将使应用程序难以维护和扩展。
当代码严重依赖于特定供应商的产品时，就会发生供应商锁定。最终会在在可维护性、性能、进化能力、价格等几个方面受到该厂商的限制。
如果你计划使用自由软件，你可能会发现它毕竟不是那么自由。你可能需要购买商业支持，这并不一定便宜。
许可条款很重要，即使对于自由软件也是如此。例如，在一些公司中，使用根据GNU许可条款许可的软件是不可接受的，因为它具有病毒传染性，即使用它开发的软件必须与其源代码一起分发。
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.
我个人应对这些问题的策略是从小事做起，只使用绝对必要的工具。通常，最初的重点是消除底层基础架构编程工作(和问题)，比如，通过使用一些中间件而不是使用原始套接字来实现分布式应用程序。然后根据需要添加更多。我还倾向于通过接口和分层将外部工具与业务领域对象隔离开来，这样，如果需要的话，我可以用较低的代价来更换工具。这种方法的一个积极副作用是，我最终得到的应用程序通常比原来预测的要小，而使用的外部工具也比原来预测的要少。
Last updated