Posts tagged code quality


Maybe you know, maybe no – it’s about five years as I’m involved in the Apache Struts project. About two years ago I became a Struts 2 Lead – whatever it means in non-profit organisation working on an opensource project where everyone is equal 🙂 Nevertheless I like what I’m doing – code and refactor 🙂 And as there is a plenty of code in the project and most of them need to be improved – I have what to do for the next few years 😀

Recently I’ve started working on a new plugin – the MVEL plugin – which will allow to use MVEL instead of OGNL to handle expressions. In theory the task wasn’t too difficult, Struts 2 already provides many extension points where you can hook in with your code. Replacing expression engine require to implement two interfaces – very simple and straightforward.  After I did that, I have started testing many possible expression syntaxes which are already present in unit tests.

And then problems show off :/ The main problem is conversion, to give you a hint check the below expression which simple means array in both – MVEL and OGNL


but the problem is how both engines handle such statement (pseudo code):

  • MVEL:
    new Object[]{Integer, Integer, Integer}
  • OGNL:
    new ArrayList(){Integer, Integer, Integer}

As you can see the difference is slight but important – the wrapping object is totally different. And then goes conversion logic, as I wanted to get string on output, built-in conversion mechanism do this:

  • MVEL: [1]
  • OGNL: [1,2,3]

Not so good 😉 The problem is that the conversion logic is too narrowed to OGNL. After some internal brainstorming I’ve came up with a plan – to allow other expression engines to work with Struts 2, first I must decouple conversion logic and OGNL 🙂 So the plan is:

  • extract conversion mechanism to allow replacement of it (another extension point)
  • simplify current logic related to converters created by users
  • implement more common logic to allow handle wide list of results
  • implement MVEL specific conversion
  • implement MVEL plugin 🙂

As you see the plan is simple, but as it is with plans – it is good to prepare them, but to follow them is a different story 😉

Finally, I found something interesting in the latest newsletter from TED – something about attention 🙂

metrics and worm holes

It took me more time than I’ve expected to start the New Year on my blog. So here it is, the first post for the New Year! Happy New Year!

The last year I was at conference and attended to ‘s presentation about . This talk based on his post on the IBM’s web site about and the whole series.

The talk was about and – quite interesting tools to discover potential bugs and hard-to-maintain code in a project. What was the most important for me, Neal used the  project as an example, especially the class – you can find the details in the mentioned article. He presented how to prepare these metrics, how to read them and what they mean. A really interesting talk.

After all, I’ve asked Neal to give me more details about the problem and few days later I received an e-mail from him. I’ve followed his advice and inspired by his talk I’ve gave a promise to my self that I must improve that badly-looking code.

…. but wait, it’s just a badly-looking code. It had taken me another few weeks to discover it isn’t so important to improve that piece of code, it really doesn’t matter right now. There are plenty of places to improve code base of the project and so many users don’t care about that – UIBean doesn’t exist for them.

The current UIBean implementation do the job, it isn’t pretty or easy to maintain, but right now there is no one for whom it is important. No one complains about it. Some day I’ll refactor the code of UIBean class but today isn’t that day.

The conclusion is the same as for code optimization, you shouldn’t optimize too early, so you shouldn’t improve too early. Don’t throw everything and try to improve some bandwagonhost vps not-important part of your project. Don’t trust metrics by heart, they can lie to you, try to figure out what they mean in context of your knowledge of the project. They aren’t a silver bullet.

Today’s day brings to me another newsletter from web site and gave me answer to important question: the shortest connection between two points is …

beautiful code

Yesterday I had to help a younger team mate to solve a simple problem with persisting data with HTTP session. Case was quite simple but proposed solution wasn’t the best. We discussed other possibilities and found that what we had done is the best one for given circumstances. He did the work and has committed changes to source repository and then informed project architect.

As I said, solution wasn’t prefect but was the simplest one and easy to understand in the future when someone else who will take a care for the project. I took a look on the code and it was etoro beautiful! Separated meaningful method name, named constants for String literals, null safe – beautiful! And all that was achieved without any comment from my side regarding how a code should looks like!

half a way

I started, mentioned early code clean-up and refactoring. It was huge task but quite simply – I just had to keep focus on what I was doing. I implemented all the changes and confirmed that everything was ok with Unite tests. No problem so far!

Then I decided to committed the code to have clean starting point for next step. In first step I just introduced one common interface which base on Template Method pattern and reimplemented all needed concrete classes. After all I had one common interface to use in many places, it simplified many operations and I was able to cut off bunch of unneeded methods.

