Có điều gì giống như vai trò của nhóm tái cấu trúc / khả năng bảo trì của nhóm trong các công ty phần mềm không?

Vì vậy, tôi làm việc trong một công ty phát triển phần mềm nhúng, các nhóm khác tập trung vào phát triển cốt lõi phần mềm của các sản phẩm khác nhau và bộ phận của tôi (ở một vị trí địa lý khác) đặt tại nhà máy cũng phải đối phó với phát triển phần mềm. , nhưng trên tất cả các sản phẩm, để chúng tôi cũng có thể khắc phục mọi thứ nhanh hơn khi các dòng bị hỏng do sự cố phần mềm với sản phẩm.

Nói cách khác, chúng tôi là những người tổng quát trong khi các nhóm khác chuyên về từng sản phẩm.

Điều quan trọng là, rất khó để tham gia vào phát triển cốt lõi khi bạn được phân phối theo địa lý (vâng, tôi biết điều đó thực sự không khó, nhưng có thể có những rào cản văn hóa / chính trị ngoài ý muốn khi nói đến kỷ luật cộng tác từ xa ).

Vì vậy, tôi đã hiểu rằng, vì chúng tôi hiện đang dập lửa và hơi bị sử dụng / sử dụng phụ (mặc dù chúng tôi là một bộ phận mới, hoặc có thể đó là lý do), tôi nghĩ rằng một vai trò tốt cho chúng tôi có thể phát hiện các khu vực về cơ hội tái cấu trúc và tái cấu trúc mã và tất cả các triển khai khác có thể phải làm với việc quản lý khả năng bảo trì và mô đun hóa. Các nhóm khác không tập trung vào việc này vì họ không có thời gian và họ có thời hạn quyết liệt, làm hỏng chất lượng của mã (câu chuyện vĩnh cửu của các dự án phần mềm)

Vấn đề là tôi muốn nhóm / bộ phận của mình được ban quản lý và các nhóm khác công nhận vai trò này một cách chính thức và tôi gặp khó khăn khi đưa ra một định nghĩa / danh tính tốt cho nhóm của chúng tôi về vấn đề này.

Vì vậy, câu hỏi của tôi là: vai trò này đã tồn tại chưa?, Hay tôi là người đầu tiên tạo ra thứ gì đó như thế này?

Chỉnh sửa : Ý tôi là một nhóm thúc đẩy các sáng kiến ​​tái cấu trúc, không tự mình thực hiện tất cả các công việc tái cấu trúc. Giống như một cộng đồng nguồn mở cho một sản phẩm nguồn mở, bây giờ tôi nghĩ về nó.

Tôi chưa bao giờ nghe nói về một điều như vậy tại bất kỳ công ty nào mà tôi đã làm việc hoặc phỏng vấn. Các công ty thường chỉ muốn trả tiền cho các tính năng mới hoặc thay đổi có những cải tiến có thể đo lường được cho người dùng cuối (như cải tiến hiệu suất). Mã tái cấu trúc không làm điều này theo cách có thể đo lường trực tiếp.

Điều tôi đã chứng kiến ​​tại các công ty hiểu và quan tâm đến chất lượng mã là các nhà phát triển được khuyến khích tái cấu trúc mã khi họ làm việc. Nếu bạn định thay đổi tập tin bằng mọi cách, bạn cũng có thể dọn sạch nó trong khi bạn ở đó. Thêm kiểm tra đơn vị, tái cấu trúc, chạy một công cụ phân tích tĩnh, v.v.

Điều này có hai mục đích. Đầu tiên, mã được tích cực cải thiện theo thời gian mà không ủy thác nhiệm vụ đó cho bất kỳ nhà phát triển nào. Thứ hai, thời gian chỉ dành để cải thiện mã cần phải thay đổi. Nếu bạn có các mô-đun mã sẽ không bao giờ được chạm vào nữa, sẽ không có nhiều ý nghĩa trong việc dành thời gian để duy trì chúng. Họ sẽ không cần nó. Tốt hơn là dành ít thời gian hơn bằng cách chỉ tái cấu trúc những mô-đun có khả năng thay đổi nhất trong tương lai.

