I really dislike things that are implicit. Okay, it doesn’t help that I’m the most forgetful person I know, but still.
I’m a believer that if you want something done, you should do it. Use a framework if you like as a tool, but explicitly ask that tool to perform the task. Things shouldn’t be hidden away, doing as they please.
Post build steps
I’ve mentioned it before, but I really do like my build process to explicitly do everything I need, in one place.
My boss gave me a tip yesterday. He says that for things like this:
insert into a_table (id, the_value) values (1, 11)
He sometimes cheats and does this:
insert into a_table select 1, 11
I think that’s dead clever (because I thought you had to specify the columns you want to insert into), although I’d personally never run it on a production database, and it would only be for quick and dirty test code on a database I control. The problem is (and to be fair he admitted this), if someone changes the schema of that table, things can get messy very quickly. I’m more anal so my first thought was that I just like to know what columns I’m editing without having to investigate that table schema before I run it.
Of course we all know the evils of:
select * from a_table_that_might_have_columns_added
Which speaks for itself, so let’s not dwell on that.
Attack of the Scheduled Job
I personally dislike any kind of scheduled task. It makes me nervous to think that there’s an unknown cloud of processes that I don’t know about that might be editing my data without me knowing. Also, you lose a bit of the “realtimeness” of information with scheduled jobs. Of course sometimes this is necessary, as in the case of maintenance tasks.
So I like to do things by hand a lot of the time. I don’t like to write classes that do work in constructors, I prefer instead to use factory methods or create static methods called “Load” which create the object and populate it for me. Right or wrong is tough to decide, and is probably a religious issue as much as anything else. But “better safe than sorry” and “keep it simple, stupid” are principles that make applications easier to maintain, because you avoid more issues from happening, and make it easier to find and fix those that do appear.