The idea of creating more sustainable code seems to be a topic of war in development communities these days. To one side, hackathon regulars throw together spagetified code that takes days to debug and months to inevitibly refactor into a startup. On the other end of the specrum are men with beards and pipes that create architechtural perfection that never leaves their mind.
However, this idea of better architecture is worth looking at in depth because there are more benifits than just impressing the men with pipes.
The idea of segmenting my code was something engrained in my skull during collegete years sitting in the back of dry academic programming courses. The true value of this never set in while there (partially because the Java import statements were often as long, arduous, and incomprehensive as the library classes which they referenced). In fact, it didn't set in either when diving into web development and seeing that my controllers and models were becoming as fat as the frameworks upon which they were built. No, the point of truth came while watching a talk given by Uncle Bob. Even though I am not a ruby developer there was one thing that stuck out in the entire talk:
This is just plain old Ruby code! Well if your architecture is any good, your whole application should be non-web Ruby… You should be able to rip out your code and have a gem.
This took me back for a while. Especially in PHP, this seemed strange to me. I had never really written PHP that didn't either echo something out to the page, check the database, or know something about the framework which it lies in. In fact, I think that this is almost the rule for PHP developers. We are highly concerned with the web because that happens to be the outlet for our code. But, what if we wanted to grab that business logic and move it to a PHP based command line interface. If you are running in something like Laravel, this may be easier with Artisan, but let me complicate things a bit: you also are switching to flat .bson files instead of a database structure. Can your business logic still be ported?
Chances are, this seems like a crazy thought to you. But, in one week I went from mocked json responses in flat file format, to mongo DB, to non-normalized SQL, to normalized SQL on a remote API. Your logic has to be able to change.
Even for small projects, imagine the benifits if your helper can be abstracted to a package, put on packagist, peer reviewed through use, and a securtity edge case is found. You benefit from encapsulation because you can fix the edge-case update the package and roll on your merry way.
Or say you have a simple authorization schema 1=admin, 0=guest this works great for your app for months, but then you want to swap in a many-to-many authorization solution like Sentry or Entrust. Can you do this quickly and easily without having to change code all over your application?
For me, the first jump was striving for better architecture when creating the Laravel 4 Package Installer. Since I knew I was making a proposal for a feature in Laravel 4.1, I knew that architecture was a must. If you look at the code (which is still far from perfect architecture), you will see that there are small classes declared for Provider objects as well as a Provider Creator. In all honesty, the Provider Creator is still a bit tightly coupled for my taste, it only will take in .json files, in a best case senario, this would be something like a FileProviderCreator that implements a ProviderCreator interface that requires a create method. The less coupling, the more flexible this application becomes. In fact, this entire code surrounding the Provider is quite easily replaced with about 10 lines of code within the PackageInstallCommand (it is just a single line of regex and some json_decode references). In fact when you look at the Provider class it actually is little more than a StdObj (and the initial code actually used a Standard Object).
This pulling apart of tight coupling, and dense code has already jump started my development confidence and made it so that I am not afraid of the code that I am now creating. Sure there are more files, but a Provider file is much more readable and easier to debug than a long method that throws around StdObj instances with no set API format.
**Adendum
Since writing this post, I have puslished my first Framework (and web) agnostic Test Driven Package, Geocoder. It was a challenge using a TDD mindset while keeping classes as slim as possible. True, the original iteration of the code had raw CURL calls, then it moved to Guzzle with quite a few lines of configuration. Then I was able to find (Shuber/Curl)[https://packagist.org/packages/shuber/curl] allowing for an elegant single line:
$response = $this->curl->get($this->url, $attributes);
To make things even better, this package (which could have easily remained in my proprietary stack), allowed me to then create a simple Service which overrides the getLocationFromQuery method and allows for caching in a DB to limit my calls to the Google API.