Why cannot Ruby on Rails become the mainstream in enterprise application development?

Will ozzzzzz die in Java? A standard to measure the mainstream industrial languages in the future is put forward, one of which is very interesting:

Ozzzzzz writes 1. Writing should be standardized, rather than creating different styles like C.

Java is obviously a language that is easy to unify the programming style, while Ruby is obviously a language that is difficult to unify the programming style. Someone in the javaeye forum once said:

By referencing the Java language, both the master and the Low-hand code are similar, while Ruby is different.

The syntax of the Java programming language is very simple and the specification is strict. The benefit of standardization is that once the programmer has a good understanding of the object-oriented programming basics and design patterns, the code is almost the same.

Why can we easily read the source code of an excellent Java open-source framework? Why is Java so easy to write code with no ambiguity and high similarity? Why is there always only one optimal way to do the same thing in Java? Why is it difficult for Java to develop an amazing skill? Why is Java always regarded as a clever one? Let's move on to another question: Why is there still three years of generic programming with a high level of skills introduced by jdk5.0? Why is it still not widely used? Let's think about where the Java language was designed for use?

Looking at these problems, we will find that Java has become a mainstream internal reason for Enterprise Application Development (there are also many external factors, not to mention here), because the Java language is rigid enough!

Therefore, writing a Java program is useless, so in order to make it easy, the Java Community is forced to develop dynamic reflection and AOP, and the generic type is copied, the objective is to increase the flexibility of the Java language.

So what are the advantages of a rigid and simple Java language? The advantage is that it is suitable for industrial languages!

So what are the syntax requirements of industrial languages?

1. The syntax is simple and strong.
2. The syntax is rigid enough to do the same thing. There is only one optimal solution.
3. Enough syntactic barriers to suppress your random use and give me proper coding

Why do industrial languages have such inherent requirements?

1. team collaboration needs
Large-scale projects require collaboration between dozens of people or even remote collaboration. This large-scale team collaboration requires that the programmer's code style must be highly consistent, and the dependencies between code blocks must be minimized. Obviously, the rigid and easy-to-decouple Java is very qualified.

2. batch production needs
The current software outsourcing industry is particularly evident! You don't need your creativity, you don't need your design, you need your coding, and the coding style and functions are no longer required. Java is obviously quite suitable.

Well, the above analysis shows why Java has become an industrial language from the perspective of syntax features, so let's look at why Ruby cannot become an industrial language:

1. Ruby syntax is too flexible and there is too much room for play, resulting in different code styles for everyone

When I first started learning Ruby, I was very uncomfortable. I was dizzy by the various syntaxes of Ruby. In the same way, do you have several methods, clumsy and common, smart, talented, varied, and even a book in Ruby quiz specifically explains the various techniques and tricks of Ruby programming. The inherent Syntax of Ruby directly creates the miracle of Ruby on Rails. There are countless Ruby magic in the Ruby on Rails framework, which is amazing. Without Ruby's flexible syntax support, rails won't become so much magic.

However, Ruby's syntax flexibility has become a major obstacle to industrial languages! There will be no major difference in style between the code of the top Java experts and the code of the common Java Masters (I don't think rod Johnson code is better than me ), but the code of Ruby's top-notch experts and Ruby's common Masters is just like a storm! Compete! As a top expert, like DHH, has made Ruby an amazing exclamation point, and it also makes it impossible for you and my generation to write Ruby code in a DHH style.

This problem also occurs in our javaeye2.0 website development. It is difficult to understand the ruby code written by two people. Because there are a lot of Ruby writing methods to do one thing, people of different personalities may even choose different implementation methods. In a team, it is very difficult to unify the coding style! In Java projects, such problems can be basically eliminated.

Because the code style is difficult to be unified, using Ruby programming in a large team can lead to obstacles to cooperation!

2. Ruby on Rails will lead to a high degree of code coupling, which is not conducive to collaborative development.

Rails stipulates that it is difficult to break your code framework, whether it is horizontal function decoding or vertical hierarchical decoding.

First, vertical hierarchical decoupling is a common method for large-scale Java projects, but it is basically impossible in Ruby on Rails. Because there are too many implicit conventions between Ruby on Rails layers, you cannot perform hierarchical development. Currently, horizontal functional decoupling is recommended for Ruby on Rails projects. Vertical and hierarchical decoupling is not recommended.

Further horizontal functional decoupling: First, each person must undertake functional modules with a large granularity and cannot split them too finely. Because a controller file in rails represents a large block of functions.

For example, in javaeye2.0, the entire forum has only one controller, and the entire blog has only one controller. Of course, you are amazed that the entire Forum code is handled by a file, and there are too few codes! But in turn, you can also say that the forum function can only be handed over to one person, and there is no way to split the function. This makes it difficult to coordinate teams. If two people are working on the Forum module at the same time, the Controller files will be merged frequently. Even if you compromise, each person is only responsible for a large functional block, but the underlying model code is associated with each other. It is difficult to avoid concurrent modifications and merge file conflicts.

But JAVA does not. Why? Because Java Splits a controller into countless small actions and a model into Po, Dao, and service, and implements full functional responsibilities, everyone's work will not interfere with each other, so the problem of team collaboration is easy to solve.

This problem occurs during the development of javaeye2.0. Even if a small part of the task is split, file conflicts are often merged, and most program tasks can only be pressed to Jerry. The respectable Jerry almost wrote the vast majority of javaeye2.0 code by one person. While amazed that Jerry completed the entire javaeye2.0 coding work with a one-month high efficiency, we also had to reflect on why Ruby on Rails is difficult for team-based development?

In my favorite book "getting real", I suggest that a development team of three people should be enough to design and plan the product functions, design the interface by one person, and write the code by one person. The same is true now: Robbin designs product features, ouspec is responsible for the interface, Jerry writes code, and then Robbin and ouspec are responsible for testing. However, not all projects can be done by three people. We have no answer yet for the large-scale application project team to collaborate in development.

Jerry has a point that I highly agree with. He thinks that we have not found a proper team collaboration method because none of the software development methods are suitable for the Ruby on Rails development team. What is the software development method that really suits Ruby on Rails? It hasn't appeared yet. I'm afraid people need to explore it. The popularity of Ruby on Rails must be accompanied by software development methods suitable for Ruby on Rails.

Therefore, before people come up with this software development method suitable for Ruby on Rails, Ruby on Rails will still be confined to the Web2.0 development field. In this field, all the advantages of Ruby on Rails will be fully realized, and the disadvantages will be avoided. However, once enterprise application development is involved, we will face these problems.

Therefore, my conclusion is that Ruby on Rails is currently not suitable for enterprise application project development. Of course, if there is a software development guidance method suitable for Ruby on Rails, or the definition of the enterprise application has been completely changed, then my conclusion will no longer exist.

The following is a summary:

Ruby on Rails is the peerless sword of martial arts experts, but it is not a conventional combat weapon (Java is such a conventional weapon) used by soldiers in the two armies ).

BTW: It doesn't mean that my idea is very mature. In fact, this is only the first time we try to use Ruby on Rails, when I am not familiar with it and do not understand it, I am not too hasty. However, my goal is to attract others. At present, we have encountered these team collaboration problems during development, I hope my bricks can be used to attract jade. We have not yet come up with a good solution to these problems. Thank you, haha!