Develop Reference

How to phrase to business why refactoring is important [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am currently working on a project with some (in my opinion) architectural problems.
For example - every dependency is retrieved when needed from a common Framework Bean that every object has access to via a static method. This is in effect just a wrapper around spring that will return a Spring bean. No dependency injection.
Entities have references to DAO's to retrieve relational data - hidden in the Entity getters.
Exceptions have references to services to parse and translate error messages.
Every service or DAO inherits from some common abstract framework bean that have their own dependencies and configuration requirements. If you try to do anything else you will get a 'Framework not initialized' error. It should also be mentioned that the Framework is a black box that noone dares touch.
Every test is in effect an integrationn test as all of them requires a working database connection to a central, shared database.
We have a dependency graph that everything is connected to everything, basically.
And no tests.
Imagine how hard it is to set up a unit test in this environment. In fact every test tries to insert test data and clean up after itself - without using any kind of transaction.
And I'm only scratching the surface here.
Needless to say, I worry a little about the code quality. The project is (of course) running low on time and resources, and deadline is approaching.
So - How to convince management in a language they understand that refactoring is needed if we shall have any hope of delivering something that resembles functional software?

In my opinion the best approach is:
Metrics: Collect all the possible data about the problems caused by the use of the current architecture. Analyze the information and separate it in topics of interest like: reliability, efficiency, security and Maintainability. (See: Software quality)
Visual: Make beautiful bar charts and pie charts with the analyzed info.
Diff: Compare your results with an standard or ideal metrics.
With this you are ready to present your point of view of the project to the management.
Usually this work is responsibility of project manager, team manager, or team leader.
Good luck!

Actually, in many cases refactoring may not be good for business, because benefits are less than cost. In other cases benefits may be bigger than cost, but cost is too much to be payed right now. Try to estimate benefits and cost of refactoring in some units which business can convert to $$$, i.e. in man hours of developers, testers and support team, in hours of system unavailability, etc and let business decide whether refactoring is worth to be done, or not. Such decisions is where business is stronger than developers.

I'm working on a project that is similar in dependencies. Unit testing it isn't ideal. I'm mocking so many classes in each my tests that simply running the full application in a development environment is a better solution.
I guess it depends on your application. Mine was a custom web application serving HTTP requests. I turned it on and sent all sorts of requests to try and follow all possible paths. It is more of a functional test than unit testing, but I found the process to be much faster and my log statements were informative enough to lead me to bugs in specific class or methods.
I wrote my code, functional tested it in dev. environment, then when I found time, I slowly added unit tests to classes.
Talk to them about the expected changes that might affect the future of your application, new features, requirements, technologies, etc. The project might not warrant refactoring if it'll never evolve.
I am not saying functional testing is a replacement for unit testing.

If you think you need to persuade "the business" about the benefits of refactoring, what you have in mind is not refactoring. Refactoring is a kind of redesign, but not all redesign is refactoring. A refactoring is a small, incremental design improvement. As it is small, it is cheap and quick. So it does not need approval from "the business": you can just do it. It sounds like what you really have here is that the existing code is not fit for purpose. So you should be trying to petsuafe them of that, rather than trying to persuade them of the need to do something that will sound to them like needless "polishing".

any experience with "Play" java web development framework? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've just stumbled upon the following new java web framework: Play
http://www.playframework.org/
http://www.playframework.org/documentation/1.0/home
with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...
Sounds like the java web development promised land...
has anybody tried it? any real experience with it? do you think it's worth studying it?

I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.
One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.
For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.
That being the case, I see where the Play team is coming from.
Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.
I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.
I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.
The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)
I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.
The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.
I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.
I'll report back again later as I dive deeper in.

I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.
Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.

After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.
Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.
Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.
That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.

I like it, I'm using it for small projects and so far it looks perfect for the job.
However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model":
http://www.playframework.org/documentation/1.0.1/model
but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...
However, many thumbs up for: development speed, code cleanness, and in the end... fun!

I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.
I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)

Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.

I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...

I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.

I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.
Regards,
Uilian.

