10 points for better software quality

Introduction

As bigger a project is, there’s more chance for quality issues. What can be these quality issues: too many bugs, too long runtime, too high memory usage, difficult to understand/difficult to modify coding style etc. These quality issues are making normally the user of your program unhappy, and the development slower. Unfortunately you can never rid of all quality issues, but you can avoid most of them by follow the points below. Of course these solutions costs a lot of time, but it is better to do this kind of effort in time and not loosing the same time with bug fixing.

1. Analysis of requirements

Before the start of development you need to make sure, that it is 100% clear what your program should do. Here of course you need to think about things like compatibility of the requirements with each other or if it is possible to implement all the requirements, are there any certain hardware limitations?

To be honest most of the bugs are coming from simple misunderstandings: the customer had a different understanding about the functionality as the developer.

That’s why it is good to document these requirements in a clearly written form and let the customer read them and accept them.

2. Software design

If the requirements are clear still don’t start with the coding. First think about the solution, about how it should be implemented? Which algorithms needs to be used? Which part of the code will be reusable? Which libraries could be used? How will the different components and classes communicate with each other? And so on…

With this kind of planning you can already find and avoid a lot of possible problems in the future. Document your design in form of text and/or UML diagrams.

3. Coding guideline

If multiple developers are working on the same code always have a coding guideline which defines the coding style to be used (naming of functions and variables, usage of brackets etc.). So that your code will have a uni formic style which is well-readable.

4. Regular reviews

Do design and code reviews with other team members. They can find easily the mistakes in your way of thinking or in your code code. Don’t let any piece of code be merged without a review on that.

5. Static code analysis

Use static code analyser tools. These tools are analysing your source code without running it. They can find a lot a of possible problems, like uninitialised variables, never satisfied conditions, unreachable code part and so on. They can check for coding style as well.

6. Unit tests

Implements unit test for you code. A good unit test is running fast and testing a small piece (unit) of your code. Unit tests can help to be sure in case of every change that you didn’t brake the already working functionality and they can help to understand for other programmers what your code is for, since from the unit tests they can see what is the expected behaviour.

7. Component and system tests

Don’t forget to do some higher level tests and the you component or system as it is. This is basically a black box test, so you are not doing it based on the code, but based on the requirements. You can easily check if your component is fulfilling the requirements or not. Think always about corner cases as well. These tests can be manual of automatised as well. Automatised tests have the advantage, that you can run the tests later any time.

8. Continuous integration

Setup a continuous integration server with a CI system (like Jenkins), let it to run nightly builds and check your code in case of each new change. You can integrate the static analyser and the automatised tests as well. So that after each commit you have an automated feedback if your software is working fine or not.

9. Bug tracking

Track you already found bugs in a bug tracker system (ex.: Mantis). For each bug document how to reproduce them and how it is differing from the expected behaviour. If one bug got fix you can shortly document the way of solution of the fix as well, to avoid the same kind of bugs in the future. With this method you will never forget about any bug.

10. Profiling and memory usage

To be able to maintain the performance of your software you need to measure it’s runtime regularly. For that you can any profiling tool. With this method you can also discover the part which are using the most runtime. You need to check the memory usage of your tool also. For such purposes always try to define the scenarios which are the most difficult one from computation point of view.

How to prepare yourself for an interview as a software developer?

Introduction

Attending a job interview is really not easy and it can be quite stressful, but that’s almost the only way to get your dream job if you don’t have a good network. Your performance at a job interview can decide if you are getting the new job or not, you need to be fit from technical point of view and you need to pay attention on your way of communication as well. With a short preparation you can make your chances much higher. All the next points are based on my own experiences. I attended many interviews from both sides: as an interviewer and as a candidate. In this article I’m trying to summarise my experiences.

The application process is different at every company, but it’s a good idea to figure out what is waiting for you. The interview can be just a short introduction focusing on that what you are searching for. It can be an interview where they are focusing on your personality. Or it can be a technical interview. And it can be any combination of these three. So if you are getting an invitation for an interview and based on the invitation it is still not clear what will be the topic of the interview feel free to ask. You should clarify the language of the interview as well.

How to prepare yourself for the different type of interviews?

