Tôi đã chuyển từ Ruby sang Python như thế nào?

Bài viết này là một kinh nghiệm cá nhân được chia sẻ bởi Benoit - kỹ sư đầu tiên của Sqreen - người đã từng tham gia phát triển các dự án với cả Ruby và Python.

Trở lại năm 2008 khi tôi còn học đại học, hai người bạn của tôi quyết định thành lập một công ty tên là Feedbooks. Mục tiêu của họ là làm cho sách điện tử với chất lượng cao trở nên dễ dàng tìm kiếm cũng như tải xuống và chia sẻ hơn với tất cả mọi người. Một thư viện kỹ thuật số được tạo ra, bao gồm các tác phẩm được công khai miễn phí, các văn bản tự xuất bản và các tác phẩm được phân phối thương mại.

Trang web cho phép họ đạt được mục tiêu này cần phải nhanh chóng, hiệu quả và dễ bảo trì. Vào thời điểm đó, khi vừa xem chương trình giới thiệu nổi tiếng lúc bấy giờ về cách tạo blog trong 15 phút bằng Ruby on Rails, những người sáng lập đã quyết định chọn Ruby on Rails để phát triển dự án của mình. Vài tuần sau đó, để có thể phát triển sản phẩm của họ 1 cách nhanh nhất có thể, họ đã liên hệ và hỏi thêm ý kiến của tôi.

Giống như nhiều kỹ sư thuộc thế hệ của mình, trước đây tôi đã tìm hiểu khá nhiều về các trang web được phát triển từ PHP & Mysql, tôi thậm chí đã đóng góp cho một hệ thống CMS bằng mã nguồn mở nhỏ. Tôi đã quen thuộc với mọi thứ liên quan đến Web lúc bấy giờ, tuy nhiên tôi lại không biết Ruby, thậm chí chưa bao giờ nghe nói về Ruby. Vì vậy, tôi đã xem video và cũng rơi vào "lưới tình" của Ruby on Rails. Kể từ thời điểm đó thì tôi đã gắn bó với Ruby trong 10 năm tiếp theo. Nhóm bạn cùng chí hướng của chúng tôi đã phát hành thành công trang web thư viện điện tử của mình và sau đó cũng phát triển thêm khá nhiều ứng dụng web khác sử dụng công nghệ này.

Nhưng tại sao lại là Ruby, những điều rất tuyệt về nó?

Ruby là một ngôn ngữ "rất biểu cảm". Matz, nhà thiết kế chính của ngôn ngữ, đã có một mục tiêu rất đơn giản khi tạo ra Ruby: tối ưu hóa sự hạnh phúc của lập trình viên. Đối với tôi, điều này rõ ràng đã đạt được. Ruby là một ngôn ngữ kịch bản hướng đối tượng. Mỗi thứ trong Ruby là một Object. Máy ảo Ruby đảm nhiệm việc biên dịch cú pháp trông rất tự nhiên và thực tế. VM này liên tục được cải thiện và mã được tạo sẽ nhanh hơn với mỗi phiên bản mới. Các đối tượng trong Ruby cộng tác bằng cách tự gửi tin nhắn có chứa tên phương thức và danh sách các đối số. Ruby cũng rất trực quan, nó dễ dàng thay đổi hoặc tạo mới mọi thứ

Những điều này làm cho nó trở thành một ngôn ngữ rất tốt để viết ngôn ngữ đặc tả chuyên biệt (Domain Specific Languages - DSL) . Đó chính xác là những gì David Heinemeier Hansson (còn gọi là DHH) đã làm khi ông tạo ra Rails. Ruby on Rails, ở cốt lõi của nó, là một bộ sưu tập DSL cộng với một khung để dễ dàng tạo các ứng dụng web theo mô hình. Cho đến ngày nay, nó đặc biệt thích nghi và tạo ra các ứng dụng mà logic kinh doanh & mô hình hóa sẽ đóng một phần quan trọng. Và vì vậy, 6 năm sau khi tôi gia nhập Sqreen với tư cách là kỹ sư đầu tiên, sự lựa chọn hợp lý sẽ là sử dụng Ruby. Tuy nhiên, khi chúng tôi bắt đầu viết backend cho Sqreen, chúng tôi đã không lựa chọn Ruby để đi cùng mà thay vào đó là sử dụng Python.

Bạn yêu Ruby nhưng lại chọn Python?

Tại sao vậy? Trước hết, phần backend cho hệ thống Sqreen thực sự bao gồm nhiều dịch vụ bên trong. Phần đầu tiên mà một khách hàng mới nhìn thấy là trang web công ty của chúng tôi thực sự là một trang web tĩnh (mặc dù chúng tôi tạo ra nó bằng cách sử dụng Jekyll, một trình tạo trang web do Ruby cung cấp). Sau đó, xuất hiện tiếp theo là trang Dashboard, ngược lại với trang web tĩnh kể trên thì nó là một ứng dụng cực kỳ năng động, được xây dựng dưới dạng một ứng dụng trang duy nhất (single page app), được viết, sau lần đầu tiên thâm nhập vào Meteor (đó là một bài đăng trên blog cho một ngày khác!) Như một ứng dụng React. Dashboard được giao tiếp với một API chuyên dụng, mà chúng tôi gọi là backend cho frontend. Đây không phải là API duy nhất của chúng tôi, chúng tôi có một vài API khác, nhưng cho đến nay, điều quan trọng nhất là phần backend sẽ được tách riêng ra theo mục đích sử dụng.

