Computer >> Máy Tính >  >> Lập trình >> Ruby

Làm thế nào để bạn thực hiện một cuộc lặn sâu Rails?

Có thể việc sửa một lỗi vừa sinh ra hàng chục cái mới. Hoặc mã của bạn bị hỏng theo một cách kỳ lạ đến mức bạn tự hỏi liệu bạn có thực sự hiểu nó không. Bạn nghĩ đã đến lúc phải đi sâu tìm hiểu.

Nhưng biết bạn cần đi sâu vào một chủ đề? Đó chỉ là bước 1. Làm cách nào để bạn thực sự tìm hiểu một chủ đề từ các nguyên tắc cơ bản của nó? Làm thế nào để bạn học đủ để nó đến với bạn một cách tự nhiên?

Bạn bắt đầu từ đâu?

Có rất nhiều nơi bạn có thể bắt đầu việc học của mình. Nhưng khi tôi cần tìm hiểu nhanh về một chủ đề, sách là nơi tôi yêu thích để bắt đầu. Ví dụ:nếu bạn đang tìm hiểu sâu về git, một cuốn sách có tên là Pro Git có thể là chính xác những gì bạn đang tìm kiếm.

Sách rất phù hợp để tìm hiểu sâu vì chúng toàn diện:Hầu hết các chủ đề cỡ trung bình đều được đề cập khá tốt trong một cuốn sách 200–400 trang. Cuối cùng, bạn có thể không phải là một chuyên gia, nhưng bạn sẽ có hiểu biết khá tốt và các nguyên tắc cơ bản vững chắc để phát triển. Điều đó sẽ hữu ích nếu bạn quyết định chuyển sang đọc mã nguồn hoặc thông số kỹ thuật.

Nhưng có thể bạn không muốn mua sách. Hoặc một cuốn sách về chủ đề của bạn thậm chí không tồn tại. Khi điều đó xảy ra, bạn có thể tìm ở đâu khác?

Tài liệu chính thức là một giải pháp thay thế tốt. Nếu bạn đang tìm hiểu sâu về một phần của khuôn khổ như Rails hoặc công nghệ web như OAuth, thì các tài liệu chính thức là một lựa chọn đặc biệt tốt.

Đối với các dự án và khuôn khổ, thứ có tên “(Các) Hướng dẫn X” là lựa chọn tốt nhất để bạn bắt đầu. Ví dụ:tôi thường giới thiệu Hướng dẫn về Rails cho các nhà phát triển Rails mới và Hướng dẫn về Elixir là một nơi tuyệt vời để học cách viết mã Elixir.

Nhưng trong khi hướng dẫn toàn diện hơn một bài đăng trên blog, chúng không hoàn toàn toàn diện. Thay vào đó, bạn có thể sử dụng hướng dẫn làm điểm khởi đầu cho tài liệu tham khảo, như RDoc.

Tài liệu tham khảo sẽ khó hiểu nếu bạn không có cách đặt tất cả các phương thức và lớp đó vào ngữ cảnh. Nó chỉ là một mớ hỗn độn của các chi tiết không có cấu trúc thực sự. Vì vậy, tôi thấy rằng tài liệu tham khảo hoạt động tốt nhất khi bạn ghép nối chúng với hướng dẫn hoặc sách.

Ví dụ:hầu như không có gì dạy bạn ActiveModel nhiều hơn việc đào sâu qua các tài liệu API ActiveModel. Nhưng hướng dẫn ActiveModel sẽ giúp bạn tổng hợp tất cả lại với nhau.

Tôi nói "hầu như không có gì", bởi vì có một thứ toàn diện hơn việc đọc tài liệu chính thức:Đọc mã nguồn. Nhưng đọc mã nguồn không giống như đọc một cuốn sách:nó cần có kinh nghiệm, thực hành và hướng dẫn. Vì vậy, mặc dù nó sẽ cung cấp cho bạn chi tiết nhất, nhưng đó không phải là nơi bạn nên đến đầu tiên.

Sau khi tìm hiểu kỹ tất cả tài liệu viết này, bạn sẽ có một số câu hỏi mở. Vì vậy, hãy hỏi họ! Tác giả của một thư viện thường sẽ có một mô hình tinh thần tốt hơn bất kỳ ai khác và có thể hướng dẫn quá trình suy nghĩ của họ để giúp bạn. Nhiều tác giả của các dự án và khuôn khổ nguồn mở tự cung cấp thông qua Slack hoặc IRC. Bạn thường có thể tìm thấy thông tin chi tiết trên các trang của dự án.

Nếu bạn không có quyền truy cập vào những người đó? Bạn vẫn có thể hỏi. Hỏi đồng nghiệp của bạn hoặc các nhà phát triển cấp cao hơn. Tôi ngạc nhiên về mức độ thường xuyên đặt một câu hỏi chưa được trả lời cho một người bạn sẽ khiến mọi thứ khác trở nên ổn thỏa.

Một khi bạn biết mình phải lặn sâu, có một vài nơi bạn có thể bắt đầu. Đây là thứ tự tôi thường làm theo:

  1. Một cuốn sách hoặc một hướng dẫn chính thức
  2. Tài liệu tham khảo chính thức (như RDoc) hoặc một thông số kỹ thuật / RFC
  3. Mã nguồn

Và tôi sẽ lấp đầy khoảng trống bằng cách đặt câu hỏi. Đây không phải là quá trình nhanh nhất nhưng là sự kết hợp tốt nhất giữa chiều rộng và chiều sâu mà tôi tìm thấy cho đến nay.

Bạn có thường xuyên lặn sâu không? Nếu vậy, tôi muốn biết những tài nguyên nào bạn thấy hữu ích nhất. Để lại bình luận và cho tôi biết!