One of the best ways to show off your technical knowledge is with Github repositories. (If you’ve never played with Git, check out https://lab.github.com/). Many companies today ask one of their experienced developers to evaluate a candidate’s Github. Often this is done by asking the candidate to submit a homework assignment, but even if they don’t assign you a project, someone likely still looks at your repositories. Unfortunately, this can work against you. To get your repositories to work for you, you need to make sure that your code is well factored.
To understand the basics of code factoring, consider the following basic diagram of webpage.
In this diagram, there are three operations happening: initialization of the HTTP listener, a request over HTTP, and some core logic. This is how the code should be divided up. You want three files: a main file that will do all your initialization, and a file for your HTTP listener, and your core logic.
Why is this important? Because professional development is done by layering more and more code onto the skeleton of your applications or services. The more isolated the functionality of that code, the easier it is to work with. We commonly call this the “single responsibility principle“. When someone is reviewing your code, factoring into files that have each have a single responsibility is one of most common criteria that you’ll be judged on.
Here is a rules of thumb:
- Your main function is a file. Its purpose is to initialize everything.
- Any input, known as ingress, into your application — such as network, screen actions, or direct user input — should go into its own file for the appropriate input type. A parsed config file gets its own file. If you also parse an input CSV (comma separated value), that should have its own file.
- Each type of egress to storage files, databases, or 3rd party APIs gets a file.
- Your core business logic, the interesting part about what your code does, should have its own file.
Most code has the same pieces: you take in data; you store it; you read it back. But there is nearly always a part that’s unique to your problem space. We call this the “business logic”. For example, when you log into your email, there is a part that figures out how many emails to show you initially, using what sort order, and what filter (inbox, spam, and so on). This is the business logic of email. If you have a mobile app and webpage, this part of the code can be shared. The part of your code that you can share should be in its own file.
The core operations of your business logic often form the acronym CRUD, which stands for create, read, update, and delete. Imagine you’re going to create an item for a to do list over an HTTP endpoint. The actual operation will happen across three files: the HTTP parsing and validation is one. The file or database storage logic is two. The business logic for any sort of lookup or calculation before you store it (for instance, what time it was created) is part of your business logic, and is your third file.
For sample projects, this might seem like overkill, and it is. For anything larger than a sample project, though, it isn’t. By splitting up your projects in this way, you will likely discover that it’s easier to continue adding features and changing things (which is the point). But importantly, it shows potential employers that you understand and can apply this principle.
Hopefully, if you’re not used to factoring code, this might give you an idea of what other developers look for in your code.
Many consider Martin Fowler’s Refactoring to be the definitive book on this subject. It’s written as a series of recipes for how to perform each type of refactor.
Here are some links for further reading:
Grimkey Bytes 