Tư vấn / Cách tiếp cận để chắt lọc mã đồng nhất và xây dựng mã chung cho một nhóm

Tôi làm việc cho Bang California. Theo tôi, nhóm lập trình của chúng tôi không thực sự là một "nhóm" ở chỗ chúng tôi thường làm việc một mình trong các dự án trong suốt vòng đời của ứng dụng / hệ thống.

Kết quả cuối cùng là rất nhiều nhà phát triển đang 'phát minh lại bánh xe' ... viết các lớp dữ liệu của riêng họ, mặc dù đại đa số chúng ta làm việc trên cùng một DB DB ... viết nội dung bảo mật của riêng họ ... trên.

Tôi không thể thay đổi tâm lý của nhân viên của mình và không có bất kỳ tham vọng thực tế nào liên quan đến việc thay đổi quy trình nhóm của chúng tôi ... nhưng mục tiêu của tôi là khiến nhóm của chúng tôi làm việc cùng nhau nhiều hơn, ít nhất là để xây dựng tòa nhà chung khối mà tất cả chúng ta có thể sử dụng cho chức năng soạn sẵn.

Những lợi ích rõ ràng là, kiểm tra và hỗ trợ sẽ dễ duy trì hơn nhiều khi tất cả người dùng của chúng tôi đều quen thuộc với một phần chung, thời gian sản xuất sẽ ít hơn khi bạn không viết cùng một kho lưu trữ mà người khác đã làm và chúng tôi có thể tập trung vào việc cung cấp các giải pháp tốt hơn đối với các vấn đề độc đáo, ứng dụng của chúng tôi phải giải quyết ... vv

Tôi đang giảng cho dàn hợp xướng, tôi chắc chắn.

Bí quyết là, Nhà nước không thích thay đổi, nhân viên cũng không. Các nhà quản lý thường coi thường những ý tưởng mới chỉ đơn giản vì họ muốn tránh ma sát và thà tiếp tục như vậy.

Có những câu hỏi tương tự ngoài kia, nhưng điều tôi đang tìm kiếm là lời khuyên về việc bất kỳ ai trong số các bạn có thể phải đối mặt với một tình huống tương tự, và bất kỳ hướng nào để có được một nỗ lực 'rễ cỏ' sẽ có cách tiếp cận quản lý dễ dàng hơn.

EDIT: Chỉ cần làm rõ một vài điều:

• phạm vi tôi đang tìm kiếm nằm trong cửa hàng CNTT của Cơ quan Nhà nước. Tôi không cố gắng phối hợp giữa nhiều bộ phận. Bắt mọi người rời khỏi bánh xe huấn luyện trước khi yêu cầu họ đi xe máy.

• Bảo mật không phải là vấn đề đáng lo ngại, hầu hết các ứng dụng của chúng tôi đều là nội bộ và được viết bằng Windows Forms được phân phối trên Citrix (ugh.) Và gần như tất cả đều sử dụng cùng một bảng doanh nghiệp trong Oracle ... rất ít nếu có bất kỳ ứng dụng nào được "phân loại" nói. nó không nên cản trở sự hợp tác.

• Tôi đã đi xa hơn để thiết lập một nguồn cấp dữ liệu NuGet, với một vài đoạn mã soạn sẵn, và viết một vài repos cho Oracle, gửi một số email, nhưng nhận được rất ít phản hồi. Tôi đã có khoảng 1/3 nhóm của chúng tôi sử dụng ReSharper và thỉnh thoảng gửi email bằng các mẹo ... một lần nữa, không phải là rất nhiều phản hồi.

Rắc rối là...

những lợi ích rõ ràng

