In a recent Moderne Code Remix session, we had the honor of speaking with Jente Sondervorst, a software engineer at Colruyt. Jente is part of a central team that, among other responsibilities, develops recipes and sets standards for their software engineering teams. In addition to his work at Colruyt, Jente actively participates in the OpenRewrite community, where he both answers questions in the OpenRewrite community Slack and contributes to Gradle recipes.
During this Code Remix session, Jente offered valuable insights on various topics, including his rapid onboarding with OpenRewrite, the concepts he found challenging, and the features that proved most beneficial to him.
In this article, we’ll highlight some of the key points from our discussion.
Discovering the power of OpenRewrite
Code Remix (CR): How did you go from an unfamiliar code base to fixing problems in it so quickly?
Jente Sondervorst (JS): “I think, as Tim mentioned, we met [for the] first time at Spring IO in Barcelona last year. I did the workshop over there, and I was overblown by the demo and then struggled all the time during the workshop… That’s how you can trigger me. Don’t just give me a video of this working, just give me a problem. Maybe it didn’t even work on Tim’s PC, who knows? Maybe he was struggling all the time, and he was finally happy that someone else fixed his issue?”
“[After some time] I was just doing some OpenRewrite testing, poking, piloting, shouting it within the company here. Like, ‘Hey guys, you don’t have to do your Spring Boot upgrade! Just have it be done for you.’ As a central expert developer in the company, I’m more doing assistance. We don’t really have a lot of applications running. We have more of the central libraries running. So doing a Spring Boot 3 upgrade over there just using the OpenRewrite recipes… that’s how I basically gained the trust [of the developers in the company].
And then, of course, you always want something more. I’m also an end-user in this story. So I’m also a business who always wants more–who wants that additional feature and that additional feature on top of that… And at a certain moment, [the OpenRewrite team is] completely booked with other features. So any open-source project, I never expect someone else to fix my requirement.”
> Jente knows that the priorities of his business and team may not always be the most important for others, so he takes things into his own hands and contributes the fixes and features he wants to OpenRewrite himself.
Deep diving into OpenRewrite concepts
CR: When you were coming to this project for the first time, do you remember any OpenRewrite concepts that were particularly difficult or challenging to learn?
JS: “I had no idea what an LST (Lossless Semantic Tree) was before I started writing my recipe. I’m not the guy who looks at a video and understands it. I need to deep-dive. I think one of the first things that Tim showed me was, ‘Hey, here are some existing recipes that do something with Groovy or that use the Scanning accumulator.’ And one of the most important tips that he also gave me was, ‘Start with the test.’
“And one of the most important tips that he also gave me was, ‘Start with the test.’”
I’m going to some conferences and there’s always some workshops on TDD (test driven development). And it’s always like the test has to be read first, and then you do the code. In OpenRewrite, I find it very pleasing to really describe very small test cases. If you start from scratch with a new recipe, and after you’ve added some test cases, that’s one unit of work. When compared to real application development, where it’s the MVC pattern or online applications or batch applications…”
CR: “Things that are stateful or distributed systems are… difficult to unit test.”
JS: “Yes, and you already have to start mocking stuff where, for OpenRewrite, you just start from your code basically in a multi-line string. Thank god we have multi-line strings for the unit tests. You basically just mention, ‘I have this–I now want this’. And okay your test is red (failing) and you write a recipe, you start your visitor, and you start looking at okay, ‘What’s the visitor I need?’ Because that’s often, today, still my confusion.”
CR: “I think OpenRewrite recipes are very amenable to a test-driven-development approach to software development in a way that not all software projects are. Particularly when you have stateful components or distributed components, making a unit test can be quite challenging. But a recipe is a lot like a pure function in some ways. Its inputs wholly determine its outputs—it should be deterministic, it should be stateless. It has all of the attributes that you would look for in something that is very unit testable. So I think that’s an excellent point you made there.”
> We’ve put in a lot of work to improve this experience so that it’s not as difficult to wrap your head around. If you want to learn more about Lossless Semantic Tree (LST) types, check out our Java LST examples doc where we provide visualizations and break each LST type down. If you want to learn more about writing and testing recipes, check out our writing a Java refactoring recipe guide or our recipe testing guide.
OpenRewrite documentation
CR: Was the documentation useful to you? Did you reference the documentation? Or did you mostly do your learning inside of the debugger?
JS: “It’s definitely useful. I find myself not in the habit enough of, ‘Hey, I’m going to try this new stuff… Maybe I should read up on this first?’ Because, often, I code like plenty of lines of code, and then I end up like, ‘Hey, but there’s ListUtils in OpenRewrite… So I shouldn’t be doing it like this. There’s already a method there…’”
“So the documentation is very complete. Kudos to Mike… But, as I said, I’m the kind of guy who needs to debug first and then read the documentation. We have other people at the company who are like, ‘I first want to understand a bit of the pieces of the puzzles before I deep-dive into the code.’ I’m more like, ‘Let me deep-dive on this one and fail hard and learn even more… Or maybe have a lucky first shot?’”
> We are continuously adding to and updating the Moderne and OpenRewrite documentation based on community feedback and changes. If there’s anything missing there that you’d like to see, please don’t hesitate to let us know.
Central team impact
CR: During that learning process, what was maybe missing that would have helped you?
JS: “Like I said in the beginning, I did not have a clue what an LST was. But, I think it’s somewhere in the documentation, the TreeVisitingPrinter. This one saved my life. Writing your LST once to your controller, just System.out.println Tree Visiting Printer. I can even write it blindly right now… Just printing out all of the elements inside the LST helps me in finding if I do this logic or if I take this visitor… And, by the way, the fix on Monday [used the TreeVisitingPrinter for debugging]. All Gradle files were messed up. But, it’s a one-line code change, and you immediately see impact. And it’s not on one repository you see impact on… You see the impact across the entire organization immediately.”
“...the TreeVisitingPrinter. This one saved my life. Writing your LST once to your controller, just System.out.println Tree Visiting Printer.”
CR: “I feel like I’ve seen good success at organizations that are using Moderne or OpenRewrite when there is a kind of a central team that is working on the migration or the code quality or the security—kind of whatever the central initiative is that cross-cuts many different feature teams or many different business units. That you develop some people who bring together subject matter expertise in y’know Gradle or Spring Boot or security as well as the OpenRewrite or Moderne expertise together. They can then go share that with the individual feature teams, and then also take their feedback and build that into recipes so that not every single engineer needs to become an OpenRewrite expert. And those people, like you, who become the OpenRewrite or recipe expert can then have some idea of how the system works—what it’s good at and what it isn’t—and can make a much better bug report or a feature request.”
> The top three things we’d recommend to people getting started are:
- Take advantage of unit tests for recipes. Look at what tests exist in other recipes and then write your own.
- Be aware of the TreeVisitingPrinter. Read the documentation around it and get it working on your machine.
- Use the JVM debug flag on the CLI to debug recipes that are run against real code.
Framework consolidation
CR: If you had a magic wand and could wish for one additional kind of thing from OpenRewrite, what would it be?
JS: “That’s a tough one. We still have so many nice things ahead of us which are already there. We have some Spring Boot version upgrades coming out… I would love if I can migrate my JEE application to a Spring Boot application. And for once and for all, be gone with JEE. Just uniform framework all the way.”
Helping out the OpenRewrite Community
CR: Any final thoughts you want to talk about or cool things that you’re working on that you want to share?
JS: “I’m looking forward to providing even more. I did the recipe patch for someone—for some code that I didn’t even need… That really gave me… some good feelings. But, unfortunately, Tim is always too fast. Whenever someone launches a question in the Slack, Tim beats me to it. It becomes like a challenge. We should send Tim a bit more frequently on a holiday.”
Our session with Jente Sondervorst was both insightful and motivating. It’s great to see different perspectives in how people learn and what is or isn’t useful to them. We greatly appreciate the work that Jente has put into improving the OpenRewrite community, and we look forward to seeing what he does in the future. Watch the full Moderne Code Remix session here:
If you have any questions about what was discussed or want to engage further with us, please don’t hesitate to join the OpenRewrite community Slack.
