2 Replies Latest reply: Jul 1, 2010 7:33 AM by 843807 RSS

    Java web application code practice

    843807
      Hey folks!

      This client we've made some applications for(some in production) is now with a new java code auditing guy which is picking up on a lot things which in my opinion aren't relevant at the moment, and it's delaying all the development process in a specific project while we could actually be making progress on important matters. I'd like to know your opinion about certain topics. Just so you know better, this system is almost done(98% maybe), it has almost 30 Use cases and most are complicated. It was written in record time(forced by the client) from the ground(3 months) with a bunch of developers and it’s MVC with JSF (tomahawk). Also there are other similiar application in production in this same client.

      Here’s a list of their ‘complaints’ that came after the application was done:
      - Our DTOs are generally based on the DB tables, and they say ALL DTOs must have no more or less attributes than the amount of columns on the table. My view on this is the application isn't a simple CRUD, many DTOs follow that rule, but some have more attributes which you end up using for controlling conditions, rules etc.
      They even suggested we used a 'General DTO' or something for the extra attributes for all UC. I say it's a way to over complicate the code.

      - They forced us to use tomahawk 1.1, and they complain about certain anti W3C code which is generated by its tags.

      - They say there shouldn’t be use of ‘java.util.Date’. Only ‘java.sql.Date’. The system in fact uses sql.Date for its attributes in the DTOs and in some cases (outside DTOs) on some rules and conversions it uses util.Date. Anything wrong with that?

      - There are methods which you don’t know what the return inside a List is, so it’s declared like this: List fooList<Object> … so we don’t get warning on Eclipse. And I imagine that’s good for legibility as well. He says we must remove the ‘Object’ part.

      - They say we should optimize certain points with allegations such as: when you go from on screen to another(submits), don’t retrieve certain data from the database again, just keep the data on the request during all process(this UC has many steps). The data I talk about here isn’t massive, processor intensive or anything like that. Just usual registry retrieval when the user clicks the button to go to the next screen.

      - They complaint about too much line space in the code.


      There are other items which I agree with they listed and make sense to me and we’re fixing. The ones above in a gray area are the ones bothering me that keep getting talked about repeatedly because of one person’s view. Therefore wasting our time.

      Any of you ever had complaints about these items to the point where meetings are scheduled to discuss them as if they were damaging the application maintainability?
      The contract doesn’t say anywhere how we should do it specifically nor did we have to follow a developer guide line. But even so I’m positive the application was fairly well written and organized.

      I’d appreciate your view/experience on this situation and would like to know if the items above are really relevant given a crazy deadline for the application.

      I wasn't sure where to put this post, it's java code practice, web application related. Please move it if necessary.

      Thanks!!
        • 1. Re: Java web application code practice
          EJP
          - Our DTOs are generally based on the DB tables, and they say ALL DTOs must have no more or less attributes than the amount of columns on the table. My view on this is the application isn't a simple CRUD, many DTOs follow that rule, but some have more attributes which you end up using for controlling conditions, rules etc.
          Ask for a budget to meet these requirements. Ask for a cost/benefit analysis. Ask for a risk analysis. Ask what bugs, or classes of bugs, are going to be fixed by adopting this practice. Ask management for a statement of priorities: ship the product or 100% technical 'purity'.
          They even suggested we used a 'General DTO' or something for the extra attributes for all UC. I say it's a way to over complicate the code.
          That sounds worse than the disease. I rarely use POJOs at all in DBMS (or LDAP) code.
          - They forced us to use tomahawk 1.1, and they complain about certain anti W3C code which is generated by its tags.
          So ask them to make the choice.
          - They say there shouldn&#146;t be use of &#145;java.util.Date&#146;.
          See above. Ask for a budget, a cost/benefit analysis, a risk analysis.
          - There are methods which you don&#146;t know what the return inside a List is, so it&#146;s declared like this: List fooList<Object> &#133; so we don&#146;t get warning on Eclipse. And I imagine that&#146;s good for legibility as well. He says we must remove the &#145;Object&#146; part.
          He is 100% wrong about that.
          - They say we should optimize certain points with allegations such as: when you go from on screen to another(submits), don&#146;t retrieve certain data from the database again, just keep the data on the request during all process(this UC has many steps). The data I talk about here isn&#146;t massive, processor intensive or anything like that. Just usual registry retrieval when the user clicks the button to go to the next screen.
          See above. Ask for a budget, a cost-benefit analysis, a risk analysis. Ask for a measurement of the 'inefficiency' in seconds and a survey of beta-test clients who complained/didn't complain about the performance at that point.
          - They complaint about too much line space in the code.
          Tell them to get knotted. Tell them that things that don't make any difference to the generated byte code are out of scope. Ask for a budget/cost-benefit analysis/risk analysis etc as above.
          The ones above in a gray area are the ones bothering me that keep getting talked about repeatedly because of one person&#146;s view. Therefore wasting our time.
          I agree. Time spent arguing is time wasted. If the benefit isn't self-evident let them establish the business case.
          Any of you ever had complaints about these items to the point where meetings are scheduled to discuss them as if they were damaging the application maintainability?
          Only on projects that had analysis paralaysis. On projects that I've run things were done my way or the highway.
          The contract doesn&#146;t say anywhere how we should do it specifically nor did we have to follow a developer guide line.
          Ship a working product and improve it when the revenue starts rolling in.
          • 2. Re: Java web application code practice
            843807
            Thanks, ejp. I really appreciate your input. Especially coming from someone experienced.