có thể không quá rõ ràng với những người xung quanh bạn, đặc biệt nếu họ không phải là nhà phát triển. Tôi đã làm việc cho cả chính phủ Nhà nước và chính phủ Liên bang để tôi có thể đồng cảm với hoàn cảnh của bạn. Theo kinh nghiệm của tôi, bạn cần cho họ thấy tiền . Bắt đầu đánh đồng các thay đổi với số ( ví dụ: số liệu ) và sau đó đánh đồng số liệu với tiền. Tôi nhận ra điều này không có gì thú vị và tôi nhận ra bạn cũng không nên có, nhưng đây thường là cách của mọi thứ. Tất cả các bang đều rơi vào khủng hoảng ngân sách và chỉ cho họ cách họ có thể đáp ứng nhu cầu lớn hơn mà không cần nhiều tiền hơn, ý tưởng của bạn có thể trở nên hấp dẫn hơn.

Trên đường đi, bạn có thể thấy rằng một cái gì đó bạn muốn làm âm thanh ( hoặc cảm thấy ) tốt hơn nhưng những con số không hỗ trợ bạn. Nếu điều đó xảy ra, bạn có thể đang bắt đầu một cuộc tranh luận tôn giáo công nghệ có thể thực sự gây khó chịu; hoặc trật bánh hoàn toàn; tiến bộ khác bạn đang thực hiện. Trong trường hợp đó, hãy từ bỏ nó và chuyển sang ý tưởng tiếp theo. Hãy quay lại với những người một khi mọi người cởi mở hơn với những thay đổi.

Đối với các số liệu ... bắt đầu với kinh điển, chúng hoạt động tốt trong hầu hết các trường hợp.

• Thời gian / Lịch biểu ( Có thể bao gồm hiệu suất của hệ thống )
• Tiền ( dành và tiết kiệm )
• Vật chất
• Khiếm khuyết ( Tỷ lệ, Mức độ nghiêm trọng, Khả năng hiển thị cho người dùng cuối )
• Độ tin cậy ( theo thuật ngữ của chính phủ, đây là Ao [Tính khả dụng của hoạt động] và Thời gian trung bình giữa các lần thất bại của MTBF )

Chúc may mắn!

Bạn có thể xem xét hợp tác với một hoặc hai đồng nghiệp của mình để giúp bắt đầu xây dựng một khuôn khổ chung không? Đó sẽ là gợi ý của tôi cho một điểm khởi đầu vì bạn sẽ cần các đồng minh và một số lợi ích có thể tự tiết lộ sau một thời gian làm việc cùng nhau để mọi thứ không bị cô lập. Bạn có thể phải có một vài cuộc thảo luận với đồng nghiệp để xem mức độ dễ tiếp thu của những ý tưởng này và đó là những người chấp nhận sớm mà bạn có thể sử dụng để đưa ra ý tưởng này.

Chủ đề chính của tôi sẽ là xem xét các bước bé ở đây. Thay đổi nhỏ định kỳ có thể hoạt động tốt.

Bước đầu tiên sẽ là quảng cáo (trong số bất kỳ ai quan tâm và làm việc cho cùng một chủ nhân) những gì bạn có .

Giống như các văn phòng khoa của các trường đại học, có áp phích minh họa kiến ​​trúc, chức năng và thiết kế của các bộ phận bạn có. Đây là "hàng tồn kho" hoặc "tài sản" của Nhà nước.

Câu hỏi thứ hai là liệu nhà tuyển dụng có được phép xem mã nguồn của người khác không. Nếu điều này không được phép, việc cộng tác sẽ rất khó khăn (trừ khi bạn có thể nhận được hỗ trợ ở cấp Bang).

Khi nói đến an ninh, có khả năng Nhà nước đã có một số nhiệm vụ bảo mật thông tin phải được đáp ứng bởi tất cả các dự án. Nó có thể là một điểm khởi đầu tốt cho tiêu chuẩn hóa.

Một số loại công việc, đặc biệt. "Các dự án tùy biến", sẽ luôn là tác phẩm solo, bởi vì đây là nơi chúng thuộc về.