Java Time Savers [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I find the nature of this question to be quite suited for the practical-minded people on Stack Overflow.
I'm setting out on making a rather large-scale project in Java. I'm not going to go into specifics, but it is going to involve data management, parsing of heterogeneous formats, and need to have an appealing interface with editor semantics. I'm a undergraduate student and think it would evolve into a good project to show my skill for employment -- heck, ideally it would even be the grounds for a startup.
I write to ask you what shortcuts I might not be thinking about that will help with a complicated project in Java. Of course, I am planning to go at it in Eclipse, and will probably use SWT for the GUI. However, I know that Java has the unfortunately quality of overcomplicating everything, and I don't want to get stuck.
Before you tell me that I want to do it in Python, or the like, I just want to reiterate why I would choose Java:
Lots more experience with algorithms in Java, and there will be quite a bit of those.
Want a huge library of APIs to expand functionality. ANTLR, databases, libraries for dealing with certain formats
Want to run it anywhere with decent performance
I am open-minded to all technologies (most familiar with Java, perl, sql, a little functional).
EDIT: For the moment, I am giving it to djna (although the low votes). I think all of your answers are definitely helpful in some respect.
I think djna hit better the stuff I need to watch out for as novice programmer, recognizing that I'm not taking shortcuts but rather trying not to mess up. As for the suggestions of large frameworks, esp. J2EE, that is way too much in this situation. I am trying to offer the simplest solution and one in which my API can be extended by someone who is not a J2EE/JDBC expert.
Thanks for bringing up Apache Commons, although I was already aware. Still confused over SWT vs. Swing, but every Swing program I've used has been butt ugly. As I alluded to in the post, I am going to want to focus most on the file interchange and limited DB features that I have to implement myself (but will be cautious -- I am aware of the concurrency and ACID problems).
Still a community wiki to improve.

Learn/use Spring, and create your project so it will run without a Spring config (those things tend to run out of control), while retaining the possibility to configure the parameters of your environment in a later stage. You also get a uniform way to integrate other frameworks like Hibernate, Quartz, ...
And, in my experience, stay away from the GUI builders. It may seem like a good deal, but I like to retain control of my code all the time.

Google-collections:
http://code.google.com/p/google-collections/

Joda Time for all date and time manipulations.
One of Hibernate or iBATIS to manipulate data in a database
Don't forget the IDE: Eclipse, Netbeans or IDEA if you have some cash and like it

Apache Commons has a lot of time saving code that will you most likely need and can reuse.
http://commons.apache.org/

A sensible build and configuration platform will help you along the way, Ant:
http://ant.apache.org/
or Maven (preferably):
http://maven.apache.org/
Especially as the size of the project, and the number of modules in the project increase.

There's getting the "project" completed efficiently and there are "short cuts". I suspect the following may fall into the "avoiding wasted effort" category rather be truly short cuts but if any of them get you to then end more quickly then I perhaps they help.
1). Decomposition and separation of concerns. You've already identified high-level chunks (UI, persistence layer, parser etc.). Define the interfaces for the provider classes as soon as possible and have all dependent classes work against those interfaces. Pay a lot of attention to the usability of those interfaces, make them easy to understand - names matter. Even something as simple as the difference between setShutdownFlag(true) and requestShutdown(), the second has explicit meaning and hence I prefer it.
Benefits: Easier maintenance. Even during initial development "maintenance" happens. You will want to change code you've already written. Make it easy to get that right by strong encapsulation.
2). Expect iterative development, to be refining and redesigning. Don't expect to "finish" any one component in isolation before you use it. In other words don't take a purely bottom up approach to developing your componenets. As you use them you find out more information, as you implement them you find out more about what's possible.
So enable development of higher level components especially the UI by mocking and stubbing low level components. Something such as JMock is a short-cut.
3). Test early, test often. Use JUnit (or equivalent). You've got mocks for your low level components so you can test them.
Subjectively, I feel that I write better code when I've got a "test hat" on.
4). Define your error handling strategy up front. Produce good diagnostics when errors are detected.
Benefits: Much easier to get the bugs out.
5). Following on from error handling - use diagostic debugging statements. Sprinkle them liberally throughout your code. Don't use System.out.println(), instead use the debugging facilities of your logging library - use java.util.logging. Interactive debuggers are useful but not the only way of analysing problems.

Don't discount Swing for the GUI. There are a lot of good 3rd party Swing libraries available (open source and commercial) depending on your needs e.g.
JGoodies Form Layout
SwingX
JFreeChart

Use logging framework (i.e. Log4J) and plan for it. Reliable logging system saves a lot of time during bug fixing.

