Part III. The Process Pillar
The process pillar was created in order to define the steps required to get code from the developer’s brain to the user’s browser. It encompasses each permutation the code goes through, from qualified idea to validated design to accepted commit to deployed code.
If you’ve been doing development for long enough, you’ll probably notice that our processes have evolved immensely in the past several years. My first experience in web development involved being asked to digest two months’ worth of email correspondence, determine what the client was asking for, and then FTP into their server and make the necessary changes.
This, in hindsight, was a horrible way to perform updates to a website. What would have happened if I misread the email and changed the wrong thing? What if I had accidentally deleted a large chunk of CSS, inadvertently breaking other pages on the site? What would have happened if I fixed a JavaScript bug, but it introduced two other bugs? Now, by itself, these problems would be annoying, and a prime example of why you never use FTP to edit the live site! But what happens if you aren’t backing up often enough, and you are left with a broken website to fix, and you still have a list of tasks to complete?
Fortunately, for most of us, we’ve learned from these mistakes and are following much better practices these days. Instead of FTPing changes sent in an email, we now:
- Use issue tracking and user stories to properly track workflows and mark completed tasks
- Set up development environments where you can properly test code changes
- Create build processes that compile, validate, and test code
- Get feedback from story owners before any code is accepted
- Push the committed code to a central code repository
- Employ a build system that seamlessly pushes out the new batch of code into production, and could roll that patch back, restoring original functionality if needed
Are You Up for the Task?
As a frontend architect you will usually be tasked with developing, or at least championing, each of the steps just listed. Any weak links in this process will quickly surface as a pain point for developers, or a source of constant unmet expectations or regressions.
As I’ve said in previous chapters, when it comes to frontend architecture, the “user” is the developer. The tools we select, the code we write, and the processes we create are all aimed at allowing the developer to write the most efficient, error-free, scalable, and sustainable design system possible.
In this part, we will look at the larger picture of onboarding and equipping new developers. We’ll dive into the process they go through to turn requirements into published code. Then we will dive right into the heart of the process in discussing the role of task runners and how they help us to create better code in less time.