Tại sao tôi cần phải sử dụng một khung phổ biến?

Question

Tôi đã là một nhà phát triển PHP trong nhiều năm nay, với nhiều công cụ theo vành đai của tôi; các công cụ mà tôi đã tự phát triển hoặc các giải pháp sử dụng miễn phí mà tôi đã học được để tin tưởng.

Gần đây tôi đã xem CodeIgniter và phát hiện ra rằng họ có nhiều lớp và trợ giúp để phát triển, nhưng không thấy gì trong các ví dụ mà tôi không thể làm dễ dàng bằng các công cụ của riêng mình. Những thứ đơn giản như trừu tượng DB, người trợ giúp Email, v.v. Có một số mã thú vị liên quan đến tuyến đường - ánh xạ url tới bộ điều khiển phù hợp; nhưng thậm chí không khó để tự viết mã nếu bạn đã từng viết một ứng dụng web kiểu MVC với các url đẹp.

Ngay cả sau khi xem xét một số khung công tác phổ biến khác, tôi vẫn không thấy điều gì sẽ là rằng nhiều người tiết kiệm thời gian. Thậm chí nhìn vào các diễn đàn, tôi thấy mọi người đang gặp khó khăn để có được những công cụ để làm việc cho họ. Tôi hiểu làm thế nào họ sẽ hữu ích hơn cho các nhà phát triển cơ sở, vì các kỹ năng thiết kế toàn bộ hệ thống mất một lúc để hiểu và đánh giá đầy đủ.

Tuy nhiên, tôi thường được thông báo rằng tôi nên sử dụng khung giới thiệu để sản xuất các giải pháp của mình, nhưng tôi vẫn không thuyết phục. Lợi ích thực sự của một người như tôi là gì? Tôi chỉ là người ưu tú, hay đây là một ý kiến ​​chung?

Chỉnh sửa: Nhìn vào một số câu trả lời ở đây, tôi có nên xem xét việc đóng gói bộ công cụ của mình làm khung công tác rất riêng của mình, viết một số tài liệu và hướng dẫn đăng không? Nếu tôi do dự để tiếp nhận các khuôn khổ của người khác, sẽ mở nó ra và nhận được nhiều hơn vào nó giúp cải thiện kỹ năng/công cụ của riêng tôi?

Answer 1

Khung có một số lợi thế:

• Bạn không cần phải viết tất cả mọi thứ. Trong trường hợp của bạn, điều này là ít giúp đỡ bởi vì bạn có khuôn khổ của riêng bạn mà bạn đã tích lũy qua nhiều năm.

• Khung cung cấp các cách thức chuẩn hóa và thử nghiệm để thực hiện mọi việc. Càng nhiều người dùng có một khung công tác nhất định, các trường hợp cạnh hơn đã gặp phải và được mã hóa. Mã của riêng bạn có thể, hoặc có thể không, được chiến đấu cứng theo cùng một cách.

• Những người khác có thể được tuyển dụng vào một dự án có khung tiêu chuẩn và có quyền truy cập vào tài liệu, ví dụ và kinh nghiệm với khuôn khổ đó. Các đoạn trích của riêng bạn có thể hoặc có thể không được viết đầy đủ hoặc có các ví dụ về sử dụng ... nhưng không có nhiều cơ hội mà những người khác cảm thấy thoải mái với họ ban đầu.

EDIT:

Liên quan đến ý tưởng của bạn bao bì lên khuôn khổ của riêng mình, vì lợi ích của làm sạch nó lên đối với công chúng có thể lớn hơn lợi ích của việc người khác sử dụng nó.

Lý do rất đơn giản: bạn sẽ phải đánh giá lại các giả định của bạn về từng thành phần, cách chúng khớp với nhau và cách hiểu rõ từng phần. Khi bạn xuất bản khung công tác của mình, thành công của bạn sẽ phụ thuộc rất nhiều vào việc dễ dàng chuẩn bị và hoạt động như thế nào.

