Làm thế nào để đối phó với các khuôn khổ công ty nội bộ và các nhà máy SW?

Question

Dựa trên kinh nghiệm của riêng tôi và kinh nghiệm của bạn bè tôi thấy rằng nhiều công ty có một số ý tưởng kỳ lạ để phát triển khung công tác của riêng họ và các nhà máy SW (xây dựng bộ khung ứng dụng cho bạn). Những ý tưởng này thường dựa trên niềm tin rằng khung riêng sẽ tốt hơn nhiều so với bất cứ điều gì khác có sẵn. Làm thế nào để đối phó với những ý tưởng như vậy và làm thế nào để giải thích rằng nó không phải luôn luôn là cách tốt để đi?

Tại sao tôi nghĩ rằng khuôn khổ nội bộ/nhà máy là không tốt:

• Ngân sách & Tài nguyên - Thường chỉ có một số ngân sách ban đầu để tạo ra khuôn khổ. Không ai nghĩ về ngân sách cần thiết để duy trì và hỗ trợ khung. Không ai thậm chí có thể ước tính ngân sách và tài nguyên cần thiết để duy trì. Lúc đầu, không ai nghĩ đến việc duy trì nhiều phiên bản của khung công tác để hỗ trợ các ứng dụng hiện có.
• Thiếu kinh nghiệm - Khung thường được tạo ra bởi những người không có kinh nghiệm như vậy hoặc với sự hỗ trợ của "chuyên gia tư vấn" - thường là những người đắt tiền hơn với bộ kỹ năng tương tự.
• Kiến trúc/thiết kế - bất kỳ vấn đề kiến ​​trúc nào trong khung ảnh hưởng đến tất cả các ứng dụng được xây dựng bằng cách sử dụng khung này. Thiệt hại thiết kế xấu trong các nhà phát triển lực lượng khuôn khổ để mã ứng dụng theo cách xấu.
• Nợ kỹ thuật - mã xấu trong framwork là nợ kỹ thuật.
• Niềm tin giả về viên đạn bạc - người quản lý tin rằng khung/nhà máy riêng là viên đạn bạc. Tất cả các ứng dụng sẽ được viết theo cùng một cách và nó sẽ dễ dàng duy trì. Kinh nghiệm của tôi là nó đơn giản không phải là sự thật. Ngay cả với nhà máy SW mỗi ứng dụng là cụ thể.
• Không đủ tài liệu - tài liệu trước tiên bị ảnh hưởng bởi ngân sách thấp. Khung mà không có tài liệu là vô dụng. Reflector (.NET) là người bạn tốt nhất của tôi.
• Không đủ nhóm người dùng - khung nội bộ chỉ có nhóm người dùng nhỏ. Nhóm người dùng nhỏ có nghĩa là trải nghiệm nhỏ. Nếu tôi đang sử dụng công cụ/khung công cộng và tôi gặp sự cố, tôi có thể đặt câu hỏi trên SO (hoặc trang web tương tự) hoặc chỉ tìm cách tìm câu trả lời trên google. Với khung nội bộ, điều đó là không thể.
• Chính sách - chính sách của công ty buộc bạn phải sử dụng khuôn khổ để xác minh chi phí khuôn khổ. Điều này đi xa đến mức khung được chọn trước khi yêu cầu đầu tiên được thu thập.
• Nghiêm cấm việc tuân thủ khung.
• Nghiêm cấm việc sử dụng các khung công tác khác.

Tại sao tôi nghĩ rằng các công ty đang làm điều này:

• Ngạo mạn & ích kỷ - sombody trong công ty tin rằng ông có thể làm điều đó tốt hơn.
• Sự thiếu hiểu biết - bỏ qua các khung/giải pháp hiện có và thực tế là chỉ có các khuôn khổ tốt tồn tại đủ lâu để trở nên phổ biến. Bỏ qua nhóm người dùng và các thông tin sẵn có trên Internet.
• Thất bại quản lý và không đủ năng lực - không hiểu được tác động (đặc biệt là dài hạn) của sự suy giảm này. Decission dựa trên thông tin không chính xác. Quản lý không có nền phát triển SW.

Tôi hiểu rằng đôi khi giải pháp hoặc khung công tác riêng cho kịch bản chuyên ngành là cần thiết nhưng tôi mệt mỏi với tất cả "khung nội bộ tuyệt vời" này để tạo ứng dụng web hoặc máy tính để bàn. Liệu tôi có sai? Các khuôn khổ này có thực sự cần thiết (.NET và Java world) không?Bạn có thể cung cấp cho tôi một số ví dụ hoặc lý do tại sao nó là tốt để có khuôn khổ nội bộ/nhà máy?

Edit:

Cám ơn câu trả lời nhưng tôi mong đợi một số lời khuyên làm thế nào để đối phó với một vấn đề như một nhà phát triển (trừ thay đổi một công việc) không phải là một người quản lý.

Answer 1

Theo kinh nghiệm của tôi, nguyên nhân phổ biến nhất của khung công tác dư thừa là ... nhà phát triển chán! Các nhà phát triển không có nhà phát triển thấy rằng việc phát triển các khuôn khổ để giải quyết vấn đề của họ thú vị hơn nhiều so với việc giải quyết những vấn đề đó - kết quả cuối cùng là các khuôn khổ chịu đựng tất cả những điều trên (vì dĩ nhiên nhà phát triển chỉ thực hiện các bit thú vị), và có thể không thậm chí giải quyết vấn đề thực tế (vì mục tiêu là để vui chơi, không giải quyết vấn đề).