For me big time-savers are:
use version-control (Subversion/Git)
use automatic builds (Ant/Make/Maven)
use Continuous-integration (Hudson/CruiseControl)
the apache-commons-libraries are very useful

Test Driven Development
Figure out the functionality you want and write tests to demonstrate the functionality. Then write just enough code to pass the tests. This will have some great side effects:
By writing just enough code to satisfy your requirements you will not be tempted to overbuild, which should reduce complexity and make your code cleaner.
Having tests will allow you to "refactor with confidence" and make changes to the code knowing you're not breaking another part of the system.
You're building quality in. Not only will you have assurance that you code "works, but if you really want to use this code as a sort of "resume" for potential employers, this will show them that you place a lot of value on code quality. This alone will set you apart from the majority of the developers out there.
Aside from that, I would agree that other big time savers are Spring, having an automated build (Maven), and using some form of source control.

For data persistency, if you're not certain that you must use SQL, you should take a look at alternate data-storage libraries:
Prevayler: an in memory database systems, using developing ideas like "crash only components", that make it easy to use and very performatic. May be used even for simple applications where you just need to save some state. It has a BSD License.
BerkleyDB Java Edition: a storage system with different layers of abstraction, so one can use it as a basic key-value storage (almost an in-disk hashtable) to a fully transactional ACID system. Take a look at it's licensing information because even some commercial software may use it for free.
Be aware that they have trade-offs when compared with each other or with a standard SQL database! And, of course, there may be other similar options around, but these are the ones I know and like. :)
PS: I was not allowed to post the respective links because I'm a new user. Just google for them; first hits are the right ones.

You can save time between restarts by using JavaRebel (commercial). Briefly, this tool allows you to write your code in Eclipse and have the code changes picked up instantly.

Spring Roo can not only get your project quickly kickstarted (using a sound architecture) but also reduce your ongoing maintenance. If you're thinking of using Spring, servlets, and/or JPA, you should definitely consider it. It's also easy to layer on things like security.

Making life better by not using Java web frameworks? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm so tired of having to learn yet another Java web framework every other day.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC to name just a few - all this countless frameworks out there try to address the same issues. However, none of them really solves the fundamental problems - that's why there are still coming up more and more new ones all the time.
Most do look very bright and shiny on the first impression because they simplify doing simple things.
But as soon as it comes to the implementation of a real world use case one is running into problems.
Often the frameworks don't provide any help but are hindering one and limiting the options by forcing things to be implemented according to the frameworks own logic and environment.
In short, I see the following disadvantages when using a framework:
There mostly is a steep learning curve and you first need to understand sometimes quite academic concepts and know meaning and location of a bunch of configuration files before you can get started.
The documentation usually is more or less awful, either missing a public accessible online reference, is helpless outdated, confuses different incompatible versions or all of this together and often doesn't provide any helpful examples.
The framework consist of zillions of classes which makes it practically impossible to understand the intended use only by browsing the sources.
Therefore you need to buy some "XYZ in action for dummies in 21 days" kind of books which have a bad user interface because they are missing a full text search and are heavy to carry around.
To really use one of this frameworks you need to learn by heart how things can be done the way the framework requires it by remembering the adequate classes and method names until your head is full of stupid and useless information you can't use for anything else.
There is a big overhead, slowing down your applications performance and making your brain feeling numb when try to understand what really is going on.
In the real world there is usually no time to get well familiar with something new because of the pressure of being productive. As a consequence of this learning by doing approach one always looks only for the fastest way to get the next task done rather than really understanding the new tool and it's possibilities.
The argument that following a standard would allow people who are new to a project to quickly get started is not valid in my view because every project uses a different framework even within the same company (at least in my case).
It seems to me that the following quote from Albert Einstein fits here very well:
“We can't solve problems by using the same kind of thinking we used when we created them.”
Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next.
This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules.
This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.
While perfectly adjusted to the requirements of the current project, it also was easy expandable and had a very high performance due to zero overhead.
So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
What should I say to my boss when we're starting tomorrow the next project with a new framework again?
Or are there maybe frameworks which really make a difference?
Or some hidden advantages I have ignored?

