Một lỗi trong phần mềm có thể gây rối loạn, khó nắm bắt, gây khó chịu và xâm lấn. Quả thực, một nhà phát triển thường cần đến sự kiên trì của Edison để tìm ra và khắc phục sự cố.
Nhưng sự kiên trì không phải là tài sản duy nhất mà một nhà phát triển yêu cầu. Người ta cũng cần thông tin để gỡ lỗi mã:Triệu chứng và ảnh hưởng của sự cố là gì? Tần suất của nó là bao nhiêu? Tính lan tỏa? Xuất xứ? Bằng chứng và hiện vật của một lỗi — kết xuất lõi, dấu vết ngăn xếp, nhật ký hoặc trường hợp kiểm thử — là vô giá.
Hãy cùng khám phá một số kỹ thuật và công cụ có sẵn cho các nhà phát triển Ruby và Rails để thu thập và điều tra bằng chứng về một vấn đề. Dữ liệu không thể thay thế được sự kiên trì nhưng nó có thể giúp bạn giảm bớt nỗ lực (và giúp bạn không bị mất ngủ).
Rails cung cấp một số công cụ tuyệt vời để xem xét một ứng dụng đang chạy, bao gồm cả một ứng dụng có thể cấu hình để ghi lại chẩn đoán của chính ứng dụng đó và bất kỳ công cụ nào bạn muốn thêm. Rails cũng cung cấp nhật ký truy vấn chi tiết để xác định nguồn gốc của các truy vấn cơ sở dữ liệu và nhật ký hàng đợi dài dòng để làm sáng tỏ nơi các công việc nền được xếp hàng đợi. Hai nhật ký sau được bật theo mặc định trong development môi trường; bạn có thể kích hoạt cả hai trong các môi trường khác bằng hai câu lệnh.
Một tùy chọn nhật ký ít được biết đến hơn có sẵn vì Rails 7 chú thích từng truy vấn SQL kèm theo nhận xét. Nếu bạn thêm phần sau vào config/application.rb hoặc bất kỳ tệp môi trường nào:
Nhật ký truy vấn của bạn sẽ tự động được sửa đổi với tên ứng dụng, tên bộ điều khiển, tên hành động hoặc tên công việc nền. Đầu ra mẫu sau đây được lấy trực tiếp từ hướng dẫn gỡ lỗi của Rails:
Bạn có thể không muốn kích hoạt tất cả các tính năng này trong quá trình sản xuất. Việc tạo nhật ký có thể tốn kém về mặt bộ nhớ và thời gian (tài nguyên hữu hạn cho một ứng dụng đang tải).
Tuy nhiên, vẫn có những ngoại lệ. Bạn có thể muốn kích hoạt ngắn gọn một tính năng theo yêu cầu, đặc biệt là khi gỡ lỗi các chế độ thử nghiệm và đang phát triển. Thay vì thay đổi mã (và có thể triển khai lại) để bật hoặc tắt chẩn đoán, hãy sử dụng các biến môi trường để kiểm soát trạng thái. Trong một số môi trường, chẳng hạn như Heroku, việc thay đổi cài đặt của biến môi trường không bắt buộc phải triển khai mới.
Ví dụ:bạn có thể xác định một tập hợp các biến để kiểm soát việc ghi nhật ký và mức độ chi tiết.
Để thuận tiện, hãy tạo một lớp nhỏ để truy vấn cài đặt cấu hình.
Bây giờ hãy sử dụng các biến và mã để đặt tính năng ghi nhật ký trong config/application.rb :
Sử dụng shell, tệp dotenv, tích hợp liên tục hoặc nền tảng lưu trữ và triển khai của bạn để đặt từng tùy chọn. Bạn cũng có thể sử dụng một tính năng theo yêu cầu. Chỉ cần khởi động ứng dụng với biến môi trường được xác định trên dòng lệnh.
Điều chỉnh Puma để phát triển
Dựa trên phần trước, hãy xem cách sử dụng các biến môi trường để điều chỉnh cấu hình Puma của bạn nhằm gỡ lỗi trong môi trường phát triển.
Thông thường, Puma được cấu hình để tối đa hóa thông lượng trong quá trình sản xuất, chạy nhiều công nhân và nhiều luồng cho mỗi công nhân. Trong quá trình phát triển, bạn muốn điều ngược lại:một công nhân, một luồng và thời gian chờ rất dài để cho phép gỡ lỗi tương tác. Mỗi thông số đó là một thông số bạn có thể điều chỉnh.
Thay đổi config/puma.rb để phản ánh đoạn mã sau.
Bây giờ bạn có thể định cấu hình ba biến môi trường để kiểm soátPuma trong từng môi trường. Trong quá trình phát triển, hãy đặt các giá trị để tối ưu hóa cho việc gỡ lỗi tương tác.
Nếu bạn muốn xác thực cài đặt Puma của mình, hãy đặt biến môi trườngPUMA_LOG_CONFIG=true và bắt đầu ứng dụng của bạn. Puma phát ra cấu hình hoạt động khi khởi động.
Thật trùng hợp, cấu hình Puma mặc định trong bản phát hành Rails gần đây nhất tương tự như những gì được hiển thị ở đây (cảm ơn Nate Matykiewicz về mẹo này).
Chạy nội tuyến các công việc nền
Một ứng dụng Rails ở bất kỳ mức độ phức tạp nào thường tận dụng các tác vụ nền để chạy các tác vụ tính toán chuyên sâu và (tương đối) dài. Công việc nền chạy không đồng bộ, bị ngắt kết nối khỏi chu kỳ yêu cầu/phản hồi. Các ứng cử viên lý tưởng để xử lý "ngoài luồng" bao gồm tạo báo cáo, gửi email và tương tác với API của bên thứ ba. Nhưng tính chất không đồng bộ của công việc cũng khiến việc gỡ lỗi trở nên phức tạp.
Để đơn giản hóa việc khắc phục sự cố, hãy thực hiện công việc ngay lập tức trong môi trường thử nghiệm và phát triển tại địa phương của bạn. Ở chế độ ngay lập tức, các công việc không được xếp hàng mà thay vào đó được thực thi ngay lập tức. Chạy ở "nền trước", bạn có thể đặt điểm dừng và kiểm tra trạng thái một cách tương tác.
Hãy xem một ví dụ sử dụng Công việc bị trì hoãn, một chương trình phụ trợ xếp hàng phổ biến và dễ quản lý cho Công việc đang hoạt động. Công việc bị trì hoãncung cấp cài đặt để bật xếp hàng. Theo mặc định, cài đặt là true và công việc được xếp hàng đợi như thường lệ. Tuy nhiên, nếu được đặt thành false , công việc sẽ được thực hiện ngay lập tức.
Thêm mã sau vào ứng dụng của bạn trong config/initializers/delayed_job.rb :
Nếu DELAYED_JOBS_DISABLE_JOB_QUEUES được đặt thành bất kỳ giá trị nào, việc xếp hàng sẽ bị vô hiệu hóa. Nếu biến môi trường trống hoặc không được xác định thì tính năng xếp hàng sẽ được bật.
Tiếp theo, trong shell, trên dòng lệnh hoặc trong tệp dấu chấm của bạn, hãy đặtDELAYED_JOBS_DISABLE_JOB_QUEUES khi cần thiết.
Đặt biến môi trường thành không có gì hoặc xóa biến môi trường để khôi phục hàng đợi.
Không có quy tắc đặt tên biến môi trường. Chọn những tên có ý nghĩa đối với bạn. Một quy ước hữu ích để phân loại các biến là thêm tên gói làm tiền tố, chẳng hạn như PUMA_ và DELAYED_JOB_ . Cái trước biểu thị các biến ảnh hưởng đến Puma; cái sau bao hàm các biến được sử dụng bởi Delayed Job.
Cuộc gọi ngang hàng trong mạng
Giống như các công việc nền, ứng dụng Rails cũng có thể sử dụng giao diện lập trình ứng dụng (API). API cung cấp quyền truy cập vào các dịch vụ bên ngoài, chẳng hạn như cơ sở dữ liệu GraphQL, giao dịch thương mại điện tử và nguồn dữ liệu công cộng.
Đây là một ví dụ khác để phát ra các yêu cầu và phản hồi HTTP có điều kiện từ Net::HTTP thư viện. Nếu biến môi trường DEBUG_HTTP được đặt thành bất kỳ giá trị không trống nào, yêu cầu gửi đi và phản hồi gửi đến sẽ được in thành STDOUT .
Để xem hoạt động mạng, chỉ cần khởi động ứng dụng với biến môi trường được xác định trên dòng lệnh.
debug? phương thức này cung cấp một số thông tin trừu tượng từ việc triển khai thực tế. Nó và phần còn lại của mã này có thể tạo thành lớp cơ sở cho tất cả các yêu cầu mạng của bạn, như được hiển thị trong ý chính được lấy từ mã sản xuất.
Thế giới của đá quý Ruby rất rộng lớn:không thể bao gồm tất cả các loại đá quý tuyệt vời có sẵn để gỡ lỗi. Thay vào đó, hãy xem xét một số công cụ bạn có thể thêm ngay hôm nay để tăng tốc ngay lập tức. Bạn có thể sẽ thêm từng thứ này vào tất cả các dự án của mình.
-
awesome_printvàtable_printtạo ra các cuộc kiểm tra phong phú, dễ đọc về cấu trúc dữ liệu Ruby, bao gồm cả các mô hình Bản ghi Hoạt động. Bạn có thể sử dụng mã gemin hoặc từ bảng điều khiển.Dưới đây là ví dụ về mô hình được phát ra bởi
awesome_printtrong bảng điều khiển:Thay vì
p, sử dụngapđể hiển thị đầu ra nâng cao. tuyệt vời_print liệt kê các thuộc tính theo thứ tự bảng chữ cái, một thuộc tính trên mỗi dòng, cùng với các thuộc tính khác. -
better_errorsthay thế trang lỗi Rails tiêu chuẩn bằng dấu vết ngược ngăn xếp nâng cao, danh sách tham số và bảng điều khiển tương tác nơi bạn có thể thăm dò khung ngăn xếp và các biến tại hiện trường ngoại lệ. Bạn cũng có thể liên kết các liên kết mã nguồn với trình soạn thảo yêu thích của mình. Đây là mã để buộcbetter_errorstới mã Visual Studio:Chạy
export BETTER_ERRORS_EDITOR=vscodetrong shell của bạn và khởi động lại máy chủ Rails. Bây giờ liên kết đến các tệp sẽ tự động mở trong Visual Studio. -
Giữ
fakervàfactory_botđá quý (hoặc các lựa chọn thay thế của chúng) trong cả nhóm thử nghiệm và phát triển trong Gemfile . Cả hai đều vô giá nếu bạn cần tạo dữ liệu nhanh chóng trong bảng điều khiển.
Một ý tưởng nữa:Nếu bạn sử dụng AppSignal làm công cụ giám sát ứng dụng của mình, nó có các tính năng để diễn giải nhật ký của bạn và xác định nguồn gốc lỗi. Xem Gỡ lỗi trong Ruby bằng AppSignal để biết thêm chi tiết.
Gỡ lỗi là một kỹ năng
Mã gỡ lỗi là một nghệ thuật và giống như bất kỳ nỗ lực sáng tạo nào, bạn càng thực hành nhiều thì bạn càng trở nên giỏi hơn.
Gỡ lỗi trong khi ghép nối với nhà phát triển khác, đặc biệt là nhà phát triển có kinh nghiệm. Nếu đối tác của bạn sẵn lòng, hãy cùng nhau suy nghĩ kỹ và trao đổi linh cảm cũng như hiểu biết sâu sắc.
Hãy tiến lên và hack!
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!
Martin Streicher
Tác giả khách mời Martin của chúng tôi là một nhà phát triển Ruby chuyên nghiệp. Ông có bằng cao cấp về Khoa học Máy tính tại Đại học Purdue, từng giữ chức vụ Tổng biên tập Tạp chí Linux (Mỹ) trong 5 năm và là tác giả sáng lập chuyên mục "Nói trong Unix" được xuất bản trên cổng thông tin devWorks trước đây của IBM. Khi không viết mã hoặc viết về mã, anh ấy sưu tầm nghệ thuật và đánh nhau với nhiều con chó nhỏ.
Tất cả bài viết của Martin Streicher