Tổng quan về Ruby on Rails - Ruby on Rails là gì ? ( phần 3 )

6 khía cạnh của một ứng dụng Rails

Khía cạnh trình duyệt Web

Như chúng ta đã thấy, từ quan điểm của các trình duyệt web, Rails chỉ đơn giản là một chương trình tạo ra HTML, CSS, và các tập tin JavaScript. Những tập tin này được tạo ra tự động (mặc dù bạn vẫn phải lập trình cho chúng). Bạn không thể nhìn thấy máy chủ (web

server) làm gì nhưng bạn có thể xem kết quả của việc đó thông qua các tập tin, hãy sử dụng các công cụ phát triển web được xây dựng trong mọi trình duyệt (chọn mục trình đơn “Web Developer” trong Google Chrome hoặc “Web Developer Toolbar” trong Firefox. Dùng Ctrl-Shift-C để bật các toolbar này nhanh hơn).

Khía cạnh lập trình viên (coder)

Nếu bạn đang nhìn vào một chương trình Rails, bạn sẽ thấy gì ?

Bạn sẽ thấy một tập hợp các tập tin mà bạn có thể chỉnh sửa bằng trình soạn thảo văn bản để tạo ra ứng dụng web (các lập trình viên Rails thích dùng VIM, tuy nhiên hãy lựa trình soạn thảo văn bản yêu thích của bạn). Các tập tin được tổ chức với một cấu trúc cụ thể. Cơ cấu là như nhau cho tất cả các ứng dụng Rails và việc này giúp cho việc cộng tác giữa các lập trình viên được dễ dàng hơn. Sử dụng Rails, bạn phải tìm hiểu về cấu trúc thư mục và mục đích của các thư mục/tập tin.

Rails tổ chức thư mục và tập tin theo cấu trúc sau

+-app
| +-assets
| | +-images
| | +-javascripts
| | +-stylesheets
| +-controllers
| +-helpers
| +-mailers
| +-models
| +-views
+-config
+-db
+-features
+-lib
+-log
+-public
+-script
+-spec

Cấu trúc tập tin Rails khá thuận tiện. Thư mục “assets” chứa hình ảnh (trong thư mục “images”), các tập tin CSS (trong thư mục “stylesheets”), JavaScript (trong thư mục “javascripts”). Thư mục “config” chứa các files cấu hình như cấu hình database, cấu hình cho web server,.. và các tập tin dùng để viết chương trình test như “features” và “spec”.

Từ quan điểm của coder, chúng ta có thể nói rằng Rails là một bộ các tập tin được tổ chức một cách cụ thể. Chúng ta sử dụng trình soạn thảo văn bản để chỉnh sửa các tập tin để tạo ra một ứng dụng web. Nhưng những tập tin chứa cái gì?

Khía cạnh kiến trúc của phần mềm

Nội dung của các tập tin (đặc biệt là các tập tin viết bằng ngôn ngữ Ruby) được tổ chức theo một mức độ trừu tượng cao hơn được gọi là “kiến trúc phần mềm.” (software architecture)

Phần mềm hoàn toàn là một khái niệm; nó giống như các tập tin văn bản nhưng mang một ý nghĩa nào đó trong tâm trí của các lập trình viên. Trong thực tế, hầu hết các ngôn ngữ lập trình áp đặt một bộ các khái niệm trừu tượng phản ánh nhu cầu chung của hầu hết các lập trình viên dùng chúng. Như mảng (array) dùng để giữ các danh sách; còn các biến lặp (“iterator”) thì được dùng để quét qua mọi quần tử của mảng nhằm thực hiện một tính toán nào đó. Mỗi ngôn ngữ lập trình giải thích các khái niệm trừu tượng này trong tài liệu tham khảo ngôn ngữ (xem Ruby API).