Back in my good old PHP coding days
when coding still was fun and
productive, I used to write my own
frameworks for most things and just
copy-pasted and adopted them from one
project to the next. This approach
paid out very well, resulting in fast
development, no overhead at all and a
framework which actually was mightier
than most Java frameworks out there
Forgive me for believing that not one second.
but with only a few hundred lines of
code in a single file plus some simple
mod_rewrite rules. This certainly
wasn't solving all problems of web
development, but it was simple, fast
and straight to the point.
So basically you developed your own framework over the course of months or years, tailored to your own needs, and could work very fast with it because you knew it intimately.
And yet you can't understand why others do the same and then try to turn the result into something useable by everyone?
Where's this great framework you developed? If it's so powerful and easy to use, where are the dedicated communities, thousands of users and hundreds of sites developed with it?
every project uses a different
framework even within the same company
(at least in my case)
Well, that's your problem right there. Why would you throw away the expertise gained with each framework after each project?
The idea is to choose one framework and stick with it over multiple projects so that you get proficient in it. You have to invest some time to learn the framework, and then it saves you time by allowing you to work on a higher level.

The problem with coming up with your own framework is that you will make all of the same mistakes that all of the established frameworks have already stumbled on and addressed. This is true particularly when it comes to security.
Just ask Jeff and the guys about what they had to consider when implementing the WMD in stack overflow. I'd rather use what they have produced in a project rather than implement it from scratch. That is just one example.

Here is a quote from Kev from the thread What’s your most controversial programming opinion? which fit's in here really well:
I think that the whole "Enterprise" frameworks thing is smoke and mirrors. J2EE, .NET, the majority of the Apache frameworks and most abstractions to manage such things create far more complexity than they solve.
Take any regular Java or .NET OMR, or any supposedly modern MVC framework for either which does "magic" to solve tedious, simple tasks. You end up writing huge amounts of ugly XML boilerplate that is difficult to validate and write quickly. You have massive APIs where half of those are just to integrate the work of the other APIs, interfaces that are impossible to recycle, and abstract classes that are needed only to overcome the inflexibility of Java and C#. We simply don't need most of that.
How about all the different application servers with their own darned descriptor syntax, the overly complex database and groupware products?
The point of this is not that complexity==bad, it's that unnecessary complexity==bad. I've worked in massive enterprise installations where some of it was necessary, but even in most cases a few home-grown scripts and a simple web frontend is all that's needed to solve most use cases.
I'd try to replace all of these enterprisey apps with simple web frameworks, open source DBs, and trivial programming constructs.

The problem is of course not just with Java frameworks. I've lost count of the number of C++ MFC projects I've seen floundering around trying to shoe-horn their requirements into the Document/View model (which really only workks for text and graphic editors - database applications are particularly difficult to shoehorn).
The secret of succesful framework use is to change your application to match the framework, not the other way around. If you can't do that, don't even think of using the framework - it will end up being more work than if you had written the app from scratch with the help of some good, reliable and well-documented utility libraries.

So are you saying we should deal in sockets and HTTP every time we want to build a web application!
The servlet container itself can be considered a framework, since it handles all these messy details, and leaves you to write much simpler Servlets/Filters/Listeners (ie: 'extensions' of the framework specific to your application).
All any framework tries to do is separate mundane, repeatable, error-prone, legwork code from the fun application-specific code.
However, for a small application, you can get away with simply having a Model 2 MVC approach which uses only JSPs and Servlets.
Example:
class MyController extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
MyBean model = // do something
request.setAttribute("model", model);
request.getRequestDispatcher("/view.jsp").forward(request, response);
}
}
Then as your app becomes more sophisticated, you could look at using Spring MVC to provide looser coupling (and hence more flexible) of controllers, view resolvers etc..