Giải pháp rất phức tạp - khó biết được điều gì thúc đẩy nhà phát triển vì mọi người đều được thúc đẩy bởi những thứ khác nhau, tuy nhiên các nhà phát triển có động lực đang bận làm những việc mà họ thích không thấy bị bệnh này!

Điều đó nói rằng, cũng nghĩ ra các khung khi sử dụng đúng cách chắc chắn là điều tốt - Tuy nhiên, nếu nó chỉ được sử dụng trong nội bộ thì có thể tốt hơn thay vì nghĩ về nó như một phần mở rộng để tái bao thanh toán và mã lại sử dụng hơn là một khuôn khổ.

Một dấu hiệu cổ điển rằng ai đó đang bị phát triển chán hội chứng khuôn khổ là khi một khuôn khổ đang được phát triển để giải quyết các trường hợp chung khi vẫn chưa có một giải pháp cho trường hợp cụ thể:

• Làm cách nào để biết cách giải quyết trường hợp chung cho đến khi bạn giải quyết được ít nhất một trường hợp cụ thể?
• Cho đến khi bạn phải giải quyết trường hợp chung một vài lần, bạn chỉ cần đoán rằng một khuôn khổ thậm chí là cần.

Trường hợp thứ hai dẫn đến khung khuôn khổ tồi tệ nhất - khung chung chung của ma mút chỉ được sử dụng một lần để giải quyết vấn đề đơn giản hơn khung chính. Thay vào đó, hãy xem xét các loại khung này như là một bài tập trong "tái cấu trúc mở rộng" - nếu khuôn khổ được tạo ra như một cách để nhóm và làm sạch mã phổ biến trên cơ sở cần thiết thì khung sẽ phát triển về kích thước và độ phức tạp động - đã giải quyết vấn đề trước khi bạn bắt đầu sản xuất các khung công tác tốt đẹp vì nó có nghĩa là bạn đã là các chuyên gia trong bất cứ điều gì mà khung công tác cần làm.

Cuối cùng, cố gắng để giữ cho các nhà phát triển không bị chán (họ nhận được lên đến tất cả các loại nghịch ngợm khác!)

Answer 2

Khái quát là xấu, nhưng đây là những gì tôi đã nhận thấy, đặc biệt là trong các dự án doanh nghiệp lớn:

• hành vi như vậy thường được dẫn dắt bởi một trong số ít các kỹ sư phần mềm hơn (họ thường đặt tên cho chính họ kiến ​​trúc sư phần mềm) rơi vào mô tả bạn đã viết trong câu hỏi của mình. Mọi người cần phải tự hào về một cái gì đó để có can đảm để thức dậy vào buổi sáng. Tôi sẽ thêm rằng chúng thường được định hướng CV vì lý do đó và cố gắng áp dụng các mẫu thiết kế mới nhất mà không suy nghĩ về các tác động kinh doanh và ROI. Điều quan trọng là KHÔNG thuê loại người đó (hoặc cố gắng huấn luyện anh ta/cô ấy để hiểu hậu quả kinh doanh của sự lựa chọn của anh ta/cô ấy). Cố gắng để làm cho họ tự hào về làm việc cho công ty thay vì làm việc trên khuôn khổ của họ có thể giúp quá.

• Thời hạn bị lỡ, lỗi, chuyển đổi cao có xu hướng được giải quyết bằng cách áp dụng các phương pháp ưa thích (thường được triển khai kém) như scrum hoặc thuê tư vấn có giá cao sẽ làm mọi thứ tồi tệ hơn, ... thay vì xóa (hoặc huấn luyện) những người không nên được thuê ở nơi đầu tiên.

• Xóa người được đề cập trong hầu hết trường hợp là một điều xấu kể từ khi anh ấy sở hữu điều này. Vì vậy, dạy anh ta/cô ấy để hiểu hậu quả của sự lựa chọn của mình có lẽ là cách thích hợp nhất để giải quyết vấn đề. Nhưng để làm điều đó, bạn cần một người quản lý tốt tốt.

Vì vậy, lời khuyên duy nhất của tôi sẽ là:

Thuê nhà quản lý tốt hơn đó hiểu rất rõ cả hai phát triển kinh doanh và phần mềm. Họ sẽ không thuê loại người đó hoặc sẽ cố gắng dạy họ cách xem xét việc kinh doanh ngoài việc phát triển phần mềm thuần túy. Họ cũng sẽ hiểu rằng nhiên liệu động lực mạnh mẽ nhất cho nhân viên là làm cho họ tự hào làm việc cho công ty đó.

Answer 3

tôi sẽ thêm một số lý do khác những điều này phát triển, và tôi đã thấy điều này trong nhiều hơn một địa điểm: - Khóa nhà phát triển. Một khi bạn có các devs mã hóa trong một bộ kỹ năng không thể chuyển nhượng, nó khó khăn hơn cho họ để lại. - Tác giả đăng nhập. Khi bạn có một số ứng dụng đang được bảo trì phụ thuộc vào khung công tác, bạn có tổ chức phụ thuộc vào nhóm quản trị. - Kiểm soát chính trị. Việc tập trung cho phép khuôn khổ trở thành một kênh để kiểm soát chính trị.