Tricky code and concentration
Mar. 23rd, 2016 07:37 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mtbcI recently wrote about the OME data model. I work on code to do all kinds of things on directed graphs of model object instances whose property values constitute edges; I'll write about that separately as it's tangential to tonight's entry. One thing my code does is duplication of some specified subgraph, grafting it into the previous graph as appropriate.
I'd also mentioned our use of Hibernate for the ORM. The duplication makes use of this. For the uninitiated, ORM makes your relational database tables look like related objects to your code. You can change property values, etc., and your changes are written back to the database. Hibernate is a popular Java library that provides ORM. However, it's sufficiently complicated and buggy that one determines what works somewhat by experimentation, and generally ends up wishing that one had stuck with JDBC instead. Many of our Hibernate and JPA annotations, which control exactly how the object model relates to the database, are produced from the automated code generation I'd mentioned.
Duplication of subgraphs is actually quite tricky as there is a fair bit to keep in mind and watch out for: one can see how it should be possible but down in the mud there are several issues to recognize and accommodate. My code has appeared to work fine for months, even as I added further automated tests of it, but this month I stumbled upon a plate from a Maia Scientific microscope for which it reproducibly fails. My current guess is that the failure is another case of Hibernate not making the object model a seamless view of the database and I must try asking correspondingly less of it.
Unfortunately, the change that I think might fix the problem involves refactoring the trickiest part of my duplication code to complicate it further. This morning I'd cleared the decks sufficiently to dare to face it. I had valid reason to attend an interesting digital pathology seminar at noon but I nobly skipped that as too good an excuse to avoid what actually needing doing.
This brings me to the actual point of this entry. I was quite conscious of that, to understand my code well enough to see how to refactor it, I would more or less have to fill my head with it. It hurts and takes a while and, knowing this in advance, I was reluctant. A trick with which I get myself started is to make code changes that I am confident are close to what I will need even if I am not yet sure what will work for other parts. Once I again understood my duplication code well enough I was thankful that I had bothered to comment it well the first time around. Then, I had a good afternoon refactoring, in which I lost track of time and turned enough of the hard thinking into new code that tomorrow morning I can continue to work on without understanding as much, as clearly, all at once.
It is interesting how that happens. It's far easier when I am working from home (or in a private office) on the kind of project for which people can just have me surface a fortnight later with a new chunk largely done. Then, it can all more or less stay in my mind and I can live and breathe it. Whereas, in an open-plan workspace with myriad distractions, including today a brief meeting after lunch, a question from someone using my code where it turned out their code was buggy, a question about use of our command-line interface, and another question about test data, it's a rare treat to really be able to concentrate on anything for a few hours.
In the end, in view of the further complexity I added, I broke out the code into more methods and another helper object. Tomorrow I'll tidy, document and test it, and see if my blood and sweat sufficed to placate the Hibernate gods.
I'd also mentioned our use of Hibernate for the ORM. The duplication makes use of this. For the uninitiated, ORM makes your relational database tables look like related objects to your code. You can change property values, etc., and your changes are written back to the database. Hibernate is a popular Java library that provides ORM. However, it's sufficiently complicated and buggy that one determines what works somewhat by experimentation, and generally ends up wishing that one had stuck with JDBC instead. Many of our Hibernate and JPA annotations, which control exactly how the object model relates to the database, are produced from the automated code generation I'd mentioned.
Duplication of subgraphs is actually quite tricky as there is a fair bit to keep in mind and watch out for: one can see how it should be possible but down in the mud there are several issues to recognize and accommodate. My code has appeared to work fine for months, even as I added further automated tests of it, but this month I stumbled upon a plate from a Maia Scientific microscope for which it reproducibly fails. My current guess is that the failure is another case of Hibernate not making the object model a seamless view of the database and I must try asking correspondingly less of it.
Unfortunately, the change that I think might fix the problem involves refactoring the trickiest part of my duplication code to complicate it further. This morning I'd cleared the decks sufficiently to dare to face it. I had valid reason to attend an interesting digital pathology seminar at noon but I nobly skipped that as too good an excuse to avoid what actually needing doing.
This brings me to the actual point of this entry. I was quite conscious of that, to understand my code well enough to see how to refactor it, I would more or less have to fill my head with it. It hurts and takes a while and, knowing this in advance, I was reluctant. A trick with which I get myself started is to make code changes that I am confident are close to what I will need even if I am not yet sure what will work for other parts. Once I again understood my duplication code well enough I was thankful that I had bothered to comment it well the first time around. Then, I had a good afternoon refactoring, in which I lost track of time and turned enough of the hard thinking into new code that tomorrow morning I can continue to work on without understanding as much, as clearly, all at once.
It is interesting how that happens. It's far easier when I am working from home (or in a private office) on the kind of project for which people can just have me surface a fortnight later with a new chunk largely done. Then, it can all more or less stay in my mind and I can live and breathe it. Whereas, in an open-plan workspace with myriad distractions, including today a brief meeting after lunch, a question from someone using my code where it turned out their code was buggy, a question about use of our command-line interface, and another question about test data, it's a rare treat to really be able to concentrate on anything for a few hours.
In the end, in view of the further complexity I added, I broke out the code into more methods and another helper object. Tomorrow I'll tidy, document and test it, and see if my blood and sweat sufficed to placate the Hibernate gods.