Nếu một lập trình viên biết người khác sẽ tái cấu trúc mã của họ - anh ấy / cô ấy sẽ KHÔNG BAO GIỜ phải cấu trúc lại công việc của chính họ. Thiết lập một nhóm riêng để tái cấu trúc giống như biện minh cho mã chất lượng kém hiện có ở nơi đầu tiên. Nó giống như thừa nhận rằng sẽ có vấn đề và sau đó sửa đổi cấu trúc tổ chức của công ty bạn để phục vụ cho nó. Tôi ngưỡng mộ niềm đam mê của bạn đối với mã chất lượng, nhưng có lẽ trong trường hợp này tốt hơn là nói "không phải việc của tôi". Tái cấu trúc nên là một bởi người lập trình viết mã, chứ không phải bởi bên thứ 3 đã không viết nó.

Chúa không, đừng làm điều này. nghĩ về việc ở vị trí khác - bạn viết mã, bạn cam kết, bạn làm một số công việc khác, sau đó bạn được yêu cầu thực hiện một số lỗi trên mã của mình, vì vậy bạn nhận thấy nó đã được cập nhật, hãy kiểm tra và thấy rằng nó có không giống với những gì bạn đã viết ban đầu.

Bạn cũng mất rất nhiều khả năng truy nguyên trong SCM - tất cả những phương thức được di chuyển và đổi tên có nghĩa là mã bạn kết thúc không có dấu vết trực tiếp với bản gốc, nó thường xuất hiện quá nhiều để sử dụng các khác biệt.

Vì vậy, tất cả những gì bạn đang làm là chọc tức mọi người rằng bạn quét vào và nhấp vào một vài công cụ tái cấu trúc trong IDE của bạn, sau đó nói với các lập trình viên khác rằng bạn đã cải thiện nó cho họ. Kiểu như Slashdot nơi bạn thỉnh thoảng khiến mọi người trả lời những câu trả lời mỉa mai cho bài đăng của bạn với "ở đó, đã sửa nó cho bạn". Nó có thể ổn nếu nó hài hước trên /., Sẽ không phải là nếu bạn đã làm điều đó với mã của tôi - Tôi sẽ nói với bạn rằng đó là của riêng bạn từ đó trở đi và bạn có thể thực hiện bảo trì nó.

Bây giờ, nếu bạn đang thực hiện công việc thực sự về mã, thì khác, nhưng việc tái cấu trúc cho riêng nó, ngay cả theo hướng dẫn "bảo trì" sẽ chỉ gây khó chịu cho những người khác và điều đó sẽ tăng gấp đôi cho "muốn nhóm / bộ phận của tôi được công nhận bởi ban quản lý và các nhóm khác với vai trò này một cách chính thức "- bạn có thể nói" điều động chính trị "không? Bạn có thể tưởng tượng những gì các bộ phận khác sẽ nói khi mã của họ gặp sự cố trên trang web của khách hàng? "Thật tốt khi chúng tôi chạm vào nó lần cuối, nó phải là bộ phận tái cấu trúc đã phá vỡ nó, họ đã chạm vào nó lần cuối."

Những gì bạn có thể thử là thuyết phục ban quản lý rằng các phần khác nhau của phần mềm cần được chú ý nhiều hơn, đưa các phần kém lên và xem liệu họ có dành thời gian để cải thiện phần mềm không. Trong khi điều này xảy ra, bạn có thể đề nghị bạn lấy một số nhóm cốt lõi khác khối lượng công việc khác để thêm các tính năng cho sản phẩm cốt lõi. Tôi nghi ngờ bạn sẽ cố gắng triển khai lại chức năng cốt lõi cho họ, nhưng bạn sẽ tăng khả năng của bộ phận để thêm các tính năng có thể được đẩy trở lại vào nhóm cốt lõi, sau đó bạn sẽ chịu trách nhiệm nhiều hơn.

Nó phụ thuộc vào những gì bạn thực sự có nghĩa là bằng cách tái cấu trúc và bảo trì - cả về lý thuyết và thực tế.