If it is an interview an HR partner most likely it will focus on that what you are searching for and on your personality. In this case you should not expect deep technical questions. Most likely you will go through your CV and you need to talk about your experiences. So before attending an interview always read through your own CV and try to introduce all your previous workplaces for yourself, focus on that what you were really doing there, which projects were you supporting, which technologies did you use, which responsibilities did you have. You should talk ca. 2 minutes about each previous position. There can be questions regarding studies as well, then you need to tell what were your studies, what was the main focus, what was the topic of your thesis. One more important thing: for sure you will be asked for what you are really looking for. For this question you need to have a clear answer. Like “I’m looking for a C++ developer position, where I can deal with software architecture as well”. Next to that there are some typical HR questions. To be honest for me it was always the most difficult part for me. Because I have no problem with talking about technical topics, but answering questions like: why are you better than the other candidate, or what is your strength and weakness is really difficult for me. So I would suggest you to collect the possible HR questions (you can find a lot of collection of them online, with some ideas what to answer), make a list from them and write down your answers. So that on the interview you won’t need time to think about.

At most of the companies there is a technical interview as well. But some companies are merging the HR and the technical interviews. As preparation for the technical interview read again the job description, which you applied for and the main technical skills in your CV. Of course you can not learn everything in some days, but it’s helping a lot if you are checking these topics before the interview. For all technical topics there are some popular interview questions. Like if you applied for a C++ developer job I’m almost sure that there will be questions about smart pointers and about multithreading. At the preparation try to focus on these topics. For all technical topics you can find interview question collections online, read them through and try to answer, if you can’t answer google it. If you are still not feeling comfortable enough my suggestion is the following: apply for jobs which has a similar description, but you are not really interested in the company (it is too far from your place, you heard a bad feedback etc.). So if you wanna have a job as a java developer apply for some java developer position even if they are not so interesting for you. Then you can take part on some interviews, where you have absolutely no risk, so you can try out yourself without stress and you can figure out what are the typical questions in that field.

Before the interview always try to find some information about the activities of the company. It can help a lot if you are thinking a bit before what can be their technical challenges or which technologies are they using.

How to behave during the interview?

During the interview stay calm and confident. The interviewer may try to make you feeling uncomfortable, but try to stay calm. Typical questions for making your feeling uncomfortable are questions like “Why would you like to change your job?”, “Why are you better than the other candidates?”, “How is your connection with your current boss and colleagues?”. It is good if you are preparing some answers for these question before the interview. They should be honest, but political correct. So it is not a good idea to answer: “I hate my boss, because he’s a shitface.”, better to tell: “Sometimes it is a bit difficult for me to ensure my boss about my ideas.”.

If you are already at the interview try to give always your best answer, stay calm and confident. But one important thing: don’t be shy to give the following answer: sorry, I don’t know, I have no experience with that. So you can save a lot of time for the interviewer and some uncomfortable minutes for yourself. At most of the interviews it is not a problem if you don’t know everything, but that’s a problem if you are telling something what is totally not true. It happened thousand times with me as well. When I’m leading the interviews and asking the candidate: “do you have experience with QT Signal-Slot model?” I’m usually get the answer: yes. And then for the question: “How does it work?” I don’t get a clear answer, just some bullshit. So that’s something to avoid, it is much better to tell: “No, sorry”, then no problem, let’s talk about some other topic.

There’s one more thing: a job interview is like dating: both sides try to make sure that you are matching together. So you need to show your best side: mention everything what you can do, but don’t lie, they will realise and you can get some really uncomfortable situations. On the other hand you need to check if the company is fitting to your needs or not. At the first part of the interview let the interviewer ask, but after that normally the interviewer asks you if you have any other questions. Yes, you should have! Ask about the position, ask about the company, ask about the used technologies. So that you can have a clear picture about the opportunity and you can decide if you wanna join them at all. On the other hand it makes a better feeling to the interviewer as well, it makes the feeling that you have real interest in the position.

On the day of the interview don’t make any stress anymore. Fine some matching clothes. At this point you should follow the dress code of the company. Check their website before and if they have pictures check what their employees wear at work. The most important: go there in time. It is better to plan your arrival 20-30 minutes earlier than the start of your interview. A lot of thing can happen: no parking slot in the near, traffic jam, your train is late, you can’t find the address etc. But if you are arriving too early don’t enter the building. Use this time to walk around the building and check everything what can be interested: where are parking slots, is the a place where you could eat etc. Enter the building around 10 minutes before the start of your interview. Go to the reception introduce yourself and tell that you came for an interview. Never forget the name of your interviewer (if it was in the invitation). At the beginning of the interview most of the cases you will be asked if you need water. It is good to say yes. You can always win some really useful second during the interview by drinking some water. In the meanwhile you can think about the answer. Regarding winning time: if you know the answer but you need to think some seconds you can start to bullshit. OK, this is maybe not the most correct word, but what I mean here is sentences like: “Yes, I had to solve such a problem at my previous project, it was quite complicated to find the solution…” and the you have some seconds in the meanwhile to formulate your answer. Or just one more example: the question is how locks are working in multithreading. Then you start with that what is locking and why is it necessary at all and at the end you can tell how it is working, but then you had some time during your introduction to formulate your answer.

