It's not used anymore
-
So we have a lot of asynchronous processing of our business model through COM+ components. Recently, I've been porting them from C++ to C#. Most of them are extremely simple, in actual functionality, and the 100+ line function that was mostly XML XPath parsing in C++, then did the regular logic, got converted to approximately 5 lines in C# (with proper OO techniques). As I said, these are mostly extremely simple. Deserialize the XML message, call a proc, then drop the message, or part of it, to another queue. Because of the convoluted mess that is the C++ code, most of the time is figuring out what they're actually doing, and not missing any edge cases. Seeing as how nobody from the time this code was written is on the team currently, we unfortunately don't know a ton about the business purpose behind some of the older code. So I get done writing 3 components, and my coworker went to find out exactly what the purpose of calling this stored procedure was.
Coworker: hey <dba>, can you help me figure out what this proc in the <> DB does? <proc name> it gets called after <some process>
DBA: ya, it's an old process that we tried to <purpose> it didn't work
Coworker: it still gets called though. does the proc just not do anything?
DBA: you sure? I thought we turned if off in the config
Coworker: I'm positive that it gets called after every <process>
DBA: that can be disabled if you have a way to do that
So we have this functionality in our system that was created in April '09, didn't work so the config was disabled, meaning this component has never really done anything. It's still in the workflow, though, and it still gets updated whenever there's some new "update all the components to use this" feature. Luckily, we're in a situation where we can create a project and actually remove it from the workflow, so it won't be around for long.
-
In a previous job we would approach a business requirement as such:
1.) Create a unit test for an instance that encompasses the workflow/lifecycle as a whole, with mock classes that use stub functions. (In other words, the unit test simply proved that the workflow performed all necessary steps in order.)
2.) Create a unit test for each step in the workflow/lifecycle. Each instance in this workflow would be the "concrete" classes that actually did stuff.
3.) After all is finished, client/boss/stakeholders/etc make alterations to the workflow by adding, deleting, and modifying what we just did.
4.) Many times, instead of removing the class out of the workflow entirely, simply stub out the function if it's no longer necessary, but leave it in the workflow.
Over time we'd have tons of functions that simply invoked a callback or was populated with a // noop comment, leaving many newbies (such as myself, at the time) scratching their heads.
-
@Sutherlands said:
So we have a lot of asynchronous processing of our business model through COM+ components. Recently, I've been porting them from C++ to C#. Most of them are extremely simple, in actual functionality, and the 100+ line function that was mostly XML XPath parsing in C++, then did the regular logic, got converted to approximately 5 lines in C# (with proper OO techniques). As I said, these are mostly extremely simple. Deserialize the XML message, call a proc, then drop the message, or part of it, to another queue. Because of the convoluted mess that is the C++ code, most of the time is figuring out what they're actually doing, and not missing any edge cases. Seeing as how nobody from the time this code was written is on the team currently, we unfortunately don't know a ton about the business purpose behind some of the older code. So I get done writing 3 components, and my coworker went to find out exactly what the purpose of calling this stored procedure was.
Coworker: hey <dba>, can you help me figure out what this proc in the CustomerAccountsData DB does? isCustomerValid, it gets called after CustomerSessionStart.
DBA: ya, it's an old process that we tried to verify security hashes on login, it didn't work
Coworker: it still gets called though. does the proc just not do anything?
DBA: you sure? I thought we turned if off in the config
Coworker: I'm positive that it gets called after every CustomerSessionStart
DBA: that can be disabled if you have a way to do that
So we have this functionality in our system that was created in April '09, didn't work so the config was disabled, meaning this component has never really done anything. It's still in the workflow, though, and it still gets updated whenever there's some new "update all the components to use this" feature. Luckily, we're in a situation where we can create a project and actually remove it from the workflow, so it won't be around for long.
you need to funnify your anonymization, it's hard to keep track in generic types.
what the componen/function was supposed to do?
-
Something like summarize the usage on the account (bandwidth, diskspace).
Although i can't say your change is totally out of line...
-
It's an antipattern called "lava flow". Every system has them unless they are [b]constantly[/b] refactored.
