Yet Another Representative Code



  • I was given the task to rewrite some old program of ours. I could write a book about it, but I'm going to show you guys just this one representative piece of code, that is written many, many times across the program. Verbatim, with only some slight identation variance:

        }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}

    This appears at random. All the team architect had to say was "good luck".

    ...



  •  What.

     The.

     Fuck!



  • I'm in the exact situation here: I tried digging through the rotting flesh to find how this rickety old app works, but every time a traced a piece of functionality, I found that:

    a) It never worked in the first place

    2) It's buried behind a scary (212 table) schema with similar table and column names, and barely works

    iii) Buried 4-5 views deep with case statements, and when broken down into smaller pieces, are also broken.

    Wanna know what I did?  Closed the fucking IDE and started from scratch based off the requirements and wire-frames. I already lost a piece of my soul by mapping the old schema to my new one, but once I did that, I didn't really have to look back.  I just found that I was spending more time trying to figure out if it's supposed to do it that way, or is it broken...



  • @C-Octothorpe said:

    I'm in the exact situation here: I tried digging through the rotting flesh to find how this rickety old app works, but every time a traced a piece of functionality, I found that:

    a) It never worked in the first place

    2) It's buried behind a scary (212 table) schema with similar table and column names, and barely works

    iii) Buried 4-5 views deep with case statements, and when broken down into smaller pieces, are also broken.

    Wanna know what I did?  Closed the fucking IDE and started from scratch based off the requirements and wire-frames. I already lost a piece of my soul by mapping the old schema to my new one, but once I did that, I didn't really have to look back.  I just found that I was spending more time trying to figure out if it's supposed to do it that way, or is it broken...

    That's great when you have both a schema and a specification. I've got neither, and I'm also being paid to try and find out how the old program works and what it does.



  • [quote user="Renan "C#" Sousa"]That's great when you have both a schema and a specification. I've got neither, and I'm also being paid to try and find out how the old program works and what it does.[/quote]I'm...  So sorry...



  • @C-Octothorpe said:

    Wanna know what I did?  Closed the fucking IDE and started from scratch based off the requirements and wire-frames.
    Amen.  Nuke it from orbit... it's the only way to be sure.

     Table-Oriented Programming is a bitch to refactor or comprehend after the fact, because every special case ends up in the SQL.  DAL should be pure; use cases should be in the business layer.



  • [quote user="Renan "C#" Sousa"]
    That's great when you have both a schema and a specification. I've got neither, and I'm also being paid to try and find out how the old program works and what it does.[/quote]Assuming your project owner survived, the BOFH would solve this by destroying the hard drive the application is on as well as the backup hardware.  By the time the replacement backup hardware arrives, everyone in the company will know exactly what that software does.  If you need more time, just jam a daughterboard in backwards or something.



  • @hoodaticus said:

    Amen.  Nuke it from orbit... it's the only way to be sure. Table-Oriented Programming is a bitch to refactor or comprehend after the fact, because every special case ends up in the SQL.  DAL should be pure; use cases should be in the business layer.
    I'm actually working on an MVC3 app right now, and I have all the business logic behing the service layer and the controllers are pretty empty only passing stuff to and from the client proxy and view.



  • @C-Octothorpe said:

    have all the business logic behing the service layer and the controllers are pretty empty only passing stuff to and from the client proxy and view.
    Nice.  Controllers don't usually get that complicated in business apps in my experience.  But God save the maintainer if you forgo it entirely.



  • @hoodaticus said:

    @C-Octothorpe said:
    have all the business logic behing the service layer and the controllers are pretty empty only passing stuff to and from the client proxy and view.
    Nice.  Controllers don't usually get that complicated in business apps in my experience.  But God save the maintainer if you forgo it entirely.
    What do you mean? I put as much of the business logic in the service layer as possible, and only hydrate ViewModels in the controllers.  You can also argue that even some rendering logic is business logic; lets say some property like Total, if it gets below zero, it turns red and bold.  Isn't that *also* a type of business logic?  If this is true, then you can never really seperate your views from your business logic (although MV[C|P], MVVM patterns will get you as close as possible).



  • @C-Octothorpe said:

    @hoodaticus said:

    @C-Octothorpe said:
    have all the business logic behing the service layer and the controllers are pretty empty only passing stuff to and from the client proxy and view.
    Nice.  Controllers don't usually get that complicated in business apps in my experience.  But God save the maintainer if you forgo it entirely.
    What do you mean? I put as much of the business logic in the service layer as possible, and only hydrate ViewModels in the controllers.  You can also argue that even some rendering logic is business logic; lets say some property like Total, if it gets below zero, it turns red and bold.  Isn't that also a type of business logic?  If this is true, then you can never really seperate your views from your business logic (although MV[C|P], MVVM patterns will get you as close as possible).



  •  @C-Octothorpe said:

    lets say some property like Total, if it gets below zero, it turns red and bold.  Isn't that *also* a type of business logic?
    I'm pragmatic about it - do what it to takes to make the code as clean as possible.  If I have styling information in a customer record, then style will be handled initially by the Model.  If the styling requirement is going to be consistent with a given UI, then it goes in the View.  If style is dynamic based on complex states in the View, then I put it in my controller/ViewModel.


  • Garbage Person

     Every layer needs some semblence of business logic. A properly built relational DB can be the *entire* model layer if you really want - you controller can be a single class that shovels data back and forth between the two, but more likely it's going to require things like "in such and such case, do these TWO things to the database instead of just one" - business rules. The view layer needs business rules to present them to the user and to have any sort of workflow at all.

     

    The trick is separating the business rules to their proper places. A database-level business rule is either structural information (referential integrity, constraints, etc.) or a simple, atomic thing that you do to the data. Like "add a customer" or "update a customer" or "merge two customers" or "get the customer list". View-level business logic is stuff like "turn this field red if it's below zero, and don't allow the form to submit" or "Use CrystalReports to show me a breakdown of orders by customer that looks like this template". Controller-level business logic is anything that doesn't fit in the other two - "add a batch of customers" or "get me the customer list and the order list and massage them for CrystalReports"


Log in to reply