And last but not least: at an interview your technical knowledge is not the only thing what is checked, your attitude, your personality and your way of communication is very important as well! Be honest, open-minded, look motivated, that a half success.

The big question regarding salary

One of the most interesting part of the interviews is the salary. Usually this topic is coming up only at the end of the interview. Let the interviewer come up with the topic. If the topic is not coming up don’t worry, maybe it will only come up on the next round interview. Regarding the answer: If I’m searching for something new I’m always deciding first what is the minimum salary I can accept. When I’m asked about my salary needs I’m usually telling 10-20% more than this amount, but I’m mentioning that I’m flexible. So if the company can pay my wish for the position I will be more than my minimum expectation, if not there’s still space for some further discussions. For me this strategy worked well. If you have no idea about what would be realistic use google: there are several pages which can tell you what is the average salary for a specific role in your city!

Summary

These were my tips for this topic, I hope I could help you, feel free to extend it if you have more ideas. So prepare yourself for the typical questions, know what you want, be honest and do your best! I wish you a good luck at job search!

Most important points of good software architecture

Software architecture is really similar in my view as architecture of buildings. You can build a small house without a well-planned architecture, but it will never be perfect. And you can not build a big building without good plans. During the planning phase you need to take care about several thinks: choose the correct walls, plan the electricity, water-system, all rooms, light system, air-conditioning and heating and a lot more. So this is a complex, difficult but necessary job.

It is the same at software architecture: you can implement small programs without a proper architecture, but they will be never perfect and you won’t be able to build up and maintain a huge program, because it will become a big monster with a lot of unknown code part, unknown functionality and bugs. And after a while at fixing each bug you are covering five other bugs. But of course it is not easy to plan the correct software architecture, you need to think about several points: main functionality, hardware requirements (memory usage etc.), define the main components, reusability of the code, stability, timing, internal communication, compatibity, extensionability, configrability etc. etc. etc.

And what are you doing in fact when you are planning your software architecture: based on the requirements you are splitting the whole software into components and subcomponents, planning their responsibilities and interfaces and planning the way of communication between the components.

There is one more big difference between the architectural plan of a building and software architecture: since the building and not changing frequently the software is changing: the requirements are changing often and new functionality is coming. So you need to plan your software in a way that it is possible to extend it without big changes. For that you need to find a really modular architecture.

I have one more favourite explanation of good software architecture: a nice modular software architecture is just like a furniture in IKEA (no, it is not an advertisement here). That furnitures are built up from really simple modules (modular built-up and components with single responsibility), which are connecting to each other at some predefined connection points (clear interfaces) and they are documented in a pretty easy and pretty clear way (well documented usage). Furthermore there are several variant of each furniture, you can choose between glass door and wooden door, 3 or 4 chest versions, add a lot of extensions like extra lights or a mirror inside. So it is open for extensions and it is configurable. So my goal at desigin a software is always a similar result.

Here I just tried to collect the most important points of good software architectures.

1. Modularity
   
   

Your software needs to be built up from well-defined modules/components. If your component is still to big you can split it into so-called subcomponents. In case of a complex software you can use multiple level of subcomponents. As you are using this strategy you will have a lot of reusable components.

2. Clear responsibility for the components
   
   

Each of your components needs to have a clear responsibility. It is good is you can describe its responsibility with one sentence. If you can not describe it without using the words “or” and “and” then your component is too big as it should be splitted. Good examples for the responsibilities: “This component is responsible for the storage of user data.” . But even inside this component some subcomponents can be introduced, like a component responsible for the connection with the database.

3. Clear interfaces
   
   

The defined components needs to communicate with each other through clear interfaces. Each interface has a name, a return type (it can be void as well), and optionally some parameters. That a good practise to make a difference between private and public interfaces. Private interface is available only inside the same component, public interfaces are available for the other components as well. The number of public interfaces should be as limited as possible. Each public interface needs to be well-documented. On long term you should avoid to change or remove already existing interfaces.

4. Documented behaviour
   
   

