November 13, 2015 at 9:52 am
cphite (11/13/2015)
call.copse (11/11/2015)
cphite (11/10/2015)
...It was comprised of a join between two other views - their names don't matter - what matters is that each of those views was comprised of other views; as were the next views, and the next views, and the ones after that. All in all I think I counted 27 total views. I mapped the thing out and it took an entire white board.
...
Sounds like something I'm looking after. I can barely explain how much I dislike working on this system, it's virtually impossible to rewrite the views without a chunk of time I cannot take, as there are multiple procedures dependent on them. You start trying to work out what is happening but my poor brain cannot keep the whole thing in RAM, so by the time I get to the bottom of the view stack I've forgotten what was happening. Also because I am not always clear on the requirements (they're not written down and there are no comments) I have to go by trial and error on matching results and the aggregates, unions and distincts seem to have a lot of different, weird, consequences.
It will be rewritten from scratch before too long fortunately.
I have found that mapping these sorts of things out on paper helps enormously. Basically I just make a tree and keep going until I get to the base tables. At each view I put some notes about any aggregation or filtering that's taking place.
And then in most cases I just write something new from scratch, using the tree as at most a reference.
In the example I describe, it was 27 views that ultimately came from around eight tables. The final query that replaced the mess was actually pretty simple.
Or, if the views you're looking at are more complex, consider taking it on in stages. You may not be able to rewrite the thing in one pass; but maybe you can combine a handful of views into one. And then later do another handful, repeating as you have time. Eventually, you have a couple of queries (instead of dozens) and it's a lot easier to wrap your head around the whole thing.
Seems to be more common that we would like. Everyone is too busy to learn the data. Must be too easy to just use the views they know, and go from there.
The more you are prepared, the less you need it.
December 1, 2015 at 6:35 pm
Steve Jones - SSC Editor (11/10/2015)
GilaMonster (11/10/2015)
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.
Write a test. You might be surprised how much it helps.
The problem is what test to write. If the code and documentation is such that you havent a clue how it's supposed to achieve whatever it's expected to achieve (and maybe appears to achieve) your chance of producing a test that reveals anything useful is approximately nil.
I'm a great believer in testing. But I thin k youu are being a bit naive here, Steve.
Then write another.
When the first test fails to provide ny useful information people tend to be discouraged from writing another. For a serious chunk of software, you need to star from "write five dozen tests" - and then use the one (ones if you are lucky) that tells you something useful to discover some more tests that have a good chance of being useful.
Tom
December 2, 2015 at 2:35 am
TomThomson (12/1/2015)
...When the first test fails to provide ny useful information people tend to be discouraged from writing another. For a serious chunk of software, you need to star from "write five dozen tests" - and then use the one (ones if you are lucky) that tells you something useful to discover some more tests that have a good chance of being useful.
Write the first test with a purpose. Either you are defining a scenario covered by a recorded defect or you are proving new code. The value is there if the intent is.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 2, 2015 at 3:13 am
TomThomson (12/1/2015)
For a serious chunk of software, you need to star from "write five dozen tests" - and then use the one (ones if you are lucky) that tells you something useful to discover some more tests that have a good chance of being useful.
I think the app I was talking about would probably need a gross of tests before changing anything to make it safe to change things. The entire thing was so tightly coupled, most functions were thousands of lines long, calling other functions thousands of lines long. Most functions had multiple parameters that would change what they did. It was a serious mess.
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
December 2, 2015 at 4:21 am
I am currently adding a database to an app that has used a mixture of application and user defined directories containing a variety of text and binary files. The original app has around 150k lines of code of which, by my estimate, a third is duplicated. In some places it is seriously scary - there are two 10 letter identifiers that differ by only one character 0ne being a Class and the other a data structure, with the potential of the latter being manipulated by the former. Ideally major areas need re-coding but time pressures will not let this happen.
I have started writing a test plan to ensure all the changes work correctly - over 250 test cases so far. It will be a good starting point when the app migrates to the cloud as it will then have to be rewritten for both security and a multi-user environment.
December 2, 2015 at 2:37 pm
I find the idea that code can be so scary that no-one will touch it hard to understand. Either the code does what is wanted, or it doesnt. If it does, I'm not going to touch - not because it's scary, but because there's no need to touch it. If it doesn't do what's required, I'm going to touch it, enen if at the end of the day I decide that the only reason to touch it is to see see if I can find any useful stuff in it to use in the working replacement for it that has to be built.
Yes, I've had to deal with code where I hadn't a clue how it worked, why it had ever worked, or why it sometimes didn't work, and I guess that's what the editorial means by "scary code"; and on at least one occassion that was code I'd written myself. But even then I found a use for some of it in its replacement.
Tom
December 3, 2015 at 4:22 am
TomThomson (12/2/2015)
I find the idea that code can be so scary that no-one will touch it hard to understand...
I think that it was just a turn of phrase describing the scenarios when one might be apprehensive. There are no dragons here.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 3, 2015 at 7:59 am
Gary Varga (12/3/2015)
TomThomson (12/2/2015)
I find the idea that code can be so scary that no-one will touch it hard to understand...I think that it was just a turn of phrase describing the scenarios when one might be apprehensive. There are no dragons here.
I'll have to disagree here..., I've seen several companies where management did not want to put in the resources to understand how older processes work. Until they break. And then just enough resources to get them back up and running. The managers fully expect to be somewhere else in the near future, and figure that it can be someone else's problem. Sadly, an increasing problem in many organizations.
The more you are prepared, the less you need it.
December 3, 2015 at 8:17 am
Andrew..Peterson (12/3/2015)
Gary Varga (12/3/2015)
TomThomson (12/2/2015)
I find the idea that code can be so scary that no-one will touch it hard to understand...I think that it was just a turn of phrase describing the scenarios when one might be apprehensive. There are no dragons here.
I'll have to disagree here..., I've seen several companies where management did not want to put in the resources to understand how older processes work. Until they break. And then just enough resources to get them back up and running. The managers fully expect to be somewhere else in the near future, and figure that it can be someone else's problem. Sadly, an increasing problem in many organizations.
That is certainly true but not the scenario I think people are referring to as "scary code".
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 3, 2015 at 9:18 am
TomThomson (12/2/2015)
I find the idea that code can be so scary that no-one will touch it hard to understand. Either the code does what is wanted, or it doesnt. If it does, I'm not going to touch - not because it's scary, but because there's no need to touch it. If it doesn't do what's required, I'm going to touch it, enen if at the end of the day I decide that the only reason to touch it is to see see if I can find any useful stuff in it to use in the working replacement for it that has to be built.Yes, I've had to deal with code where I hadn't a clue how it worked, why it had ever worked, or why it sometimes didn't work, and I guess that's what the editorial means by "scary code"; and on at least one occassion that was code I'd written myself. But even then I found a use for some of it in its replacement.
The problem is when a situation comes up where it doesn't work and you have to fix it, or when you need to add new functionality; and you find yourself spending much more time tracking down whatever it is you need to change - and determining what else will break when you change it - than you do actually making whatever change you intended.
So, while it's not a high priority, whenever I see code that is far more complicated than it needs to be, I try to deal with that when I have time to spare, rather than deal with it when time is critical.
Viewing 10 posts - 61 through 69 (of 69 total)
You must be logged in to reply to this topic. Login to reply