- Save the password and API certificate used by your program in a custom configuration file. I use a yaml file and use a format similar to database. yml.
- Use constants when necessary. Do not repeat strings such as customer service email addresses, but store them in constants (they can be saved in environment. RB or custom configuration file), and then use this constant throughout the program.
- Use UTC time whenever possible, which makes the application look more consistent. (However, the timezone of rails 2.1 provides better functions)
- Do not traverse other data models in one activerecord data model. In this case, a large number of SQL query operations are generated. The correct implementation method is as follows: 1) if multiple data models are already correlated, you can use the find (: Include) method to use the pre-loading technology, in this way, data in multiple data models can be obtained in one SQL query. 2) if these data models are not associated, you can write a custom find statement, where select and join are used to define cross-table queries. In this case, you may need to set the value-based reading method for the non-local table fields in your database model to obtain the correct type of value.
- Be careful when using binary fields. By default, the query database returns all fields, including the complete content of any binary field. It is best to use select to define the fields to be obtained to reduce the system load.
- To generate a periodic report, create a dedicated data table for the report data and cache the report data to the table. This is much faster than re-generating data for every real year or monthly report.
- Create a country list database. By default, rails uses strings to select and list countries, which is harmful to data mode consistency. In addition, problems may occur when a report is generated.
- Avoid writing a bloated controller. Do not add a bunch of methods into the controller. If there are more than 10 controller methods, the design may be wrong.
- Keep your controller and view as concise as possible. In most cases, most of the Code should be placed in the data model, rather than in the Controller or view.
- Do not save objects in sessions. When necessary, the session can store numbers or strings, and then retrieve data from the database based on the session content when processing a single request. (The new session mechanism in rails 2.0 solves this problem)
- Avoid handling response requests with a large amount of information ). When you encounter a request to process a large amount of information, you can mark the change record as pending, and then use a Cron transaction or message service to process this time-consuming task. Backgroundrb is also an option (I use this base to filter spam in the blog ).
- When sending emails in batches, use ar_mailer instead of sending emails in a rails request.
- Use the exception_notification plug-in, Munin, monit, and other tools to monitor your applications and servers.
- Do not mean hardware investment. Using Poor backup or cheap hardware will make you spend a lot of money on server maintenance. This is not worth the candle.
- Test-drive development
- Database indexes are used to provide query speed. Rails only indexes primary keys, so you need to set additional indexes based on the actual situation.
- Perform a performance test on the code. Using ruby-prof and plug-in testing, you can speed up your applications by making some minor changes to the performance bottleneck.
- Reduce image-related code dependency to a minimum. If the application only needs to generate some thumbnails, do not waste the memory on importing huge image libraries. Instead, you can use lightweight image libraries such as mini-magick or image_science.
- Avoid rendering small clips (partials) unlimitedly ).
- Use CSS instead of defining styles in the tag.
- Do not use the serialize option of activerecord to store large objects in the database.
- Use attr_protected: fieldname in the data model to avoid modifying the key data through the modified form. (Attr_accessible is a safer method.
- Using Ruby classes and inheritance to reconstruct repeated controller code
- Use the javascrip technique to separate page behavior from the page code tag.
- Encapsulate self-sufficiency classes and modules into plug-ins or rubygems.
- Cache frequently accessed databases as much as possible.
- Writing a custom test: Unit assertion or rspec file helps debug errors during testing.
- Use the logrotate daemon on Linux to poll rails and mongrel logs.
- Create a reliable backup system.
- Use Capistrano or vglad for automatic deployment.
- Try to simplify the method. Please refactor the method with more than 10 lines of code.
- Run flog To Find Out Methods and classes that are too complex.
- Avoid using too many conditional statements. Use Ruby case statements and Ruby objects for conditional processing, instead of ugly multi-layer nested if statements.
- Do not be smart. Ruby provides extremely powerful meta-programming functions, but this function is easily abused (such as eval and method_missing ).
- Familiar with various popular plug-ins. Do not re-invent the wheel. Using tested popular plug-ins can save time and effort.
- Use filter_parameter_logging: Password,: password_confirmation In the login or user controller to filter important logs. Your program logs will be filled with user passwords.
Transferred from http://wiki.rubyonrailscn.org/rails/show/rails
