DEV Community: Tomas Mūžas

Refresh.NET - code migration tool for .NET projects

Tomas Mūžas — Fri, 01 May 2020 18:08:29 +0000

Shareable refactorings

Refactoring is a term coined by Martin Fowler. It describes an action of changing
the structure of a code without altering it's behaviour.

We are performing refactorings daily in our jobs - we rename, move, change classes and methods. Those refactorings, however, are usually highly specific
to one's projects and will be performed only once.

However, there are three groups of refactorings which can be performed on
multiple projects without knowing their specifics:

Adaptation to library API changes
Language version or dialect update
Language change (e.g. C# -> Java)

In this article we will focus on the first two types of refactoring. Both
of those refactoring types are absolutely independent of the project code itself.

When using a library, we are provided with a set of methods and classes to achieve the functionality of the library. If for some reason the developers of the library decide to change the API of the library, all the projects that are using this library will have to perform the same changes if they want to update the library version. In this case, the library can be both conventional library and a framework, as in essence they both only provide APIs.

Also, all of the projects will be written in some programming language. All the projects will use the same, strictly defined language constructs. And in the case of language evolution, all developers will be able to perform same abstract changes on their projects.

In these cases, wouldn't it be nice if someone wrote and shared all the changes necessary
and all others could automatically apply those changes on their projects? :)

There are a few tools allowing to do that: Eclipse refactoring scripts for Java and JsCodeShift for JavaScript. Eclipse however only allows to record high level refactorings to the migration script. JsCodeShift, on the other hand, grants full flexibility by allowing to modify syntax trees, however lacks support for higher level refactorings.

Refresh.NET

Having done quite an extensive research in this field for my bachelor paper, I have made a prototype in C# which is supposed to migrate .NET projects, since there are no such tools for C# environment which I'm the most familiar with.

Now what do I mean by migration? Migration, both in my paper and in the tool, signifies a series of refactorings, which can be shared and executed across multiple projects.

Such migrations can be adaptations for library or framework API changes, language
version updates or any arbitrary other refactorings expressed through a change of AST (abstract syntax tree).

Everything can be written in one .cs file, which can be versioned and shared across multiple projects! Moreover, it doesn't even need to be in any project!

If you happen to need higher level migrations, the tool provides fluent API -based migration builder, which can easily combine multiple prebuilt higher level migrations.

On the other hand, if you need something more specific, like changes for language migration, you are given the plain Microsoft's SyntaxTree to work with as you need.

The tool and its detailed documentation can be found on:

tomasmuzas / Refresh.NET

A tool to easily migrate .NET projects

Refresh.NET

A simple CLI tool to easily migrate .NET projects by writing custom migrations.

This tool is built with intention to create shareable migrations to be able to easily adapt to library, framework or even language updates.

Supported migrations:

Rename class, interface, method, member, namespace
Add, remove, change, reorder arguments
Replace class, method
Change method return type

⚠️Disclaimer! At this point, only references are refactored! Support for end-to-end refactoring (with declarations) is coming soon.

Usage

Install the tool by using:

dotnet tool install -g refresh.tool

Use the tool:

refresh -p Path/To/Project.csproj -m Path/To/Migration.cs

Migration file

Install Refresh.Components Nuget package in order to get Intelli-Sense support:

Install-Package Refresh.Components

Migration.cs can be any C# class, implementing IMigration and it can have any name (Migration, MyMigration, CustomMigration etc.).

IMigration interface

SyntaxTree Apply(SyntaxTree initialAST, MigrationContext context);

SyntaxTree is just Microsoft.CodeAnalysis.SyntaxTree without any alterations. This is an AST of a…

View on GitHub

Everyone is welcome to suggest improvements, report bugs, etc.!:)

Feedback

If someone happens to be interested, please provide any feedback here in the comments or on the github repo! :)

Also, have you faced any breaking changes in the libraries that required a lot of manual refactoring? If so, I would love if someone shared it with me and I could see if I can adapt the tool to fit it. Maybe it will save someone a bit of time!

Insights on how to teach students a difficult subject

Tomas Mūžas — Thu, 06 Dec 2018 19:25:42 +0000

A little bit of context

I am a student myself. At our university, we have a student-driven initiative which is called "Students to students" - higher grade students voluntarily give lectures on difficult subjects to younger students, removing all of the formality of standard lectures.