Trong Ruby (cũng như trong nhiều ngôn ngữ hướng đối tượng khác), một “đối tượng” là cơ sở cho tất cả các khái niệm trừu tượng khác. Tài liệu về Ruby mô tả, “Trong Ruby, tất cả mọi thứ là một đối tượng” (nếu số 10 đôi khi không phải là đối tượng trong ngôn ngữ khác, thì nó lại là đối tượng trong Ruby. Nên bạn có thể dùng nó như sau: 10.times do <<something>>. Chúng tôi sẽ post các bài dạy Ruby lên sau, mong bạn tìm đọc ^^;), và sau đó cho thấy rằng tất cả các đối tượng đều có thuộc tính (attribute, là dữ liệu hay tính chất của đối tượng), hành vi (behavior, thủ tục hay “phương thức”), và sự định danh (sự tồn tại duy nhất trong số tất cả các đối tượng khác). Đối tượng được mô tả bằng cách định nghĩa một “class”  mà bao gồm các thuộc tính (attributes) và phương pháp (methods); chương trình sử dụng các “thể hiện” của class (gọi là instances). Ruby cung cấp một cú pháp tiêu chuẩn để tạo các lớp (class), tạo các instance, và gọi các phương thức (method).

Ở một mức độ trừu tượng cao hơn, lập trình viên cố gắng tối ưu mã chương trình (code) để các lập trình viên khác có thể sử dụng. Code dễ đọc hơn nếu nó được trình bày theo dạng mà ai cũng đã từng gặp; từ đó việc phân tích và hiểu mã lập trình viên khác đã viết cũng dễ dàng hơn nếu nó phù hợp với cấu trúc thiết kế phần mềm phổ biến (software design pattern). Một ví dụ là mô hình Model-View-Controller (Rails sử dụng mô hình này). Mặc dù bạn có thể nhận ra tên của mô hình thông qua tên thư mục của Rails, nó cũng tồn tại trong cách mà Rails phân cấp các Class, đặc biệt là ActionController (bộ điều khiển), ActionView (bộ hiển thị), và ActiveRecord (bộ mô hình hóa cơ sở dữ liệu), trong đó có các đối tượng có thể được chia nhỏ thành các thành phần nhỏ hơn.

Như vậy, từ khía cạnh kiến ​​trúc phần mềm, một ứng dụng Rails được tổ chức như một hệ thống các lớp (class), và Rails dùng các API (Rails API) để tạo ra Class..

Khía cạnh Thời Gian

Cho đến nay, chúng ta đã thấy một ứng dụng web được tổ chức từ quan điểm của một trình duyệt web, hệ thống tập tin, và kiến trúc phần mềm. Quan điểm thời gian cũng rất quan trọng. Mỗi dự án phát triển phần mềm có khía cạnh thời gian này; nó không phải là duy nhất cho Rails, nhưng điều quan trọng là phải hiểu để có thể sử dụng Rails.

Một ứng dụng web được phát triển theo thời gian; thường chúng ta mắc sai lầm và cần phải quay trở lại với một phiên bản trước của software. Máy vi tính cũng là cỗ máy lưu trữ & vận dụng dữ liệu để tính toán. Tuy nhiên, nó không cho phép đi ngược thời gian; các tập tin trong đĩa lưu trữ và bảo quản chỉ có phiên bản mới nhất của công việc của bạn. Khi lập trình, đã có hệ thống kiểm soát phiên bản (version control systems) giúp bạn phục hồi các phiên bản trước đó của dữ liệu.

Có một số hệ thống quản lý phiên bản phổ biến (ví dụ svn, cvs, mercurial, git,..); git được sử dụng thường xuyên nhất bởi các nhà phát triển Rails. Bạn có thể nghĩ git như là một loạt các bức ảnh chụp hệ thống tập tin của bạn. Bạn có thể lưu một bản chụp bất cứ lúc nào với một lệnh “git commit”. Sau đó, bạn có thể phục hồi các tập tin từ ảnh chụp đó.

Git rất quan trọng không chỉ cho sao lưu và phục hồi các tập tin (sau này thì các phần mềm sao lưu như Time Machine của Apple có thể làm điều đó). Bạn có thể sử dụng git với GitHub để lưu dự án của bạn từ xa (phòng khi máy bạn bị hư). Quan trọng hơn, git và GitHub cung cấp các cơ chế chính cho sự phối hợp giữa các lập trình viên, cho dù mã nguồn mở, hay dự án độc quyền. Bạn sẽ sử dụng git và GitHub liên tục trên bất kỳ dự án Rails thực tế.

