Previous Entry Share Next Entry
Pissed off about code
I have rarely been as angry as I was today.. over code.   

I'm having growing pains.  I'm working with a team on a web app, which is very MVP with a BLL and a DAL.   Right now, we're finishing plumbing between the BLL down into the DAL.  And the level of indirection is ... onerous.

Here's what I'm used to:

If you have a person with subscriptions to magazines, then you might have a call where you get:

List<Subscriptions> = utility.GetSubscriptionsForPerson(Person P);
Which ends up at something like
"Select s.* from subcriptions S where S.personId = :personId"

In the previous projects i'd worked on, which had a DAL but not a BLL, this would then get read in a loop and sucked into a List<Subscription>.

In this new implementation, the way its layed out is like this:

  • BLL.IPerson.Subscriptions() returns List<BLL.ISubscriptions>
  • + Unit tests at this layer
  • lazy loads, calls
    • BLL.Services.SubscriptionService.GetSubscriptionsForPerson(BLL.IPerson)
    • + unit tests for this layer
    • which in turn calls
      • DAL.Repositories.SubscriptionRepository.GetSubscriptiosnForPerson(Dal.Person.Key)
      • which does the sql, and wraps them into DAL objects
      • + unit tests (acutally db-tests) at this level
    • Receives the list of dal objects
    • for each onenews up the lazy-loading BLL.IPerson.Subscription that matches that Dal object
    • + unit tests at the new-up-a-subscription level
    • Returns the list of BLL.ISubscriptions
  • saves the list for future references and returns it
hmm.. do the indents match?

In all, I counted  a total of 9 sources files, spread across 6 directories in 4 projects.


I think what's hurting most in my head is, i'm used to expressing creativity, getting it out there, and then moving on.   With the number of layers that I'm having to go through, its like a big buzzkill right in the middle of that creativity.   So, i guess there's that grief - the difference between my expectations on how fast I think I could/should be able to go, and how fast I'm actually going.   Before, i would rely on that inertia to just take me from one topic to the other, and coast in to get the thing done.  Now its like start! stop! other! back! forth! where the heck am I!   (and its basically // TODO: and a backlog that's keeping that sane).

The other part of that is the level of testing.   Its like.. finger-numbing.  Take for example, the database has some strings - say, "COW", "CAT", "DOG", "RAPTR".  The BLL has an enumeration - Cow, Cat, Dog, Raptor.    We have a switch statement that converts from one to the other.   Then, we have 4 tests !-

[Test] public void AnimalType_Returns_Raptor_if_dal_type_is_RAPTR() { ... }
[Test] public void AnimalType_Returns_Dog_if_dal_type_is_DOG() { ... }
[Test] public void AnimalType_Returns_Cat_if_dal_type_is_CAT() { ... }
[Test] public void AnimalType_Returns_Cow_if_dal_type_is_COW() { ... }

And then don't forget the test where its not set in the db, and the test where its a bad value - ExpectedException's.

I guess this is important, because what about if the DB had "raptr" instead of "RAPTR" ?   we must document this somehow!  and we document by writing unit tests.
Would be nice if we could convert the unit tests into assertion-based documentation.   

The frustration, specifically, is the amount of typing, copying, pasting, and the mistakes that crop up during that process.  Then again, when its all done, you KNOW its good.

What's the principle at work here

What's going on is part of SOLID and DRY (although i feel like i repeated myself ad nauseum in the above RAPTR tests).  

Each layer, each class, does exactly one thing -
- one method for selecting from the database
- one method for converting a selection from the database into a DAL object
- one method for converting a DAL object into a BLL object
- one method for converting a list of DAL objects into a list of BLL objects
- and then each one of the above has their 2-3 unit tests (boundary conditions)

How can I adapt?

#1. I'm not doing this for me.  I'm a paid software engineer, and for that, I must put on my company hat - this is not a hobby.  I'm doing it for the company, because they pay me, not be cause I like it.  Somebody has made the decision that this is how we're developing, so this is what I will do, accept it, embrace it, work with it.

#2. Enjoy it.  There's a feeling of joy that comes from things going green as you write more tests.   Work for that feeling of green happiness, rather than the "hey its done" happiness.

#3. Template it.  We use R#, i'm sure I can pull some snippets of commonly used code together.

#4. Go exactly as fast as I am going.  I cannot rush it.    I cannot use adrenaline here. 

#5. I have a choice - to be happy or not.  Being angry and pissy doesn't get me anything here.  I might as well be happy with it.

*Sigh*.  Okay, i have to be back at work in 8 hours.   Sleep, wake up as a new person.. God, please guide.  Thanks.

Tags: ,


Log in