Chúng tôi đã từng có một nhóm dành riêng cho việc dọn mã và sửa lỗi. Nó đã không hoạt động tốt như vậy, bởi vì, không ngạc nhiên, các nhà phát triển giỏi không muốn dành toàn bộ thời gian của họ để làm sạch mã và sửa lỗi.

Một số tổ chức chọn để có một nhóm "công nghệ phần mềm" chuyên dụng, họ sẽ có xu hướng dành nhiều thời gian cho việc xem xét mã và cố vấn cho các nhà phát triển ít cấp cao hơn về các thực tiễn tốt. Tuy nhiên, đây không phải là một nhóm kỹ thuật thực sự trừ khi nó tham gia nhiều vào các kế hoạch dự án, kiến ​​trúc, kế hoạch thử nghiệm, quy trình phát hành, v.v. Điều quan trọng là phải có cách tiếp cận toàn diện này, và tốt nhất là đào tạo về phần mềm hoặc kỹ thuật khác, mặt khác, nó có xu hướng chuyển sang "dọn dẹp" ở trên.

Điểm mấu chốt, các nhà phát triển không tạo ra người điều khiển tốt trong một đoạn đường dài. Và ngay cả khi bạn có một nhóm kỹ thuật thực thụ, cách tiếp cận đó có xu hướng hoạt động tốt hơn với các nhóm chức năng chéo, nếu không, các nhóm khác có thể bắt đầu phớt lờ hoặc thậm chí phẫn nộ nỗ lực, xem nó như một tháp ngà.

Đừng có một phòng đầy các nhà phát triển không làm gì ngoài việc tái cấu trúc và nghiên cứu lại. Nó sẽ không kết thúc tốt đẹp.

Thông thường khi mọi người thực hiện tái cấu trúc, mọi người đều sử dụng tái cấu trúc cơ hội . Vì vậy, tôi không nghĩ rằng bạn sẽ tìm thấy một tên chung cho một thực hành không phổ biến như vậy.

Nhưng trong tình huống bất thường của bạn, mặc dù có tất cả mọi người tái cấu trúc có thể là lý tưởng, nhưng có vẻ như nó sẽ có ý nghĩa để thử nó.

Tuy nhiên, những vấn đề chính trị tương tự hiện đang ngăn cản mọi người tái cấu trúc mã của riêng họ rất có thể sẽ khiến bạn thất vọng (đó có lẽ là một phần lý do tại sao không có tên cho những gì bạn đang nghĩ đến). Các đội khác sẽ ổn khi bạn "cải thiện" mã của họ chứ? Điều gì xảy ra khi lần đầu tiên bạn giới thiệu một lỗi trong quá trình thực hiện một công việc quản lý nào đó không được coi là có giá trị ngay từ đầu? Điều gì xảy ra khi một nhóm khác không thích thiết kế mới của bạn?

Bạn không thể đảm bảo rằng bạn sẽ không bao giờ tốn một đội khác một thời gian. Và hầu như bất kỳ đối số nào cho thấy bạn sẽ có hiệu ứng tích cực ròng cũng có thể được áp dụng để cho phép họ tự cấu trúc lại.

Có thể những gì bạn đang đề xuất sẽ được chấp nhận nhưng vẫn không cho phép mọi người tái cấu trúc khác - nhưng cách duy nhất tôi có thể hình dung điều này xảy ra là nếu mọi người về cơ bản đồng ý rằng tái cấu trúc là một điều tốt giúp tiết kiệm thời gian trong thời gian dài nhưng mất thời gian ngắn hạn và nhóm của bạn là người duy nhất có đủ thời gian rảnh trong thời gian ngắn. Và nếu các đội khác tin tưởng bạn thực hiện tái cấu trúc và sẵn sàng đối phó với bất kỳ vấn đề nào mà nó gây ra cho họ.

