Here at Watermelon, we regularly work with Magento (or WordPress) projects starting from the ground up by estimating project costs, implementing Content Management System (CMS) solutions, creating and deploying site designs, and working with product, customer, order, and content data for a variety of eCommerce, membership-driven and boutique web sites. Magento and WooCommerce are favorites for different reasons.
We also regularly get requests to inherit Magento and / or WordPress sites already in production that require design updates, customized site functionality, and/or code updates in order to resolve errors or other unexpected site problems. When we feel we can provide solutions for inherited sites like these, we typically respond with an enthusiastic “Yes, we would be happy to plug in”! We pride ourselves for identifying and resolving issues as efficiently as possible, taking great care to be non-disruptive while working with production sites.
Unfortunately, we often find problems that stem from inefficient or confusing development practices from prior developers. For example, problems with code written without regard for ‘future-proofing’, hard-coded variables that cause unexpected front end behavior, and code written with what I call the ‘swiss army knife’ approach, that attempts to implement a variety of customization features but are fragile, convoluted, and prone to breaking when the core features of the site require an update.
We recently have been resolving the ‘swiss army knife’ approach on a very large, very active Magento 2 eCommerce site, which required so much additional troubleshooting, different staging environments, and trial and error approaches to enabling/disabling features that prompted us to write this post, which we hope will outline our coding practices that attempt to circumvent these common customization problems. This style of coding is called Lean Development, and is essential to keeping sites easy to debug, easy to update, and easy to implement new features.
The idea is simple: when creating new features, keep things simple, short, well documented, and focused. I will first describe a recent example of how this style of code production was NOT utilized, the problems it created, and how they could be avoided.
When the Magento 2 Swiss Army Knife Breaks Down
In a recent Magento 2 site we inherited, we noticed immediately the core structure of the code base was highly modified, which was the first red flag. Upon further review, we noticed the prior development team implemented the ‘swiss army knife’ style of development: there was one, large, convoluted custom extension that handled a huge variety of features. The code base was fractured and didn’t conform to Magento 2 standards of code isolation and scope. The extension also used a large amount of simlinks, which linked from where Magento 2 expected the code to be, back to the convoluted structure of the custom extension.
This made it a huge problem to determine what parts of the code could be disabled for testing: if we disable this specific module, will it have reprocussions with other modules in the extension? Usually it was unclear (and often disruptive) to determine the answer to this question.
The client also wanted to make sure the Magento 2 core code was up to date with the latest version. This would almost certainly cause the site to break upon doing so. Because the code was written in a structure not recommended by Magento coding best practices, finding the code that needed to be updated was far more difficult than if the structure was using acceptable coding methods.
Another problem was wading through all the code to disable features the client no longer needed. If the custom code base was organized properly, finding and modifying the correct files would have been much simpler. The ‘any-size-fits-all’ approach added much more overhead to our development time, which of course adds a great deal of unnecessary burden to the project budget.
The Philosophy of Magento Lean Development
So, how can the lean development philosophy help to avoid this problem in deploying site customizations? Here are a few key principles to adhere to:
1. Keep it Simple
All Content Management Software (CMS) solutions have an established, documented code structure. Your custom solutions should inherit the ‘best practices’ defined by the CMS code base. More importantly, the customizations you need should be concrete and well-defined. An ideal customization should do exactly what the customization spec requires. No more, no less. ‘Bloated’ code only makes future updates more difficult. This idea is similar to the next principle.
2. Keep it Lean
Isolate and define the parts of your customization in such a way that isolates the code in discrete, easy to understand chunks. This means creating discrete classes that do simple, easy to understand functions. It is much easier to deal with 10 different, defined chunks of code that do different tasks, than dealing with a 1000 lines of code in one file. This makes development and debugging much faster and much easier to make incremental changes.
3. Separation of Concerns
This philosophy can be applied to all manner of software creation, such as UI, back-end programming, database schema, and more. The idea is to properly separate parts of the program dependent on their functionality. Keep code that displays the front-end separate from code that executes custom business logic, or code that accesses database information, or code that responds to actions from the user. This philosophy increases the ease of addressing issues by keeping the code organized in a sane fashion.
4. Testing
This one is a no-brainer. Be sure to allow time in your development budget for a proper QA of the site after customization work is done. Explore all the site features that can be impacted by your customizations from a typical user perspective. Attempt to ‘break’ your code, with unit tests or submitting erroneous input data. This step is critical, and while some QA will occur during development, there should always be a final QA assessment before customization is complete.
Keeping these principles in mind saves time, effort, and ultimately budget hours. We strive to provide the best solutions as efficiently as possible, and by following lean development best practices, our job becomes that much easier to do so.
Are you wondering if your Magento developer is using Lean development practices? Get in touch and we’ll help you find out.