Your component will be used by other components and so maybe by other programmers. So it should be documented in a very clear way what are the components doing and what is the expected behaviour of their interfaces. You can change the internal behaviour of your component any time (how is it doing), but avoid to change the external behaviour (what is is doing). For this purpose you can use UML diagrams.

5. Easy to understand
   
   

I have seen several times architectural designs with very long chain of derivation and complicated connection between components. In the end they were working perfectly, but no one understood why and how to use them. You should avoid such solutions. Since your component will most likely be used by other developers it should be easy to understand its behaviour.

Configrability

Your component should be well configurable to be able to use it in multiple environments. My strategy for making my code configurable is the following: everything what would be a magic constant in the code (path, magic string, magic numbers etc.) should be moved to a configuration class which is storing all such information. And then this information should be able to be modified from outside through a config file.

7. Layered-architecture
   
   

In case of a complex software not all components should communicate with all the others directly. You can introduce some additional restrictions, like layers. You should organise your components into layers and only the once can directly communicate with each other which are either in the same layer or in the neighbour layer. A good example is the so called MVP (Model-View-Presenter) architecture which is often used for GUI applications. The view can not communicate directly with the model, but the presenter can communicate with both of them. With this solution your way of communication will be much more clear and you can change your components much easier.

8. Clear communication sequence
   
   

It should be defined in a clear way how your components are communicating with each other. How is the information flowing between them. Which one is calling which one. For the purpose you can use a UML sequence diagram.

9. Well-designed error handling
   

The error handling of your whole software should be handled based on a common concept. There are several solutions: using special return values, exceptions or error flags, but what is important, that you need to use the same solution in all of your components. That makes it easier to understand your whole system.

These 9 points are not covering everything, software architecture is a much more complex topic. But if you are taking care about these 9 points at planning your software you will already reach a good software architecture.

That’s how you recruit - The most annoying recruiting methods

As a programmer I’m active on several professional portals like LinkedIn and I’m getting in touch with several recruiters every week. Most of them are really nice, but unfortunately during the years and especially during the last months I collected a lot of bad experience with them. Sometimes I’m finding myself in strange situations, which I have never expected. When I was in such a situation quite often I couldn’t find the optimal solution, but later on I was thinking about how should the situation have been solved and found some good ideas. In this post I try to collect the most typical issues with recruiters and their possible solutions.

“I have a great position as senior java developer” - Finding you with totally irrelevant positions

At least once in a month I get some messages about senior java developer positions, however I’m not experienced with java and java is even not mentioned in my profile at all. To be honest I don’t understand why I'm getting these messages. Sometimes I'm clarifying the situatio in an answer, usually the reaction is “no problem, I’m sure I can find you something else”.

So my suggestion in such cases is just send and answer containing the fact that you have nothing to do with that technology, maybe there are other opportunities as well.

“Send me your number, I have a great opportunity, I will call you”

I get often messages like “You have a good profile, send me your number, I will call you”. OK and now? I don’t wanna waste my time with talking about irrelevant opportunities. So usually I’m asking the recruiter to send me a description about the opportunities. Most of the cases I even don’t get an answer on that. If you have a lot of time, feel free to do these calls, otherwise just ask for a description.

“Please fill out these 10 page long document to be able to start with your process”

A lot of head counters are asking you to fill their questioneries. Usually these documents are containing exactly the same information as my CV but in a different format. It takes quite long to fill them out. I don’t really see why they really need to have your CV in a new format. But here if you really would like to have a position you can not do anything else, than filling out the document.

I have a position for you, but I don’t know anything about that

I often receive messages like: “Hi, I have a great C# position, are interested?”. Come on, how could I decide based on that if it is interesting for me or not? So the simplest solution: ask for more details.

My other usual issue in the same category is when I’m asking about the location of the office (since often the name of the company is not public). Since I don’t wanna move to a new flat for me it is important to find a workplace which is not too far from my place. And in case of bigger cities it really makes a difference if the office is in the next streets or in the other side of the city and it takes one and a half hour to get there. I'm usually asking for the location of the office. Most of the cases the recruiter has even no idea about that and it is sad. Here the only thing what you can do is to wait until the first personal interview, there you will know the location of the office.

“Are you interested?” OK, then I disappear now

Sometimes I’m just getting messages like “I have a position which would fit to your profile, would you have interest?” And if my answer is “yes” I'm never hearing again about them. It is strange, I never understood. But if you really have interest in the position you can try to apply at the company directly (without the support of a headhunter).

