A software contract is a formalized documentation of an interaction with a software component. It can be an interface (in the object-oriented sense), an API, or a protocol (for example, TCP). Contracts allow diverse unconnected components of a system to work together. Having clear, crisp contracts is a prerequisite to enabling successful distributed software development. Here, distributed means not just in the normal distributed systems sense (software with independent components), but also distributed teams.

All libraries and products implement contracts, explicit or implicit. Contracts may be documented (using formal prose such as RFCs, ideally), or embedded in code (less than ideal unless clearly called out).

Contracts do change. The key task of the architect is to ensure the following:

• Contracts are durable and not reactive, and there is no change amplification...

In object-oriented programming, the key idea is to split code into several small, manageable parts or objects. Each object has its own identity, data (or attributes), and logic (or behavior). For example, consider modeling an elephant in software.

Attributes are the properties of the object. For example, in the case of the elephant, things such as these:

• Weight
• Color
• Type
• Location

The collection of all these attributes describes the current state of an object. The state of one object is generally independent of another. Behavior is things that the object can do; in the case of an elephant, it can trumpet. Behavior is the object's interface with the outside world. The individual constructs (or functions) by which you can invoke behavior on the object are called methods.

A class is a blueprint, or a template for objects that share the same behavior and...

Eventually, any interesting software project will come to depend on another project, library, or framework. Packages provide a namespace or a firewall for your code. By firewall I mean, insulate the code in the package from changes in other parts or packages. Entities inside a package (types, functions, variables, and so on) can be exported (public—visible outside the package) or unexported (private—not visible outside the package). The way to control visibility is exactly like the mechanism described for classes: if the identifier name starts with a capital letter, and it is exported from the package, otherwise, it's unexported.

This is an example of a convention over configuration paradigm and is one of the key enablers of encapsulation in Go. The rule of thumb is this:

There are two critical aspects that affect the testability of a good application:

• Writing code that can be tested easily
• Having self-contained, easily reproducible tests

The first part is about structuring code so that the code business logic is isolated from dependencies such as external services, and so on. This allows mocking the dependencies about these boundaries to allow the test cases to exercise the execution flow along various interesting paths. For example, consider you are writing the flight search feature on a travel marketplace. There are two aspects to this:

• Obtaining prices for a sector from various providers
• Running some business logic to filter and sort the results

Now, it may not be possible to get various error scenarios reliably reproduced by making direct calls to the provider. Also, it might be expensive (and insecure) to give API keys to...

To summarize, good packaging is important because it enables changes to code to happen faster with less risk (it is easy to grasp what to change and where due to the clear separation of concerns within the modules). This also leads to fewer bugs in production.

Good packaging also helps the non-technical aspects of engineering: there is a clear quanta of ownership for teams, and so there are fewer conflicts/communication and more of a sense of ownership.

In the next chapter, we will begin to look at design patterns. These are blueprints for solutions to various well-known scenarios that we encounter in software engineering.