The tradeoff is, historically, that you're going to have to hire a team of seven developers, three business analysts, and a project manager to do what is, honestly speaking, two decent engineers worth of work if they were working in e.g. Rails. This is a worthwhile tradeoff for many enterprises, as they care about risk much, much, much more than the salary bill.
(I spent several years in the Big Freaking Enterprise Java Web Applications salt mines. These days I generally work in Rails, and vastly prefer it for aesthetic and productivity reasons, but I'm at least intellectually capable of appreciating the advantages that the Java stack is sold as bringing to users. You can certainly ship enterprise apps in Rails, too, but "the enterprise" has a process which works for shipping Java apps and applying the same development methodology to e.g. a Rails app would result in a highly effective gatling gun for shooting oneself in the foot.)
I had to re-read your comment twice as I thought that there exists an OTS ERP for salt production.
PS. The company I work for actually grows salt.
I remember (vaguely) the beginnings of Java, but not how it did end up in Enterprise and why it was loved so much there.
My personal preference in terms of demonstrating maintainable code is using two modulus operations with variables. However, I fully understand the argument that an additional % 15 is preferable compared to the overhead of storing two variables on each iteration. Both are valid approaches IMO, and the debate can roar on for eternity. Micro-optimizations and whatnot.
I just don't like to see four modulus operations, which IMO shows a lack of basic willingness or ability to refactor while coding. It's fine to initially write the four modulus operations, but if someone doesn't immediately catch the duplication and do something about it, it screams "I write code until it works and then move on without cleaning anything up."
Strangely enough, only once have I seen someone use the % 15 optimization and add a short comment along the lines of "// least common multiple, divisible by both 3 and 5". Spotting the optimization is nice; placing a short comment explaining why % 15 when the test is about % 5 and % 3 is a nice touch. Explains something that might not be immediately obvious to the next person coming to the code.
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style. I've seen two lines of code inside an if() block indented at different levels, with no excuse for "different opinions on formatting". Not a wrapped line continued on the next, but just two simple statements inexcusably indented at say 8 and 12 spaces. Don't call us, we'll call you...
Aside: it astounds me how many people, when asked to write a short snippet of code during an interview, have basic formatting problems and inconsistent code style.
If this is being done on paper or an absolutely "non-IDE" text editor then it's probably someone dependent on an IDE to do the right formatting for them. If they still do this in an auto-formatting IDE, it's probably a sign that they have no good idea of the structure/flow of the code.
Then again it is FizzBuzz and not FizzBuzzMozz, where numbers divisible by both 3 and 5 produce a string that cannot be concatenated by the individual 3 and 5. So to be fair, this solution is perfectly valid. :p
# Inputs
>>> i = range(1, 100)
>>> d = [(15, 'FizzBuzz'), (5, 'Buzz'), (3, 'Fizz')]
# Let's define some lambdas - calculation, test, reduction
>>> c = lambda x, y: y[1] if (x % y[0] == 0) else x
>>> t = lambda a, b: a if type(a) is str else b
>>> r = lambda e: reduce(t, e)
# Now process
>>> map(r, map(lambda x: map(lambda f: c(x, f), d), i))(my version - https://gist.github.com/vai/4647768 )
http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...
http://docs.spring.io/spring-framework/docs/2.5.x/api/org/sp... (this one is somewhat famous - maybe it wins the "most number of design patterns in a class name" award?)
The impression I get whenever I come across code like this is that its authors were more interested in "creating architecture" than solving a real problem - and creating many classes containing short methods whose only function is to create more objects or pass existing ones around is a particularly insidious form of busy-work.
GNU Hello (http://www.gnu.org/software/hello/ ) is basically the same sort of thing done to a Hello World program.
Also, they author finally got around to actually providing a proper pom.xml file.
Check the commit history for details.
If you're interested in contributing, there's definitely room for expanding the unit test coverage, and also instrumenting the build process to support a code coverage tool such as EMMA or Coberture. Also, I don't believe that the code has undergone a security audit, and I don't see any code reviews for many of the commits, which is distressing.
And documentation! The code does not support javadoc, and in fact, there are only two comments in the entirety of the nearly 1500 line code base!
This is just _so_ non-compliant with Best Practices that it reveals itself too easily as a parody.
Each class should at least have the default Eclipse comment telling you how to change the template for a new class file, and most methods should have auto-generated JavaDoc for the first version of the method which was written years ago, with nothing filled in.
/src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackagehttps://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Brilliant.
Being enterprise software, the last thing they need in the codebase is clutter.