未加星标

Fixing Legacy Applications: A Real-Life Example

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二04 | 时间 2019 | 作者 红领巾 ] 0人收藏点击收藏

For the FIFA World Championship of 2014, my friends and I wanted a website where we could “bet” on the games. Not for money, just for fun. In the past, we used an Excel file with some fancy formula’s. But then came the idea to write a web application. As the only developer, I accepted the challenge. It was done in a rush, with the technology of the time. Four years later, this gives me an excellent exercise for refactoring. In this series, I will show some techniques I will be using to turn this legacy application into a leaner, more readable, more maintainable and more testable codebase.

The Application

The Application was written quick & dirty in ASP.NET MVC with Angular 1. I started on May 23 2014, and the tournament started on June 12. I continued while games were being played, but the code itself was a mess. Commit messages like “no time for good solution, ui logic in controller” provide proof. If you’re interested, you can still see the state of the code at the end of the 2014 World Championship . In upcoming posts I will dive into more detail of what existed, why it was bad, and how I fixed it.

The bottom line is that it did what it was supposed to do, and it was done (more or less) in time. The fact that it was such an ugly codebase didn’t really matter too much. I was going to fix that all for the European Championship of 2016. But that came faster than expected and apart from adding support for multiple tournaments and bugfixes, nothing was done to improve the quality of the code.

Again, this didn’t really matter as it was an application that would only be used every two years and, well, it worked. But now that I specialize in fixing legacy applications, it should be an interesting experiment to refactor. Let’s take a look at some examples of bad code.

The Comments

Sometimes, I knew there was a problem, and added a comment. This satisfies our conscience when we add the comment, but does nothing to fix the problem. Take this TODO for example:

//TODO: code grew organically with increasing number of ifs, indenting,... Crap

And there are a few other TODO comments in the code, that have never been addressed. I have a theory that most TODO items in code remain there forever, and so these must definitely be addressed when refactoring. I will have to run over the various TODO items and fix them.

Commented or Unused Code

I have previously railed against commenting out code and here I am doing the same . The solution for this is very simple: just remove it.

I take the same approach with unused code. ReSharper does a great job graying out unused code so that you can easily spot it. And it’s trivial to remove it: just move the cursor to the code and press ALT+ENTER. Another tool that does this is NDepend, which we’ll cover later.

Removing commented or unused code is something that you should just do when you see it. It’s no fun going over hundreds and thousands of lines of code to remove code. Just clean up when you encounter it.

Dependency Injection

There is no dependency injection in this project. This can quickly become a pain in a C# application of more than a trivial size. It blocks us from writing fast-running unit tests. For example, it means every Controller instantiates the DbContext by calling the constructor:

public class MatchDetailsController : ApiController { private readonly MatchesContext _contextProvider = new MatchesContext(); ... }

Because of this code, we can’t test our controllers without a database. We will have to inject an interface to abstract away the database access.

Angular 1

This was my first real single-page application (SPA), apart from a demo of Durandal . Angular 1 was still all the rage at the time and in fact, it’s called AngularJS and is still being updated. At the time I’m writing this, the latest version is 1.7.2 which was release on June 12, 2018. My application is using 1.5.5, released on April 18, 2016.

I could update to the latest version of AngularJS, but maybe it would make more sense to use Angular (6.x). I haven’t decided yet, because I could also use an entirely different framework. On the other hand, that might take us too far. We’ll get back to this issue later.

What Is Our Goal Exactly?

What is refactoring? No changes in behavior. We’ll probably change and modernize the look and feel and behavior though.

In an enterprise-context, this happens in conjunction with new features. Or at least, it should. Often, teams aren’t given time to refactor, and so they don’t. I’ve written about how we should just do the right thing , regardless of what higher management people tell us. New features are still important, but nobody is stopping you from making small improvements to ugly code that you encounter when implementing these new features.

For this excercise, I’m not going to add any new features just yet. I’m going to focus purely on refactoring and improving the codebase.

Join me in my next post as I start with an update to Bootstrap.

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

代码区博客精选文章
分页:12
转载请注明
本文标题:Fixing Legacy Applications: A Real-Life Example
本站链接:https://www.codesec.net/view/627893.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(64)