Nghiêm túc mà nói thì git và GitHub không nằm trong Rails (chúng là công cụ có thể được sử dụng trên bất kỳ dự án phát triển nào). Nhưng Rails và gems được dùng trong ứng dụng web phức tạp sẽ không tồn tại mà không có git và GitHub nên điều quan trọng là phải nhận ra vai trò quan trọng của những công cụ này như một phần của một dự án Rails.

Từ quan điểm thời gian, chúng ta có thể nói rằng một dự án Rails là một loạt các bức ảnh chụp các tập tin được lưu trữ trong một kho lưu trữ git.

Khía cạnh Gems

Lợi thế quan trọng của Ruby là RubyGems, bộ quản lý các gói thư viện (package manager). RubyGems giúp cho việc tạo ra và chia sẽ các gems thật dễ dàng. Rails phổ biến cũng bởi vì nhiều lập trình viên đã viết ra và chia sẽ nhiều gems mạnh mẽ giúp xây dựng nên các tính năng của trang web.

Bạn có thể xem một ứng dụng Rails như một bộ sưu tập các gems nhằm cung cấp chức năng cơ bản, cộng với mã tùy biến (mã bạn viết thêm vào) để thêm các tính năng độc đáo khác. Trong thực tế, khi một nhà phát triển bắt đầu làm việc trên một dự án Rails, họ sẽ thường xuyên nguyên cứu những gems đã được sử dụng trước đó.

Mọi ứng dụng Rails có Gemfile trong thư mục gốc. Các Gemfile liệt kê các gems được sử dụng. Gemfile được dùng bởi một chương trình tiện ích (tên Bundler), nó sẽ “thêm” các gems này vào môi trường Rails (thật ra là nó download và đặt các gems này vào một nơi được Rails hiểu. Từ đó, Rails gọi các gems này ra, tích hợp vào ứng dụng). Một số gems được yêu cầu bởi tất cả các ứng dụng Rails, ví dụ, một bộ chuyển đổi cơ sở dữ liệu (database adaptor) cho phép Rails kết nối với cơ sở dữ liệu. Các gems khác có thể không bắt buộc, nhưng được sử dụng để phát triển ứng dụng dễ dàng hơn, ví dụ, gems để kiểm tra (test) ứng dụng và giúp các lập trình viên tìm thấy lỗi. Còn có các gems khác thêm chức năng cho các trang web, chẳng hạn như gems cho phép người dùng đăng nhập vào trang web, hay gems xử lý thẻ tín dụng.

Nghệ thuật lựa chọn gems là một trong những kỹ năng của một nhà phát triển Rails. Có những gems được đề nghị bởi David Heinemeier Hansson hay những người tham gia tạo Rails. Những lập trình viên dày dạn kinh nghiệm thường thay thế các gems “chính thức” bởi tập các gems mà trở nên phổ biến gần đây mà có nhiều tính năng mới. Hiểu biết cách sử dụng và lý do vì sao dùng một gems dòi hỏi phải có kinh nghiệm và thực hành nhiều.

Khía cạnh Kiểm Tra

Trong số các nền tảng (framework) phát triển cho trang web, framework Rails là framework duy nhất bao gồm một bộ framework cho test đi kèm (ít nhất là ở thời điểm tác giả viết bài này :)). Điều này phản ánh cam kết tạo ra một framework tuân theo phương pháp phát triển phần mềm được gọi là Test Driven Development (TDD). Mặc dù TDD là tùy chọn, không bắt buộc, cho bất kỳ dự án phát triển Rails, nó thường được sử dụng. Chúng ta không thể hoàn toàn hiểu Rails nếu không hiểu được khía cạnh này của nó.

