Lập trình không cần đến Framework

Gần đây tôi cơ hội thử sức trên khá thú vị đủ nhỏ để tôi thỏa mái thử nghiệm những điểu mới mẻ , nhưng cũng đủ lớn để một dự án nhỏ nhưng khá thú vị tôi được thoải mái thử nghiệm những điều mới, mặt khác, cũng đủ lớn để đánh giá các ý tưởng của tôi và xem chúng có quy mô như thế nào. Một trong những thí nghiệm mà tôi đã thực hiện trong suốt dự án là lập trình mà không sử dụng bất kỳ framework nào. Điều đó có mất nhiều thời gian không? Và nó khó đến mức nào?

Cách tiếp cận

Rõ ràng, những ý tưởng được trình bày ở đây không có gì mới và khá nhiều người cho rằng đó là cách đúng để làm phần mềm. Vì vậy, nếu bạn đã quen thuộc với Nguyên lý Đảo Ngược Dependency hoặc sử dụng nhiều thư viện nhỏ thay vì một framework lớn, thì phần này không giúp gì được nhiều.

Như đã nói ở trên, tôi đã quyết định dựa vào Nguyên lý Đảo Ngược Dependency, do đó bất cứ code “infrastructure” nào tôi tạo ra trong quá trình thì đó là code được điều chỉnh theo nhu cầu của tôi chứ không phải những thứ có trong framework hoặc thư viện.

Để cụ thể hơn, đối với bất kỳ loại code “bình thường” nào được cung cấp bởi một framework, tôi sẽ bắt đầu với một giao diện mô tả các nhu cầu hiện tại của mình.  Một khi bản thiết kế giao diện đã hoàn thành, tôi tiến hành thực hiện nó trong layer infrastructure của ứng dụng. Về cơ bản, tôi sử dụng các vòng lặp để tạo một số loại “API đẹp như mơ” cho một vấn đề nhất định và sau đó sử dụng nó.

Vì tôi có một khoảng thời gian khá khó khăn cho dự án, nên tôi đã xem các giao diện này như một sơ đồ dự phòng trong trường hợp gặp các vấn đề. Nếu có bất cứ lỗi nào xảy ra, tôi ít nhất có thể sử dụng những chúng để khắc phục điều đó.

Chừng nào không có vấn đề gì với thời gian biểu hoặc các kỹ năng lập trình low-level, tôi sẽ quyết định gắn bó với việc sử dụng các thư viện nhỏ (tương đối) và tự viết code cho một số mảng quan trọng.

Ví dụ: REST Endpoints

Tôi đoán rằng code của một REST endpoint là ví dụ khá tốt về các chức năng thường được cung cấp bởi framework như Spring, Ratpack hoặc tương tự. Tôi cũng nghĩ đó là một ví dụ phù hợp cho bài này, vì các phương pháp của việc xác định endpoints được cho là một điều quan trọng khi chọn một framework.

“API mong muốn” trong trường hợp này khá đơn giản. Nó đòi hỏi layer infrastructure để thực hiện hai giao diện và xác định hai loại tên giả khác (trong Kotlin):

Rõ ràng, tôi đã không viết tất cả những điều này cùng một lúc. Tôi lặp lại feature bằng feature, method bằng method. Nếu tôi nhớ chính xác, endpoint đầu tiên của tôi chỉ yêu cầu hỗ trợ “post” và request body.

Trong quá trình khởi động ứng dụng, một ví dụ của quá trình Router hoạt động được truyền vào một method có trách nhiệm khởi tạo tất cả các router trong ứng dụng:

Ý kiến của bạn có thể khác ở bước này, nhưng tôi thực sự nghĩ rằng đây là phần tốt nhất của API. Điều quan trọng nhất ở đây là nó thực hiện mọi thứ tôi cần cho các trường hợp sử dụng cụ thể của ứng dụng này.

Bây giờ, tôi không thực sự muốn tiết lộ toàn bộ việc thực hiện ở đây vì một vài lý do tích cực, nhưng tôi muốn bạn biết rằng chuyện đó đơn giản hơn nhiều người nghĩ.

Ví dụ: một cơ chế đơn giản để xử lý các tham số đường dẫn sử dụng API Servlet là vấn đề tách String và lặp các phần URI:

Một ví dụ khác liên quan đến việc exposing các REST endpoint từ ứng dụng của bạn là bắt đầu nhúng một web server. Một số người rất vui vì các framework như Spring Boot có chức năng này:

Lời kết

Tôi vui khi thử nghiệm nhỏ của tôi đã thành công và ứng dụng được giao đúng thời hạn mà không sử dụng bất kỳ framework nào. Và tôi không hề cảm thấy mình thực hiện chậm hơn nhiều so với khi sử dụng một số framework phổ biến.

Gác những chuyện vui sang một bên, tôi không chắc liệu có bất kỳ bài học hay nào được rút ra từ cuộc thử nghiệm này. Một mặt tôi vẫn tự hỏi tại sao chúng tôi, các lập trình viên lại mù quáng tuân theo khuôn khổ của framework khi không có nhiều lợi ích từ nó (nếu có).

Techtalk via Tidyjava