November 9, 2015 at 8:29 pm
Comments posted to this topic are about the item Do You Have Scary Code?
November 10, 2015 at 1:11 am
Recent client has 6 millions line of code in COBOL, VB5 and PL/SQL (plus a little VB.NET and C# in the mix). It was written in the mid-90s.
Their opinion is that if you can get away with it then the preference is to leave it alone.
I don't argue with that.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 3:03 am
Couldn't agree more, but you have to accept that to make this work you need to invest time at the beginning and it isn't always available - or at least people think it isn't.
It pays back big time if you do though. start with a simple script to run the most common use case from live and test and compare the results. even this will take a day to set up, but it's a start and you can add the rare use cases as you go along.
K8
November 10, 2015 at 3:18 am
It definitely is too expensive to save money by not unit testing software. The same goes for documentation.
Especially for newbies that work themselves into it: If they have documentation AND tests they hesitate far less when implementing or adapting functionality...
________________________________________________________
If you set out to do something, something else must be done first.
November 10, 2015 at 3:23 am
I joined a project part way though and got ridiculed the week when I added the first unit test project to the solution. It had 1 test.
By then end of the project it had hundreds and proved invaluable.
The overhead of adding the first test is too costly for the benefits from just one test but the return on a significant number of unit tests is immense. NOTE: Significant here is totally dependent upon specifics.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 5:36 am
Gary Varga (11/10/2015)
I joined a project part way though and got ridiculed the week when I added the first unit test project to the solution. It had 1 test.By then end of the project it had hundreds and proved invaluable.
The overhead of adding the first test is too costly for the benefits from just one test but the return on a significant number of unit tests is immense. NOTE: Significant here is totally dependent upon specifics.
Hi Gary,
Not having touched any front-end code for well over a decade, I'm admittedly a bit lost when people say things like "added a unit test project to the solution". What does that project consist of and (just looking for a high level explanation) how does it test front-end code?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 10, 2015 at 6:03 am
Actually im on that exactly scenario.
Working on 10 year old VB6 application that's in production.
No less than 5 programmers pass trough this code and none of them still on this project 😀 only me.
November 10, 2015 at 6:10 am
While unit testing is definitely a skill I need to improve, there are legacy applications and code I've been dealing with for years and I have no problem messing with them. I keep going back to stuff *I've* written thinking: "I could probably do that better."
One simple reason: I have a testing environment. Between that and source control, I can try all kinds of crazy things with no worry I'll blow up anything in production.
Even so I've had a couple of "Oh s---" moments now and again, but nothing that affected valuable data and couldn't be fixed in a couple of moments.
There are a couple things I don't mess with yet because there are some skills I know I need to learn, but that doesn't mean I won't ever tackle those challenges. Case in point: For a while I really had no idea now to print natively from .NET (as opposed to using a third-party alternative). So I sat down with MSDN, Google and Visual Studio and knocked out a mini word processor to learn it. We have an Access-based application that prints various reports and controlled forms and now I fell confident enough that I can (eventually) replace Access entirely.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
November 10, 2015 at 6:30 am
I've recently seen a system with many user-defined functions, each with thousands of lines of code, often calling each other. Tests or no tests, I'm not touching that.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
November 10, 2015 at 6:30 am
Over the years I think I've written some of that scary code. If something needs changing then change it. But I am not a proponent of just changing code because you think you can make it better, because you don't like the way it was written. Half the time that introduces errors. Just leave it alone unless there is a good reason to be in there messing with it.
November 10, 2015 at 6:39 am
I would lurrv to work on that system, for exactly that reason.
😀
November 10, 2015 at 6:39 am
I'm in a similar situation myself. I have a large stored procedure that calls other procedures (sometimes multiple times) and the logic is a bit dizzying. The sheer amount of code isn't the problem, however. Many of the individual pieces are not written optimally and the overall approach is a bit haphazard. It takes hours to run, bloats the logs and really dogs the server when it runs.
To be fair, the specifications have been in a state of always-changing for years and the code reflects it. It's also had several authors over the years, but it's in desperate need of a rewrite. The owners on the business side have never taken the time to give it the overhaul it so desperately needs until now. Somehow, I won the prize of getting to do it. I guess I should be honored.
November 10, 2015 at 6:45 am
Jeff Moden (11/10/2015)
Gary Varga (11/10/2015)
I joined a project part way though and got ridiculed the week when I added the first unit test project to the solution. It had 1 test.By then end of the project it had hundreds and proved invaluable.
The overhead of adding the first test is too costly for the benefits from just one test but the return on a significant number of unit tests is immense. NOTE: Significant here is totally dependent upon specifics.
Hi Gary,
Not having touched any front-end code for well over a decade, I'm admittedly a bit lost when people say things like "added a unit test project to the solution". What does that project consist of and (just looking for a high level explanation) how does it test front-end code?
This was .NET so some of that is just the lingo for that technology stack.
A .NET solution is a collection of .NET projects. In this case one being a unit test project. This unit test project is a container to hold the definitions of the unit tests and used to group them together in order to execute them in a single run.
Often these unit tests are used to check the database interaction, the application logic and the presentation logic. Sometimes, albeit rarely, the UI is tested like this as well.
Does that answer your question Jeff?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 6:46 am
kate.fletcher 80760 (11/10/2015)
I would lurrv to work on that system, for exactly that reason.😀
Where is that Like button? Ooops. Different website 😛
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 10, 2015 at 6:47 am
I believe the term is "technical debt". If you're allowing code to age, you are allowing it to die and eventually bring down the company with it. My approach is to always tackle some large technical problem right after a code branch to have plenty of time to test before release. It is a good time to get rid of deprecated features, change schema to clarify data, and refactor code.
Fear of changing code = fear of working for a company getting further in debt.
Viewing 15 posts - 1 through 15 (of 69 total)
You must be logged in to reply to this topic. Login to reply