Khi KHÔNG sử dụng khung [đóng]

Ngày nay, người ta có thể tìm thấy một khuôn khổ cho bất kỳ ngôn ngữ nào, để phù hợp với bất kỳ dự án nào. Hầu hết các khung hiện đại đều khá mạnh mẽ (nói chung), với từng giờ thử nghiệm, mã được đánh giá ngang hàng và khả năng mở rộng tuyệt vời.

Tuy nhiên, tôi nghĩ rằng có một nhược điểm của BẤT K framework khung nào trong đó các lập trình viên, với tư cách là một cộng đồng, có thể trở nên quá phụ thuộc vào các khung đã chọn của họ đến mức họ không còn hiểu được các hoạt động cơ bản, hoặc trong trường hợp các lập trình viên mới hơn, không bao giờ học các hoạt động cơ bản để bắt đầu với. Thật dễ dàng để trở nên chuyên biệt ở một mức độ mà bạn không còn là một "lập trình viên PHP" (ví dụ), mà là một "lập trình viên Drupal", để loại trừ bất cứ điều gì khác.

Ai quan tâm chứ? Chúng tôi có khuôn khổ! Chúng ta không cần phải biết cách "làm bằng tay"! Đúng?

Kết quả của việc mất các kỹ năng cơ bản này (đôi khi đến mức các lập trình viên không sử dụng các khung công tác được xem là "lỗi thời") là việc sử dụng một khung công tác không cần thiết hoặc phù hợp. Các tính năng của khung tạo điều kiện thuận lợi cho việc nhầm lẫn với những gì ngôn ngữ cơ sở có khả năng. Các nhà phát triển bắt đầu sử dụng các khung công tác để hoàn thành các nhiệm vụ cơ bản nhất, do đó, thứ từng được coi là một quy trình thô sơ bây giờ liên quan đến các thư viện lớn với các quirks, lỗi và phụ thuộc của riêng họ. Những gì đã từng được hoàn thành trong 20 dòng giờ được hoàn thành bằng cách bao gồm khung 20.000 dòng VÀ viết 20 dòng để sử dụng khung.

Ngược lại, người ta không muốn phát minh lại bánh xe. Nếu tôi đang viết mã để hoàn thành một số nhiệm vụ cơ bản, phổ biến, tôi có thể cảm thấy lãng phí thời gian khi biết rằng XYZ khung cung cấp tất cả các tính năng mà tôi đang theo đuổi, và nhiều hơn nữa. Phần "toàn bộ nhiều hơn" vẫn khiến tôi lo lắng, nhưng dường như nhiều người thậm chí không xem xét nó nữa.

Phải có một số liệu tốt để xác định khi nào thì phù hợp để sử dụng khung. Bạn coi ngưỡng là gì, làm thế nào để bạn quyết định khi nào nên sử dụng khung, hoặc khi nào không.

"Phải có một số liệu tốt để xác định khi nào thì phù hợp để sử dụng khung."

Không hẳn vậy. Nếu có các số liệu tốt để xác định sử dụng phù hợp bất kỳ công nghệ nào, bạn sẽ không thấy các cuộc chiến thần thánh, ngôn ngữ và phương pháp luận.

Các nhóm tôi đã làm việc cùng đều làm điều tương tự - đoán dự đoán về chi phí và lợi ích, chọn con đường hiệu quả nhất và hy vọng họ đúng. Đó không phải là khoa học khủng khiếp - một phần trực giác, ba phần kinh nghiệm, một phần nhạy cảm với tiếp thị, một phần xảo quyệt và năm phần xếp hạng ý kiến.

Khung chỉ là công cụ. Tôi không nghĩ đó là lỗi của khung nếu nó được sử dụng quá mức, thay vì của người lạm dụng nó. Câu nói cũ "nếu bạn có một cái búa, mọi thứ trông giống như một cái đinh" cho thấy cách suy nghĩ này đã tồn tại từ lâu trước cả máy tính.

Trở nên quá chuyên biệt thực sự có thể biến thành một vấn đề trong dài hạn - cho một nhà phát triển cũng như các loài sinh học. Để tồn tại lâu dài, người ta phải cân bằng cẩn thận nỗ lực phát triển kỹ năng của mình trong nhiều lĩnh vực.

Để trả lời câu hỏi cụ thể của bạn, tôi không nghĩ có một số liệu cho việc này. Tôi thích sử dụng một khung công tác khi nó đơn giản hóa việc giải quyết vấn đề. Nếu sử dụng khung giúp tôi giải quyết vấn đề với 2 dòng mã thay vì 20, rõ ràng tôi sẽ sử dụng nó. Nhưng ngay cả khi 20 dòng so với 20, tôi có thể quyết định sử dụng khung nếu nó mang lại cho tôi sự trừu tượng tốt hơn, gần với miền vấn đề hơn, giúp mã dễ hiểu và duy trì hơn.

