Experiences in development
Published on Sept. 6, 2017
updated 2 years, 10 months ago
I've come to believe that the quantity of projects you work on don't dictate the quality of your products. That's one particular reason why I decided to re-embark on a second iteration of Windflower. Some people don't like to revisit old projects, and prefer to start something new. I've come to be annoyed with old works that I started itching to make them better.
Here are some short lessons and tips I've learnt from the first iteration of Windflower that I've rectified in the upcoming version.
Seriously? That's the first thing I'm going to say? Yes. Surprisingly, the lack of communication for the first iteration led to many assumptions.
"I think the users will..."
It never ends well - assuming what your client wants, and how the users will behave is a one-way path to hell. For example, this could lead to poor database designs which could eventually lead to extremely slow querying speeds, on top of many other issues. Something more on the front-end: poor user experience - too many unnecessary stuff they never asked for, weird user paths from cart to checkout...it never ends...
Thus, the importance of proper planning and wire-framing. I daresay that in projects after the first iteration last year, I began to relook at my entire process - was I planning? was I thinking before I started coding? No, I wasn't.
I think it's safe to say that proper web developers should spend 70% of the time planning. This includes, planning the architecture, the UX, and the pipeline.
Proper planning allows for a much clearer logical blueprint when you code, thereby reducing spaghetti code and bugs. It also allows you to constantly be aware of how the project is progressing, and there will be less times you feel in the middle of creating a component.
Here are some ideas to get you started on proper planning:
- ALWAYS start with understanding the project's requirements, from the client, from the user, from whoever is a stakeholder - I cannot emphasize this more. Without this, you've already started on the wrong foot.
- Wireframing: start by drawing it out, how the pages are laid out, how they link with each other, how various user stories play out
- Wireframing v2.0: use a tool like Sketch or Photoshop to bring the penciled drawings to life - this isn't always necessary if projects are small-scale but it helps you when you're working on the front-end. It REALLY does. Imagine having a nice image of how the page should look right in front of you and all you need to do is code out the HTML and CSS to match it. On the other hand, if you DON'T do it, you might find yourself creating stuff on the fly which might turn around and bite you.
- Design your database properly: based on project requirements, assess what data needs to be stored and check with your client. From there, design the schema GENEROUSLY - this means not to denormalize prematurely. As you go along, there are many other things to optimize your database before you decide to normalize
- Think hard about the right architecture - this means the entire app structure, from the best folder structure that suits your needs to how each component fits together - it's ok to change this along the way, but it's something to constantly be aware of. The last thing you want is to bury your head coding and finish only to find that you longer understand what you just did
- Plan to fail: always document your code and insert proper exception catching and logging code to ease your debugging woes; you can even go to the extent of planning bug trackers to keep track of what bugs you've experienced so when you meet them again, you save yourself time!
These are just some ideas to get you started and is definitely not all. I'm learning as well and I believe you'll find better ways as you go along.
3. Isolation of Concerns
This is closely linked to proper architecture. Always keeping your code neatly sorted out and your general web app architecture well thought through goes a long way. Being able to know what each and every component or service does will help you easily track down where bugs arise. As code becomes more complex, it is more important to keep reminding yourself to keep things simple. For example, when a certain function starts getting too long and you start to realise it's getting heavy - think about how you might be able refactor the function: maybe create utility functions? maybe split the function's logic elsewhere? Most of the time, there is always a way to keep things simple and DRY (Don't Repeat Yourself)
It's a never ending journey, and we keep learning. I guess the most important thing for any web developer, software engineer, or human being is to constantly reflect - the ability to grow from experiences is priceless. More specifically, the ability to debug with critical thinking must be the most valuable asset of any programmer :P