Chiến thắng lớn với ít nỗ lực là điều cần thiết để nhận con nuôi (những chiến thắng đó sẽ khuyến khích mọi người nghiên cứu kỹ hơn về khuôn khổ). Ruby on Rails trong một ví dụ về một khung công tác mang lại những thắng lợi lớn như vậy với ít nỗ lực, và sau đó có các lớp ẩn của các tính năng mà có thể đã choáng ngợp một người nào đó vừa mới bắt đầu. (Câu hỏi về chất lượng của các ứng dụng RoR không phải là vấn đề, vấn đề là tốc độ chấp nhận).

Sau khi mọi người áp dụng một khuôn khổ, đó là về tính dễ sử dụng liên tục. Các chi tiết nhỏ như các mẫu sử dụng tham số nhất quán tạo nên tất cả sự khác biệt ở đây. Nếu một lớp có nhiều tham số trên mọi phương thức, trong khi một lớp khác có các giá trị được mong đợi sẽ được gọi trước khi gọi các phương thức, bạn sẽ mất người dùng vì họ không thể nhận được "cảm giác" cho những gì được mong đợi trong một trường hợp cụ thể mà không phải dùng đến các tài liệu.

Nếu cả hai vấn đề dễ dàng áp dụng và dễ sống đều được giải quyết đúng cách, bạn chỉ phải may mắn khi mọi người chấp nhận khuôn khổ của bạn. Nếu những vấn đề đó không được giải quyết đúng cách, ngay cả một mối quan tâm ban đầu trong khuôn khổ sẽ mất dần một cách nhanh chóng. Lý do là có nhiều khung công tác: bạn sẽ cần phải nổi bật để đạt được lợi thế khi có người khác sử dụng bộ công cụ của bạn (vì chúng đúng là cảnh giác với khuôn khổ của bạn như bạn là người khác).

Answer 2

Bạn có thể có một điểm .... tuy nhiên tôi sẽ không đánh giá thấp sức mạnh của nhiều người, như là một ví dụ phpBB là như xa như tôi đang quan tâm giải pháp bb để sử dụng. Tại sao? Bởi vì có rất nhiều, hàng ngàn bài viết trên bảng hỗ trợ của họ và nhiều người sử dụng nó là những người am hiểu và có thể giúp mọi người giải quyết vấn đề.

Do đó, lý do duy nhất trong trường hợp của bạn sử dụng khung phổ biến là nhiều người khác sử dụng khung này, báo cáo lỗi chống lại, sửa lỗi và hỗ trợ nó. Sẽ rất khó để có được mức độ phù hợp trên các thư viện của riêng bạn.

Answer 3

Một điều mà bạn sẽ bỏ lỡ là tất cả Xác thực đi vào một khung phổ biến.

Các thường trình của bạn đơn giản là không có sự phơi nhiễm giống như các thư viện phổ biến có.

Answer 4

Tôi nghĩ lý do chính là khi bạn sử dụng một khung công tác chung, có rất nhiều người ngay lập tức quen thuộc với sản phẩm của bạn.

Ngoài ra, tôi nghĩ điều quan trọng nhất là bất kỳ công cụ nào bạn sử dụng đều thực sự hoàn thành công việc. Nếu điều đó xảy ra là quen thuộc với người khác, thì đó là tiền thưởng.

Answer 5

Mã khung có thể được kiểm tra kỹ lưỡng và tương đối không có lỗi. Bằng cách sử dụng nó, bạn tiết kiệm cho mình thời gian thử nghiệm/duy trì mã của riêng bạn để làm điều tương tự.

Và bất kỳ thời điểm nào được lưu đều tốt. Laziness trả tiền trong lập trình.

Answer 6

Tôi đồng ý bạn nên sử dụng khung tùy chỉnh của riêng mình. Không chỉ dễ dàng hơn cho bạn để hiểu, nhưng nó cung cấp tối ưu trong công việc bảo mật!

Answer 7

