Hello guys, I would like to have an advice: the bo...
# announcements
d
Hello guys, I would like to have an advice: the boss of my boss told me to start migrate one of our microservices to Kotlin. His idea to study the migration so that could be a paper/presentation, meaning that we need to measure stuff (cost of migrating a service, the language learning curve, developers opinion etc..). Did you see something like this around from which I can get inspiration? (not copy and paste it, rather understand a methodology to do such analysis)
๐Ÿ‘ 1
c
dierre: We did a lot of that kind of stuff at my previous job, but eventually found out that all scientific methods would essentially rise the cost of such migrations so much that it is actually cheaper to just do it. Simple, not completely scientific method which more or less worked for us was this: Take a feature, give it to several developers to develop independently from each other, half of those developers work using "old" technology, the other half uses the new one, measure whatever is your KPI, average within same technology. But key here is, the new technology group has already to know the technology for the results to be meaningful. If you want to also measure ease of learning the new technologies, I'm not too optimistic, everyone learns with different speed, it is heavily influenced by past experience and attitude towards the new technology itself. And other fun quirks ๐Ÿ™‚
For my team main argument to switch most of the development to Kotlin was: it's fun while being heavily supported, popular, stable enough, and mostly interoperable with Java eco-system, it's fully readable for people who do not know/use Kotlin themselves.
But again, we have developer-driven culture here, if business is happy, developers can do whatever they like if they at least agree with each other ๐Ÿ™‚
d
Tnx!
c
Another thing to mention is, we decided not to just go in and convert everything to Kotlin, because if the problem isn't there don't fix it ๐Ÿ™‚ Our java code works perfectly fine ๐Ÿ™‚ Sometimes we do go in and press Ctrl+Alt+Shift+K, but only if we're working on that part of code anyway and it doesn't require more then half an hour of refactoring ๐Ÿ™‚ You're welcome!
o
Same here, we convert Java code only if we need to make non-trivial changes to the code.
d
Our approach will be the same. The o only thing we will convert from scratch is everything related to spring.
(basically adapters and dependency injection)
z
Are you going to opt out of using dependency injection? Curious to know the reason if so.
d
No I want to move from start the part about Spring configuration because I want to be sure, for the future, that our integration with Spring, works correctly. To me this is important because the kind of questions I get from colleagues is about interoperability with it. Actually, up until now I was able to move everything to kotlin without problem, the spring plugin works like a charm.
๐Ÿ‘ 1
c
Spring team is doing a great job working out all of the kinks of supporting Kotlin, I frequently see comments and requests from Spring team on Kotlin project github repositories and Kotlin team also does a great job of helping them, so present is quite okay and future seems even more cloudless ๐Ÿ™‚