Abstract the company away (part 1)
While my department at $work isn't strictly R&D, we still do a lot of development work. I'd dare say we average a rather healthy amount of code, taking into account we also try to be rather minimal. Code is simply a means to an end, it is not your goal.
We get to write a lot of code that interacts with our systems, and a lot of duplication is achieved by mistake. Sometimes it's stuff people don't realize is indeed duplication, or they think it's unpreventable. I've decided to tackle this. I've presented some of my findings at Weborama after giving my Moose talk, and they really enjoyed the ideas, and I've decided to write about them here as well, in more detail.
Since this is a lot of text and I hate reading a lot at a single time, I decided to parcel it out to smaller portions. This part will focus on refactoring schemas.
We started with code that needed to access a database, so we used the really-kickass DBIx::Class. Once we defined our schema, we were able to reduce our code and increase our readability by quite a bit! Unfortunately code that was irrelevant to the current project had to use the schemas as well. At first smaller portions of those schema was planned to be embedded. However, instead, we decided to separate the schemas.
I started by creating MyCompany::Schemas which included schemas for our major databases. Inside MyCompany::Schemas you had MyCompany::Schema::Kitties and MyCompany::Schema::KittieBeds. Then all code was converted to use MyCompany::Schemas.
At some point we noticed we have a problem with slow performance. What we noticed is that we're using two schemas which connect to the same database, and thus creating two different connections. How silly. DBIx::Class of course supports providing one host for multiple schemas. You just have to configure it correctly. Once we've done that, our performance was greatly increased.
Now that we have our schemas, we can push all the useful searches that are done in more than one application to the schema objects. Instead of each application doing the same search, just have a method in the schema that provides that search.
That's it for now! I hope you found it useful.
Following posts will discuss much bigger and more elaborate refactoring for database authentications, user access control and system-wide configurations for applications.
Gots to do the bloggingz
Not to be mean, but, please take a bit to read this: http://plasmasturm.org/log/340/
Meanness out of the way, this looks to be the start of a very nice series. Are you also going to be talking about how you host/disseminate those things in your company?
I don't understand what "meanness" you're referring to, or what this link contributes to me. Could you elaborate?
I could add another post on how I maintain and spread $company code.
I guess he doesn't explain it in the clearest terms: Using obvious fake names in an explanation about programming makes it harder to understand what is being explained than if real names pulled from actual work context were being used. Granted, this wasn't so much an issue for your post, but it still does it, which is simply an indicator of a non-optimal habit. :)
I'm sorry but I vehemently disagree the association of that (perhaps bad) habit with what I was doing.
Sometimes you simply aren't able or willing to share private details, sometimes even the company name. This is not your business but mine. Giving a opaque term such as "Foo::Schemas" is one thing, but giving "MyCompany::Schemas" is another.
The company name thing is fine. (Though i personally would've preferred CompanyName.) :)
The kitty thing gave me reason to pause and feels wrong. (Unless your company actually is a pet hostel aimed at cats only.)
I honestly did not want to give the names of our databases but instead gave something relatively equivalent. "Kitties" is a akin to "Users", and I assumed an average programmer would have identified that.
Still, I'll try next time to provide names that are more useful and meaningful.
Thanks for the input.
It’s not even the complaint my article was really about.