That was the half of way. The second part was to used custom Enums instead of String constants. I implemented the Enums and started replacing Strings. It was very bored and could introduce accidental bug. Hopefully it didn’t – lots of manual typing without mistake!

I reran the tests to confirm that I didn’t break anything. Done and committed! That was all for today, tomorrow I will still try to simplify the interface. To have less code needed to cover by tests 😉

too good

As I said last time, today I was assigned to a new task. The job was mostly done by a team mate, I just had to implement some additional functions – basically extend already existing logic. It was an old code I’d written some time ago, but was a bit overused and became a mess. So, I thought to clean-up it first, to did it in right way. I’ve started refactoring some large parts of application and after three hours I still was in middle of nowhere, with bunch of  changed classes. Neither new functionality wasn’t done, nor code clean-up.

The time was important, so I decided to revert back all my changes and start again with the simplest changes to met requirements. I also dropped idea to improve code quality in the same time, I had already registered some extra time with PM to do this later. Anyway, after another two-tree hours, I finished and the team mate was able to moved forward with his changes.

I committed my changes and also he did the same. Than we verified the application and double-checked all key figures. Everything was as expected, we were able to mark bug as solved.

At the end of day I started refactoring and cleaning the code, that work will follow during upcoming days!

I also begun introducing Zen-To-Done in to my life, it should allow me to better manage my time and life 😀

done, busy, exciting

The last two days were very busy – I was polishing the application and the print layout to be for sure ready for upcoming training next week. I had to add missing mappings from UI to Data Model – many of them wasn’t in use because there wasn’t 外汇交易平台 needs for that 😉 That’s the worst thing – design application and a model to satisfy only given context. In such way it’s very hard to add another functionality without breaking what was done already. Especially if there hadn’t been any unit tests.

The application and print layout are ready for test and I’ve got new assignment – I must help team mate to solve high priority bug which prevents starting training phase of the main application. It was discovered few days ago and he already did a great job to accomplish it, but I will have to double-check in case of side effect of his changes. If we deliver the application on Tuesday, than we have also clean-up the source code in such area to improve code quality.

The upcoming week will be very buy. And exciting!

hidden plan

As you maybe noticed, I wrote nothing for yesterday. Frankly, I forgot about that because I’ve been testing delicious bottle of wine 🙂 But there is one thing worth to mention – I had got my books from Amazon – , and . Lot’s of reading.

Indeed,  but that is connected with my hidden plan. After I read all those books, I will propose to introduce Scrum methodology to the company. I will not be easy, but I have to try, what can I loose?

And the last thing, we finished our Clean Code Days. It took two days to clean almost all warnings from the Checkstyle. We discovered some hidden bugs, so it wasn’t wasted time. Any way, we figure out (as team), phentermine that code quality matters and we will try to keep it high and always on top. The work is not done yet, but that was the first step to build stronger team of highly skilled developers. What an exciting future is coming 😀

the d-day is comming

I spent the whole day preparing Issues for the Clean Code Day. What the Clean Code Day is? It’s a day when we put the effort to improve code quality by removing unnecessary comments, some Checkstyle warnings and so on. It isn’t optimal way to solve such problems, but in our situation, the only one! We have about 3.000 warnings from the Checkstyle – quite a bit! So we’re trying to improve the Code Quality each day – when you’re working with some class, clean it up, improve a design, split huge methods – be aware!trailer film Conni und Co 2 – Rettet die Kanincheninsel

Tomorrow I will host a meeting for the reset of the team, to explain what we want to achieve and why. How to solve assigned issues and do even more. It’s a vacation period, so it shouldn’t be a problem – almost nobody is testing the application. And the most important thing is that, we have a bless from Project Manager!

task force

Our project have a big problems with performance and to improve that, the Task Force was introduce few weeks ago to help us.  The Task Force are the group of very experienced Software Architects which are trying to dig in to the application to find what is wrong, what “stinks” 😉

Today, we spend the whole day on the meeting with Task Force, we have been discussing what is wrong, how can we improve the Code Quality and how to be a better software developer 😉 I can agree with them in many places, they have been presenting almost the same point of view as “Uncle” Bob in the book Clean Code, but I also disagree in some other places. Anyway, I’m planning to take some time to try to introduce theirs idea and to see what will happen, incoming vacation’s period it’s a good opportunity to do that!

Go to Top