Có một nhóm chỉ tập trung vào tái cấu trúc và duy trì và thực hiện nó với chi phí của các nhóm phát triển khác là nguy hiểm cho tổ chức của bạn. Cần phải có một cam kết từ quản lý cấp trên, người kiểm tra và tất cả các nhóm phát triển để cải thiện chất lượng mã thông qua tái cấu trúc để cải thiện khả năng bảo trì và giảm thiểu lỗi. Trách nhiệm của mọi người là cải thiện mã. Khi tái cấu trúc cần phải được thực hiện, sau đó nó nên được đưa vào lịch phát hành cùng với các tính năng mới. Các nhà quản lý cần được giáo dục và hiểu rằng việc dành thời gian để cải thiện mã sẽ được đền đáp trong thời gian dài, bởi vì nợ kỹ thuật là thứ sẽ khiến sản phẩm bị đình trệ nếu không được thanh toán như một phần của quá trình phát triển đang diễn ra. Nếu tất cả những gì bạn đang làm là liên tục chống lại các đám cháy từ việc sửa lỗi liên tục,

Nhóm của bạn nghe có vẻ giống như một nhóm nhân viên kiến ​​trúc / phần mềm chuyên phát triển kiến ​​trúc thế hệ tiếp theo sẽ dễ bảo trì hơn. Nhóm của bạn có lẽ nên tập trung vào cách chứng minh rằng tái cấu trúc trả tiền cho các loại "tóc nhọn", khuyến khích các nhà phát triển với các phương pháp và quy trình mới và giáo dục các bên liên quan chính trong quản lý để áp dụng chất lượng mã tốt hơn và khiến họ "mua vào" đến quá trình. Hãy đưa ra một kế hoạch để di chuyển các sản phẩm sang một kiến ​​trúc tốt hơn nếu có bất cứ điều gì bằng cách đặt một nền tảng đơn giản trước tiên. Hãy học những bài học đau đớn mà mọi người đã học được từ việc hỗ trợ các sản phẩm của bạn và đưa ra một kế hoạch để giảm bớt nỗi đau đó trong tương lai.

Nó khá phổ biến. Tôi đã làm việc tại một công ty phần mềm nơi đây là chuẩn mực. Bạn đã có các nhóm dành riêng để thực hiện chức năng mới. Sau đó, có một đội bảo trì đã sửa lỗi gây ra sự cố cho khách hàng. Nhóm bảo trì thuộc chi nhánh tư vấn / hỗ trợ của tổ chức.

Trong trường hợp đó, có những lợi ích cho các nhà phát triển, cụ thể là họ làm việc chặt chẽ hơn với khách hàng, thậm chí dành thời gian trên trang web. Các nhóm sản phẩm đang thực hiện phát triển mới hoàn toàn không tương tác với khách hàng (một tình huống đáng ghét imo).

Nó có vẻ phổ biến hơn trong các công ty phần mềm và các nhà cung cấp thuê ngoài mà trong việc cung cấp nhà. Tôi đang ở trong lĩnh vực tài chính và tôi chỉ có thể nghĩ về một ngân hàng đã sử dụng cấu trúc này trong quá khứ. Điều đó nói rằng, thông thường là các đội chiến thuật có thể xử lý các loại vấn đề đó như là một phần của bài đăng của họ. Nó không hoàn toàn giống nhau, nhưng tương tự.

Nếu nhóm của bạn đang bị sử dụng kém, bạn cần cẩn thận một chút. Việc sử dụng dưới mức có thể được dịch thành "chi phí không cần thiết" khá dễ dàng, vì vậy nhóm X của bạn có thể trở thành một nhóm X-1 khá nhanh chóng.

Một cách tiếp cận thích hợp hơn có thể là dành thêm một chút thời gian cho các bản sửa lỗi và kết hợp một số thời gian tái cấu trúc không thành công vào thời gian sửa lỗi.

Nó phụ thuộc vào cách công ty của bạn làm việc mặc dù. Điều thú vị là bạn không thực sự biết, vì vậy nếu bạn có một nhóm trưởng, sẽ đáng để thảo luận với họ. Nếu họ không biết, hãy để họ nói chuyện với người tiếp theo trong chuỗi (hãy tham gia vào đó, đừng bỏ qua). Nếu họ không biết liệu điều đó có phù hợp với những gì quản lý mong đợi hay không, bạn có thể rơi vào danh mục chi phí hơn là danh mục tài sản.