IDRsolutions has always been an agile development operation and in 2016 we made a number of changes to improve our development processes.
What we did in 2016
Here is a summary of our major changes:-
1. Make code more modular
After 18 years of development, we had ended up with a small number of large projects. We split the 340K lines of code we have into 18 modules (which combine together to provide our end products).
2. Move to Maven and Git
We liked Mercurial but Git is clearly the more popular repository and so we switched from Mercurial to Git. We still have some legacy Ant scripts but we also took the opportunity to move from Ant in our IDEs to Maven.
3. Run more static analysis tests
We have substantially increased the number of tests we now run and we now use the static Analysers in NetBeans and IDEA as well as FindBugs and PMD. We have continued to switch rules on each week.
4. Announce Move to Java8
We want to get the balance right between backwards compatibility and embracing new features. So we publically announced (with 12 months notice) we would move from Java6 to Java8 in April 2017.
5. Rewrite old classes
Have you looked at old code with fresh eyes? We decided as part of our plans to move to Java8 in 2017 that we would review the old code and tidy it up. We especially wanted to ensure that it was easy to maintain for the next 19 years!
6. Refactor code
We refactored lots of long methods and split large classes where these did not impact the public API.
7. Custom builds
We started to offer our Enterprise clients their own custom builds. So they could leave out the Viewer if they were just using the software as a server solution. We also provided a custom area for downloads and custom tests.
So much for 2016….
What will we might be doing different in 2017
Now we are looking at what we may do in 2017. Here are some of our possible ideas:-
1. Increase modularisation
We could split the code into many more modules.
2. Totally replace Ant
Is it now time to move completely to Maven, or make we should be looking at a replacement for Maven as well?
3. Investigate Java9 enhanced version
Would a Java9 only version be a useful option or is Java8 good enough?
4. Have a more public roadmap
In past years we tend to keep this to ourselves, occasionally discussing with some select clients. Are there any advantages to making it more open? What would you like to see on it?
5. Separate code into separate jars (core, examples)
Traditionally we tried to have the fewest jars (one reason we wrote our own replacements for JCE and ImageIO). Would developers prefer several jars to use together so that things like examples are easier to add and remove?
6. Move more code onto GitHub
Being on Git makes it much easier to use GitHub. What would be useful to post there?
7. Give some customers more access to our git repositories
At the moment, clients get access to the source for the releases, but not the raw Git repository. Should we consider this?
What should we change about the way we develop software?
Before we finalise our list, we wanted to give you the chance to give us your thoughts.What would you like to see? What would make our customers life easier? What extra features would you pay for?
If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (Twitter, Facebook and Google+) or the Blog RSS.
Related Posts:
Mark Stephens
Latest posts by Mark Stephens (see all)
- How we have revamped our support in 2017 - July 5, 2017
- Is attending JavaOne still worth the hassle? - June 21, 2017
- Is it still worth attending software conferences in 2017? - June 1, 2017
- What should be in Java10? - May 31, 2017
- What are NetBeans Days? - April 4, 2017
or maybe making your some libraries open source 🙂
Hi Sinan, thanks for your feedback we like to offer a range of commercial products like JPedal our Java PDF Library but also have open source offerings.