Skill Builder: Write a Shopping Cart

Some projects are great for building your skills as a developer. A shopping cart can cover a wide range of skills and is definitely a worthwhile playground.

Another Shopping Cart?

Before you dismiss this completely, I am not suggesting you build a complete, working shopping cart; merely that you build a cart as an exercise. We aren't trying to build a serious competitor to Shopify; we're trying to improve our development skills.

Picking A Project

Selecting a project to build experience can be hard. TODO projects are popular because they have a clear set of requirements. This is the same reason a shopping cart is a good choice. It's something you know enough about to attempt.

Requirements & Goals

Odds are you've used at least one e-commerce website, so you already have an idea of how they work, even if you don't have all the technical details.

Building a basic cart and then adding features is a great way to get a feel for breaking down big projects into smaller tasks and creating maintainable, extensible code. It can be a small enough project to try different design patterns with, or a big enough project to work on how you break your code down into libraries and modules.

Do you want to try a new framework or data store? Do you want to re-think how you code with promises or functional reactive programming? Try it on a shopping cart!

Defining the Task(s)

A shopping cart is a mix of clearly-defined expectations and limitless possibilities. Ten people could create ten different lists of priorities and requirements, and that flexibility is great for test projects.

Shopping carts touch on many different aspects of design and development, of display and data design. What does a product entry look like? What about the data object that represents it? This is a great sandbox to see what issues you run into, which can help you identify these same issues in future projects.

Try and See

Many of the capabilities of a shopping cart can be developed in any order, so it makes for a great development playground. And, because you don't have to spend much time on the basic requirements gathering, you can dive in! Take a moment to think about the first steps you would take designing a shopping cart...what would you do first?

Starting Questions

Think about the features you want to implement.

• What should the cart look like?
  
  
  
  
  • A separate page?
  
  
  • An overlay?
  
  
  • A sidebar that is always visible?
  
  
  • Multiple appearances depending on context?
  
  
  
  
  
  



• Should products have in-stock quantities?
  
  
  
  
  • Should the quantity decrease as you add items to the cart?
  
  
  • Is there an "out of stock" appearance?
  
  
  • What happens if an item in the cart becomes out of stock?
  
  
  • Is there a "limit # per customer" feature?
  
  
  • Do all products need quantities?
  
  
  
  
  
  



• Do any items support options or configuration?
  
  
  
  
  • How does that affect inventory or "out of stock" appearance?
  
  
  • Can you/how do you support options in search?
  
  
  
  
  
  



• Do you have product categories?
  
  
  
  
  • Can they be filtered or sorted?
  
  
  
  
  
  

Takeaways

Building up from scratch is really about learning. The goal here is to try something.

Failure Is The Best Option

One of the ways you learn is by seeing how things don't work out. Because many of the basic requirements are implicit, you can focus on writing code and running into problems. When you find something that doesn't work, that's great! Now you have to figure out the problem.

• Can you adjust your existing design, even if it isn't the best solution?


• Do you need to re-work part of the project?


• Did you discover a fatal flaw in the basic design that would prevent you from supporting features you wish to add later.

These are all great discoveries because they teach you to change your approach, work through challenges, and sometimes accept there isn't a good answer with your current code. These are difficult realities at work, and being able to communicate that you've hit a point where re-writing might be better than refactoring can be helpful information.

Comparison is The Thief of Joy

Shopping carts are good exercises, but it's also easy to get caught up in the idea that your project needs to do everything that Amazon.com does. But, it doesn't. The point of the exercise isn't to build the best cart, or achieve feature parity with a major vendor. Having worked on custom carts in the past, very often the lack of complex features is a selling point. So don't worry about what your project doesn't accomplish; it's there for you to learn.

Building Requirements.

If you stick with the project a while you may run into functionality that isn't as obvious or straightforward to design. That can be a good way to transition to creating and understanding requirements.

• Are there rules for this functionality?


• What must it do?


• What must it not do?


• Does it change other functions?


• How do I test this requirement/decision?

Conclusion

Coding can be fun, challenging, or – ideally – both. A shopping cart combines basic expected functionality and the freedom to pursue many different options, which opens you up to trying new things and seeing how your design decisions and coding choices build and compound over time. This is a great way to introduce yourself to different project structures and data handling decisions.

I hope you'll give it a try!