Ba lý do tôi có thể nghĩ đến ngay lập tức:

• Một khung nổi tiếng sẽ quen thuộc với các nhà phát triển khác, những người có thể phải làm việc trên dự án của bạn
• Một khung nổi tiếng sẽ có nguồn như sách , các bảng thảo luận và các chuyên gia khác có thể được sử dụng để tìm hiểu thêm thông tin
• Các nhà quản lý thường sẽ có triết lý "không sáng tạo lại bánh xe". Trên thực tế, các giải pháp hiện có có thể giải quyết được cùng một vấn đề mà bạn muốn khám phá nếu bạn tạo ra giải pháp của riêng mình.

Tất cả điều đó cho biết, vẫn có thể là nơi dành cho các giải pháp của riêng bạn. Chúng tôi sẽ không có nhiều khung công tác (hoặc ngôn ngữ kịch bản) để lựa chọn nếu không có ai bắt đầu một cái gì đó mới.

Answer 8

Như bạn có thể biết: "thời gian là tiền". Vì vậy, bằng cách sử dụng một khung phổ biến với rất nhiều người trợ giúp, rất nhiều ví dụ mã trên web và một cộng đồng lớn bạn làm nhiều hơn trong thời gian ít hơn. Đôi khi nó nếu ok để sử dụng khuôn khổ bởi vì bạn trở nên hiệu quả hơn, nhưng trong một số dự án tiên tiến và khó khăn nó có thể xảy ra để khuôn khổ ở lại theo cách của bạn và bạn phải tìm cách giải quyết. Các tính năng chính của chúng tôi là gì?

Tôi nghĩ rằng không có câu trả lời dứt khoát nào. Bạn nên cân bằng những thuận và chống và đưa ra quyết định đúng cho dự án của bạn.

Thông thường, tôi áp dụng các khung phổ biến rất nhanh nhưng không phải trong các phần quan trọng của dự án và trong thời gian tôi mở rộng việc sử dụng chúng.

Answer 9

Tôi nghĩ rằng nếu bạn không thấy cần phải sử dụng khung thì không.

Lý do tôi sử dụng khung làm ví dụ Django cho python hoặc Rails cho Ruby hoặc Webforms và MVC cho ASP.net là vì chúng giúp bạn viết ứng dụng dễ dàng và nhanh hơn. Trong trường hợp của Ruby và Python không sử dụng một khuôn khổ cho tôi sẽ làm cho tôi phát điên.

Nếu bạn có thứ gì đó hoạt động tốt và không thấy cần phải sử dụng một khung, tôi sẽ nói với những gì bạn cảm thấy là tốt nhất. Nhưng, tôi vẫn sẽ cập nhật các khung công tác.

Answer 10

Điều cơ bản của bạn là khung làm việc của riêng bạn. Vì vậy, nó không phải là một tiết kiệm thời gian CHO BẠN, bởi vì bạn đã dành thời gian để phát triển khuôn khổ. Nếu bạn không có điều đó để xây dựng từ, nó chắc chắn sẽ dễ dàng hơn và nhanh hơn để sử dụng một khuôn khổ hiện có hơn để cuộn của riêng bạn. Bạn cần xem xét liệu khung của bạn có tốt hơn các tùy chọn khác không và liệu sự quen thuộc của bạn với mã của bạn có lớn hơn khi nhìn vào nó hay không và những người khác sử dụng nó theo nhiều cách khác nhau khả năng của bất kỳ vấn đề được tìm thấy và sửa chữa là cao hơn nhiều.

Ngoài ra, nếu khuôn khổ của bạn như vậy là tốt hơn nhiều so với tất cả mọi người khác không, bạn có thể xem xét mở của bạn lên đến cộng đồng;)

Answer 11