Tôi nghĩ rằng các khung có thể được sử dụng quá mức trong một số bối cảnh, vâng. Một khung chỉ là một công cụ, vâng. Một khung cho phép bạn có được một cái gì đó chạy rất nhanh, và như vậy là một công cụ tạo mẫu tuyệt vời.

Ở đâu đó, khi ứng dụng của bạn đạt đến một mức độ phức tạp nào đó, những hạn chế vốn có trong một khung bắt đầu kìm hãm sự phát triển hơn nữa, dường như đối với tôi. Bí quyết là nhận ra khi bạn gặp phải điểm bùng phát như vậy, và sau đó quyết định bạn sẽ làm gì với nó.

Tôi có xu hướng làm việc nhiều nhất với các ứng dụng web và mặc dù tôi đang cố gắng nói chung, câu trả lời của tôi có thể không áp dụng cho lĩnh vực lập trình của bạn.

Tôi cũng sẽ sử dụng "khung" đồng nghĩa với "thư viện".

Trước khi thực hiện một khung, người ta phải xem xét một vài điều, đây là một vài ví dụ chung.

# 1. Khung sẽ tiết kiệm thời gian và công sức?

Câu trả lời cho câu hỏi này hầu như luôn luôn là có . Các khung có xu hướng được xây dựng để giải quyết các vấn đề cụ thể và giải quyết chúng rất tốt. Chẳng hạn, các khung như EntityFramework có thể giúp bạn tiết kiệm hoàn toàn khỏi việc viết mã SQL. Điều này có thể tuyệt vời nếu nhóm lập trình của bạn không thông thạo SQL.

Các khung được xây dựng để, a) thêm giao diện thân thiện với lập trình viên vào các thành phần phức tạp khác hoặc b) thêm sự trừu tượng cho các thành phần đã được biết đến (hoặc đã thiết lập).

Loại thứ hai (hoặc thậm chí cựu trong một số trường hợp) có thể thực sự nhận được trong cách phát triển. Điều này đặc biệt áp dụng khi bạn hoặc nhóm lập trình của bạn sẽ triển khai một khung mới, trong đó họ chưa từng làm việc trước đây.

Điều này có khả năng làm chậm quá trình phát triển của bạn, có khả năng gây tốn kém.

# 2 Quy mô của ứng dụng của bạn

Người ta nói rằng "bất cứ điều gì đáng làm là đáng làm quá" , nhưng thường thì không phải vậy. Có lẽ không có lý do chính đáng để thực hiện một khung siêu cỡ nếu quan điểm của ứng dụng của bạn là in "khoai tây" .

Khi bạn đang phát triển một ứng dụng (có thể là web, máy tính để bàn, thiết bị di động hoặc bất kỳ loại ứng dụng nào có thể hiểu được) dấu hiệu cảnh báo rằng khung của bạn có thể làm đầy ứng dụng của bạn. Một giai thoại hay sẽ là nếu bạn bao gồm jQuery, chỉ cần thêm một lớp "được tải" vào thẻ cơ thể của bạn khi tài liệu đã sẵn sàng. Làm điều đó chỉ với JavaScript gốc có thể khó hơn một chút , nhưng nó không làm hỏng ứng dụng của bạn.

Mặt khác, nếu một khung làm nhiều công việc bẩn thỉu ở bên trong (tức là khung cơ sở dữ liệu), thì có thể có khả năng thực hiện nó, ngay cả khi bạn chỉ "sử dụng một phần" khung. Một giai thoại hay là đừng cố xây dựng trình điều khiển ADO.NET hoặc MongoDB của riêng bạn, chỉ vì bạn không cần phải sử dụng toàn bộ thư viện.

Đôi khi các khung công tác đến nguồn mở (và với giấy phép 'làm bất cứ điều gì bạn muốn'). Điều này mở ra một khả năng mới trong đó một nhóm lập trình chỉ có thể chọn các phần của khung.

Điều này cuối cùng liên quan trở lại câu hỏi # 1 và # 3.

# 3 Tác động.

Đôi khi thực hiện một khung có thể tác động trực tiếp đến người dùng cuối. Điều này đặc biệt đúng đối với các ứng dụng web, vì các khung công tác phía máy khách lớn có thể ảnh hưởng tiêu cực đến trải nghiệm của người dùng cuối. Người dùng có máy chậm hơn có thể gặp phải sự cố kết xuất chậm, hiệu suất với javascript hoặc các sự cố tương tự do máy phụ. Người dùng có kết nối chậm có thể gặp thời gian tải chậm (ít nhất là ban đầu).

