Những lỗi cơ bản thường gặp với lập trình viên Rails (Phần cuối)

Rubu and Rails cung cấp khả năng kiểm thử tự động vô cùng mạnh mẽ và hiệu quả. Rất nhiều lập trình viên Rails sử dụng kiểu TDD và BDD để viết nên những bộ test vô cùng tinh vi, họ còn tạo cho chúng ta những framework kiểm thử vô cùng mạnh mẽ cùng với gem như rspec hay cucumber. Mặc dù việc viết test cho những project Rails và vô cùng dễ dàng và mang lại hiệu quả cao trong việc hạn chế tối đa bugs trong project, tuy nhiên, mình đã gặp rất nhiều lập trình viên không hề viết một chút test nào cho project Rails của mình, điều này thật sự mang lại một cảm giác khá khó chịu xen lẫn một chút ngạc nhiên (vì việc viết test cho Rails không phải là một vấn đề gì quá khó khăn cả). Trong khi có rất nhiều cuộc tranh luận nổ ra về việc làm thế nào để kiểm thử một cách toàn diện nhưng chắc hẳn bạn cũng đồng ý với mình rằng, rõ ràng là cần không nhiều thì ít ra cũng phải tồn tại một số thứ được gọi là kiểm thử trong mỗi project về Rails. Nhu một quy luật chung bất thành văn, bạn phải viết ít nhất một bộ kiểm thử tích hợp level cao cho mỗi action trong controller của bạn. Trong tương lai phát triển của một project Rails, một lập trình viên khác có thể có nhu cầu mở rộng hoặc sửa đổi code, hoặc nâng cấp phiên bản của Ruby and Rails, và framework tessting mà bạn đã viết sẽ cung cấp cho họ một cách rõ ràng về cách hoạt động của những phương thức cơ bản bên trong ứng dụng. Một lợi ích khác nữa là nó cung cấp cho các lập trình viên khác một cái nhìn rõ ràng về hoạt động của các funtiuon được cung cấp bởi ứng dụng.

Các nhà cung cấp dịch vụ bên thứ ba của Rails thường là cho việc sử dụng các dịch vụ của họ trở nên dễ dàng thông qua sử dụng gem và APIS của họ. Nhưng điều gì sẽ xảy ra nếu dịch vụ từ bên thứ ba chạy một cách chậm chạp? Để tránh việc chặn request thay vì gọi các dịch vụ trực tiếp trong quá trình xử lý của một request. Bạn nên chuyển chúng về hàng chờ background job để thực hiện khi có thể. * Delayed Job * Resque

• Sidekiq

Trong trường hợp việc đưa processing về background job là không khả thi hoặc không thực tế thì bạn cần chắc chắn rằng ứng dụng có thể xử lý được lỗi và kiểm soát được những trường hợp fail cho những tình huống có thể xảy ra khi dich vụ mở rộng không họat động hay có vấn đề xảy ra.Bạn cũng nên kiểm thử ứng dụng của mình khi mà không có các dịch vụ mở rộng để chắc rằng nó sẽ không gây ra bất kỳ hậu quả không lường tước nào.

Cơ chế migration database của Rails cho phép bạn tạo một files để tự động thêm, xóa bảng và dòng dữ liệu. Do các tệp tin migration này được đặt tên một cách tuần tự, bạn có thể chạy chúng lại từ đầu để tạo một database trống. Đây là một cách tuyệt vời để quản lý các thay đổi nhỏ trong cơ sở dữ liệu của ứng dụng và tránh các vấn đề của Rails. Mặc dù cách này hoạt động rất tốt khi bắt đầu dự án nhưng theo thời gian, quá trình tạo cơ sở dữ liệu có thể sẽ mất một khoảng thời gian kha khasvaf đôi khi trật tự bị thay đổi một cách vô ý hay thất lạc một file migration nào đó chẳng hạn hoặc bị chèn vào từ một ứng dụng Rails khác sử dụng cùng server database. Rails sẽ tạo ra một miêu tả về giản đồ cơ sở dữu liêu hiện tại của bạn trong tệp tin shema.rb sau mỗi lần cập nhật database. Tệp tin này có thể được tạo ra khi không có sự thay đổi nào trong database chỉ bằng cách chạy lệnh db:schema:dump. Sai lầm phổ biến của nhiều lập trình viên đó là tạo một migration mới vào trong ứng dụng của bạn mà không cập nhật file schema tương ứng. Khi mà việc migrations nằm ngoài tầm kiểm soát mà mất quá nhiều thời gian để chạy hoặc không còn tạo database đúng cách, lập trình viên không nên e ngại việc xóa những files migration cũ, tạo một giản đồ mới và tiếp tục từ đó. Thiết lập một môi trường development mới sẽ yêu cầu chạy rake db:schema:load chứ ko phải là db:migrate mà phần lớn lập trình viên hay sử dụng.

Rails framework cung cấp cho ta khả ăng dễ dàng chống lại những cuộc tấn công bảo mật bằng nhiều cách khác nhau. Một trong số đó là sử dụng những token "bí mật" để đảm bảo bảo mật trong một phiên làm việc. Mặc dù những token này thường được lưu trữ trong file secrets.yml, và file này sẽ đọc token từ một biến môi trường từ server production, một số phiên bản cũ của Rails lưu token trong file config/initializers/secret_token.rb. File này thường bị nhầm lẫn mà đưa vào trong source code cùng voiwis ứng dụng của bạn, khi điều này xảy ra, bất kỳ ai truy cập được vào source code sẽ dễ dàng gây ảnh hướng tới toàn bộ người sử dụng ứng dụng của bạn. Vì thế, bạn nên chắc chắn rằng file cấu hình cho source code của bạn (ví dụ như gitignore) không bao gồm những file có chứa token. Sau đó các server production của bạn có thể lấy những token này thông qua các biến môi trường.

Loạt bài viết về những lỗi cơ bản thường gặp khi lập trình với Rails của mình xin khép lại tại đây. Hi vọng bài viết này sẽ phần nào giúp được các bạn cải thiện project của mình theo chiều hướng tích cực hơn.

Nguồn: https://www.toptal.com/ruby-on-rails/top-10-mistakes-that-rails-programmers-make