Khi nào thì hiệu quả hơn để xây dựng khung của riêng bạn hơn là sử dụng một khung hiện có? [đóng cửa]

Tôi muốn biết lý do tại sao bạn quyết định xây dựng khuôn khổ của riêng bạn trong công ty của bạn.

Theo khung, tôi không có nghĩa là vài thư viện bạn sử dụng thường xuyên. Tôi có nghĩa là một cách cụ thể để xây dựng các ứng dụng trên đầu trang của nó, với các lớp cơ sở, quy ước, v.v.

Vậy tại sao bạn xây dựng khuôn khổ của riêng bạn? Làm thế nào bạn có thể biện minh điều đó cho người sử dụng bạn. Bạn đã đo lường tác động tích cực và tiêu cực của nó?

Về kinh nghiệm của bạn, bạn có nhận thấy rằng trong một số trường hợp, khung công ty tạo ra lợi ích thực sự, hoặc mặt khác, làm tăng chi phí phát triển (đường cong học tập, gỡ lỗi, bảo trì, ...)?

Trả lời tại sao:

• Vấn đề giấy phép
• Các yêu cầu cụ thể của công ty không tồn tại trong các khung hiện tại
• Công ty muốn có quyền kiểm soát hỗ trợ và bảo trì khung
• Kiến trúc sư không biết rõ hơn! Anh ấy / cô ấy không biết về khuôn khổ cụ thể đó tồn tại, vì vậy họ quyết định phát minh lại bánh xe.

Cập nhật:

Các doanh nghiệp thích phát minh lại bánh xe hơn là sử dụng các khung "nhỏ". Bởi nhỏ tôi đề cập đến khuôn khổ có thể có tương lai không chắc chắn. Ví dụ, .NET framework an toàn hơn cho các doanh nghiệp chọn hơn là một khung được tạo bởi một cộng đồng nhỏ. Các doanh nghiệp cần bảo mật vì nhiều ứng dụng của họ là kinh doanh quan trọng và cũng tồn tại lâu dài. Chi phí tái phát minh bánh xe có thể nhiều hơn trong ngắn hạn. Nhưng chi phí có thể cao hơn nếu khung sử dụng trong ứng dụng của công ty không được hỗ trợ và không còn được hỗ trợ, hoặc giấy phép bị thay đổi. Ở đây, công ty có thể phải loại bỏ khuôn khổ hiện tại và đưa vào một khuôn khổ khác. Visual Basic là một ví dụ điển hình về ngôn ngữ không còn được Microsoft hỗ trợ. Và chi phí này hàng tỷ công ty kể từ khi họ phải bắt đầu lại với sự phát triển mới.

Tại sao xây dựng của riêng bạn?

1. bởi vì nó chưa bao giờ được xây dựng trước đây (hiếm, nhưng dù sao cũng có khả năng)
2. bởi vì bạn muốn kiểm soát hoàn toàn
3. bởi vì bạn chỉ cần một chút chức năng để có thể tự xây dựng nó rẻ hơn

Tại sao không xây dựng của riêng bạn?

1. bạn không có thời gian để làm như vậy
2. nó có thể rẻ hơn rất nhiều nếu bạn mua một khung hiện có
3. bạn tiết kiệm rất nhiều thời gian và có thể làm việc hiệu quả nhanh hơn rất nhiều

Trong bài viết của tôi khi thích hợp để phát minh lại bánh xe, tôi liệt kê một số lợi thế của việc thực hiện lại. Tôi nghĩ những lợi thế đó đặc biệt áp dụng cho các thư viện khung. Ví dụ, thường không thể tách biệt việc sử dụng thư viện khung bên trong một phần nhỏ trong ứng dụng của bạn. Thay vào đó, họ có xu hướng ra lệnh cấu trúc của mã nguồn máy khách, và do đó, mong muốn có toàn quyền kiểm soát thư viện.