“Are you interested in this position? No problem, I have 5 similar opportuities”

This is the most annoying one. It happened with me multiple times: I’m applying for a position which would fit really good to me. In some days I will be called, but at this time it is not going about the position which I was applying for, but about similar positions which are anyway always less fitting for me. I have sometimes the feeling that these positions are not existing at all, they are there only for Marketing purposes. Because if you are getting already in touch with the recruiter most likely you will check he’s other opportunities as well. In this case you can not do a lot, just decide if the other (offered) positions are interesting for you or not.

“What is your current salary?”

I have been asked by recruiters often about how much I’m currently earning. I think this is a private info and anyways it shouldn’t influence my situation. So my suggestion is: never tell your current salary, it is a secret info, but tell the salary what you would like to have. I think in this ways it will be most more fair and clear.

The strangest interviews

There are several different kind of interviews. I think the strangest ones are the ones with the HR about questions like “what are your strength?” “How can you imagine yourself in 10 year?” etc.

The strange one was when I got a complicated problem to be solved during the interview. What ever I tried to explain about my solution idea I got the feedback: “Yes it would may work, but this is not the solution I would prefer. Come on? If my solution is working as well, why should I stick to his solution? I didn’t get an offer, but to be honest I didn’t mind.

With such “strange interviews” I think you can not do anything. But what is important in my view: an interview is not just about the introduction of the candidate, but about the introduction of the company as well. If the interview is strange, then there’s a high chance that the company is strange as well.

“Would you like to move to the end of the world for a 6 months project? You should start tomorrow”

I’m getting such messages every week. And I really don’t understand who would overtake a fixed-term project for some months long long kilometres away from his home in the middle of nowhere. The costs of moving and staying there does not worth, even if the salary is good. Regarding start ASAP: I think the good developers are usually not free and they can start earliest in some month, but for sure there are exceptions.

Never ending interview processes

The interview process at some companies are really chaotic. You are having 3-4 rounds of interviews and that’s why the whole process takes 2-3 months long. Is it really neccesary? I think after one, maximum two round a decision can be taken. Otherwise there’s the risk that the candidate joins to an other company. And of course it is really frustrating for the candidate as well: somehow you need to get free from your work for each and every interview. Normally you don’t wanna tell that you are having a job interview, so you need to lie something. It is really inconvinient. And them do it 3-4 for times for each company you applied too. Really crazy.

So this was short collection about the things what are annoying the most connecting to topic recruitment. I hope it would be good for all the developers, but also for the companies if these point would be avoided in the future. If you have any points to extend don’t forget to do it.

The refactoring guideline

The software life cycle

Almost all software has been started with a nice plan and high hopes. The one who started though that it will fulfil all requirements in the future. Later on the first version has been implemented, usually it is already not totally following the original plans. With time new needs are coming: new features should be added, some behaviour needs to be changed, some bugs must be fixed. These activities are usually done with as-fast-as-possible attitude. Not thinking about the future, not thinking about the past, not thinking about the architecture, just solve it in the fastest way. After a while there will be a code which is basically doing what it should, but there the code quality is horrible, it is usually managing the memory in a strange way, which causes some tricky bugs. The runtime is neither optimal. There’s a lot of code duplication and death code and it is really difficult to figure out what should be changed in case of new needs. So even the implementation of a small feature can take quite long. And one more important thing: most of the developers hate to work with such a bad quality code!

What is the meaning of refactoring?

Refactoring is changing the code in way that its quality will get better, but it’s behaviour is not changing. So that for example bug fixing, or making the behaviour more user friendly is not part of refactoring. But code changes which are increasing the readability or the modularity of the code or changes which achieve a better performance on runtime or memory usage are part of refactoring.

What are the benefits of refactoring?

During refactoring you are always increasing the quality of your code, with other words: you are making your code better. Code quality is a quite complex topic, but I think it is mainly about the following points: stability, readability, modularity, maintainability, reliability, efficiency, security, testability and size. So during your refactoring you are addressing one or more point regarding this code and you are making your code better from the selected purposes. Pay attention here, the different purposes can be contradicting. For example quite often you can reach a better runtime by using more memory.