Phần mềm phải luôn được kiểm tra. Đôi khi chỉ bởi người sử dụng (người không biết họ là chuột bạch) nhưng thường xuyên hơn ( và có trách nhiệm hơn ) là tester, trước khi nó được phát hành. Trong lịch sử của các dự án phần mềm lớn ở một công ty, thường có một đội ngũ kỹ sư kiểm nghiệm (QA team) mà công việc là kiểm tra mọi tính năng của một sản phẩm phần mềm từ quan điểm của người sử dụng. Đối với đội QA, “kiểm tra tích hợp” (integration testing) có nghĩa là mọi thành phần đã được thử nghiệm sau khi được kết nối với nhau, hoạt động ảnh hưởng lẫn nhau (ví dụ bạn tích hợp controller & model  vào, controller sẽ dùng model để thay đổi database. Như vậy, để kiểm tra quá trình này, chúng ta cần “kiểm tra tích hợp). Chấp nhận thử nghiệm (acceptance testing) hơi giống như kiểm tra tích hợp, nhưng ý nghĩa thiên về việc đánh giá sản phẩm dựa vào bản đặc mô tả (requirement specification). Thực tế họ thường dùng kiểm tra tự động, có nghĩa là họ viết ra các chương trình phụ (test program) để kiểm tra chương trình chính. Nếu việc này làm kỹ lưỡng, kiểm tra tự động sẽ bao gồm các mẫu kiểm tra đơn vị (unit test), là chương trình nhỏ để kiểm tra các bộ phận rời rạc của một chương trình phần mềm (theo ví dụ về controller và model ở trên, thì unit test chính là đoạn chương trình chỉ test RIÊNG cho model hay controller. Còn intergration test là test sự PHỐI HỢP giữa chúng). Thường thì unit test tập trung vào các lớp (class) hay phương thức của lớp (method).

Kiểm tra có một số mục đích. Đầu tiên, nó cải thiện trải nghiệm của người dùng bằng cách tìm ra các lỗi trước khi gởi ra cho khách hàng. Thứ hai, nó cung cấp cho các nhà quản lý một tầm nhìn về những gì đã được hiện thực và cam kết nó chạy đúng với mong đọi.

Tuy nhiên, một kỹ sư phần mềm có tay nghề thường viết các mẫu thử để test chương trình của chính anh ta. Như vậy, việc kiểm tra trở thành một phần của quá trình lập trình. Thay vì viết unit test sau khi bạn đã viết code, bạn có thể viết bài kiểm tra của bạn trước khi viết mã. Đây là bản chất của quy trình TDD. Nó có vẻ kỳ lạ, hoặc tốn thời gian, nhưng đối với một lập trình viên có tay nghề cao, TDD mang lại sự gắn kết chặc chẽ với quá trình lập trình. Đầu tiên, bằng cách viết các bài kiểm tra trước khi hiện thực chương trình, các nhà phát triển sẽ phát hiện những gì cần được thực hiện từ khía cạnh người dùng và từ khía cạnh quản lý chất lượng. Thứ hai, bằng cách viết các bài kiểm tra trước khi viết mã thực hiện, các nhà phát triển sẽ đảm bảo rằng chương trình kiểm tra đã đầy đủ (viết code trước rồi viết test sau thường sẽ bị quên vài phần. Còn viết test trước thì không thể quên code được, vì quên sao trang web chạy được ^^;). Các lập trình viên (đặc biệt là những người trên cùng một nhóm) có thể tách ra và viết mã để thay đổi tính năng và để cấu trúc lại mã, ý là sắp xếp lại mã để được rõ ràng hơn và hiệu quả hơn (refactor). Chạy một bộ kiểm tra sau khi kết nối các phần nhằm đảm bảo rằng không có gì vô tình phá vỡ kết nối sau khi ai đó thay đổi một phần nào đó.

Cũng như các unit tests, TDD khuyến khích viết các acceptant test trước khi thực hiện bất kỳ bộ phận của một dự án. Việc này khác với thát triển dựa vào hành vi (Behavior Driven Development) mà tập trung vào viết các đặt tả cho một dự án dưới hình thức những câu chuyện, để sau này làm cơ sở để viết các mẫu thử tự động.

