Trong phần này, tôi nói về lý do tại sao đôi khi bạn nên tránh sử dụng các framework. Điều cần thiết là bạn biết khi nào nên sử dụng framework và khi nào nên tránh sử dụng framework. Đôi khi, sử dụng một công cụ quá nhiều cho công việc có thể tiêu tốn nhiều năng lượng hơn và cũng mang lại kết quả tồi tệ hơn. Hãy tưởng tượng sử dụng rìu chặt củi để gọt hoa quả. Mặc dù bạn có thể cố gắng và thậm chí đạt được kết quả cuối cùng, nhưng việc này sẽ khó khăn và tốn nhiều năng lượng hơn so với việc sử dụng một con dao thông thường (và bạn có thể không có gì ngoài hoa quả đã dập nát thay vì hoa quả đã được gọt hết vỏ). Chúng ta sẽ thảo luận về một số tình huống trong đó sử dụng framework không phải là một ý tưởng hay, sau đó tôi sẽ kể cho bạn nghe một ví dụ về một team đã thất bại trong việc triển khai ứng dụng do sử dụng framework.
Hóa ra, giống như mọi thứ khác trong phát triển phần mềm, bạn không nên áp dụng một framework trong mọi trường hợp. Bạn sẽ thấy các tình huống trong đó một framework không phù hợp— hoặc có thể một framework phù hợp nhưng không phải là Spring framework. Bạn nên cân nhắc không sử dụng framework trong trường hợp nào sau đây?
Bạn cần triển khai một chức năng cụ thể với dung lượng nhỏ nhất có thể (Ý tôi là bộ nhớ lưu trữ bị chiếm dụng bởi các file của ứng dụng).
Các yêu cầu bảo mật cụ thể buộc bạn chỉ triển khai custom code trong ứng dụng của mình mà không sử dụng bất kỳ open source framework nào.
Bạn sẽ phải thực hiện rất nhiều custom trên framework đến mức bạn sẽ viết nhiều code hơn nếu bạn hoàn toàn không sử dụng nó.
Bạn đã có một ứng dụng và bằng cách thay đổi nó để sử dụng một framewrork, bạn không nhận được bất kỳ lợi ích nào.
Bạn cần triển khai một chức năng cụ thể với dung lượng nhỏ nhất có thể.
Ở đây tôi đề cập đến các tình huống mà bạn cần làm cho ứng dụng của mình trở nên nhỏ gọn. Trong các hệ thống ngày nay, tôi nhận thấy ngày càng nhiều trường hợp services được phân phối trong các container. Bạn có thể đã nghe nói về các container, chẳng hạn như Docker, Kubernetes hoặc các thuật ngữ khác liên quan đến chủ đề này. Các container nói chung là một chủ đề nằm ngoài bài viết này, vì vậy hiện tại, điều duy nhất tôi cần bạn biết là khi bạn sử dụng kiểu triển khai như vậy, bạn muốn ứng dụng của mình càng nhỏ càng tốt. Một container giống như một hộp chứa ứng dụng của bạn. Một nguyên tắc quan trọng liên quan đến việc triển khai ứng dụng trong container là các container phải dễ dàng dùng một lần: chúng có thể bị hủy và tạo lại nhanh nhất có thể. Kích thước của ứng dụng rất quan trọng ở đây. Bạn có thể tiết kiệm thời gian từ quá trình khởi tạo ứng dụng bằng cách làm cho nó nhỏ hơn. Điều đó không có nghĩa là bạn sẽ không sử dụng các framework cho tất cả các ứng dụng được triển khai trong container. Nhưng đối với một số ứng dụng, thường cũng khá nhỏ, thì sẽ hợp lý hơn nếu cải thiện quá trình khởi tạo và làm cho dung lượng của chúng nhỏ hơn thay vì thêm dependencies vào các framework khác nhau. Trường hợp như vậy là một loại ứng dụng được gọi là server-less function. Các server-less function này là các ứng dụng nhỏ được triển khai trong các container. Bởi vì bạn không có quá nhiều quyền truy cập vào cách chúng được triển khai, nên có vẻ như chúng thực thi mà không cần server (do đó có tên như vậy). Các ứng dụng này cần phải nhỏ và đó là lý do tại sao, đối với trường hợp ứng dụng cụ thể này, bạn sẽ muốn tránh thêm framework càng nhiều càng tốt. Do kích thước của nó, nên cũng có thể bạn sẽ không cần framework.
Security requirements chỉ có thể triển khai custom code.
Tôi đã nói ở điểm thứ hai rằng trong các tình huống cụ thể, ứng dụng không thể sử dụng framework vì yêu cầu bảo mật. Case này thường xảy ra với các ứng dụng trong lĩnh vực ngân hàng, quốc phòng hoặc tổ chức chính phủ. Một lần nữa, điều đó không có nghĩa là tất cả các ứng dụng được sử dụng trong các tổ chức chính phủ đều bị cấm sử dụng framework, nhưng đối với một số ứng dụng, các hạn chế sẽ được áp dụng. Bạn có thể tự hỏi tại sao? Giả sử một open source framewrok như Spring được sử dụng. Nếu ai đó tìm thấy một lỗ hổng cụ thể, lỗ hổng đó sẽ được biết đến và hacker có thể sử dụng kiến thức này để khai thác lỗ hổng đó. Đôi khi, các bên liên quan của những ứng dụng như vậy muốn đảm bảo rằng khả năng ai đó xâm nhập vào hệ thống của họ càng gần bằng 0 càng tốt. Điều này thậm chí có thể dẫn đến việc xây dựng lại một chức năng thay vì sử dụng nó từ nguồn của bên thứ ba. (Gần đây nhất bạn có thể biết đến là bug lớn của log4j đã gây nên 1 cơn sốt cho các nhà phát hành ứng dụng, các hacker đã khai thác bug này ngay sau đó nhưng cũng rất nhanh log4j cũng đã update và fix bug này).
Note: Cũng có ý kiến cho rằng sẽ an toàn hơn khi sử dụng open source framework vì nếu tồn tại lỗ hổng bảo mật, ai đó có thể sẽ phát hiện ra lỗ hổng đó. Nếu bạn đầu tư đủ thời gian và tiền bạc, bạn có thể tự mình đạt được điều này. Nói chung, tất nhiên, sử dụng một framework sẽ rẻ hơn. Và nếu bạn không muốn quá thận trọng, thì việc sử dụng một framework sẽ hợp lý hơn. Nhưng trong một số dự án, các bên liên quan thực sự muốn đảm bảo rằng không có thông tin nào bị công khai.
Các custom quá nhiều.
Một trường hợp khác (điểm 3) mà bạn có thể muốn tránh sử dụng một framwork là khi bạn phải custom các components của nó nhiều đến mức cuối cùng bạn phải viết nhiều code hơn so với khi nó chưa được sử dụng. Một framework cung cấp cho bạn các phần mà bạn kết hợp với business logic code của mình để tải ứng dụng. Các components này do framework cung cấp không hoàn toàn phù hợp và bạn cần custom chúng theo những cách khác nhau. Việc custom các components của framewrok và style mà chúng lắp ráp là hoàn toàn bình thường so với việc bạn phát triển chức năng từ đầu. Nếu bạn thấy mình trong tình huống như vậy, có thể bạn đã chọn sai framewrok (tìm kiếm các giải pháp thay thế) hoặc bạn hoàn toàn không nên sử dụng một framework nào đó.
Bạn sẽ không được hưởng lợi từ việc chuyển sang một framework.
Ở điểm cuối cùng, tôi đã đề cập rằng một lỗi tiềm ẩn có thể là cố gắng sử dụng một framework để thay thế thứ gì đó đã tồn tại và đang hoạt động trong một ứng dụng. Đôi khi chúng ta muốn thay thế một kiến trúc hiện có bằng một cái gì đó mới. Một framework mới xuất hiện, nó phổ biến và mọi người đều sử dụng nó, vậy tại sao chúng ta không thay đổi ứng dụng của mình để sử dụng framework này? Bạn có thể, nhưng bạn cần phân tích kỹ những gì bạn muốn đạt được bằng cách thay đổi thứ gì đó hiệu quả. Trong một số trường hợp, có thể hữu ích khi thay đổi ứng dụng của bạn và làm cho nó dựa trên một framework cụ thể. Miễn là thay đổi này mang lại lợi ích, hãy làm điều đó! Một lý do có thể là bạn muốn làm cho ứng dụng dễ bảo trì hơn, hoạt động hiệu quả hơn hoặc an toàn hơn. Nhưng nếu sự thay đổi này không mang lại lợi ích cho bạn, và đôi khi còn mang lại sự không chắc chắn, thì cuối cùng, bạn có thể phát hiện ra rằng mình đã đầu tư thời gian và tiền bạc cho một kết quả tồi tệ hơn. Để tôi kể cho bạn nghe một câu chuyện từ kinh nghiệm của chính tôi.
Sử dụng các framework không phải lúc nào cũng là lựa chọn tốt nhất và tôi đã phải học điều đó một cách khó khăn. Nhiều năm trước, chúng tôi đang làm việc trên phần backend của một ứng dụng web. Thời gian ảnh hưởng đến nhiều thứ, bao gồm cả kiến trúc phần mềm. Ứng dụng đang sử dụng JDBC để kết nối trực tiếp với cơ sở dữ liệu Oracle. Code này khá xấu. Ở mọi nơi mà ứng dụng cần để thực hiện một truy vấn trên cơ sở dữ liệu, nó sẽ mở một câu lệnh và sau đó gửi một truy vấn đôi khi được viết trên nhiều hàng. Bạn có thể đủ trẻ để không gặp phải việc sử dụng trực tiếp JDBC trong các ứng dụng, nhưng tin tôi đi, đó là một đoạn code dài và xấu. Vào thời điểm đó, một số framework sử dụng phương pháp khác để làm việc với cơ sở dữ liệu ngày càng trở nên phổ biến. Tôi nhớ lần đầu tiên tôi gặp Hibernate. Đây là một framework ORM, cho phép bạn xử lý các bảng và mối quan hệ của chúng trong cơ sở dữ liệu dưới dạng đối tượng và mối quan hệ giữa các đối tượng. Khi được sử dụng đúng cách, nó cho phép bạn viết ít code hơn và có nhiều chức năng trực quan hơn. Khi bị lạm dụng, nó có thể làm chậm ứng dụng của bạn, làm cho code kém trực quan hơn và thậm chí gây ra lỗi. Ứng dụng chúng tôi đang phát triển cần một sự thay đổi. Chúng tôi biết mình có thể cải thiện mã JDBC xấu xí đó. Theo suy nghĩ của tôi, ít nhất chúng ta có thể giảm thiểu số lượng dòng. Sự thay đổi này sẽ mang lại lợi ích to lớn cho khả năng bảo trì. Cùng với các nhà phát triển khác, chúng tôi đã đề xuất sử dụng một công cụ do Spring cung cấp có tên là JdbcTemplate. Nhưng những người khác đã thúc đẩy mạnh mẽ quyết định sử dụng Hibernate. Nó khá phổ biến, vậy tại sao không sử dụng nó? Tôi có thể thấy việc thay đổi code đó thành một phương pháp hoàn toàn mới sẽ là một thách thức. Hơn nữa, tôi không thấy lợi ích gì. Sự thay đổi cũng ngụ ý nguy cơ phát sinh lỗi lớn hơn. May mắn thay, sự thay đổi bắt đầu với một bằng chứng về khái niệm. Sau một vài tháng, với rất nhiều nỗ lực và căng thẳng, nhóm đã quyết định nghỉ việc. Sau khi phân tích các tùy chọn của mình, chúng tôi đã hoàn thành việc triển khai bằng cách sử dụng JdbcTemplate. Chúng tôi đã cố gắng viết code sạch hơn bằng cách loại bỏ một số lượng lớn các dòng code và chúng tôi không cần giới thiệu bất kỳ framwork mới nào cho thay đổi này.
Nguồn: Spring start here.