As coders, many of us would have started our development career by writing scripts or code that we found helpful, which helped out with a hobby. That buzz, the insight that you can create something practical and useful, that's where the passion starts. It's from these hastily assembled first few lines on which many of us have built a career.
In those early days, we found ourselves writing code that spanned hundreds of lines, but with no regard for how it might look if we came back to it in six months. Would it be understandable? Can a feature be added without breaking something else? Also, what if we want to share it with a friend or on the Internet? Trying to work out the cause of a bug is going to rapidly become a nightmare.
In fact, the Internet is littered with such code. Why is this a problem? Let's say you got roped into building a simple shopping cart for a friend. You knew enough to get it working, but also enough to be dangerous. A shopping cart is responsible for taking payment for goods, and a single security hole could result in someone being out of pocket. Suddenly, your favor for a friend has become something that has caused them to lose face and money.
Fortunately, in my case, there were no drastic ramifications for my lack of development expertise as a newcomer to coding. I created a PHP script. This script generated a photo gallery for a website. It started off as a list of photos and expanded to include thumbnail generation, pagination, and an administration/upload facility. It was an example of traditionally bad PHP with HTML mixed in with logic code and spaghetti loops to try and make the thing work the way I wanted.
With time, the solution comes organically; we start to break our work into smaller chunks that make sense for the application. It will slowly become clear that there are sensible ways of working, which make life easier, as your codebase grows. In the photo gallery example, I could start to extract very simple aspects (such as headers, footers, and pagination links) in order to focus on the core functionality.
Of course, not everyone starts this way. Developing a hobby into a career is just one path by which the coding community develops its skillset. University or online courses, books, and forums contribute to our learning process. The important thing to bear in mind is that neither coder nor architect was born into the world knowing everything and it's okay, even essential, to admit when there's a gap in your knowledge. From a senior consultant to hobbyist hacker, we're going to try and fill some of these gaps, as you build larger and more complex applications.
Rather than writing code that is for a hobby or side project, we're now writing applications that help run businesses. Someone is paying for this development time, and someone's livelihood is relying on it. As professional software developers, we need to adopt a professional mindset and skillset to match. Rather than coming up with an idea and sitting down to code it immediately, we need to carefully consider how our application is constructed. We need to ensure that it will work as expected when real-world users get their hands on it; this will provide a strong platform for future developers to build on.
As software developers, we can be responsible for tens of thousands of lines of code—and in many cases more—and may be working in a team comprising a range of other individuals. At this scale, badly designed applications can become unwieldy, unreliable, and difficult to test.
It's unwieldy because without a strong design, functionality is tacked on as it's required, building on an already shaky foundation; unreliable because this shaky foundation has cracks crawling with bugs, and difficult to test because the system's parts are so intertwined that each component doesn't have a clear set of responsibilities and capabilities.
This is the danger of taking an idea and running with it; you may be creating code that grows out of control like a weed in a garden. A design is the key because it allows you to be the gardener (carefully tending each facet of the system as it grows). We want to create a clear, positive structure for our team members to start from and build on.
The structure we want to create in an application should give us clear delineation between one component and another. Each part of the system should be responsible for itself and nothing more (a small part in a larger machine). The layers of our code (from data to presentation and all the wiring in between) should also be clear-cut because no one wants to see a template talking directly to a backend service.
This is a classic example of overlapping concern. In this presentation, code should never have to worry about fetching data, only how to present it. This, and many more such issues, can be easily avoided with a strong structure and application design that is implemented from the start.
Many have gone on this journey of scalability before us. It's worth remembering that there are many formal metrics to help us determine whether our code is too complex. "Cyclomatic complexity" is one example, a technique that evaluates details (such as code cohesion and branching depth) and can be tied into automated systems that raise a warning when a threshold for complexity is crossed.
In reality though, such metrics are a method of firefighting complexity rather than planning to avoid it. By looking at ways in which we can structure our code for success, we can minimize the need for such automated checks.
The first stop must be object-orientated programming (OOP). By encouraging a piece of functionality to be encapsulated in a class, we immediately impose a sense of separation in our application. Just as splitting our multi-hundred-line script into separate chunks made sense, here we can formalize this approach by creating classes that take responsibility for a single piece of functionality.
With the photo gallery, the pagination is a great example of where concerns could overlap. My original implementation just had a lot of loops and conditional statements wrapped up with the HTML. Instead, we can have one class that does the logic of the pagination (for example, whether the "next" link is available) and another class responsible for generating the HTML based on this data.
In Ext JS 4, Sencha brought in a new class system that allows you to better create objects that encapsulate application functionality as well as a strong application framework. Ext JS 5 builds on this and adds some extra features to make the Ext JS application architecture ideal for everyone (from individual developers to large teams). The structured approach that it makes available allows you to scale a code base while keeping its foundations strong.