Tôi sẽ bắt đầu bằng cách nói rằng tôi là một người hỗ trợ và nhà phê bình khổng lồ cho mã có thể tái sử dụng và xác định các khối xây dựng tuyệt vời, tiện lợi và mạnh mẽ mà nhiều nhà phát triển phải sử dụng. Tuy nhiên, tôi cũng chỉ ra rằng việc cuộn mã / thư viện / khung có thể tái sử dụng của riêng bạn đôi khi có thể là con dao hai lưỡi rất sắc. Và một cái gì đó mà bạn nghĩ nên tiết kiệm thời gian, đôi khi có thể làm điều ngược lại.

Đây là mô hình mà tôi đã quan sát trong quá khứ: Khi một nhà phát triển tiếp tục làm việc trên một sản phẩm / tính năng / bản phát hành, một số trong số họ (có thể 10-25%) sẽ xác định một số thành phần có thể tái sử dụng hoặc một số lớp sẽ hoàn toàn ngớ ngẩn để tiếp tục viết hơn và hơn Những người còn lại, tiếp tục sao chép / dán và phát minh lại bánh xe. Hãy quên những điều đó đi, bạn không phải là một trong số họ.

Vì vậy, khi bạn xác định mã có thể tái sử dụng, bạn bắt đầu tạo thư viện cá nhân của riêng mình về những thứ hay ho theo thời gian giúp cuộc sống của bạn ngày càng dễ dàng hơn. Bạn có thể có các lớp tiện ích để giúp bạn làm việc với XML, luồng, sổ đăng ký ... bạn đặt tên cho nó. Tôi đã làm điều này và đưa nó cho bất cứ ai sẵn sàng lắng nghe và một số người sẵn sàng chấp nhận thực tế rằng họ có thể phân tích những gì họ cần từ một tài liệu XML với 6 dòng mã. Những người khác được thiết lập theo cách của họ và họ thích mã hóa 100 dòng MSXML thẳng.

Phát hiện của tôi:

1. theo thời gian khi thư viện của bạn được cải thiện, những người khác sẽ dần dần bắt đầu sử dụng nó.

2. khi những người khác bắt đầu sử dụng nó, bây giờ bạn đã trở thành người hỗ trợ cho bất cứ khi nào họ gặp sự cố và họ nghi ngờ đó là mã của bạn. Đôi khi, họ tìm thấy một lỗi trong mã của bạn vì họ sử dụng API hơi khác so với cách bạn sử dụng, đôi khi lỗi đó nằm trong mã của họ vì họ không hiểu cách sử dụng API và đôi khi lỗi không liên quan nhưng gánh nặng là bạn bởi vì họ tin chắc rằng trước khi họ thêm thư viện của bạn, mọi thứ đều hoạt động.

3. (đây thực sự là từ một bài đăng / blog khác nhưng không thể tìm thấy liên kết): nếu bạn đã viết một số "mã có thể tái sử dụng" và bạn phải mất 3 tuần để làm điều đó. Nhìn chung, bạn cần dành thêm 3 tuần để làm sạch nó để người khác có thể sử dụng nó và cung cấp tài liệu rõ ràng và 3 tuần nữa để viết các bài kiểm tra đơn vị rộng rãi và cũng bao gồm các kịch bản sử dụng chung, không chỉ các kịch bản sử dụng của bạn. Những người khác tìm thấy điều tương tự, các khung / thư viện mất gấp 3 lần nỗ lực so với phát triển ban đầu.

4. Hy vọng bạn sẽ không phải đối mặt với điều này. Một số mã của tôi trở nên có thể tái sử dụng đến mức mọi người thực sự bắt đầu sử dụng nó trong một cài đặt rộng hơn. Sau đó khoảng 9 tháng, ban quản lý đã quyết định chia sản phẩm của chúng tôi thành 2 sản phẩm khác nhau, mỗi sản phẩm có chu kỳ phát hành riêng. Bạn nghĩ gì đã xảy ra với thư viện khung / tiện ích đó? Cả hai sản phẩm đều phụ thuộc vào nó nhưng bây giờ bạn phải cẩn thận cách thư viện được sửa đổi nếu bạn đang tích cực phát triển sản phẩm A trong khi sản phẩm B sắp được tung ra. Giải pháp của chúng tôi là tạo ra khuôn khổ sản phẩm C có chu kỳ phát hành độc lập của riêng mình. Vì vậy, ở đây tôi 9 tháng sau và tôi vẫn cảm thấy những dư chấn từ tất cả các vấn đề xây dựng / tích hợp / đóng gói liên tục mà điều này đã gây ra.