Bất kỳ nhà phát triển có kinh nghiệm có thể xây dựng một khuôn khổ - phần thử thách là thuyết phục người khác rằng nó có giá trị sử dụng. Bạn sẽ cần phải tạo tài liệu và hướng dẫn cho nó cho những người có kế hoạch sử dụng hoặc duy trì nó. Bạn có thể sẽ cần phải tạo một trang demo để chứng minh rằng nó hữu ích và thực sự hoạt động như nó được cho là.

Điều đó một mình có thể là một khoản đầu tư đáng kể, không bao gồm các lỗi có thể xuất hiện ở giữa. Khi tất cả của nó nói rằng nó được thực hiện, nó có thể là giá trị dành thời gian học một khuôn khổ khác thay vì làm của riêng bạn.

Bạn đã đề cập đến CodeIgniter - Cá nhân tôi cảm thấy như đó là một khuôn khổ đẹp - nó không nhận được nhiều cột mốc hơn thế nữa.

Answer 12

Tôi nghĩ rằng chúng hữu ích hơn nếu bạn bắt đầu từ đầu và không có thời gian để viết của riêng bạn. Nếu bạn đã có một codebase bạn đã phát triển qua nhiều năm, chúng có thể kém hữu ích hơn nhiều, nhưng nó vẫn có thể hữu ích để xem và xem chúng đã làm gì.Ví dụ, tôi chắc chắn các cửa hàng phát triển trò chơi lớn không sử dụng các công cụ, công cụ và khung công cụ của bên thứ ba, không phải vì chúng không đủ, nhưng chúng đã tự xây dựng từ thập niên 80 hay bất kỳ thứ gì.

Ngoài ra, nếu bạn đang sử dụng thành phần không có giá, không có cách nào vượt quá nó trong khu vực cụ thể của nó. Nếu bạn cần trở thành người dẫn đầu thị trường trong một chiều hướng cụ thể, bạn nên xây dựng giải pháp của riêng mình trong thứ nguyên đó, để bạn có thể dẫn đầu. Nếu bạn không cần khả năng này, sử dụng một thành phần của bên thứ ba tốt như bạn có thể là một giải pháp tốt miễn là nó là một quá trình chuyển đổi dễ dàng. Thời gian để đào tạo trong công cụ mới và sống với idiosyncrasies của nó có thể hoặc có thể không có giá trị nó mặc dù.

Điều khác cần xem xét là nếu bạn có thể xây dựng một cái gì đó, bạn thực sự hiểu nó. Nếu không, bạn không. Bây giờ, bạn không cần phải hiểu đầy đủ các công cụ để sử dụng chúng, miễn là chúng "chỉ hoạt động", nhưng tất cả chúng ta đều biết cách đó ... :)

Answer 13

Có nhiều ý kiến ​​ở đây là lợi thế của việc sử dụng một khuôn khổ, và chắc chắn tôi nghĩ rằng trong một nhiều trường hợp tốt, họ là hoàn toàn chính xác.

HOWEVER

Tất cả các khuôn mặt đều có nhược điểm là chúng có miền có thể được lắp vào chúng. Nếu vấn đề của bạn nằm trong phạm vi của miền thì việc sử dụng khung công tác không phải là một vấn đề, và phần lớn thời gian nó rõ ràng là dễ dàng nếu vấn đề của bạn nằm ngoài miền để bạn không suy nghĩ. Các vấn đề nảy sinh khi bạn cố gắng đưa một vấn đề vào một khung công tác mà nó không hoàn toàn phù hợp hoặc có một số tính năng phi tiêu chuẩn bất thường - trong trường hợp này bạn hoàn thành 90% mã thực sự nhanh chóng sau đó dành tất cả thời gian lưu tìm ra cách uốn cong hoặc mở rộng khuôn khổ để nó có thể thực hiện một số yêu cầu tối nghĩa. Bởi vì trong trường hợp này giải pháp/mở rộng của bạn phải cắm vào khung, nó thường có thể khó khăn hơn để viết mã hơn nếu bạn muốn sử dụng nó một cách độc lập.