Trước khi Rails ra đời, kiểm tra tự động hiếm khi là một phần của phát triển web. Một ứng dụng web sẽ được kiểm trabởi người dùng (hic..) và (có thể) một đội ngũ bảo đảm chất lượng. Rails giới thiệu các nguyên tắc của TDD cho cộng đồng phát triển web. BDD ít được sử dụng vào các dự án Rails (ít ra là ít trong các công ty khởi nghiệp, BDD thường xuyên hơn giữa các công ty tư vấn và các dự án doanh nghiệp) nhưng TDD là phổ biến và được xem như là một kỹ năng cần thiết của một nhà phát triển Rails có kinh nghiệm.

Ngăn xếp Rails

Tập hợp các công nghệ hoặc thư viện phần mềm được sử dụng để phát triển một ứng dụng được gọi là công nghệ “ngăn xếp” (Stack). Ví dụ, Mark Zuckerberg phát triển Facebook trong năm 2004 bằng cách sử dụng ngăn xếp LAMPbao gồm Linux (hệ điều hành), Apache (web máy chủ), MySQL (cơ sở dữ liệu), và PHP (ngôn ngữ lập trình). Rails là một framework dùng Ruby, có thể được sử dụng với một vài sự lựa chọn như hệ điều hành (Linux, Mac OS X, Windows), cơ sở dữ liệu (SQLite, MySQL, PostgreSQL,…), và máy chủ web (Apache, Nginx, …).

Khi mới bắt đầu, ngăn xếp Rails của bạn sẽ bao gồm Ruby, máy chủ WEBrick web (nó đi kèm với Ruby), cơ sở dữ liệu SQLite, và Linux, Mac OS X, hoặc hệ điều hành Windows (bất cứ điều gì được cài đặt trên máy tính của bạn) (thật ra, việc dùng Rails trên Windows hơi bất tiện. Vì nhiều gems được viết để chạy trên Linux hay Mac. Dịch giả khuyến khích bạn dùng Linux hay Mac để thực hành Rails.)

Ngăn xếp Rails cũng có thể bao gồm một loạt các gems. Sự lựa chọn các thành phần trong một ngăn xếp phụ thuộc vào yêu cầu của ứng dụng. Đôi khi, ngăn xếp có thể chỉ là sở thích cá nhân. Giống như thợ thủ công và người hâm mộ tranh luận đâu là ngăn xếp tốt nhất cho Rails, việc này đôi lúc làm cho không khí căng thẳng hơn là tìm ra một giải pháp hay.

Mặc dù vậy, việc hiểu hết những gì đang tranh luận cũng không phải dễ dàng cho hầu hết chúng ta. Vậy bạn hãy chấp nhận thử thách bằng cách giải quyết các vấn đề kỹ thuật bằng phong cách cá nhân. Nhưng bạn có thể học được nhiều về Rails bằng cách theo dõi những cuộc tranh luận. Những cuộc tranh luận là một nguồn cho nhiều đổi mới và cải thiện khuôn khổ Rails. Cuối cùng, sức mạnh của đám đông chiếm ưu thế; thường thì thành phần tốt nhất trong ngăn xếp Rails cũng là thành phần phổ biến nhất được sử dụng.

Sự gia tăng các sự lựa chọn cho các ngăn xếp Rails có thể làm cho việc học khó khăn, đặc biệt là ngăn xếp của David Heinemeier Hansson (tác giả của Rails) có thể không giống với ngăn xếp của nhiều nhà phát triển tài năng khác. Ví dụ, Heinemeier Hansson đề nghị các thư viện Test::Unit library mặc ​​định cho việc kiểm tra; nhưng nhiều nhà phát triển dùng gems RSpec thay thế.

Nhằm tạo ra hướng giải quyết các cuộc tranh chấp, các dự án RailsApps thường sử dụng các thành phần được thường xuyên dùng nhất bởi các nhà phát triển hàng đầu cho ngăn xếp của mình.

Xem các bài viết khác :