Lý do thực sự duy nhất để phát minh lại bánh xe là nếu nó là một ứng dụng quan trọng trong kinh doanh. Nếu công ty của bạn sẽ sử dụng trong một thời gian tới. Nếu ứng dụng này / khung / vv. sẽ có khả năng phát triển vượt ra ngoài khuôn khổ thương mại hiện có, sau đó có các lập trình viên công ty làm cho việc triển khai của họ chắc chắn được chấp nhận.

Những lý do thực sự duy nhất chống lại điều này là nếu:

1. Khung hiện tại được duy trì tốt, hoàn toàn phù hợp với nhiệm vụ của bạn và sẽ hướng tới tương lai.

2. Đây chỉ là một trường hợp của hội chứng ' Không được phát minh ở đây '

3. Thiết lập hiện tại của bạn sẽ không thể tạo thành công khung này trong một khoảng thời gian hợp lý với chi phí hợp lý.

Joel Spolsky đã viết một bài viết rất hay về vấn đề này: Bảo vệ Hội chứng không được phát minh ở đây

Về cơ bản khi bạn sử dụng công việc của người khác, bạn thêm họ làm chủ nhân vô hình hoặc "thêm tay".

Nếu họ tốt họ sẽ giúp bạn. Nếu không, bạn phải thực hiện công việc của họ ngoài việc của riêng bạn - nói cách khác là duy trì mã của họ. Đây có thể là một rủi ro không thể chấp nhận, nhưng tôi sẽ xem xét nó rất hiếm.

Từ khóa là để làm cho khung có thể hoán đổi, bằng cách mã hóa thành một giao diện. Các giao diện cứng nhắc nhất trong thế giới Java là các thông số kỹ thuật của Mặt trời, được chứng minh bằng API servlet.

Sau đó, tôi sẽ không xem xét có bất kỳ lý do cho việc không sử dụng một khung.

Chúng tôi đã có một khuôn khổ khá trưởng thành nơi tôi làm việc. Dưới đây là một Khung nền tảng tóm tắt

Một trong những lý do chính để sử dụng nó là sự ổn định. Chúng tôi không được biết đến Microsoft hoặc bất kỳ nhà cung cấp nào khác được thúc đẩy để thêm các tính năng mới và độ phức tạp hàng năm.

(Quan điểm của riêng tôi, không phải của chủ nhân của tôi, v.v.)

Tôi đã làm điều đó nhiều lần, để đáp ứng các yêu cầu không được bao phủ bởi các khung hiện có (trước đó).

Trong hầu hết các trường hợp, những khung công tác gia đình này sau đó đã bị loại bỏ bởi các khung mới hơn, được phát triển đầy đủ. Ví dụ, vào năm 2000, tôi đã tạo ra một khung web Java, ở một số khía cạnh có thể so sánh với Rails, được sử dụng để tạo ra một hệ thống nhập đơn hàng phức tạp với một số biểu mẫu có nhiều thứ. Nó hoạt động tốt, nhưng tất nhiên, một vài năm sau đó, các khung công tác trưởng thành hơn như Struts và JSF đã khiến nó trở nên lỗi thời. Nhưng hồi đó, đó là điều đúng đắn, nó hoạt động tốt và tốc độ phát triển rất ấn tượng.

Một khung khác mà tôi đã phát triển vẫn đang được sử dụng (và cả trong phát triển tích cực); phiên bản đầu tiên được viết vào năm 2004. Phiên bản này chủ yếu được sử dụng cho các ứng dụng intralogistic; công ty sử dụng nó vẫn xem nó như một tính năng khác biệt. Lý do chính để tạo ra nó là để giúp dễ dàng tạo các ứng dụng được kết nối cơ sở dữ liệu cho máy quét mã vạch di động (chạy một số hương vị của Windows CE); nó hoạt động tốt đến mức các ông chủ quyết định sử dụng khái niệm tương tự cho phần mềm PC, và, tốt, họ vẫn hài lòng với nó.