Một công ty phần mềm nên có một nhóm chuyên dụng cho các thư viện nghiên cứu và / hoặc tiện ích?

Tôi làm việc trong một công ty làm ứng dụng web cho các ngân hàng khác nhau và một số cửa hàng điện tử nhỏ hơn Chúng tôi sử dụng khoảng 20 nhà phát triển và có 4-5 dự án đang phát triển cùng một lúc. Các nhóm phát triển của chúng tôi không tương tác nhiều và rất nhiều vấn đề tương tự được thực hiện theo nhiều cách khác nhau (tốt đến xấu).

Tôi đã tự hỏi liệu một công ty nên có một nhóm lập trình viên nghiên cứu về các khung hiện tại và liên tục cải tiến một thư viện chức năng chung và một khung chung để xây dựng các dự án hiện tại và tương lai nhanh hơn và hiệu quả hơn.

Làm thế nào lớn một đội như thế này?

Ngoài ra nó nên có thành viên thường trực đào tạo người khác hay nó nên luân chuyển người?

Cập nhật: Tôi đã suy nghĩ về một dự án chung mà mọi người có thể làm việc để giải trí có thể gây hứng thú. Dường như khi mọi người có áp lực công việc, các giải pháp họ đưa ra không phải là tốt nhất.

Một điểm quan trọng là không thể phát triển một khung tốt trong sự cô lập hoàn toàn. Các khung công tác tốt được phát triển một cách hữu cơ : khi một lập trình viên nhận thấy rằng anh ta cần một số chức năng cụ thể, anh ta thêm nó vào khung, và do đó, khung phát triển từng chút một - trái ngược với kiến ​​trúc của một "khung hoàn hảo", không bao giờ hoạt động, bởi vì kiến trúc sư không thể nhận thức được tất cả các trường hợp sử dụng cuối cùng.

Tất nhiên, phát triển một cách hữu cơ khuôn khổ có nhược điểm là tính toàn vẹn bên trong của nó có thể không quá tốt, và nó biến thành mì spaghetti. Nếu nhóm của bạn giữ liên lạc nội bộ tốt, thì bạn có thể kết hợp tốt nhất cả hai thế giới: một nhóm kiến ​​trúc sư riêng biệt giữ sự toàn vẹn của khung, nhưng xây dựng cho nhu cầu thực sự của người dùng cuối (nhà phát triển).

Cảm giác của tôi là không.

Điều tôi nghi ngờ bạn sẽ tìm thấy nếu bạn làm điều này là thay vì có các nhóm riêng lẻ tạo ra các thư viện mà không ai ngoài nhóm đó sử dụng, bạn sẽ có một nhóm chuyên sản xuất các thư viện mà không ai ngoài nhóm sử dụng (và làm như vậy với chi phí bổ sung đáng kể).

Có nhiều loại vấn đề với loại nhóm bạn mô tả, nhưng đối với tôi, vấn đề chính là nó không giải quyết được vấn đề bạn thực sự gặp phải.

Vấn đề bạn gặp phải không phải là ai tạo ra các thư viện (bởi âm thanh của những thứ bạn đã có nhiều giải pháp cho những vấn đề này, vậy làm thế nào để có thêm một sự giúp đỡ?), Đó là các đội không nói chuyện và tương tác.

Có nhiều lý do tại sao các nhóm không sử dụng lại mã của nhau (ví dụ: các vấn đề trong khi bề ngoài tương tự nhau rất khác nhau hoặc thời gian dự án chỉ không cho phép phụ thuộc vào việc phát triển một cái gì đó cùng nhau), nhưng bạn cần phải nhìn vào cách bạn có thể khiến họ tương tác khi có thể.

Tôi muốn đề xuất:

• luân chuyển đội giữa các dự án
• tổ chức bữa ăn trưa nhóm và các nhóm thảo luận
• gửi bài đánh giá dự án về cách giải quyết vấn đề (có sự tham gia của các đội khác)
• thiết lập một khu vực của mã phác thảo wiki có thể được sử dụng lại (và ai sẽ nói về nó)
• nghĩ về việc khuyến khích tái sử dụng tốt - thực sự nghiêm túc trả cho mọi người thêm để làm điều đó. Nếu sử dụng lại một thành phần giúp tiết kiệm 5 ngày và 2000 đô la chi phí, tại sao không cung cấp 200 đô la lợi nhuận hiện có cho nhóm để đi chơi đêm khi kết thúc dự án (khi bạn xác thực việc tiết kiệm là chính hãng)

Một nhóm thư viện sẽ, tôi nghi ngờ, chi phí không có lợi.

Về mặt nó là một dự án phổ biến mà các nhà phát triển làm việc để giải trí - không có công ty nào nên dựa vào các lập trình viên làm việc trên mọi thứ trong thời gian riêng của họ. Đó chỉ là tiền làm thêm giờ và trong mọi trường hợp, không đáng tin cậy vì có thể sẽ có những khoảng thời gian lớn mà không ai muốn làm việc trên mọi thứ.

Nếu bạn nói rằng đó sẽ là những người làm việc trong thời gian giữa các dự án thì có thể nó có thể hoạt động nhưng tôi vẫn không nghĩ đó là vấn đề thực sự. Bạn vẫn cần tìm ra cách bạn sẽ khiến mọi người sử dụng các thư viện. Như tôi đã nói, bạn đã có giải pháp cho những vấn đề đang được phát triển trên mỗi dự án, vấn đề của bạn là tại sao chúng không được chia sẻ.

