Konstantin Sokolov
Cape of Good Code GmbH, CTO
Actions
Dipl.-Ing.(RWTH) Konstantin Sokolov has more than 15 years experience in software engineering. He has worked as software developer, architect and technical lead for small and large companies. From 2013 he worked for Siemens AG on innovative approaches in the field of automated code and software analysis. In 2018 he founded Cape of Good Code GmbH together with Egon Wuchner, where he is driving the development and application of the analysis tool DETANGLE®.
Links
Technical debt - why the term causes more confusion than clarity. And how to do it better.
Are we software engineers really clear what we mean when we talk about technical debt? "Sure", is the answer, "it's about smells, bugs, need for refactoring, missing tests ...". To some extent, we can even measure their scope and need. But how do we decide what to address first? How and what do we measure so that other stakeholders understand us at all and convince POs, project managers and department heads of the necessary budget?
In this talk, we'll show how to do it better in a data-based way. How to start with the consequences of technical debt, capture maintenance and compounding overheads in development as KPIs and identify their hotspots in code. How to identify code quality, architecture quality, test quality, etc. as root causes and correlate them with the KPIs. And how to forecast technical debt in the architecture in numbers in order to perform a cost-benefit analysis. Finally, how team collaboration also impacts technical debt.
These challenges have been the same for several decades. Microservices have not changed that.
Problems addressed:
* What is technical debt more accurately?
* How do you measure the consequences?
* What does an effective root cause analysis look like?
* How do I convince other stakeholders of the need?
* How does team collaboration impact technical debt?
Apart from microservices - what is the practical approach to refactor code along business domains?
Transform your own software system into microservices? Regardless of this, we software engineers should also better separate existing code along business domains. How do we tackle this? Strangler pattern? It is not a practical guide on a fine-granular level. Conceptually split the code into business domains and then refactor? Sounds like big-upfront design.
The talk shows how to leverage the existing data pool. How to start from features (in the issue tracker), assign them to domains on a trial basis and evaluate their couplings (design overlaps, call dependencies) in the code. Then use that to locate refactoring needs and evaluate effort. And how automated refactoring suggestions can play an important role in this.
The challenges are the same, we just need to approach them differently.
Problems addressed
* How to separate existing code by domain responsibility?
* How to do the whole thing on a trial basis before refactoring/coding?
* How to use the features of the issue tracker for this?
* How to use the code repository for this purpose?
* How to localize the need for refactoring?
* How do you evaluate the effort for it?
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top