Anatomy of a Framework

If you want a video version of this post, checkout my YouTube on this subject with visuals.

In this post, I want to break down the anatomy of a framework and help you understand how you can use code to help you understand how software works on a high level without getting into the specifics of any particular language or existing framework.

Top-Level Descriptors

At the root of the project, you'll often find a bunch of files. These are often helper files that help you understand the project itself and usually from just the list of the files, you can quickly determine the coding language used and possibly any frameworks, patterns and dependencies used in this particular project. Let's break down some commonalities across projects:

README

Almost every codebase will have a README. This is the first file that people will see when viewing your project. It often contains starter information like what your project is, how to install and other optional info like how to contribute, credits and contact info.

You really can put whatever you want in this file and most use a README.md so they can take advantage of the formatting capabilities of Markdown.

Manifest Files

This varies across programming languages, but the gist is this describes the name of the project, dependencies and base install instructions, and other options the programming language needs to describe the project.

Examples of this include:

• For NodeJS projects, package.json.
• For Python projects, pyproject.toml.
• For Ruby project, Gemfile.
• For Docker containerized environments, Dockerfile.
• For Java based projects using Apache Maven, this might be a pom.xml.
• For C/C++ projects, Makefile.

Some tools and utilities have taken advantage of this pattern, like Jenkins and provided a specification for writing up a Jenkinsfile to describe how to compile and deploy this app.

In any case, there's a plethora a things you can include in your project and these top level files help programatically describe what to do with the project and how to compile it and even describe things about their depdencencies.

Library / Source Code

You'll typically find a lib or a src folder containing the source code to the project. This is the base entry point. This is where you can start to peek under the hood of the project to better understand how it works.

Build Runner

Most programming languages have a concept of a build runner. This is software that will compile the code into a packaged artifact and make it ready for deployment and install.

Most build runners have a means by which you can run scripts, execute tests and compile "debug" states of the project and "dist" or distribution-ready packages of the software.

Sometimes the concept of a build runner, testing framework entry point and packaging are all compiled into the same software project. Some are fragmented (like Python), which is why there seems like a bunch of projects that overlap in functionality.

Artifact Repository

Even further is the concept of an artifact repository where pristine packages of the software is deployed and versions are stored. This is where the system package manager or the language-specific package manager can manage installation of the software, inspect the manifest and deploy the results to the environment.

Language Polyglot

Now that we have an understanding of some of these fundamentals, you can take it with you outside of just writing code. As a language polyglot, I understand several programming languages.

As such, there's common functionality and patterns I see in software engineering that make it possible for me to present something like this to you.

Once you get your first language down, the rest come much easier. Don't limit yourself to just one programming language. It's actually really good to know at least one high level language like Python, one low-level language like C/C++ and one functional language like Haskel or Lisp.

Understanding all these will just make you that much more of a rounded software engineer. Future languages and projects will be that much easier to pickup.

If this post moved you, let's connect on LinkedIn.

Cheers!