Đó là công việc của một kiến trúc sư .

Các trách nhiệm chính của một kiến ​​trúc sư phần mềm bao gồm:

• Hạn chế các lựa chọn có sẵn trong quá trình phát triển bằng cách chọn một cách tiêu chuẩn để theo đuổi phát triển ứng dụng
• tạo, định nghĩa hoặc chọn khung ứng dụng cho ứng dụng
• Nhận biết tái sử dụng tiềm năng trong tổ chức hoặc trong ứng dụng bằng cách Quan sát và hiểu môi trường hệ thống rộng lớn hơn
• Tạo thiết kế thành phần Có kiến ​​thức về các ứng dụng khác trong tổ chức

Đọc thêm về: - Kiến trúc sư phần mềm - Kiến trúc sư giải pháp - Kiến trúc sư doanh nghiệp .

Câu nói " Ăn thức ăn cho chó của riêng bạn " giải quyết vấn đề này. Nếu nhà lập trình nhạc rock-cool-rock hàng đầu của bạn khai sinh ra một thư viện mà anh ta không bao giờ sử dụng trong thực tế, làm thế nào anh ta có thể nói rằng đó là một thư viện tốt?

Những lý do chính để phát triển các chức năng thành khung là

1. Nó rất hữu ích cho người phát triển
2. Có một vài trường hợp nó hữu ích
3. Nó có thể hữu ích cho những người khác

Khi bạn nhấn 2, chức năng đã có, làm thế nào bạn có thể chuyển nó cho người khác?

Tôi hơi trễ trò chơi nhưng tôi cảm thấy như không có ai giải quyết vấn đề này:

Các nhóm riêng lẻ của bạn đang giải quyết các vấn đề khác nhau theo các cách khác nhau chắc chắn sẽ được hưởng lợi từ chức năng được chia sẻ và có nhiều cách khác nhau để có được điều đó theo cách không dành một nhóm duy nhất để phát triển nó, nhưng tôi đã thấy rất nhiều của những nơi làm.

Trong hầu hết các trường hợp, tôi thấy điều này được gọi là "cốt lõi" của dòng sản phẩm của bạn và đôi khi có một nhóm chịu trách nhiệm bảo trì nó, được dẫn dắt bởi (như Amir đề xuất) một kiến ​​trúc sư. Đây thường là cách bạn có thể tìm cách tận dụng hoặc tạo một khung theo các tiêu chuẩn chặt chẽ nhất bạn đặt trong tổ chức của mình nhưng chỉ cung cấp các chức năng trần nhất có thể hoặc không cần phải được mở rộng trong các ứng dụng chính thức mà các nhóm sản phẩm cá nhân của bạn cung cấp. Điều này cho phép bạn có được lợi ích của việc "dogfooding" mã cốt lõi của mình bằng cách triển khai nó ở mọi nơi bạn sử dụng, và sau đó phân nhánh ra các sản phẩm khác nhau có thể có các triển khai hoàn toàn khác nhau. Điều này cho phép tất cả các nhóm của bạn đóng góp cho các thư viện cốt lõi nhưng không làm hỏng nó với chức năng mà chỉ họ cần.

Tôi nghĩ đó không phải là một IDEA TỐT , bởi vì để các thư viện trở nên hữu ích, họ phải giúp bạn giải quyết các vấn đề thực tế của dự án và bạn chỉ làm quen với chúng bằng cách ... làm việc trong các dự án thực.

Nếu không, bạn có thể kết thúc với một thư viện "lý thuyết" rất tốt!

Tại một công ty tôi làm việc ở đó thực sự có một điều tương tự, nó dường như không hoạt động tốt. Những người trong nhóm bên trong sẽ đưa ra một ý tưởng gọn gàng và đưa ra một nguyên mẫu chủ yếu hoạt động, sau đó nó đi qua bức tường và chúng tôi dự kiến ​​sẽ biến nó thành một sản phẩm.

Điều tôi mong đợi đã xảy ra là nhóm công cụ sẽ kết thúc chương trình nhỏ của riêng mình, tạo ra các hàm không thực sự hữu ích, nhưng làm lộn xộn API và được sử dụng đủ để chúng không thể dễ dàng loại bỏ. Họ sẽ không tài liệu đầy đủ.

Nếu nhóm công cụ đủ dưới một kiến ​​trúc sư hệ thống, người tiếp xúc liên tục với những người thực sự sử dụng các công cụ, thì nó có thể hoạt động. Nếu nhóm công cụ xoay thường xuyên (sẽ cản trở việc thực hiện nhiều nghiên cứu bên ngoài) thì nó có thể hoạt động. Tuy nhiên, tôi sợ mất liên lạc với những người làm công việc thanh toán.

Bạn sẽ dành bao nhiêu thời gian để tranh luận về việc sử dụng khung công tác này có mang lại lợi ích trong mọi trường hợp không? Có một dự án bị trì hoãn bằng cách chờ đợi khung được nâng cấp? Tại một số điểm, việc sử dụng khung phải được yêu cầu để chứng minh sự tồn tại của nó.