it-swarm-vi.com

Khi KHÔNG sử dụng khung

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 nỗi 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 đến 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 thích hợp. tính năng 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 ngay cả 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 yêu cầu, 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 như mình đang lãng phí thời gian khi biết rằng khung XYZ 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 "nhiều hơn nữa" 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.

38
Chris

"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 việc 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 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.

27
Corbin March

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 lối 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.

14
Péter Török

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ó.

6
leed25d

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 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 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 trừu tượng cho các thành phần đã biết (hoặc đã thiết lập).

Cái sau (hoặc thậm chí cái trước trong một số trường hợp) thực sự có thể cản trở của sự phát triển. Điều này áp dụng đặc biệt 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 đều đá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 nào để triển khai một khung siêu cỡ nếu mục đích của ứng dụng của bạn là in "củ 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 có thể hiểu được nào khác) - nếu bạn cảm thấy rằng quy mô của khung của bạn "lùn" việc triển khai ứng dụng (có thể trong tương lai) của bạn, thì đây có thể là một vấn đề lớn 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 nguyên gốc có thể là một 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 rất nhiều công việc bẩn trên bên trong (tức là khung cơ sở dữ liệu), sau đó có thể khả thi để thực hiện nó, ngay cả khi bạn chỉ "một phần" sử dụng khung. Một giai thoại hay sẽ là không cố gắng 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 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, việc triển khai một khung có thể tác động trực tiếp 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ố không gian đĩ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ì có thể cần phải lấy vào 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 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ể là 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 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 nữa là không phải là người ưu tú . 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ó trường hợp sử dụng, đó chỉ là vấn đề triển khai chúng cho đúng mục đích.

6
die maus

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

Nếu tất cả các nhà phát triển biết khung X, sau đó đư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.)

4
J.K.

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

Khung này dường như sẽ đượ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ì theo 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.

4
Michael Kohne