Chúng tôi đã quyết định sớm, rằng chúng tôi đã không muốn viết API bằng nhiều ngôn ngữ để chúng tôi có thể dễ dàng sử dụng lại các mô hình & mã logic kinh doanh trên các API khác nhau của chúng tôi. Chúng tôi cũng đã hình dung từ rất sớm rằng ít nhất phần backend cho các đại lý sẽ có thể mở rộng 1 cách dễ dàng cho một số lượng lớn khách hàng đồng thời, vì các đại lý của chúng tôi thường ping đến phía backend nhiều lần.

Thật không may, Rails khá chậm và dĩ nhiên nó chưa bao giờ là lựa chọn đầu tiên của chúng tôi trong trường hợp này. Rõ ràng, Rails không phải là cách duy nhất để sử dụng Ruby cho các ứng dụng & API, có rất nhiều khung vi mô có sẵn trong Ruby, nổi tiếng nhất là Sinatra. Sinatra thật tuyệt, nó có API rất nhỏ và dễ sử dụng và chúng tôi có thể đã dùng nó.

Nhưng chúng tôi lại chọn Python vì hai lý do. Đầu tiên, hai người đồng sáng lập JB & Pierre đã quen thuộc hơn với Python, họ đã sử dụng nó cho một số công cụ nội bộ trong thời còn làm việc ở Apple. Thứ hai và quan trọng nhất, chúng tôi luôn tin rằng phân tích dữ liệu sẽ là điều cần thiết cho Sqreen. Thật không may, Ruby không phải là một trợ giúp tuyệt vời trong lĩnh vực này, ngược lại thì hệ sinh thái khoa học của Python đơn giản là đỉnh cao. Sự lựa chọn rất dễ dàng, hãy để sử dụng Python và giải pháp khung vi mô rất nổi tiếng của nó - Flask.

Bắt đầu bằng Python

Vào thời điểm đó, tôi chỉ biết viết về Python để viết các tập lệnh nhỏ, để chuyển đổi và định hình lại một số dữ liệu hoặc thực hiện các phép tính. Tôi đã phải tăng tốc bằng cách sử dụng nó để tạo API. May mắn thay, web và các thành phần cơ bản của nó không thay đổi nếu bạn thay đổi ngôn ngữ lập trình.

HTTP / HTML / JSON vẫn là các giao thức / ngôn ngữ dựa trên văn bản; REST vẫn vậy. Bất cứ điều gì tôi học được trong sự nghiệp của mình vẫn hợp lệ, chỉ có cách để đầu ra nó có một chút khác biệt. Làm cho các ứng dụng giao tiếp với web ở mức thấp hơn được thực hiện trong Ruby bằng cách sử dụng một đặc tả chung gọi là Rack. Nó có một thông số rất đơn giản, chủ yếu là mã hóa rằng các Yêu cầu & Phản hồi HTTP phải được thể hiện bằng cách sử dụng Array. Hóa ra, Ruby & Rack thực sự được truyền cảm hứng rất nhiều từ một sáng kiến trước đó trong Python có tên WSGI. Tốt, một trở ngại tiềm năng lớn đã được đưa ra.

Nhưng còn ngôn ngữ thì sao? Ruby như được mô tả trước đây là một ngôn ngữ kịch bản hướng đối tượng, python cũng là một ngôn ngữ kịch bản hướng đối tượng. Tuy nhiên, Python hơi kém tinh khiết trong cách tiếp cận khái niệm này. Nó được tạo ra như một ngôn ngữ hướng đối tượng và cũng hỗ trợ các mô hình khác (chủ yếu là chức năng). Nhưng, chúng vẫn là các ngôn ngữ khác nhau, và vì vậy cú pháp khá khác nhau. Có thể kể đến vài cái tên phổ biến:

