Rails system refactoring: from a single complex system to multiple small application clusters

Ruby on Rails has been favored by more and more developers in the country in recent years, and rails applications have deepened from simpler internal systems to complex enterprise applications. Rails ' habit is better than configuration ' and many of the best technologies, such as ActiveRecord, greatly improve development efficiency, but rails applications also face many problems in complex, business-heavy systems.

This article introduces a rails system refactoring scheme that splits a complex rails single system into multiple lightweight application clusters that work together, fundamentally addressing issues such as the cumbersome, inefficient, and difficult maintenance and deployment of rails systems to handle complex business times.

Problems with complex rails systems

With rails you can quickly build a simpler application, but the maintenance and expansion of the system becomes more and more difficult as the business needs grow dramatically and the functionality becomes more complex. Under normal circumstances, the problem is mainly manifested in the following aspects:

Code bloated

We know that rails advocates restful architecture, so good code is organized to operate on each entity (Model) with a corresponding processor (Controller). and rails each controller has a corresponding helper and several view. In this way, when the system functions more complex, the amount of code will increase dramatically.

First, the number of model will be many. Because the model is placed under the App/models directory, and rails does not support the model, although you can modify the load_paths to solve the problem, but sometimes (such as directory and model name) will cause difficult to debug errors, so when the model number of more than , this directory will become unmanageable.

The second is that the Controller directory hierarchy will be deeper. To maintain a clear code structure, controller should be stored in different directories according to functional classification. So when the function is more, it is easy to appear four or five or even deeper directory structure, which not only makes the code difficult to manage, routes configuration and resolution also become very complex, such as the emergence of level1_level2_level3_level4_controller_name_ Path is such a long routes helper method.

Difficult to test and deploy

Complex business code will not only increase the difficulty of writing test code, the time to run the test will inevitably increase. A large number of fixtures not only difficult to manage, but also often cause mutual interference.

Complex systems also increase the risk of deployment, and a small error can cause the entire system to crash. To mitigate this risk, you need to extend the cycle of system deployment to deploy only at specific times or when there are significant updates to the system, which in some ways weakens the rails system's benefits of rapidly upgrading iterations based on user needs.

Influence Team Building

In addition to technical problems, complex rails systems can have a detrimental effect on team building. First, if a developer submits a code that the test cannot pass, will have an impact on other people's work, reduce development efficiency, second, for complex systems, add new features or fix bugs are more difficult, over time the programmer will be lazy, the code can be changed less change, seriously hinder the rapid evolution of the system Finally, when the team has new entrants, they will worry that because they are unfamiliar with the system caused system crashes, and dare not let him really participate in, so the growth of new people is very unfavorable.

Lightweight application Cluster

To solve a series of problems with a complex rails system, we divide a single system into business functions, each of which is implemented with a separate rails application to form a number of lightweight rails application clusters that work together to achieve the overall business logic.

After splitting, each of the rails applications has the following characteristics:

Have independent database, can run independently;

A small amount of program code, usually only need one or two programmers to develop and maintain;

High cohesion, low coupling.

After the system is split, a number of key issues need to be addressed, such as how to maintain the consistency of the user experience, how applications interact, how users are shared, and so on. The solution is described below for each of these issues.

User Experience Consistency

After the system is split, several lightweight applications work together to complete a business operation. Because each application is a standalone rails program, and a more complex business process may have to jump across multiple applications, the first thing to do is to resolve the consistency of the user experience.

A unified CSS Framework

The most intuitive aspect of the user experience is the style of the page. In order to ensure that users jump between different programs without abrupt feeling, each application should look "long". To achieve this, we use a unified CSS framework to control styles.

Call the helper method inside the layout:

<%= Idp_include_js_css%>

This produces the following HTML code:

<script　src　="/assets/javascripts/frame.js"　type="text/javascript"></script>
<link　href="/assets/stylesheets/frame.css"　media="screen"　rel="stylesheet"　type="text/css"　/>

In Frame.css, you can set HTML tags and the style of common structure such as navigation, the application of the page as long as the use of defined tags and CSS classes to achieve a unified style of the interface.