I share your pain when confronted with yet another framework that doesn't do the trick.
Having survived ten years of jsp, struts, EJB, EJB2, struts2, jsf and now more recently all the new web services framworks, the xslt horrors and wsdl-first nightmares, I am definitely fed up.
There is a number of problems with frameworks. They leak so you have to learn more -not less, inhouse frameworks have huge costs, using external frameworks costs too (but much less), as they seldom deliver, and then you end up writing enourmus chunks of xml-configuration and spend days correcting case and spelling errors that you had seen immediately in your favorite content helping code editor.
Maybe the answer is to find less pompous toolkits that tries to solve a problem but not redefine the world, but that is hard too as the fundamental application model (html over http) is awkward - at best.
Add the fact that there seems to be a lot of complicators around, people that seems to be obsessed of trading boring simple problems to complex (but hard) interresting problems ( maybe a variant of Eric Sink’s Axiom of Software Development mentioned above.)
Add the hubris of developers that knows it all and do not hesitate to write a new framework to solve all the hard problems for you, Only that they can't, leaving 10% left, only much harder to fix now.
I have no .NET experience, but the .NET world seems to be less crowded with theorists and complicators, and maybe the lingering stink of VB is scaring them off, but everytime I hear someone telling me that they have spent 1500 hours on their maven config (hello?), I am seriously considering deleting "java" from my resume.
...what was the question again? Are there any frameworks that make a difference?
EDIT - added Stripes and QueryDSL.
I would try Stripes or GWT with QueryDSL + Hibernate or OpenJPA (with annotations) just for the fact that you actually develop in Java, and try to limit the use of wsdl-first web-services, xml-centric frameworks, EJB and ESBs (not the beer) as much as possible.

I once had to work on a project trying to implement it in JSF. It was a nightmare.
Most of the working time was spent to just making things compile. The fact that no less than half of what was compiled didn't work was another story. Almost no tutorials. Documentation is basically an automated source code export with no human comments. How can one be expected to work like this?
Of several frameworks we'd seen only Sun's was able to create a new project that is compilable at all! The other could only produce bunch of stuff it took many days to ring to a compilable state.
The web was almost silent. To any search there we no more than 20 pages of search results, with useful first 1-3. In that relevant what was found, a half of people was crying for help, the other half declared they had cried for help, noone came, they lost time and interest and dropped that technology.
So we spent times and only made something simple that could have been done in a few weeks with ASP.NET for example.
Then we looked at alternative JSF frameworks. To our surprise we found them all quite incompatible.
With not surprise at all, we joined the ranks of those who dropped JSF as well.

Consider the counter point. I am working at a shop right now that doesn't use any frameworks beyond the JSP standard. Everyone has a different way of doing things and we are very lax about concepts like de-coupling and security concerns like validation.
While I don't think use of frameworks automatically makes you a better coder, I do think by using a standard design pattern implemented by most frameworks and by having easy access to utility functions like validation, I think the chances are you are going to be forced to code up to a certain standard.
In web application design you aren't inventing the wheel every time, so you either end up rolling your own solution to common tasks, or using a framework. I make the assumption that by using a commonly used framework rather then roll your own, you are going to get underlying code that is well tested and flexible.
There is nothing wrong with rolling your own solution as an academic pursuit but I accept that there are people out there putting a lot more time into a robust solution then I may be able to spend. Take log4j for example, pretty easy to roll your logger, but log4j is well tested and maintained and they have taken the time to improve on flexibility and performance to a degree that most roll your own loggers can't touch. The end result is a framework that is robust but also simple enough to use in even the most basic applications.

What worked for me is: you shouldn't just learn any web framework you hear about, take a look at it, see if it makes you code comfortably, ask around stackoverflow or forums to see its advantages and disadvantages, then learn it and learn it good and just stick with it until you feel its broken or plain outdated. Any of the webframeworks you wrote about is good by itself and a fun to work with if you "REALLY" know what it does. if you don't you are just wandering in a desert with no compass! I've also found the 21 days book is a sure way for you NOT to master a framework or a technology. Docs is surely something to consider while adopting a f/w it also helps if you look around the code yourself (actually this is what helps me the best when I faced with some behavior that I find wierd.
1-So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
if you go back to the roots you rewrite code that does the same thing again and again + most of these f/ws being open source means they are probably better off with maintenance than you would do alone to your own f/w.
2-What should I say to my boss when we're starting tomorrow the next project with a new framework again?
this is my first time working with this f/w I don't see why should we use this f/w I already know X and I am really good at it. bare in mind the cost of me learning this f/w, the cost of rework that has to be done due to my ignorance of such a f/w. I think we are better off using X, if this is a specific requirement we should fight for it and only do it if we really have to stating the previous notes.
Or are there maybe frameworks which really make a difference?
only those who address the way you think not the way you write code (think struts at its golden age enforcing the MVC pattern).
Or some hidden advantages I have ignored?
can't think of any tbh.

