I have working on a web app for almost 2 years now and a lot unnecessary code(c#, html, js, css ) has accumulated in it. I have been trying to clean it up for a while now but with not great success.
Can you guys sugest ways(tools) by which i speed up this process.
Perhaps you should try using Resharper. Should work fine with Visual Studio.
What you are trying to do is called refactoring. Most IDEs provide automated support for it to a greater or lesser extent (depending on the language too) - check out yours.
It's no silver bullet - you still have to think, plan, write unit/functional tests to ensure you are not breaking anything, etc. But there are known methods and processes in place, which help you a lot.
Related
Q:
Lately ,i asked for testing a code ,,to detect the bugs and fix the problems ,,i find many problems ,, but the main problem here is the code it self ,, spaghetti code many many code lines and the tracing to fix problems is so difficult ,, plus some code is copied and pasted from the internet as it is without any modification,, no documentation is possible to this code,,the performance is so bad due to the heavy using of viewstate in every thing,, and it takes me a lot of time to fix the problems ,, and iam afraid of after all this time still other bugs may appear in the future .. how to handle this case ,,any advices concerning this issue will be a great help.
Start refactoring. This will not make only the code better readable it will also give you a btter understanding on how it works and what it does.
That's a very common situation - software was developed for some years and by many different developers and now you have to support it. You should fight the will to throw it away and rewrite the whole application - it is a big effort and chances are big that you will do many mistakes that are already fixed in bad code. See Joel article for more explanations.
In my experience the best way is to refactor the code. However it involves writing a lot of tests - unit, automated acceptance - and it will take almost the same time as rewriting, but it will be less pain
I think the mentality for working with spaghetti code is summed up quite well in Refactoring by Martin Fowler.
The picture that comes to my mind is surgery: The entire patient except the part to be operated on is draped. The draping leaves the surgeon with only a fixed set of variables. Now, we could have long arguments over whether this abstraction of a person to a lower left quadrant abdomen leads to good health care, but at the moment of surgery, I'm kind of glad the surgeon can focus
Basically what that means is start small, and update a single part of the code at a time. Little changes will add up to good, structured code in the future.
Of course, if there are major problems with the entire architecture, you may have to heed Cybernate's advice and start from scratch (unpleasant as it may be).
I would also write unit tests as well as refactoring as codymanix said. This does a couple things:
As you refactor, you will have some check that your refactoring won't break things.
Writing the tests is a good way of learning the domain knowledge embedded in the code.
Of course, there is an inherent catch-22 with adding unit tests to spaghetti code: it is usually hard to unit test, and you need to refactor it to be able to make it testable. But if you go bit by bit and start with the low-hanging fruit, usually you can make it readable.
Scrap the existing code and start afresh.
That involves lot less effort comparitively.
If that's not a possible option start with Refactoring using tool like ReSharper that will give a good start.
I would like to get some tips from peer developers about how you go about testing an application you developed, prior to release to QA. Keep in mind, this is a small scale application (requirements are verbal), and so doing formal testing processes wont work, especially, since your boss told you to develop this app quick, push it out the door.
Despite the time restraints, I would like to make sure it is bug free, however, numerous times in the past, I have had the app sent back to me because clicking the "Reset" button, messes up the other controls alignment etc.
I know there are people out there that develop small scale apps fast, and send them out with minimal bugs. How can I achieve that?
I researched this post, but it didnt quite answer my question.
Testing your code before releasing to QA
Unit testing and something like Selenium for simple UI verification might be enough. You've given impossible constraints - testing and pushing it out the door conflict. You can only do the amount of testing that doesn't compromise the speed issue.
Let's face it - all software has bugs, and the second law of thermodynamics applies. Even code that works perfectly on the day you ship will evolve and need changes, updates, and face lifts as time goes by.
Making an application bug free is quite hard even if it's tiny. The advantage is that you can test almost any aspect of such a tiny application by hand. There will however be features you cannot test at the end of your development process. It is always good to test small features on the go. It also pays to have someone else test your application and (if possible) make another developer review your code.
But then, it is probably impossible to fully test a weeks work in a few hours.
The best advise is to make at least someone test you application as it is commonly used. Nothing frustrates a user more than an error on the first clicks. Errors in a more deeply hidden feature that is hardly used is easier forgiven. So test as a user, not (only) as a programmer.
One important thing is to either develop multiple personalities or get someone else to run through the app at least once -- you are too close to the problem so there could be a design flaw that makes things unusable. Which is not technically a defect, but users do not understand the difference between "working as designed but the design was wrong" and "horribly broken."
Keep in mind, this is a small scale application (requirements are verbal), and so doing formal testing processes wont work, especially, since your boss told you to develop this app quick, push it out the door.
Did your boss also tell you not to test?
Developing quickly without tests usually does not in fact get the thing done more quickly.
There are of course no guarantees, but you might consider doing test-driven development to get the tests and maybe get code that actually works done more quickly.
See Scott Bellware's blog entry: Does Test-Driven Development Speed Up Development?
I bet many of you were in such situations in the past.
I'm currently working on huge ASP.NET web project. Ad management system of some kind. My boss doesn't want to get more professionals to help me but gives me inexperienced staff that don't even know to program on ASP.NET and think it is an easy task. I deal with programming and design
What advices do you have to handle the boss ?
What tools can help me to ease with this task ( except usage of this very website )?
Thanks
I would hope good source control is something you already haev on your list but I think its always the best thing for any big project. Keeps your code safe and has the added advantage of allowing easy review of what your team are checking in if you feel the need for oversight.
Other than that just make sure you give your boss a realistic understanding of the time taken for various tasks and if he complains make it clear that your team needs more training if he wants stuff done faster.
P.S. [Edit: removed as no longer relevant]
You could ask him for a raise from getting rid of the people who are not helpful. that might actually save him money and make your time more worthwhile.
What advices do you have to handle the boss ?
First make sure you have a good analysis document and that you have for every dependency a spoc (single point of contact). Make sure the people who you're making this application for are integrated into the process. I suggest using something like scrum but certainly daily standup meetings.
Use a good system to follow up on everyone like for example TFS2010 which has also testing capabilities integrated so your testing team can be better integrated.
Have a bug tracking tool and source safe handy. Continuous integration is also an asset.
but gives me inexperienced staff that don't even know to program on ASP.NET
It's your boss intention to upgrade his people to a level where they are capable of programming ASP.NET applications in the end. What way to better learn it than hands on experience from a dedicated professional like you?
Be aware: you're dealing with people now, not just code. They get sick, have their strenghts and weaknesses just like you. And believe me, it can be a challenge sometimes to deal with the human part of a project. Especially when there's pressure due to release dates.
Perhaps you can convince him to distribute some (technical...) parts of the project to RentAcoder.com or getAfreelancer.com? It will be cheaper than getting more manpower..
Use a decent workitem/bugtracking system. This won't turn your 'inexperienced devs' into experts but at least you'll be able to see what progress they are making(or not making as the case may be)
I religiously go through all of my code before I check it in and do a diff of the before and after code and read through it and make sure I undersatnd the changes. Usually I end up having to add comments, amend variable names, amend algorithms, amend code, retest things, discuss with other developers about their code, add new bugs/issues, but I very rarely end up doing the checkin immediately.
I do notice however that alot of developers these days seem to check their code in and think that when the build breaks that it is enough, then they go back and look at their changes. This is one of the things about continuous build systems that I definitely do not like, in that sometimes I think developers stop thinking about their code enough.
What best practices are there for ensuring only quality code goes into continuous build systems?
I do notice however that alot of developers these days seem to check their code in and think that when the build breaks that it is enough, then they go back and look at their changes.
In my opinion, using the continuous build for "verification" purpose is indeed a bad practice, developers should always try to not commit bad code that can affect the team and interrupt the work (the why is so obvious that if you don't get that, just look for another job). So, if your CI engine doesn't offer Pre-tested commit (like TeamCity, Team Foundation Server as I just saw, maybe Hudson one day, etc), you should always sync/build/sync (and rebuild if necessary) locally before to commit. Not doing this is laziness and not respectful of the team.
What best practices are there for ensuring only quality code goes into continuous build systems?
Just in case, remind why breaking the build is bad: bad code potentially affects the whole team and interrupts the work (sigh).
If you can get tool support (see the mentioned solutions above), get it.
If not, document the right workflow: 1. sync 2. build locally 3. sync 4. back to 2 if required 5. commit. Make this visible so that there is no excuses.
If this is an option, use something like (or similar to) the Hudson's Continuous Integration Game plugin. This can make things more fun.
I've seen people using a light financial "penalty" for broken build but I don't really like this idea. First, we should be able to behave as responsible adults. Second, the obtained result was that people started to delay commits (which at the end was the opposite of the expected benefit).
Team Foundation Server has something called pre checkin validation.
We're in the process of redesigning the customer-facing section of our site in .NET 3.5. It's been going well so far, we're using the same workflow and stored procedures, for the most part, the biggest changes are the UI, the ORM (from dictionaries to LINQ), and obviously the language. Most of the pages to this point have been trivial, but now we're working on the heaviest workflow pages.
The main page of our offer acceptance section is 1500 lines, about 90% of that is ASP, with probably another 1000 lines in function calls to includes. I think the 1500 lines is a bit deceiving too since we're working with gems like this
function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID, sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)
The standard practice I've been using so far is to spend maybe an hour or so reading over the app both to familiarize myself with it, but also to strip out commented-out/deprecated code. Then to work in a depth-first fashion. I'll start at the top and copy a segment of code in the aspx.cs file and start rewriting, making obvious refactorings as I go especially to take advantage of our ORM. If I get a function call that we don't have, I'll write out the definition.
After I have everything coded I'll do a few passes at refactoring/testing. I'm just wondering if anyone has any tips on how to make this process a little easier/more efficient.
Believe me, I know exactly where you are coming from.. I am currently migrating a large app from ASP classic to .NET.. And I am still learning ASP.NET! :S (yes, I am terrified!).
The main things I have kept in my mind is this:
I dont stray too far from the current design (i.e. no massive "lets rip ALL of this out and make it ASP.NET magical!) due to the incredibly high amount of coupling that ASP classic tends to have, this would be very dangerous. Of course, if you are confident, fill your boots :) This can always be refactored later.
Back everything up with tests, tests and more tests! I am really trying hard to get into TDD, but its very difficult to test existing apps, so every time I remove a chunk of classic and replace with .NET, I ensure I have as much green-light tests backing me as possible.
Research a lot, there are some MAJOR changes between classic and .NET and sometimes what can be many lines of code and includes in classic can be achieved in a few lines of code, think before coding.. I've learnt this the hard way, several times :D
Its very much like playing Jenga with your code :)
Best of luck with the project, any more questions, then please ask :)
After I have everything coded I'll do a few passes at refactoring/testing. I'm just wondering if anyone has any tips on how to make this process a little easier/more efficient.
(source: cartoonstock.com)
Normally I'm not a fan of TDD, but in the case of refactoring it really is the way to go.
Write some tests first which verify what the bit you're looking at is actually doing. Then refactor. This is a LOT more reliable than just 'it looks like it still works.'
The other huge benefit to this is that when you're refactoring something which is further down the page, or in a shared library or something, you can just re-run the tests, as opposed to finding out the hard way that a seemingly unrelated change was actually related
You're going from classic ASP to ASP with 3.5 without just re-writing? Skillz. I've had to deal with some legacy ASP #work and I think it's just easier to parse it and re-write it.
A 1500-line ASP page? With lots of calls out to include files? Don't tell me -- the functions don't have any naming convention that tells you which include file has their implementation... That brings back memories (shudder)...
It sounds to me like you have a pretty solid approach -- I'm not sure if there is any magical way to mitigate your pain. After your conversion effort, the architecture of your app will still be messy and UI-heavy (i.e. code-behind running workflows), and it will probably still be fairly painful to maintain, but the refactoring you are doing should definitely help.
I hope you have weighed the upgrade you are doing against just rewriting from scratch -- as long as you are not intending to extend the app too much and you are not primarily responsible for maintaining the app, upgrading a complex workflow-based app like you are doing may be cheaper and a better choice than rewriting it from scratch. ASP.NET should give you better opportunities to improve performance and scalability, at least, than Classic ASP. From your question I imagine that it is too late in the process for that discussion anyway.
Good luck!
Sounds like you have a pretty good handle on things. I've seen a lot of people try to do a straight-line transliteration, includes and all, and it just doesn't work. You need to have a good understanding of how ASP.Net wants to work, because it's much different from Classic ASP, and it sounds like maybe you have that.
For larger files, I'd try to get a higher level view first. For example, one thing I've noticed is that Classic ASP was horrible about function calls. You'd be reading through some code and find a call to a function with no clue as to where it might be implemented. As a result, Classic ASP code tended to have long functions and scripts to avoid those nasty jumps. I remember seeing a function that printed out to 40 pages! Parsing straight through that much code is no fun.
ASP.Net makes it easier to follow function calls around, so you might start by breaking out your larger code blocks into several smaller functions.
Don't tell me -- the functions don't
have any naming convention that tells
you which include file has their
implementation... That brings back
memories (shudder)...
How did you guess? ;)
I hope you have weighed the upgrade
you are doing against just rewriting
from scratch -- as long as you are not
intending to extend the app too much
and you are not primarily responsible
for maintaining the app, upgrading a
complex workflow-based app like you
are doing may be cheaper and a better
choice than rewriting it from scratch.
ASP.NET should give you better
opportunities to improve performance
and scalability, at least, than
Classic ASP. From your question I
imagine that it is too late in the
process for that discussion anyway.
This was something we talked about. Based on timing (trying to beat a competitor's site to launch) and resources (basically two developers) it made sense to not nuke the site from orbit. Things have actually gone much better than I expected. We were aware even from the planning stages that this code was going to give us the most problems. You should see the revision history of the classic ASP pages involved, it's a bloodbath.
For larger files, I'd try to get a
higher level view first. For example,
one thing I've noticed is that Classic
ASP was horrible about function calls.
You'd be reading through some code and
find a call to a function with no clue
as to where it might be implemented.
As a result, Classic ASP code tended
to have long functions and scripts to
avoid those nasty jumps. I remember
seeing a function that printed out to
40 pages! Parsing straight through
that much code is no fun.
I've actually had this displeasure of working with the legacy code quite a bit so I have a decent high level understanding of the system. You're right about the function length, there are some routines (most I've refactored down into much smaller ones) that are 3-4x as long as any of the aspx pages/helper classes/ORMs on the new site.
I once came across a .Net app that was ported from ASP. The .aspx pages were totally blank. To render the UI, the developers used StringBuilders in the code behind and then did a response.write. This would be the wrong way to do it!
I once came across a .Net app that was ported from ASP. The .aspx pages were totally blank. To render the UI, the developers used StringBuilders in the code behind and then did a response.write. This would be the wrong way to do it!
I've seen it done the other way, the code behind page was blank, except for declaration of globals, then the VBScript was left in the ASPX.