Ngay cả trong các loại ứng dụng khác, người dùng cuối có thể bị ảnh hưởng tiêu cực bởi các phụ thuộc ứng dụng của bạn. Các khung ít nhất luôn chiếm một số dung lượng đĩa và nếu bạn đang phát triển một ứng dụng di động (hoặc thậm chí là một ứng dụng trên máy tính để bàn) thì điều này có thể cần được xem xét.

Các khung công tác phía máy chủ (thậm chí cụ thể hơn trên web) rất có thể sẽ không ảnh hưởng đến người dùng cuối của bạn, nhưng nó sẽ ảnh hưởng đến cơ sở hạ tầng của bạn . Một số khung có phụ thuộc chính chúng có thể yêu cầu bạn khởi động lại máy chủ web của mình, chỉ là dịch vụ hoặc máy chủ hoàn toàn.

Một số khung cũng có thể rất nặng tài nguyên.

Điều này tất nhiên liên quan trở lại điểm 1 và # 2.

Tất cả chỉ là một "vòng tròn cân nhắc" lớn, và không có phương pháp khoa học thực sự nào để quyết định liệu bạn có nên thực hiện một khuôn khổ hay không.

Corbin March đã tóm tắt nó rất tốt:

Các nhóm tôi đã làm việc cùng đều làm điều tương tự - đoán dự đoán về chi phí và lợi ích, chọn con đường hiệu quả nhất và hy vọng họ đúng. Đó không phải là khoa học khủng khiếp - một phần trực giác, ba phần kinh nghiệm, một phần nhạy cảm với tiếp thị, một phần xảo quyệt và năm phần xếp hạng ý kiến.

Điều quan trọng không phải là tinh hoa . Khung là các công cụ có nghĩa là được sử dụng. Tôi biết những người thuộc cả hai thái cực; một mặt bạn có chàng trai làm cho cuộc sống rất khó khăn cho chính mình, mặt khác bạn có chàng trai xây dựng các ứng dụng chậm chạp, cồng kềnh.

Tất cả các khung công tác đều có các trường hợp sử dụng, đó chỉ là vấn đề triển khai chúng cho đúng mục đích.

Các nhà phát triển khác có biết khuôn khổ không?

Nếu tất cả các nhà phát triển biết khung X, thì đưa ra tất cả các lý do khác để sử dụng khung là khả thi, hãy thực hiện nó! Đối với tôi, sẽ không có ý nghĩa gì khi thực thi việc học một khung cụ thể khi phần lớn thời gian phát triển sẽ được dành để học các vấn đề phức tạp của khung.

Về tuyên bố của bạn về những lập trình viên mới hơn không biết những điều cơ bản, bạn sẽ từ bi hơn tôi rất nhiều! Vâng, đó là một sự xấu hổ, nhưng tôi sẽ dành thời gian của mình để lo lắng về sự bất lực của người khác? Nup (Dựa trên giả định rằng những thành viên mới này của cộng đồng sẽ không làm việc ngay với bạn.)

Tôi sẽ sử dụng khung nếu (và CHỈ nếu) các điều kiện sau đây đúng:

Khung dường như có thể được hỗ trợ trong một thời gian. Tôi đã từng mang chúng đến cuối đời với tôi và điều đó thật sự gây phiền nhiễu. Đặc biệt là khi bạn 9 tháng trong dự án của mình và chuyển đổi không thực sự là một lựa chọn nữa. Và nếu khung không còn được hỗ trợ nữa, thì hãy suy nghĩ ba lần trước khi bạn viết một cái gì đó mới bằng cách sử dụng khung đó. Không có vấn đề như thế nào bạn đã biết nó.

Dự án thực sự phù hợp với khuôn khổ. Là một ví dụ khá cũ, bạn đã thấy những điều mà MFC được tạo ra để làm chưa? Mọi người đã không kết thúc những điều kỳ lạ để làm cho nó hoạt động cho các loại ứng dụng mà nó không có ý nghĩa. Thông thường dành nhiều thời gian hơn để đánh bại MFC hơn là họ đã dành chỉ để viết ứng dụng mà họ muốn lên thẳng.

Nhóm dự án có khả năng làm việc trong khuôn khổ. Một số người không hoặc không thể dành thời gian để hiểu cách viết một ứng dụng trong một khung nhất định và thay vào đó họ viết mọi thứ theo cách họ thường làm, thay vì cách mà khung cần. Sự không phù hợp giữa mã và khung này thường khiến mọi người tốn rất nhiều thời gian và công sức.