This is how is it based on theory. But let’s see now the practise. As I meant in the introduction usually the code base of a software is getting more and more complex by time and in the meanwhile its quality is getting worse and worse. Usually it is going to be less readable, less maintainable and later on less reliable. That means bugs, bugs everywhere. And since the readability is bad it takes long to find the root cause of the bugs and since the maintainability is bad it takes long to fix these issues. Due to the wrong structure of the code it takes long to implement new features as well. So the project will reach a phase, when a lot of people are working on that without big results. It looks like that they are doing nothing, just keeping the code alive. It’s a waste of time and waste of money. This point is usually the time to refactor the code base and reach a better readability, maintainability and stability. All other points are always up to the situation, for example if the program is running to slow of course runtime will be a focus as well.

The low level benefit is better code quality, the high level benefit is nothing else, than money.

How to start with refactoring?

As I told refactoring means a code change without the change of the behaviour. Before changing anything you need to know pretty well the current behaviour. This should be documented in a way. The easiest solution is to write it down into a document. But a much more effective solution is to implement automated tests for your code if it is possible. In fact it is possible in almost every case, except some really special ones. You need to implement test cases which are covering the whole functionality, are independent from the implementation details and are passing on the current code base. After every change you can run them as check if they are still green.

Once it is done it’s good to go down onto component level. Here even if they are not present yet you should think on a component level: what are the main functionalities of your program, how could these functionalities be categorised, what are the different level of your architecture. All these points needs to be considered. The components should have a clear responsibility and well-defined input and output interfaces.

Once you figured out the main components try to separate your existing code base into these components and use the predefined interfaces between them. This can be challenging. It can happen that you need to cut classes or fuctions as well. Make always sure that your code is compiling and you automated tests are passing.

If your code is already organised based on the components you can write some component level automatised tests using their interfaces. So later on if a test is failing you will know which component is the problematical one.

What should be refactored?

Refactoring can be done on different levels and with different purposes. Let’s start with the case when the main goal is to make better readability and maintainability.

I would suggest to start it from the highest level. Check what are you current components. Do they have a clear single responsibility? Are their interfaces clear enough? Are there duplicated interfaces? Is the communication workflow as easy as possible? If the answer is no for any of these questions you should start on this level. Split the too complex components into multiple ones, remove the not needed interfaces, make the communication between your components easier.

As next step check each component and check their classes: do they have a clear and simple responsibility? Do they have clear public interfaces? Are they connected to each other in an optimal way? If any of the answers is no, you should do changes on this level. On this level you should always follow the so called SOLID principle:

• Single responsibility principle
  Each of your classes should have a simple clear responsibility

• Open/closed principle
  Your code should be open for extensions, but closed for modifications

• Liskov substitution principle
  
  This is maybe a bit more complicated. But it means, that each of your parent classes can be replaced with any of its child classes without braking the functionality

• Interface segregation principle
  
  Your interfaces shall be small and clear and having one well-specified purpose. So you should avoid having interfaces which are returning a lot of data.

• Dependency inversion principle
  
  You should design your classes your classes in a way, that the classes which are dependencies of your class can be set through some setter functions or constructor parameters. So that you can change them to any subtype later on. So for example if you have a Logger class which is used to create log files and you are can change it though a setter function you can change your Logger between an XMLLogger, a JSONLogger or a SimpleLogger if all these classes are derived from the same Logger base class. It is also helpful if at unit testing you need to mock your dependencies.

Once you are done with the refactoring of your classes go one level done to the level of functions. At this step try to eliminate functions which have too many parameters. Try to split long functions into multiple ones. Try to eliminate code duplication. Make a clear difference between functions, which are returning with some value, but not changing the state of the object and methods which have the purpose to change the state of the object. At this point make sure that you code is covered by unit tests. If not, let’s cover it. Make sure if your function names and variable names are clear enough, rename them if needed. Define constants instead of some magic numbers. This is a really complex topic to address all the points in one article. Now once you are done with the refactoring on this level go on level back to the level of your classes. Is there any class now which should be maybe splitted into multiple ones? If yes, do so. As next step do the same on the component level. And at this point you may see, that it is a never ending story. There’s no perfect code. There’s worse code and better code. Your code can be always better, but never perfect. You need to find the right balance between refactoring and implementation of new features.

If the goal of this refactoring to reach a better performance you need to analyse your code from an other perspective. You should monitor your runtime and identify which are the most critical components and functions from runtime point of view. After finding them there are two things what you can do: find ways to optimise in their algorithm and in the way of communication. Or change some part to multithreading. Multithreading is a complex topic again, be careful here, pay special attention on the shared memory fields. And one more thing: creating a new thread is not always making a better performance!

Summary

As already mention refactoring is really a complex topic, but it is needed almost everywhere. I tried to give you a rough overview, I hope it helped you.