On the first semester, there come a bunch of first graders. And they are introduced to nothing other than dreaded Assembly 🙂 Having experienced no university lectures before, and kicking off first year with something completely different as ASM leaves newcomers baffled. That is where we step in 😁

Even though I am mostly organising lectures and arranging auditoriums, I have made a few lectures myself (If someone asks, those were on Interrupts, MPL and conditional operations).

In this article, I want to share my experience on what worked, and what didn't.

Give real life examples

What worked really well in my case was comparing Assembly code to C code (in Lithuania, C is a standard language to be taught at school). C code is familiar to all of the students, thus making it easier to understand and read Assembly code.

Sometimes it is not possible to convert it 1 to 1, but that turned out to be even better. ASM --> C sometimes required additional steps in C, which in turn explained underlying logic of ASM.

This way, by seeing already familiar code by the side of ASM, they can understand things better.

Don't forget the context

When entering an unknown subject, it is much more useful to know WHY things are working or implemented in a particular way, rather than knowing WHAT they are doing.

Thats why I didn't talk only about my topic. For example, when talking about conditional operations, I had to explain how memory works, how commands are structured as machine code, that they are written as a sequence one after another, etc.

When you know the fact that commands are written into memory one after another,jmps and their offsets in machine code start to make much more sense.

Use simple language

This might be obvious, but it is crucial to use simple language to explain difficult things. Avoid using any abbreviations until you've explained them and made sure that students understood it (more on that below).

Be a student yourself

This is not meant in a literal way. You need to know, that students are not yet serious scientists, that they have short attention spams, and do like jokes. Don't overkill with jokes or memes, they will find it cringey when it comes from older people and is overused 😁 use informal language, use student slang.

Make sure the topic is understood

There is no point in lecture, if it was not understood. Be open to questions, ask for them, or even force someone to answer them. Especially people that are sleeping 😁 and definitely, don't expect perfect answer. Question them on their answer if it's wrong, to know their way of thinking and to fill in the gaps.

Double or triple check if majority has understood one point before moving to another and stay longer on the topic even if you have to go to absolute basics once again.

Make pauses

Pauses are really necessary. It is really difficult to concentrate on one subject for 1,5 hour. Give students a five minutes break to refresh their attention, to ponder on the subject you've been talking about, or simply to have a smoke 😁

Make your lectures interactive

Don't just give them all of your information. Ask students to explain things themselves. Ask them, why certain things are called so. Ask them, what is their opinion. Ask them control questions to see whether they follow you. Let them guess, and let them fail a lot to learn from own mistakes.

Have practice, not only theory

It is good to give students little excercices to understand subject deeper. After someone solved it, let them explain solution to their peers. It will benefit both them and other students.

Those were my learnings on teaching 🙂 please share your tips and tricks so me and other readers could improve our teaching skills!

Organizing the mess in your head

Tomas Mūžas — Thu, 02 Aug 2018 19:23:20 +0000

This is an honest story of a junior programmer, who dreamed a lot, was hit hard by reality, and found a peace of mind afterwards. By sharing this story I want to show other junior (or maybe even more experienced) developers, that life as a programmer is not always fun and games, that it is okay to struggle, and that there are ways out!

Origins of this story

My journey began exactly 5 months ago. It was my first day at work. All excited I am walking around the gorgeous office, getting to know my future colleagues, looking into the meeting rooms, and of course, getting to know the placement of a coffee machine, the existential need for a developer to function properly. I remember it as one of my happiest days - I've dreamed, I've worked hard to get here, it paid off and now I am in a place of my dreams. Little did I know that that will be a beginning of a new, unexpected chapter of my life.

Origins of a mess in my head

Let's get back a few months before this story began. I have completed quite a big project in the university with .NET language, however I had to use many more technologies than just C#. I have had to get familiar with Python, command line usage, deployment to Heroku, Xamarin, Image Recognition and even some machine learning algorithms. Yet I enjoyed every minute of that and did not find it difficult or overwhelming at all. So I applied to a .NET position, naively expecting to working only with it. Oh boy were I wrong... What seemed as a huge project back then, turned out to be a light walk down the street before having to run a marathon.

Bugs

First of all, let's talk about bugs. Debugging was a new discovery for me. And I have discovered it just a month before my job interview. Another important thing was that I've tried to debug only on a small scope of my project, mostly in one class, not across multiple services at once. So when I had to do just that, I felt overwhelmed and frustrated not being able to find a bug,just to find out later that the issue was way way further.

