<\/p>\n
Refactoring Makes Work Easier<\/b><\/span><\/h3>\nOf course, what these people have in mind is what is best for the company: new features have more to offer to the customers. In any case, software developers should remember and inform others about the benefits of code refactoring.<\/span><\/p>\n <\/p>\n
Anyone can write code that the computer can understand. Skilled developers create code that people can understand.<\/b><\/span><\/h3>\n\nWhich usually takes more time, writing new code or reading the old code?<\/i><\/span><\/p>\n<\/blockquote>\nI have one question for you: which usually takes more time, writing new code or reading the old code? My opinion is that on average, developers spend dramatically more time on reading existing code than on writing new code. If the existing code was more readable and understandable, how much more efficiently could developers write new code?<\/span><\/p>\nReadability is merely one of the motivations for refactoring. Refactoring can also lead to improved performance, faster bug fixes and changes as well as improved robustness, just to name a few advantages.<\/span><\/p>\n <\/p>\n
When Eating an Elephant, Take One Bite at a Time<\/b><\/span><\/h3>\nIn my experience, refactoring is not done enough (actually, I feel a bit guilty because I was often the one to make the prioritizing decisions). What would be the easiest way for organizations to ensure sufficient refactoring and detect the cases where refactoring is particularly necessary?<\/span><\/p>\nThe best way to refactor is by<\/span><\/p>\n\n- taking small bites<\/span><\/li>\n
- regularly.<\/span><\/li>\n<\/ol>\n
<\/p>\n
![\"\"](\"wp-content\/uploads\/2018\/04\/Fotolia_201052212_S-300x168.jpg\")
<\/p>\n
\u00a0<\/h3>\nChange the Structure First to Simplify Creating New Features!<\/b><\/span><\/h3>\nI will give you an example: if a story requires an added feature, you might discover that adding this feature is difficult due to the structure of the code. THIS would be the right time for code refactoring. In other words, you should refactor the code first to make adding new features easier, and only then add the new feature. When the team estimates a story, they should not just quickly estimate the story in story points but also think about how it should be carried out. If a need for code refactoring arises, it should be included in the effort for the story. This is a good way to start continuous refactoring. This is how the large product development organizations do it. It also helps organizations to avoid big refactoring problems after a few years.<\/span><\/p>\n <\/p>\n
Keep a Most Wanted List<\/b><\/span><\/h3>\n\nOne of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it.<\/i><\/span><\/p>\n<\/blockquote>\nAnother way of including refactoring on the to-do list is to keep a list of the worst outlaw classes which just HAVE TO be redone. One of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it. These parts of the software should be recognized and listed. I encourage teams to keep a to-do list for refactoring in Confluence, for example.<\/span><\/p>\n\u00a0<\/h3>\nScare Your Bosses<\/b><\/span><\/h3>\nNow that you have created the list, you will need to sell it to the product management and the Product Owner. You can approach this from two angles: scare them or explain the benefits. One of the benefits could be that creating critical features would become much easier after refactoring. To scare them, you could describe the horrors they will face if parts of the code are not refactored. The boogeyman will come at night and eat their babies, or the neighbor\u2019s pet guinea pig will chew the cables of their Porsche into tiny ribbons. Well, not literally of course.<\/span><\/p>\nThe purpose is to paint a realistic picture of what will happen in the future if a certain part of the code is not refactored at that moment. Otherwise, they might keep postponing it until the moment comes when making changes becomes slower and slower, and work becomes less and less efficient. We can all imagine that this kind of situation is not ideal for working.<\/span><\/p>\n <\/p>\n
Do It or Die<\/b><\/span><\/h3>\n\nIf you neglect refactoring altogether, you cannot succeed in the product development business in the future.<\/i><\/span><\/p>\n<\/blockquote>\nThe purpose of refactoring is to improve the readability and changeability of the code. This, in turn, results in faster changes and more completed tasks. This creates a positive cycle, and everybody wins. If you neglect refactoring altogether, you cannot succeed in the product development business in the future. The holy book of refactoring, Martin Fowler\u2019s <\/b>\u201cRefactoring: Improving the Design of Existing Code\u201d, is a book that every team should have at their disposal. Especially the first fifty pages are a must-read for every software developer.<\/span><\/p>\n\u00a0<\/span><\/p>\nContribyte is the leading product development assistant in Finland. We provide a variety of <\/i>services<\/i><\/span><\/a> for developing your organization!<\/i><\/span><\/p>\n <\/p>\n
\n
<\/p>\n
Anyone can write code that the computer can understand. Skilled developers create code that people can understand.<\/b><\/span><\/h3>\n\nWhich usually takes more time, writing new code or reading the old code?<\/i><\/span><\/p>\n<\/blockquote>\nI have one question for you: which usually takes more time, writing new code or reading the old code? My opinion is that on average, developers spend dramatically more time on reading existing code than on writing new code. If the existing code was more readable and understandable, how much more efficiently could developers write new code?<\/span><\/p>\nReadability is merely one of the motivations for refactoring. Refactoring can also lead to improved performance, faster bug fixes and changes as well as improved robustness, just to name a few advantages.<\/span><\/p>\n <\/p>\n
When Eating an Elephant, Take One Bite at a Time<\/b><\/span><\/h3>\nIn my experience, refactoring is not done enough (actually, I feel a bit guilty because I was often the one to make the prioritizing decisions). What would be the easiest way for organizations to ensure sufficient refactoring and detect the cases where refactoring is particularly necessary?<\/span><\/p>\nThe best way to refactor is by<\/span><\/p>\n\n- taking small bites<\/span><\/li>\n
- regularly.<\/span><\/li>\n<\/ol>\n
<\/p>\n
<\/p>\n
\u00a0<\/h3>\nChange the Structure First to Simplify Creating New Features!<\/b><\/span><\/h3>\nI will give you an example: if a story requires an added feature, you might discover that adding this feature is difficult due to the structure of the code. THIS would be the right time for code refactoring. In other words, you should refactor the code first to make adding new features easier, and only then add the new feature. When the team estimates a story, they should not just quickly estimate the story in story points but also think about how it should be carried out. If a need for code refactoring arises, it should be included in the effort for the story. This is a good way to start continuous refactoring. This is how the large product development organizations do it. It also helps organizations to avoid big refactoring problems after a few years.<\/span><\/p>\n <\/p>\n
Keep a Most Wanted List<\/b><\/span><\/h3>\n\nOne of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it.<\/i><\/span><\/p>\n<\/blockquote>\nAnother way of including refactoring on the to-do list is to keep a list of the worst outlaw classes which just HAVE TO be redone. One of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it. These parts of the software should be recognized and listed. I encourage teams to keep a to-do list for refactoring in Confluence, for example.<\/span><\/p>\n\u00a0<\/h3>\nScare Your Bosses<\/b><\/span><\/h3>\nNow that you have created the list, you will need to sell it to the product management and the Product Owner. You can approach this from two angles: scare them or explain the benefits. One of the benefits could be that creating critical features would become much easier after refactoring. To scare them, you could describe the horrors they will face if parts of the code are not refactored. The boogeyman will come at night and eat their babies, or the neighbor\u2019s pet guinea pig will chew the cables of their Porsche into tiny ribbons. Well, not literally of course.<\/span><\/p>\nThe purpose is to paint a realistic picture of what will happen in the future if a certain part of the code is not refactored at that moment. Otherwise, they might keep postponing it until the moment comes when making changes becomes slower and slower, and work becomes less and less efficient. We can all imagine that this kind of situation is not ideal for working.<\/span><\/p>\n <\/p>\n
Do It or Die<\/b><\/span><\/h3>\n\nIf you neglect refactoring altogether, you cannot succeed in the product development business in the future.<\/i><\/span><\/p>\n<\/blockquote>\nThe purpose of refactoring is to improve the readability and changeability of the code. This, in turn, results in faster changes and more completed tasks. This creates a positive cycle, and everybody wins. If you neglect refactoring altogether, you cannot succeed in the product development business in the future. The holy book of refactoring, Martin Fowler\u2019s <\/b>\u201cRefactoring: Improving the Design of Existing Code\u201d, is a book that every team should have at their disposal. Especially the first fifty pages are a must-read for every software developer.<\/span><\/p>\n\u00a0<\/span><\/p>\nContribyte is the leading product development assistant in Finland. We provide a variety of <\/i>services<\/i><\/span><\/a> for developing your organization!<\/i><\/span><\/p>\n <\/p>\n
\n
Which usually takes more time, writing new code or reading the old code?<\/i><\/span><\/p>\n<\/blockquote>\n I have one question for you: which usually takes more time, writing new code or reading the old code? My opinion is that on average, developers spend dramatically more time on reading existing code than on writing new code. If the existing code was more readable and understandable, how much more efficiently could developers write new code?<\/span><\/p>\n Readability is merely one of the motivations for refactoring. Refactoring can also lead to improved performance, faster bug fixes and changes as well as improved robustness, just to name a few advantages.<\/span><\/p>\n <\/p>\n In my experience, refactoring is not done enough (actually, I feel a bit guilty because I was often the one to make the prioritizing decisions). What would be the easiest way for organizations to ensure sufficient refactoring and detect the cases where refactoring is particularly necessary?<\/span><\/p>\n The best way to refactor is by<\/span><\/p>\n <\/p>\n I will give you an example: if a story requires an added feature, you might discover that adding this feature is difficult due to the structure of the code. THIS would be the right time for code refactoring. In other words, you should refactor the code first to make adding new features easier, and only then add the new feature. When the team estimates a story, they should not just quickly estimate the story in story points but also think about how it should be carried out. If a need for code refactoring arises, it should be included in the effort for the story. This is a good way to start continuous refactoring. This is how the large product development organizations do it. It also helps organizations to avoid big refactoring problems after a few years.<\/span><\/p>\n <\/p>\n One of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it.<\/i><\/span><\/p>\n<\/blockquote>\n Another way of including refactoring on the to-do list is to keep a list of the worst outlaw classes which just HAVE TO be redone. One of our teams would use the phrase \u201cClass written by God\u201d since no one else was able to understand it. These parts of the software should be recognized and listed. I encourage teams to keep a to-do list for refactoring in Confluence, for example.<\/span><\/p>\n Now that you have created the list, you will need to sell it to the product management and the Product Owner. You can approach this from two angles: scare them or explain the benefits. One of the benefits could be that creating critical features would become much easier after refactoring. To scare them, you could describe the horrors they will face if parts of the code are not refactored. The boogeyman will come at night and eat their babies, or the neighbor\u2019s pet guinea pig will chew the cables of their Porsche into tiny ribbons. Well, not literally of course.<\/span><\/p>\n The purpose is to paint a realistic picture of what will happen in the future if a certain part of the code is not refactored at that moment. Otherwise, they might keep postponing it until the moment comes when making changes becomes slower and slower, and work becomes less and less efficient. We can all imagine that this kind of situation is not ideal for working.<\/span><\/p>\n <\/p>\n If you neglect refactoring altogether, you cannot succeed in the product development business in the future.<\/i><\/span><\/p>\n<\/blockquote>\n The purpose of refactoring is to improve the readability and changeability of the code. This, in turn, results in faster changes and more completed tasks. This creates a positive cycle, and everybody wins. If you neglect refactoring altogether, you cannot succeed in the product development business in the future. The holy book of refactoring, Martin Fowler\u2019s <\/b>\u201cRefactoring: Improving the Design of Existing Code\u201d, is a book that every team should have at their disposal. Especially the first fifty pages are a must-read for every software developer.<\/span><\/p>\n \u00a0<\/span><\/p>\n Contribyte is the leading product development assistant in Finland. We provide a variety of <\/i>services<\/i><\/span><\/a> for developing your organization!<\/i><\/span><\/p>\n <\/p>\nWhen Eating an Elephant, Take One Bite at a Time<\/b><\/span><\/h3>\n
\n
<\/p>\n\u00a0<\/h3>\n
Change the Structure First to Simplify Creating New Features!<\/b><\/span><\/h3>\n
Keep a Most Wanted List<\/b><\/span><\/h3>\n
\n
\u00a0<\/h3>\n
Scare Your Bosses<\/b><\/span><\/h3>\n
Do It or Die<\/b><\/span><\/h3>\n
\n