5. Bạn có thể cực kỳ cẩn thận về cách bạn đã viết các lớp tiện ích của mình và bạn hiểu tất cả ý nghĩa của việc thực hiện thay đổi này và điều đó. Nhưng một khi những người khác bắt đầu sử dụng mã của bạn, đến một lúc nào đó họ sẽ muốn sửa đổi nó. Nếu có 20 thành phần khác phụ thuộc vào thư viện của bạn, khi ai đó sửa đổi thư viện, họ có thể phá vỡ 19 thành phần khác (tôi cho rằng họ đã thực hiện thay đổi để mã của họ hoạt động). Khi mã được sử dụng rộng rãi hơn, nó trở nên đắt hơn nhiều để sửa đổi nó.

6. Mặc dù tôi là tất cả để tái sử dụng, nhưng có những ngày đến giờ ăn trưa, tôi bắt đầu muốn bản thân mình rằng thư viện tiện ích cá nhân vẫn là thư viện tiện ích cá nhân của tôi.

Vì vậy, dựa trên kinh nghiệm của tôi, một số lời khuyên mà tôi có thể nghĩ ra:

1. Tìm kiếm các thư viện bên thứ 3 bên ngoài làm những gì bạn cần và xây dựng các ứng dụng của bạn trên đầu trang càng nhiều càng tốt. Mỗi một trong những thư viện đó đã có một nhóm người hỗ trợ nó. Giới thiệu họ đến một nơi toàn cầu trong môi trường của bạn, nơi bất cứ ai cũng có thể đến với họ.

2. Thay vì yêu cầu tất cả mọi người sử dụng công cụ của bạn, hãy tiếp cận từng người trong nhóm và các kỹ sư khác và xem ai có cùng suy nghĩ như bạn. Tôi chắc chắn rằng bạn sẽ tìm thấy một vài người khác chia sẻ giá trị của bạn và bạn có thể bắt đầu một nhóm cốt lõi không chính thức hoạt động vì lợi ích chung.

3. Không biết cái này có hoạt động không và / hoặc là một ý tưởng hay, nhưng tôi muốn thử nó trong công ty của riêng tôi: Thay vì tạo các khung / thư viện toàn cầu và được sở hữu / sử dụng bởi nhiều người / nhóm. Hãy coi tất cả các mã của bạn là "nguồn mở nội bộ". Thiết lập một kho lưu trữ tương tự như github nơi những người / nhóm khác nhau có thể gửi mã thư viện / tiện ích / mã trợ giúp. Làm cho kho lưu trữ hiển thị cho mọi người để nếu bạn viết một cái gì đó tốt, bất cứ ai cũng có thể tự do lấy mã của bạn và sử dụng nó. Nếu họ quyết định thực hiện thay đổi mã của bạn, giống như nguồn mở, sau đó có thể tạo chi nhánh của riêng họ, họ sẽ duy trì hoặc trả lại cho bạn thay đổi để quay trở lại trung kế chính. Nếu bạn không tin tưởng vào công việc của họ hoặc không đồng ý với thay đổi, vì dự án vẫn là của bạn, bạn có tiếng nói cuối cùng nếu bạn muốn chấp nhận nó. Nếu một số nhóm bắt đầu một dự án và sau đó từ bỏ nó nhưng một nhóm khác thấy nó hữu ích, họ có thể phân nhánh vào kho lưu trữ nhóm của riêng họ và tiếp tục công việc. Tôi đã xem xét việc sử dụng Redmine để làm một cái gì đó như thế này, nhưng chưa có cơ hội để thiết lập nó.