Yêu cầu bất kỳ kỹ sư phần mềm nào xem lại các phần chính của mã sản xuất và chắc chắn họ sẽ chỉ ra ba điều cần được cấu trúc lại. Vậy tại sao có quá nhiều mã xấu, dễ vỡ hoặc bị hiểu sai vẫn chạy trong quá trình sản xuất?
Câu trả lời rất đơn giản:các kỹ sư sợ chạm vào nó. Nhiệm vụ tái cấu trúc được xác định và thêm vào hồ sơ tồn đọng, nhưng hiếm khi được đưa vào sprint hiện tại.
Có rất nhiều lý do cho việc này. Mã này có thể được viết bởi một kỹ sư đã rời nhóm nhiều năm trước và không ai hoàn toàn hiểu được nó. Trong các trường hợp khác, năng lực là rất quan trọng đối với doanh nghiệp. Không ai muốn chịu trách nhiệm về khả năng ngừng hoạt động hoặc mất doanh thu.
Trong bài đăng này, chúng tôi sẽ xem xét cách bạn có thể sử dụng Nhà khoa học để di chuyển, tái cấu trúc và thay đổi mã sản xuất Ruby quan trọng một cách tự tin.
Nhưng trước tiên, bạn có thể hỏi — chúng ta không thể sử dụng các bài kiểm tra để tìm ra các vấn đề về mã sao?
Đây là mục đích của việc kiểm thử Rails phải không?
Có và không. Thường khó có được sự tin cậy hoàn toàn về việc thay đổi mã trước khi triển khai. Các bài kiểm tra đơn vị và hệ thống đều vượt qua. Đi thì tốt phải không?
Thực tế là không có sự thay thế nào cho thế giới thực, tức là sản xuất. Điều gì sẽ xảy ra nếu chất lượng dữ liệu kém hoặc thiếu các bài kiểm tra? Làm thế nào bạn có thể biết liệu phần mềm mới có hoạt động đủ tốt để xử lý thông lượng sản xuất hay không?
Các nhóm sử dụng dịch vụ công đôi khi nhận thấy rằng họ cần phải giải quyết các vấn đề về “khả năng tương thích với các lỗi”. Khi một lỗi đã tồn tại trong quá trình sản xuất được một thời gian, khách hàng có thể viết mã theo cách phụ thuộc vào hành vi không chính xác nhất quán. Khách hàng thường sử dụng phần mềm theo những cách không ngờ tới.
Quan sát những thay đổi về sản xuất trong Ruby và Rails cùng với nhà khoa học
Nếu quá trình sản xuất là nơi tốt nhất để có được niềm tin vào một sự thay đổi thì hãy xem xét việc quan sát cách hoạt động của mã ở đó. Điều này thoạt nghe có vẻ đáng sợ vì ý tưởng “thử nghiệm trong sản xuất” mâu thuẫn với các phương pháp kỹ thuật phần mềm cổ điển.
Tuy nhiên, tin tốt là việc thực hiện điều đó trong Ruby và Rails bằng cách sử dụng gem Scientist rất dễ dàng và an toàn. Tên nhà khoa học được đặt theo phương pháp khoa học tiến hành thí nghiệm để xác minh một giả thuyết nhất định. Trong trường hợp này, giả thuyết của chúng tôi là mã mới sẽ thực hiện được công việc.
Lý do chúng ta có thể áp dụng phương pháp này một cách an toàn xuất phát từ thực tế là các thử nghiệm vẫn sử dụng kết quả của mã hiện có. Mã mới chỉ được đánh giá cho mục đích quan sát và so sánh, cả về độ chính xác và hiệu suất. Chúng tôi giảm thiểu những lo ngại về phạm vi thử nghiệm đã thảo luận trước đó bằng cách đánh giá hiệu suất bằng cách sử dụng dữ liệu và thông số trong thế giới thực. Các thử nghiệm thường đánh giá tỷ lệ yêu cầu mẫu đã chọn để giảm thiểu tác động đến quá trình sản xuất. Tuy nhiên, bạn có thể đánh giá mọi yêu cầu nếu muốn.
Bây giờ chúng ta hãy xem nhanh cách Nhà khoa học làm việc trong một nhánh theo cách trừu tượng.
Chi nhánh theo mẫu trừu tượng trong Ruby's Scientist
Cách tiếp cận của nhà khoa học bắt đầu với mô hình Phân nhánh theo Trừu tượng được Martin Fowler mô tả là thực hiện “sự thay đổi quy mô lớn đối với hệ thống phần mềm theo cách dần dần”.
Chúng tôi giới thiệu một lớp trừu tượng để tách biệt mã đang được cập nhật. Lớp này quyết định sử dụng triển khai nào để thử nghiệm minh bạch với phần còn lại của hệ thống. Kỹ thuật này liên quan đến việc sử dụng cờ tính năng xác định đường dẫn mã.
Đá quý Nhà khoa học, có nguồn gốc từ Github, triển khai mô hình này bằng cách sử dụng một thử nghiệm. Mã hiện có được gọi là mã kiểm soát và mã triển khai mới là ứng cử viên. Cả hai đường dẫn mã đều được chạy theo thứ tự ngẫu nhiên, nhưng chỉ có kết quả kiểm soát được trả về máy khách.
Sử dụng nhà khoa học để tái cấu trúc dịch vụ Ruby
Hãy xem xét một dịch vụ Ruby trả về thừa số nguyên tố lớn nhất cho một số nhất định. Giả sử rằng chúng tôi đã xác định các hoạt động tối ưu hóa để giảm bớt nhóm ứng viên cần thiết, tăng tốc dịch vụ.
Tuy nhiên, chủ sở hữu dịch vụ muốn chắc chắn rằng không có lỗi nào được đưa ra. Họ cũng muốn quan sát mọi cải tiến về hiệu suất. Giới thiệu đoạn mã sau, sửa đổi client để gọi phương thức này:
Tại thời điểm này, chỉ có use (điều khiển) biểu thức được gọi. Để làm cho thử nghiệm trở nên có giá trị, hãy xác định Experiment tùy chỉnh class để kích hoạt nó (100% thời gian bên dưới) và công bố kết quả (trong trường hợp này là chỉ ghi nhật ký). Nhà khoa học tạo ra dữ liệu tuyệt vời nhưng theo mặc định, họ không làm gì với dữ liệu đó. Phần đó tùy thuộc vào bạn.
Kết quả thử nghiệm sẽ được ghi lại và chúng tôi có thể cải thiện theo thời gian dựa trên phản hồi. Khi mã mới đáp ứng các yêu cầu và độ tin cậy cao, hãy hoàn thành việc chuyển đổi sang triển khai mới bằng cách thay thế mã khoa học bằng ủy quyền triển khai mới.
LabTech đơn giản hóa các thí nghiệm của nhà khoa học trong Ruby on Rails
Bạn có thể sử dụng gem LabTech trong ứng dụng Rails của mình để dễ dàng định cấu hình Nhà khoa học và xử lý kết quả.
Các ứng dụng sử dụng AppSignal có thể sử dụng Appsignal.instrument trình trợ giúp thiết bị tùy chỉnh để theo dõi thời gian hoàn thành các sự kiện Nhà khoa học. Quấn nó xung quanh các khối mã thử nghiệm khác nhau để xem các sự kiện xuất hiện trong dòng thời gian hiệu suất.
Bây giờ, hãy quay lại LabTech — trang web bên dưới chỉ chấp nhận một số để phân tích.
Bắt đầu thật dễ dàng miễn là bạn có quyền truy cập vào bảng điều khiển. Đầu tiên, thêm đá quý LabTech vào Gemfile của bạn và chạy bundle install .
Các bảng lưu trữ kết quả và cấu hình thử nghiệm, vì vậy hãy tiến hành di chuyển cơ sở dữ liệu.
Lớp trừu tượng giống nhau, ngoại trừ mô-đun LabTech được sử dụng. Mã đầy đủ có sẵn trên GitHub.
Tại thời điểm này, thử nghiệm bị vô hiệu hóa, vì vậy hãy sử dụng bảng điều khiển để bật thử nghiệm trong mọi trường hợp hoặc trong một tỷ lệ phần trăm thời gian.
Bây giờ chúng ta có thể chạy thử nghiệm và thử nghiệm sẽ được đánh giá. Để xem kết quả bằng văn bản, hãy sử dụng một trong các lệnh sau từ bảng điều khiển Rails.
Sau một vài lần chạy thành công và một lần xảy ra lỗi, đây là ví dụ về kết quả tóm tắt. Có cái nhìn tổng quan về những thành công và thất bại cũng như biểu đồ ASCII thể hiện sự khác biệt về hiệu suất.
Đá quý Blazer cung cấp một cách hay để phân tích kết quả một cách dễ dàng. Nó rất đơn giản để cài đặt và cho phép các truy vấn SQL chạy trên các bảng. Truy vấn ở đây cho thấy quá trình triển khai ứng viên nhanh hơn đáng kể so với ban đầu.
Trong ví dụ về dịch vụ bao thanh toán nguyên tố, việc tăng tốc độ triển khai được cải thiện xuất phát từ phương pháp phỏng đoán giúp loại bỏ một số yếu tố có thể cần xem xét. Khi chúng ta xem xét các số cao hơn và tìm ra thừa số nguyên tố, chúng ta có thể ngừng tìm kiếm sau khi đạt được số mục tiêu chia cho thừa số đó. Đường dẫn mã mới chỉ thêm một câu lệnh để thực hiện việc này.
Chúng ta cũng có thể thấy thời gian thực thi giảm đi khi sử dụng truy vấn Blazer đối với các bảng LabTech.
Trường hợp sử dụng và hạn chế của nhà khoa học
Các trường hợp sử dụng tối ưu cho Nhà khoa học bao gồm tìm kiếm, tính toán và mã không có tác dụng phụ. Mã bao gồm các cập nhật giao dịch hoặc tích hợp bên ngoài như email không hoàn toàn phù hợp với mô hình vì khả năng này được chạy hai lần (cả cách triển khai cũ và mới).
Đây không phải là một hạn chế nhỏ vì nó loại bỏ một số trường hợp sử dụng. Tuy nhiên, có một số cách giải quyết nếu thử nghiệm đóng vai trò quan trọng đối với sự thành công của bạn. Xem xét liệu các tác dụng phụ có liên quan hay không hoặc liệu sự trùng lặp có phải là một vấn đề hay không. Ví dụ:trong một số trường hợp, việc hai email có được gửi trong quá trình đánh giá hay không có thể không thành vấn đề. Một tùy chọn khác là để mã mới xác định kết quả nhưng không duy trì nó. Điều này sẽ ngăn chặn mọi so sánh hiệu suất có ý nghĩa. Tuy nhiên, nó sẽ cho phép bạn xác minh tính chính xác.
Những hạn chế khác xuất phát từ việc Nhà khoa học tập trung vào giá trị trả về. Trong một số trường hợp, kết quả hợp lệ có thể thể hiện sự khác biệt theo thời gian, cho dù chúng chỉ bao gồm dấu thời gian trong phản hồi hay có một số yếu tố nhất định khác nhau. Trong nhiều trường hợp, chúng tôi có thể viết logic so sánh tùy chỉnh trong thử nghiệm để xác minh độ chính xác ngoài các phép so sánh chuỗi cơ bản.
Cuối cùng, một hạn chế của LabTech là nó chưa được chuyển sang Rails 7 tính đến thời điểm viết bài.
Các phương pháp hay nhất để thực hiện các thí nghiệm khoa học hiệu quả trong Rails
Hãy xem xét những mục này khi triển khai thử nghiệm của bạn:
- Trong các dự án Rails, Nhà khoa học có thể được định cấu hình trong trình khởi tạo hoặc trình bao bọc như gem Rails LabTech. Hầu hết các ứng dụng Rails đều đã có cơ sở dữ liệu, vì vậy LabTech tận dụng ActiveRecord để lưu trữ kết quả.
- Để tránh làm chậm quá trình phát triển và thử nghiệm, hãy chỉ bật thử nghiệm của bạn trong môi trường dàn dựng và sản xuất.
- Để giảm thiểu mọi tác động tiềm ẩn đến quá trình sản xuất, chỉ chạy thử nghiệm theo tỷ lệ phần trăm yêu cầu. LabTech hỗ trợ tính năng này ngay lập tức dưới dạng tham số tùy chọn khi bạn bật thử nghiệm (ban đầu nó bị tắt theo mặc định). Sử dụng Nhà khoa học thuần túy, logic này rất dễ mã hóa trong
enabled?của thử nghiệm phương pháp. - Một số logic tiêu tốn nhiều tài nguyên nên tốc độ lấy mẫu thấp có thể là điểm khởi đầu phù hợp. Khi bạn tin tưởng vào kết quả, hãy tăng tỷ lệ phần trăm yêu cầu được đánh giá.
- Bạn có thể thêm thuộc tính ngữ cảnh để tận dụng tối đa kết quả của mình. Bối cảnh thử nghiệm có thể được đặt thành Băm dữ liệu có khóa Biểu tượng, sau đó được cung cấp trong các kết quả được công bố, ví dụ:
Tóm tắt:Quan sát và giám sát ứng dụng Ruby của bạn cùng với nhà khoa học
Trong bài đăng này, chúng ta đã khám phá cách sử dụng gem Scientist để thay đổi, di chuyển và tái cấu trúc mã Ruby trong quá trình sản xuất.
Chúng tôi đã kiểm tra nguồn gốc của Nhà khoa học trong mô hình Chi nhánh theo Trừu tượng, sau đó đi sâu vào tái cấu trúc. Tiếp theo, chúng ta tìm hiểu cách LabTech có thể giúp thu thập kết quả và cấu hình Nhà khoa học của bạn.
Sau đó, chúng tôi đề cập đến một số hạn chế của Nhà khoa học trước khi phác thảo một số phương pháp hay nhất.
Bạn phải quan sát và theo dõi những gì đang xảy ra trong hệ thống của bạn. Tích hợp Nhà khoa học vào quá trình phát triển của bạn để thực hiện những thay đổi quan trọng trong mã Ruby của bạn một cách tự tin hơn.
Chúc bạn viết mã vui vẻ!
Tái bút. Nếu bạn muốn đọc các bài đăng của Ruby Magic ngay khi chúng được đăng tải, hãy đăng ký nhận bản tin Ruby Magic của chúng tôi và không bao giờ bỏ lỡ một bài đăng nào!
Darren Broemmer
Darren thích truyền cảm hứng thông qua chữ viết và làm cho những điều phức tạp trở nên dễ hiểu. Mối quan tâm của anh ấy bao gồm khoa học và vật lý, và đủ toán học để hiểu cả hai. Anh ấy tạo ra các giải pháp công nghệ và nội dung chất lượng cao, đồng thời thỉnh thoảng tweet về các giải pháp đó.
Tất cả bài viết của Darren Broemmer