Trong trường hợp sai, điều này thực sự có thể là thảm họa. Ví dụ, nếu một khách hàng yêu cầu một dự án mà bạn tin rằng sẽ phù hợp với một giải pháp khung và bạn trích dẫn cho phù hợp, sau khi hoàn thành 90% bạn tìm thấy gotcha thì bạn có thể thực sự lên lạch, đặc biệt nếu đó là một số tính năng mà khách hàng khăng khăng khi (và nó luôn luôn là). Những vấn đề này có xu hướng phát sinh bởi vì nó không phải lúc nào cũng rõ ràng từ từ đi nơi gotchas có thể nói dối, đặc biệt nếu bạn đang sử dụng một khuôn khổ bạn ít quen thuộc hơn (và bạn phải theo thời gian).

Đây thực sự là vấn đề tương tự như phát sinh khi triển khai bất kỳ phần mềm của bên thứ ba nào trong một dự án. Bản thân tôi không có kinh nghiệm về việc sử dụng các khung công tác hoặc tương tự, nhưng với lựa chọn tôi sẽ luôn luôn đi kèm với một trình bao bọc nhẹ nhất, mỏng nhất, tôi có thể tìm thấy những gì tôi cần. Bằng cách đó tôi có được những ưu điểm, trong khi biết rằng nếu các vấn đề phát sinh (và chúng thường ít có khả năng với một trình bao bọc mỏng hơn) thì việc tìm ra cách làm việc xung quanh chúng có thể đơn giản hơn việc học một cơ sở mã mở rộng tới điểm nơi tôi có thể sửa đổi nó một cách an toàn.

Answer 14

Đây là một lý do khác không để tạo khuôn khổ của riêng bạn. Linus' Law - "Với đủ nhãn cầu, tất cả các lỗi đều cạn". Nói cách khác, càng có nhiều người sử dụng một khuôn khổ nhất định thì càng có nhiều khả năng và không có lỗi.

Bạn đã xem có bao nhiêu khung công tác web dành cho Java? Quay trở lại trong ngày, nó đã được thời trang cho bất kỳ một nửa nhà phát triển/kiến ​​trúc sư phong nha để viết khuôn khổ web tùy chỉnh của riêng họ. Và vào cuối ngày, 95% trong số họ trông giống như một triển khai tùy chỉnh của Struts (khung công tác web Java phổ biến nhất vào thời điểm đó). Vì vậy, về cơ bản họ đã tạo ra một bản sao Struts là: 1) sở hữu độc quyền; và 2) không được ghi chép và kiểm tra kỹ lưỡng.

Hãy đối mặt với nó - viết khung khách hàng của riêng chúng ta là thú vị, nhưng điều gì sẽ xảy ra tiếp theo? Nó trở thành một gánh nặng bảo trì để theo kịp với khuôn khổ chính mình (hoặc linh hồn nghèo người thay thế bạn). Và duy trì phần mềm là nhiều, tốn kém hơn nhiều, đặc biệt là khi nói đến khung tùy chỉnh. Là công ty trong kinh doanh để giải quyết vấn đề miền hoặc trong kinh doanh của việc duy trì khuôn khổ?

Tôi quên người đã nói điều đó, nhưng tôi đã từng nghe một câu nói tuyệt vời - "Quy tắc đầu tiên để tạo khung của riêng bạn là: không". Người khác có thể đã trải qua nỗ lực làm như vậy và có thể đã thực hiện cùng một công việc bạn đã làm. Tiết kiệm thời gian, công sức và thử nghiệm.

Answer 15

Tôi sẽ chống lại hạt ở đây, và nói rằng, bạn nên sử dụng khung tùy chỉnh của riêng bạn, Nếu phần mềm bạn đang xây dựng là cốt lõi của doanh nghiệp của bạn. Như Joel sẽ nói, "Find the dependencies - and eliminate them". Nếu bạn chỉ là đưa lên một trang web nhỏ cho công ty của bạn, và bạn kinh doanh không phải là duy trì các trang web, sau đó đi trước và sử dụng một khuôn khổ. Nhưng khi trang web đó là doanh nghiệp của bạn, thì bạn không nên phụ thuộc vào một khuôn khổ từ người khác để cho phép bạn hoàn thành công việc.

