Long before I started working as a front-end developer, I was asking myself the question: how does a developer think about developing a website? For a newcomer like myself, attempting to answer this question seemed, at the time, an overwhelming task.
After one year of being a front-end developer, I am here to share the way I came to think about building a website.
My goal is to cover the thinking process that goes into the actual planning and building of a website in a very specific case:
- The websites I help build are around 80% static and usually not extremely complex
- I already have a good idea about the technologies I have to use and the file structure I have to adhere to
- Finally, due to the nature of our projects, I am the only front-end developer who works on a project - at least until a first working version is finalised.
All in all, the only variable left in our equation is the website's actual front-end implementation. This is where the thinking process is fired up.
Design is my friend
Before delving into any kind of coding activity, I reserve some quality time with the design files. The main goal is to understand what I'm about to build.
I try to look at the details - to understand the overarching functionalities and possible interactions that may not be evident from the design.
But I also think that it's important to analyse the designs as a whole and understand not only the effort that the project needs in terms of time, but also if there are any difficult challenges ahead.
More often than not, I would do the following:
- Meticulously go through the design files
It's also important to remember to check if you have the right format on hand; you should be able to easily take up measurements, export any graphics and check font sizes.
Write down anything that needs further clarification or details
Along the way, I would ask myself: is there something that could be improved in this design? Is there something that - for any reason - could be difficult to adapt on mobile? Could I propose a more technically-appropriate solution? Do I see any issues with the designs, overall?
Sometimes, the best people to discuss the above could be either the designer you're working with, or the project owner/project manager. The result of that conversation should be one or many user stories, as I will tell more about in just a moment.
Let's go on a... user journey
I am aware that there isn't such a thing as a "complete list of requirements". We can never know everything that we need or want in a project, especially in a software-related one.
But I think that once we start writing things down, we already have a good starting point.
As in any other circumstance - writing forces us to clarify our ideas about what we think that needs to be built. Writing things down boils down those ideas to just one, cohesive version of themselves.
Now that I am comfortable with the designs and the requirements, I try to break down the work into larger chunks, making sure I include test cases.
I found Gerkin to be quite useful for doing that.
Not only that test cases help my colleagues from the QA team to understand what exactly needs testing, but it's also clearer for myself in terms of what I should implement. Writing test cases early on it could indirectly document the decision-making behind any possible change - adding transparency into the entire process.
Divide et impera
Now I can start building! Well... almost!
The strategy I am currently undertaking is very much on the divide and conquer side. I am trying to build one thing at a time.
I divide my user stories into even smaller logical units of work.
There are a few benefits stemming from this, such as:
- I'm keeping my PRs short, on-point, and thus easier to review by my colleagues
- I can plan my work, and I can do that independently
- Knowing what's ahead, I can keep track of the progress and have a better grasp of how the project is going
- There's also the added psychological benefit of all of that: having a sense of ownership and confidence along the way.
Laying one brick at a time
While I work on smaller logical units of work, I make sure that these are - when possible - worked on in isolation.
I look at the designs and select the sections or elements that could be reused throughout the website. If I have a simple call-to-action section, I ask myself about the possible variations that that component could have, ignoring the context in which it should live. For the context itself, I will build another component and create its own rules.
Perhaps the most compelling benefit of this approach is the confidence of integrating an independent, fully-working component into another. All of a sudden, I have less things to worry about - and I can just focus on the actual integration between them, which, most of the time, could be much simpler to do.
This avoids overcomplicated style rules and messier HTML and it encourages better class naming.
In conclusion
These are the main aspects I have in the back of my mind when starting a new project, excluding the technical side.
I am always trying to look at what I'm doing - day-by-day - with a new pair of eyes and tweak, change or remove things that could be done better, or more efficiently.
If there's one thing I look forward in my daily work - that's change. And I hope that everything I wrote today will, in the end, be a fortunate "victim" of change.
Oldest comments (0)