Các Nguyên Tắc Của Rails
Sự phổ biến của Rails là một phần được nhờ vào “triết lý Rails” hoặc nguyên tắc hướng dẫn (guiding principles). Hãy cùng lướt qua các nguyên tắc này :
Rails là “khăng khăng” (Rails is Opinionated)
Vào giữa những năm 1990, các ứng dụng web thường được viết bằng Perl, một ngôn ngữ lập trình hứa hẹn với phương châm “có nhiều cách để làm điều đó.” Perl là một ví dụ điển hình của “không khăng khăng” phần mềm; không có gì gọi là “đúng cách” hay “cách tốt nhất” để giải quyết vấn đề trong Perl. Các tài liệu của Perl (documentation) có câu, “Nhìn chung, các hàm của Perl thực hiện những gì bạn muốn, dù bạn muốn cách này hay cách khác.” (Nguyên văn như sau: ““In general, [Perl’s built-in functions] do what you want, unless you want consistency.”)
Ngược lại, Rails được cho là có tính “khăng khăng.” Có một “cách làm của Rails” (Rails way) để giải quyết mỗi vấn đề. Nếu bạn tuân theo các quy ước của Rails, bạn sẽ quyết định ít hơn và tìm kiếm nhiều hơn những thứ đã được xây dựng sẵn cho các nhu cầu của ứng dụng mình đang làm. Lợi ích là phát triển nhanh hơn, cải thiện sự hợp tác, và bảo trì dễ dàng hơn.
Rails là Omakase (Rails is “Omakase”)
Omakase là một cụm từ tiếng Nhật có nghĩa là “Tôi để cho anh làm.” (I will leave it for you.) Khách hàng tại các nhà hàng sushi có thể đặt hàng Omakase, uỷ thác đầu bếp để thực hiện theo cách của họ thay cho sự lựa chọn của riêng mình. Trong một bài viết nổi tiếng Heinemeier Hansson tuyên bố “Rails là Omakase” (Rails is Omakase), và nói: “Một nhóm các đầu bếp chọn ra các thành phần, giốn như thiết kế các API, và bài trí chúng vào khay thay cho bạn theo ý tưởng của họ theo cách mà họ nghĩ là sẽ làm ra món ăn ngon …. Khi chúng ta, hoặc trong một số trường hợp, tôi – là đầu bếp trưởng có kinh nghiệm Rails – quyết định một món ăn, nó thường dựa trên thị hiếu và sở thích của tôi. Tôi đã làm việc này trong một thập kỷ. Tôi đã tiêu tốn mười ngàn giờ vào Rails. Điều này không làm cho thị hiếu của tôi phù hợp với bạn, nhưng chắc chắn nó được xây dựng khá tốt.”
Chấp nhận Rails là Omakase nghĩa là chấp nhận rằng rất nhiều các ý kiến nêu trong API Rails là quyết định “độc tài một cách lương thiện” (Benevolent Dictator for Life). Đối với hầu hết trường hợp, “ý kiến” của Heinemeier Hansson sẽ phục vụ bạn tốt.
Quy ước thông qua cấu hình (Convention Over Configuration)
“Quy ước về cấu hình” là một minh chứng Rails là “phần mềm khăng khăng.” Đây là một phần mở rộng cho các khái niệm mặc định, đó là Rails có các giá trị cài đặt mà người dùng không nên can thiệp. Một số hệ thống phần mềm, đặc biệt là mô hình ứng dụng web Java, cần nhiều file cấu hình, mỗi file có nhiều cài đặt. Ví dụ, một tập tin cấu hình có thể xác định rằng một bảng cơ sở dữ liệu có tên là “bán hàng” tương ứng với một lớp có tên là “bán hàng.” Các tập tin cấu hình cho phép sự linh hoạt (một nhà phát triển có thể dễ dàng thay đổi các thiết lập nếu bảng được đặt tên là “bán hàng” hay “bán đồ”). Thay vì đua ra cả đống file cấu hình, Rails cung cấp các giả định (assumptions). Theo quy ước, nếu bạn tạo một đối tượng “model” (dùng để giao tiếp và điều khiển các table trong cơ sở dữ liệu) trong Rails tên là “User”, nó sẽ lưu dữ liệu vào một bảng cơ sở dữ liệu có tên là “users” mà không cần bất kỳ cấu hình gì. Rails cũng sẽ cho tên bảng là số nhiều nếu tên lớp là số ít.
“Quy ước về cấu hình” tăng hiệu quả. Bạn không tốn thời gian để ngồi thiết lập chúng. Bạn cũng tốn ít thời gian hơn để ngồi nghĩ về những thứ như tên gọi cho một bảng mà trong Rails đã mặc định rồi. Và, bởi vì các developer khác cũng biết những quy ước này, sẽ dễ dàng phối hợp với nhau hơn.
Dừng lặp lại chính mình (Don’t Repeat Yourself)
Được viết tắt là DRY, “không lặp lại” là một nguyên tắc của phát triển phần mềm xây dựng bởi Andy Hunt và Dave Thomas và được ủng hộ rộng rãi trong các nhà phát triển Rails. Một cách đơn giản, đó là một lời khuyên để tránh trùng lặp. Khi mã chương trình (code) bị lặp lại, một ứng dụng trở nên phức tạp hơn, làm cho nó khó khăn hơn để duy trì (bởi vì mỗi lần đổi chổ này phải đổi luôn chỗ kia) và dễ bị lỗi (bug). Các nguyên tắc DRY được dùng cho quá trình coding. Ví dụ, kiểm tra thủ công là “lặp lại”; kiểm tra tự động là DRY (í câu này có nghĩa là nếu bạn kiểm tra trang web bằng cách login vào, kiểm xem thông tin được hiển thị đúng hay không. Thì việc này cần làm lại nếu như các lập trình viên đưa ra phiên bản mới hơn. Còn nếu mình viết các chương trình để test, thì sau chỉ cần chạy nó thôi).
Tái sử dụng mã (code reuse) là một kỹ thuật cơ bản trong phát triển phần mềm. Nó tồn tại rất lâu trước khi Andy Hunt và Dave Thomas thúc đẩy nguyên tắc DRY. Rails có lợi thế do tính năng lập trình meta của Ruby, điều đó không chỉ giúp sử dụng lại mã mà còn loại bỏ mã ở nơi có thể. Cộng thêm các quy ước, nó có thể tạo ra toàn bộ các ứng dụng web đơn giản chỉ với một vài dòng mã.
Khi nào Rails trở nên phức tạp
Việc hiểu các quy ước của Rails rất hữu ích. Nhưng thậm chí còn hữu ích hơn để biết khi nào và tại sao Rails trở nên phức tạp nếu tuân đi theo các nguyên tắc này.
Rails không có sự lựa chọn
Nếu như bạn có kinh nghiệm với Rails, bạn có thể gặp phải trường hợp mà Rails không thể đưa ra sự lựa chọn. Ví dụ, tính đến đầu năm 2013, không có phương pháp tiếp cận “chính thức” để tạo ra “hàng đợi” (queue) cho các job chạy nền (background jobs). (Nhiệm vụ mà thường được dùng cho các job mất thời gian, chẳng hạn như liên lạc với một máy chủ từ xa, tốt nhất là dùng “background jobs” để không bị trì hoãn các hoạt động sau đó của trang web.) Các cuộc tranh luận sôi nổi đã dẫn đến việc phát triển phiên bản mới của Rails nhằm giải quyết vấn đề này và cuối cùng sẽ được tích hợp vào API Rails.
Omakase nhưng cho phép thay thế
Tiềm ẩn trong khái niệm “Rails là Omakase” là sự hiểu biết rằng “thay thế được cho phép.” Hầu hết các giải pháp của Heinemeier Hansson giới thiệu đều được chấp nhận bởi tất cả các nhà phát triển Rails. Tuy nhiên, nhiều nhà phát triển có kinh nghiệm thay thế một số chỉ mục trên menu ở Rails cafe. Điều này dẫn đến quan điểm cho rằng Rails có hai nhánh được chấp nhận (Rails has Two Default Stacks), như được mô tả trong một bài luận bởi Steve Klabnik. Các nhà phát triển chuyên nghiệp thích thay thế framework chính thức bằng vài cách khác nhau, đôi khi là để tăng page views. Điều này làm phức tạp việc học tập khi các tài liệu thì nói là không được thay thế, nhưng bạn lại gặp vài sự thay thế khác nhau trong bài viết blog và mã ví dụ.
Quy ước hay phép màu (magic) ?
Một trong những niềm vui của lập trình chính là mọi thứ trong ứng dụng được giải thích bằng mã lệnh. Nếu bạn biết nơi để tìm, bạn sẽ thấy nguồn gốc của bất kỳ hành vi nào. Đối với một lập trình viên có tay nghề cao, “quy ước về cấu hình” thêm tối tăm nếu không có một tập tin cấu hình hay mã lệnh rõ ràng rằng lớp “Person” được kết nối với bảng có tên là “people.” Khi mới bắt đầu, bạn sẽ chỉ đơn giản là chấp nhận sự “kỳ diệu” và không làm bối rối chính mình bằng cách làm khác đi và cố gắng cho nó hoạt động. Việc hiểu được các qui tắc của Rails đôi lúc khó khăn. Ví dụ, bạn có thể có một đối tượng “User” và một bảng “users”. Rails mong muốn bạn tạo ra một “bộ điều khiển” (Controller), nhưng tên nên đặtlà “UserController” (số ít) hay “UsersController” (số nhiều)??? Bạn sẽ chỉ biết nếu bạn để cho Rails tự động tạo mã hoặc bạn chú ý tới các hướng dẫn và mã ví dụ (ghi chú của dịch giả: nên là UsersController, số nhiều)
Đôi khi DRY làm tối nghĩa
Có khi “quy ước về cấu hình” làm rối rắm nguyên tắc DRY. Để tránh mã lặp đi lặp lại, Rails thường sẽ cung cấp cho hành vi mặc định trông giống như ma thuật bởi vì việc thực hiện cơ bản là ẩn trong thư viện mã Rails. Bạn có thể thực hiện một ứng dụng web đơn giản chỉ với một vài dòng mã tùy chỉnh nhưng bạn có thể tự hỏi từ đâu là nơi xuất phát các hành vi này. Đối với người chưa quen, điều này có thể bực bội khi bạn cố gắng để tùy chỉnh ứng dụng của bạn để làm nhiều hơn những gì được thể hiện trong hướng dẫn đơn giản.
Rails hoạt động như thế nào ?
Đọc tới đây, có lẽ bạn đã có sự hiểu biết nhất định về các nguyên tắc của Rails và cả những khó khăn của nó. Vậy chúng ta hãy bắt đầu lại từ đầu để làm rõ hơn cách thức hoạt động của Rails. Chúng ta sẽ bắt đầu bằng cách giải thích làm thế nào một ứng dụng web (web application) có thể hiển thị một trang web (web page). Bạn có thể đã biết điều này rồi, nhưng chúng ta hãy xem xét lại bởi vì nó sẽ giúp giải thích cách thức hoạt động của Rails.
Bạn đang chạy một trình duyệt web trên máy tính của bạn (để đọc bài viết này chẳn hạn, ví dụ trình duyệt Chrome). Một trình duyệt web kết hợp ba loại tập tin HTML, CSS, và JavaScript để hiển thị các trang web. Một trình duyệt có được các tập tin này từ một máy chủ web (web server). Các máy chủ web có thể được điều khiển từ xa (kết nối bằng Internet) hoặc ngay trên máy tính của bạn (khi bạn đang phát triển trang web).
Bạn có thể đã biết cách tạo ra các tập tin HTML, CSS, và JavaScript. HTML (HyperText Markup Language) là một quy ước để tạo ra các tài liệu có cấu trúc kết hợp nội dung (như văn bản, hình ảnh, hoặc video). CSS (Cascading Style Sheets) được sử dụng để tạo kiểu chữ, bố trí và thiết kế. JavaScript là một ngôn ngữ lập trình được hỗ trợ bởi tất cả các trình duyệt web nhằm tác động/sử dụng các thành phần (component) trên HTML và CSS, đặc biệt là thực hiện các tính năng tương tác như mở/đóng các tab. Bạn có thể tìm hiểu về HTML, CSS, và JavaScript trong một khóa học web căn bản điển hình dạy làm “các trang web tĩnh.” (Ở Pingo, chúng tôi có khóa dạy làm web căn bản. Các bạn có thể tìm thêm thông tin về giáo trình vì chúng tôi phổ biến nó miễn phí ngay trong home page.)
Các web server cung cấp HTML, CSS và JavaScript cho các client. Các tập tin này hoặc là tập tin tĩnh được lưu trữ trên máy chủ, hoặc từ một “máy chủ ứng dụng” (application server). Application server tạo ra các tập tin này bằng cách chạy ngôn ngữ lập trình như Ruby. Một chương trình phần mềm viết bằng Ruby và sử dụng Rails là một “web application.” Rails kết hợp các Ruby với HTML, CSS và JavaScript để tạo ra một ứng dụng web. Rails nhúng các mã Ruby vào HTML, CSS, hay JavaScript từ đó có thể thay đổi được nội dung các tập tin này một cách linh động.
Tại sao tạo ra một ứng dụng web? Một trình duyệt web chỉ cần một tập tin HTML duy nhất để hiển thị một trang web (CSS và JavaScript là tập tin tùy chọn). Tuy nhiên, nếu bạn đang tạo ra một trang web lớn hơn, bạn có thể muốn để lắp ráp các tập tin HTML từ các thành phần nhỏ hơn. Ví dụ, bạn có thể tạo một tập tin nhỏ sẽ được hiển thị trên mỗi trang web của bạn giống như “header” hay “footer” (Rails gọi chúng là “partials”), một trang web sẽ bao gồm 1 header và 1 footer. Thậm chí trong 1 trang, dưới những điều kiện khác nhau (vd: bạn login vào một forum nào đó như một user thường có thể khác với user VIP). Xem xét một ví dụ khác: Nếu bạn đang hiển thị nội dung từ một cơ sở dữ liệu, bạn có thể không muốn trộn lẫn HTML code và các dòng code Ruby truy cập database (lập trình viên tách biệt chúng để dể bảo trì). Cuối cùng, nếu bạn đang sử dụng một application server ví dự như thứ được hỗ trợ bởi Rails, bạn có thể thêm các tính năng để trang web có thể được kiểm tra bởi những người khác, do đó bạn không cần phải xây dựng tất cả mọi thứ một mình. Đây là lý do để tạo ra một ứng dụng web.
Bây giờ bạn đã thấy cách Rails kết hợp ngôn ngữ lập trình Ruby với HTML, CSS và JavaScript để tạo ra một ứng dụng web, chúng ta sẽ nguyên cứu Rails sâu thêm một tí bằng cách “nhìn” Rails từ một vài khía cạnh khác nhau.
Xem tiếp các phần khác :
Bài viết được tham khảo từ : http://pingo.edu.vn/ruby-on-rails-la-gi-phan-2/
Comments
Post a Comment