Answer 16

Bạn có thể giải quyết các vấn đề bạn được đưa ra với mã của bạn nhanh hơn và đáng tin cậy hơn khung công khai không?

Nếu có, hãy tiếp tục sử dụng của riêng bạn.

Nếu không, hãy tìm khuôn khổ thực hiện công việc tốt hơn và chạy với nó cho dự án đó.

Tất cả đều đi xuống mà codebase được công việc làm tốt hơn (cho giá trị của cho tốt hơn bằng cách cho khách hàng;.))

Answer 17

Ưu điểm là rằng nó đã được viết và thử nghiệm bởi nhiều người do đó ít có khả năng được dễ bị lỗi.

Nhược điểm là nó không được xây dựng riêng cho ứng dụng của bạn và do đó rất có thể sẽ hoạt động kém hơn. Tất cả trong tất cả, tôi thực sự không thể thấy nhiều lý do để sử dụng một trong những xem xét bạn đã có của riêng bạn ... mặc dù nó có thể được giá trị phát hành mã nguồn mở để những người khác có thể kiểm tra lỗi và đề nghị cải tiến.

Answer 18

Nhược điểm.

Hầu hết các tác phẩm khung đều không được định hướng đối tượng. (trình kích hoạt mã hiển thị một số quảng cáo)

Hầu hết mã được thực hiện qua bao gồm. cố gắng theo dõi vấn đề giống như kéo sợi chỉ trên áo len, và phải làm sáng tỏ toàn bộ quần áo để hiểu đầy đủ về sự sáng tạo.

Hầu hết các công trình khung đều có tài liệu viết kém.

Hầu hết các công trình khung đều cố gắng làm nhiều việc.

Tôi tìm thấy từ kinh nghiệm của mình phát triển với các công trình khung mà phải mất 3-6 tháng tốt để có được trên đầu trang của cơ sở mã. Và chỉ sau khoảng thời gian đó bạn sẽ tìm ra thời tiết bạn đang cố gắng để phù hợp với một cái chốt vuông vào một lỗ tròn. Cho rằng hầu hết các dự án php muốn được hoàn thành trước khi giai đoạn đó trôi qua, nó sẽ làm cho người sử dụng lao động tốn kém hơn để có được bất kỳ dự án nào sử dụng một "công việc khung" lớn để thành hiện thực.

Nhiều tác phẩm trong khung php đã được viết cho php 4 và được viết trong một môi trường khác. Họ đã được mở rộng rất nhiều, nhưng đang cho thấy nguồn gốc của họ. Việc sử dụng các ràng buộc toàn cầu đặc biệt phổ biến.Tôi hy vọng rằng php 6 đặt hầu hết trong số họ đến chết. Code igniter thoát hầu hết trong số này, nhưng nó là mới, và có các phần định hướng đối tượng.

Một số tác phẩm khung có mã viết không cần thiết và gây ra sự cố .. ví dụ: CAKE có bộ điều khiển xem mô hình tuyệt vời nhất, nhưng việc xử lý phiên của nó là một thảm họa. Thật không may là các tác phẩm khung không được viết theo cách mô đun. Thường nó là một lựa chọn tất cả hoặc không có gì.

Những người lập trình MOST "hack" khung làm việc để làm cho nó làm những gì họ muốn. Điều này khiến các lập trình viên tương lai thu hút đầu của họ. Nó cũng làm cho "nâng cấp" khung làm việc một impossibility.

Tôi chưa thấy công việc khung triển khai thử nghiệm đơn vị. (làm thế nào để bạn biết rằng bạn đã không bị hỏng nó).

cho tôi một đối tượng được viết rõ mọi lúc. Ít nhất là họ bạn biết phạm vi ngay lập tức ra khỏi con dơi.