You have the same problem in PHP: more frameworks than you have fingers to count them on, each being the best and greatest (although you have some hints: pure PHP5 design vs. PHP4 compatibility, Rails philosophy (inflexible folder hierarchy, auto-generated code) vs. library approach...) and you spend more time searching and exploring the possibilities than writing your code!
But in PHP it allows to pre-solve common problems, like I18N support, integration of plugins, management of sessions and authentication, database abstraction, templates, Ajax support, etc. Avoiding to re-invent the wheel on each project, and to fall in common traps for newbies.
Of course, there are some hints for Java frameworks too: big or small? well documented or not? widely used or confidential? for XML fans or not? Etc.
I suppose most frameworks aim at large projects, where learning time isn't a big problem, scalability and ease of deployment are important, etc. They are probably overkill for small projects.
There is also a trend in such frameworks to aim at doing a consistent set of loosely coupled libraries rather a monolithic framework. That's the case, in the PHP world, for the Zend framework (some even deny the usage of word 'framework'...).
So it solves the issue of "resolving common problems" without getting in the way.

So you think it's better if we all invent the wheel in every project?
You might see an excess of frameworks as a problem, and it does make it harder to choose your own set. But on the other hand, you don't have to try each one; and even if you do, you'll end up preferring some of them. You will have a favorite framework for ORM, another for web development, IoC, etc.
It does help to read up on some forums to learn which are the most popular ones; they must be popular for a reason, and even if it's not the right reason (like being technically superior, maybe it's popular just among managers because of the buzzword overload or whatever), knowledge of said framework will be helpful because you will be able to participate in several projects that use it.
Plus, using a framework instead of writing your own will save you a lot of problems. Bugs are not always found and solved by the authors; that's often done by users of the framework. You said you ended up with your own private framework in PHP; I bet it wasn't bug-free, but maybe you didn't know it since you were the only user and the only coder.

However I disagree on some points that you have mentioned but I agree with you regarding the boring work.
Yes all web applications are about pages displaying forms, collecting data, making validation, sending the data for storage in Database, and filtering the stored data by search forms and displaying the result in tables and selecting one or more records for manipulation (CRUD, or business actions that all about changing status in database).
however I'm working for just 4 years plus of course my 4 years academic study.
I feel this type of development is boring as you are not inventing algorithms, off course you got happy when you discover new framework and will be happier if you integrated one of the AI engines into your application, but at the end I feel that this work is dummy works, or lets say machine work, so why we don't automate all of this stuff.
yes another framework ;)
MDA Model Driven Architecture, in brief is about transforming from PIM (Platform Independent Model) to PSM (Platform Specific Model), i.e for example from UML to Code.
And this may solves your problem of learning curve and technology changes as you will only need to be good at modeling, as there are some frameworks that implements the MDA specs such as AndroMDA as it have cartridges that take the Class Diagrams, Use cases, Sequence Diagrams, and Activity Diagrams and generate Database creation script, POJOs, hibernate mapping, Spring/EJB, JSF/Struts, .NET code.
Off course such frameworks will not generate 100% of the code but will generate a big percent, and off course you will ask whither this framework will solve complex and tricky scenarios of requirements? today I will say no, tomorrow yes.
so why you and I don't invest in the development of this great framework.

What is the best way to migrate an existing messy webapp to elegant MVC? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I joined a new company about a month ago. The company is rather small in size and has pretty strong "start-up" feel to it. I'm working as a Java developer on a team of 3 others. The company primarily sells a service to for businesses/business-type people to use in communicating with each other.
One of the main things I have been, and will be working on, is the main website for the company - from which the service is sold, existing users login to check their service and pay their bills, new users can sign up for a trial, etc. Currently this is a JSP application deployed on Tomcat, with access to a database done thru a persistence layer written by the company itself.
A repeated and growing frustration I am having here (and I'm pretty happy with the job overall, so this isn't an "oh no I don't like my job"-type post) is the lack of any larger design or architecture for this web application. The app is made up of several dozen JSP pages, with almost no logic existing in Servlets or Beans or any other sort of framework. Many of the JSP pages are thousands of lines of code, they jsp:include other JSP pages, business logic is mixed in with the HTML, frequently used snippets of code (such as obtaining a web service connection) is cut and paste rather than reused, etc. In other words, the application is a mess.
There have been some rumblings within the company of trying to re-architect this site so that it fits MVC better; I think that the developers and higher-ups are beginning to realize that this current pattern of spaghetti code isn't sustainable or very easily scalable to add more features for the users. The higher-ups and developers are wary of completely re-writing the thing (with good reason, since this would mean several weeks or months of work re-writing existing functionality), but we've had some discussions of (slowly) re-writing certain areas of the site into a new framework.
What are some of the best strategies to enable moving the application and codebase into this direction? How can I as a developer really help move this along, and quickly, without seeming like the jerk-y new guy who comes into a job and tells everyone that what they've written is crap? Are there any proven strategies or experiences that you've used in your own job experience when you've encountered this sort of thing?