Tools

It was nice seeing my beloved C# code. I did not really have much struggle with a language itself though not knowing how to navigate around the codebase effectively made things even more difficult. My first navigation was searching through files to find the right class only to forget about it in a couple of moments.

Unknown language(-s)

When I said that I was wrong that I expected to work only with C#, I meant it :D Beside the C# I had to work with: SQL (this one is kind of obvious and not new for me), Python, NodeJS, Docker, and more. However, having a solid background in programming before, and having eagerness to learn made it an enjoyable experience, so can't complain much about that.

Yet another Unknown language

It was the second day of my work. I was supposed to fly to meet my other half of the colleagues. Not even having all of my credentials properly set up, I was bombarded with lots of business slang. It was probably the most difficult part for me. It was very hard for me to get started with a task not knowing what is "this term", and "that term". Sometimes I even though that I weaker, not worthy, because it took me sooooo long to start understanding what people are talking about, what I am required to do and how code is interconnected with business language.

and the most important thing...

Constant fear or failure

I was constantly afraid to push my code because it could break stuff. I was double-checking, triple-checking my code, nitpicking before finally hitting that "Create new pull request" button. I was afraid to test my code, I was afraid to do something other than git add/commit/push, because, you've guessed it, it could break stuff.

Organizing the mess

All those things added up creating a huge mess in my head, and sparked some serious thoughts like: Dude, you got the job you wanted, you just can't give up at the beginning of your journey. And I didn't. Instead, I though of ways on how to solve my problems. And I have decided to share them with you, addressing every problem I've mentioned above.

Learn the context!

It is hard to debug without a context. Spend some time getting to know your code base. It really helps to find an entrance point of your problem, be it a HTTP endpoint, a Main method of your program or the beginning of a function. Look at the code surrounding it. Look at your infrastructure. Get to know the communication between code parts or services. Only then look at your problem. Yes, a few times it will be difficult, but later on you will know more and more reasons of why your code can fail, and you will spend less and less time identifying the potential problem

Get to know your tools!

We are lucky to live in the age of super fancy IDEs. Utilize them! Learn debugging, formatting, commenting, searching key bindings of your preferred IDE or code editor. It will speed up your workflow exponentially! In my particular case, Resharper helped tremendously dealing with code analysis in .NET

Face the unknown!

I really liked what my course mate said:

"I've learned that I know much, yet at the same time I've learned that I don't know even more"

That's why programming is a unique profession. You have to constantly learn. The more you learn, the more confident you grow, but then while learning, you discover, that there are even more things to conquer now with your new knowledge. Be eager to learn new stuff, read A LOT (whether it's documentation of your language/framework, StackOverflow, or Dev.to), and make it fun, because you will have to learn A LOT during your career.

Gather the knowledge!

When I was facing a problem of not knowing things, I though that it is a good idea to document my findings. And the best way to do that, at least for me, was taking notes. I've tried many tools, but I ended up with Boostnote which supports Markdown, however later on I enjoyed using Visual Studio Code as my note app, since it gave me a degree of freedom to organize and synchronize my notes.

I took notes on everything: business language, new feature of my programming language, ways to test and debug, hardships, basically - everything. I've questioned a lot my mentor, most of my questions were in fact stupid, but at the end THINGS FINALLY STARTED TO MAKE SENSE. I learned the connection between business language and code, and after that, I've finally felt like a part of a team!

Don't be afraid to spend a lot of time on that, because it will help you in the future.

Relax!

It is okay to fail. We will all inevitably fail. And we will fail multiple times. Though every fail is a lesson to be learned. Experiment freely, as long as it complies to your company rules of course, learn from your mistakes and thus grow.

Some personal bonus tips

Get cosy!

Customize your editor with fonts, themes, colors, and icons. Having familiar and neat environment gives me confidence and somehow I feel joyful to code with my personal setup.

Get moving!

We, programmers, spend most of our day sitting in front of a computer. Start moving - going to the gym, taking short walks, etc. This will not only keep you fit, but will clear your mind.

Take a break!

Don't be afraid to take a break if you feel overwhelmed! It is not worth it to spend countless hours looking at your monitor hopelessly. Take a nap, go for a stroll, have a snack or do something that will distract you for a moment. Don't force a solution from yourself :)

That was my story and my tips, hope you have liked at least some of them, or even found it useful! I would love to hear your personal tips on how you deal with difficulties at work!