• Ruby mô tả các khối bằng cách sử dụng từ khóa (bắt đầu / def end) Python sử dụng khoảng trắng. Điều này đã làm quen với một chút (và cá nhân tôi vẫn thích cách làm của Ruby hơn).
• Bạn bắt gặp các ngoại lệ trong Ruby bằng cách sử dụng begin/rescue/end còn trong Python mà bạn sử dụng try/except.
• Nhưng đối với tôi, thay đổi lớn nhất là không thể thực hiện bất kỳ khối nội tuyến nào theo cách Ruby cho phép bạn chuyển qua nhiều phương thức (như với find,map, inject). Trong Python thì khác hẳn, mọi người có thể sử dụng một sự hiểu biết nội tuyến để thường thực hiện các hoạt động tương đương nhưng cú pháp trở nên rất lộn xộn rất nhanh. Điều này thực sự buộc các nhà phát triển phải suy nghĩ nhiều hơn về số lượng vòng lặp được sử dụng và cuối cùng dẫn đến mã hiệu quả hơn. Tôi cũng phát hiện ra một vài khái niệm mới và rất chu đáo. Ví dụ: trình quản lý bối cảnh trong Python cho phép bạn áp dụng các hành vi dọn dẹp cho các tài nguyên và cú pháp thực tế, một lần nữa, thúc đẩy mọi người viết mã hiệu quả hơn.

Vậy làm thế nào để cá nhân tôi đạt được tốc độ theo cú pháp Python? Đầu tiên bằng cách thực hành sử dụng Python Koans rất đẹp. Dự án nguồn mở này cho phép mọi người tìm hiểu Python bằng cách sửa một tập các bài kiểm tra đơn vị khó hơn dần dần. Họ tham quan các tính năng khác nhau của ngôn ngữ và cung cấp một hướng dẫn thực tế và khá sâu sắc. Sau đó tôi đọc tài liệu Python. Trường hợp tài liệu Ruby có thể ngắn gọn và đôi khi thiếu một chút, tài liệu Python cực kỳ hoàn chỉnh. Ngôn ngữ được chia thành các mô-đun mà mỗi mô tả có một lời giải thích dài thường đi sâu vào chi tiết lý do tại sao mô-đun tồn tại, vấn đề mà nó nhắm đến để giải quyết, làm thế nào để giải quyết nó và khá thường xuyên khi không sử dụng nó! Và có rõ ràng, nó cũng bao gồm các ví dụ. Nó là một thứ phải đọc cho bất cứ ai muốn vào Python. Đợi đã, tất cả những điều này có nghĩa là Sqreen không sử dụng Ruby và tôi không còn làm gì nữa? Tôi vui mừng khi bạn hỏi, thực sự không! Tôi yêu Ruby và chúng tôi thực sự đã làm một chút công bằng tại Sqreen.

Trước hết, chúng tôi có một tác nhân Ruby giúp bảo vệ các ứng dụng Ruby. Phát triển và sau đó duy trì các tác nhân, mà tôi đã làm và tắt trong 3 năm qua, thực sự phức tạp hơn nhiều (đọc, vui vẻ!) Ruby hơn tôi từng làm trước đây. Mỗi đại lý của chúng tôi không thiết bị đo động. Nói cách khác, chúng tôi đang viết mã sẽ thay đổi luồng điều khiển của một phần mềm đang chạy dựa trên một mô tả - được ký bằng mật mã - được gửi qua dây. Đầu tiên chúng tôi đã thử nghiệm điều này trong Ruby nhưng bây giờ chúng tôi đang thực hiện nó trong năm (sớm sáu!). Điều này không phải là nhỏ và nó là một đặc ân để làm việc với một nhóm những người tài năng và đam mê về loại chủ đề này.

Thứ hai, khi chúng tôi tạo ra các đại lý, và trước khi gửi nó cho những người thử nghiệm đầu tiên của chúng tôi (bây giờ là khách hàng), chúng tôi muốn kiểm tra nó kỹ lưỡng trong điều kiện thực tế. Chúng tôi cần một ứng dụng thực tế mà chúng tôi cũng có thể đo lường hành vi của đại lý. Đúng với văn hóa kỹ thuật của chúng tôi, chúng tôi quyết định tự làm thức ăn cho chó và tạo ra một giao diện quản trị Rails nhỏ nhưng khá hữu ích. Nó được sử dụng mỗi ngày trong nội bộ để theo dõi hành vi của các đại lý và giúp đỡ khách hàng của chúng tôi.

Một lời khuyên nhỏ cho những người đang đứng ở vị trí như thế này

Bạn có phải là một nhà phát triển Ruby và đang nghĩ về việc bắt đầu với Python? Bạn nên làm điều đó ngay! Nó rất giống với Ruby mà bạn sẽ cảm thấy quen thuộc sớm thôi. Tuy nhiên, nó cũng đủ khác biệt để bạn học được một số thủ thuật nhất định mới có thể mở ra cánh cửa mới cho bạn. Trở thành một con ngựa "một mánh" không bao giờ là một ý tưởng hay! Một hướng dẫn tương tác tốt và tài liệu là một nơi tốt để bắt đầu. Nhưng bạn cũng nên thử làm việc trên một ứng dụng thực sự. Nhiều đặc điểm riêng của hệ sinh thái không xuất hiện khi chỉ thực hiện các hướng dẫn (ví dụ: quản lý các packages, kiểm tra, cấu hình kỹ thuật ...).

Bài viết dịch từ: https://medium.com/hackernoon/how-i-switched-from-ruby-to-python-ac7038015888