Your best bet is probably to refactor it slowly as you go along. Few us of have the resources that would be required to completely start from scratch with something that has so many business rules buried in it. Management really hates it when you spend months on developing an app that has more bugs than the one you replaced.
If you have the opportunity to build any separate apps from scratch, use all of the best practices there and use it to demonstrate how effective they are. When you can, incorporate those ideas gradually into the old application.

First pick up a copy of Michael Feather's Working Effectively with Legacy Code. Then identify how best to test the existing code. The worst case is that you are stuck with just some high level regression tests (or nothing at all) and If you are lucky there will be unit tests. Then it is a case of slow steady refactoring hopefully while adding new business functionality at the same time.

In my experience, the "elegance" of an app typically has more to do with the database design than anything. If you have a great database design, including a well-defined stored procedure interface, good application code tends to follow no matter what platform you use. If you have poor database design, no matter what platform you use you'll have a very difficult time building elegant application code, as you'll be constantly compensating for the database.
Of course, there's plenty of room between great and poor, but my point is that if you want good application code, start by making sure your database is up to snuff.

This is harder to do in applications that are only in maintenance mode because it is hard to convince management that rewriting something that is already 'working' is worth doing. I would start by applying the principles of MVC to any new code that you are able to work on (ie. move business logic to something akin to a model, put all your layout/view code in one place)
As you gain experience with new code in MVC you can start seeing opportunities to change the existing code subtly so that it also falls in line. It can be a very slow process, but if you can show the benefits of this way of doing it then you will be able to convince others and get the entire team on board.

I would agree with the slow refactoring approach; for example, take that copy-and-pasted code and extract it into whatever the appropriate Java paradigm is (a class, perhaps? or better yet, use an existing library?). When your code is really clean and terse, yet still lacking in overall architectural strategy, then you'll be able to make things fit into an overall architecture much more easily.

Iteratively refactor. Also look for new features that can be done completely in the new framework as a way to show the value of the new framework.

My suggestion would be to find the rare pages that do not require an import of other JSPs, or have very few imports. Treat each JSP imported as a black box, and refactor these pages around them (iteratively, testing each change and making sure it works before continuing). Once these are cleaned up, you can continue finding pages with more and more imports, until finally you have refactored the imports.
When refactoring, note the parts that try to access resources not given to the page and try to take this out to a controller. For instance, anything that accesses the database should be inside a controller, let the JSP handle the display of the information the controller gives to it via a forward. In this way you will develop several servlets, or things like servlets, for each page. I would suggest using a front-controller based framework for this refactoring (from personal experience I recommend Spring and its Controller interface), so that each controller isn't a separate Servlet but is rather delegated to from a single servlet that is mapped appropriately.
For the controller, it is better to do database hits all at once rather than attempt them piecemeal. Users can and generally do tolerate a page load, but the page output will be much faster if all the database data is given to the rendering code rather than the rendering code hanging and not giving data to the client while it is trying to read yet another piece of data from the database.
I feel your pain and wish you luck in this endeavor. Now, when you have to maintain an application that abuses Spring Webflow, that's another story :)

The best way is to print out the code, crumple it up, and throw it out. Don't even recycle the paper.
You've got an application that is written in 1,000+ line long JSPs. It probably has a god-awful Domain Model (if it even has one at all) and doesn't just MIX presentation with business logic, it BLENDS it and sits there and keeps stirring for hours. There is no way to take out the code that is crappy and move into an MVC Controller class and still be doing the right thing, you'll just end up with a MVC app with an anemic domain model or one that has stuff like Database calls in Controller code, you're still failing.
You could try a new app that does the right thing and then have the two apps talk to each other, but that's new complexity in itself. Also you're likely going to be doing the same amount of work that you were going to do if you just started from scratch, but you might have an easier time trying to convince your bosses that this is a better approach.