Having worked on many web development projects over the years, I can confidently say that the way to enjoy programming is to work in “bite sized chunks” of code, code that provides a single service. This is known in the WordPress community as a Plugin!
As the scope of a project increases over time, with every project giving birth to little baby projects, developers often find themselves dealing with a spaghetti mess of code. How do you remember thousands of lines of code that produces a result, especially among dozens of projects?
Earlier on, the key to keeping code scalable was the use of objects, and object oriented programming techniques. For example, you would create classes of functions and variables and store them in appropriately named files. For example: ‘class.students.php’ or ‘class.teachers.php’.
This concept then was taken further with the notion of frameworks and model-view-controller frameworks. Frameworks provide a stock set of objects, for example: ‘users’. Frameworks separate the code that produces logic, design, and interaction.
Web publishing platforms such as WordPress, or content management systems, take this concept even further by providing an inherent set of documented, supported objects, user interfaces, and community contributed bundles of design and functional packages. WordPress calls these packages themes and Plugins.
We always preach about the need to keep design/layout/style code within themes or child themes, and any functional/logical code within Plugins. What we haven’t preached about is the need to keep Plugin code down to single service operations. We like keeping Plugins sized to these “bite sized chunks” because each Plugin becomes a unit test to work on, something that can be enabled/disabled, plugged-in and plugged-out, and distributed among sites accordingly.
Often times marketing trumps the practice of keeping themes and Plugins simple, because packaging software features exposes more to the market. However, this practice does little to help users manage their limited resources within their websites. Developers prefer managing modules that they can easily comprehend the purpose and structure of, especially as multiple developers get involved. We have WordPress and Plugins to thank for this new opportunity. A future concept of child Plugins may improve upon this architecture further, but for now we at least have best practices to follow to make everyone’s job more enjoyable.
Thank you for taking the time to read this post. Note that we really appreciate feedback about what we’ve written as well as what topics you’d like us to discuss in future posts so please do let us know.
beAutomated 