Làm thế nào nhóm của tôi có thể tránh các lỗi thường xuyên sau khi tái cấu trúc?

Để cung cấp cho bạn một nền tảng nhỏ: Tôi làm việc cho một công ty có khoảng mười hai nhà phát triển Ruby on Rails (+/- interns). Công việc từ xa là phổ biến. Sản phẩm của chúng tôi được tạo thành từ hai phần: lõi khá béo và mỏng cho các dự án khách hàng lớn được xây dựng dựa trên nó. Dự án khách hàng thường mở rộng cốt lõi. Ghi đè các tính năng chính không xảy ra. Tôi có thể thêm rằng lõi có một số phần khá xấu đang cần khẩn cấp tái cấu trúc. Có thông số kỹ thuật, nhưng chủ yếu là cho các dự án khách hàng. Phần tồi tệ nhất của lõi chưa được kiểm tra (không phải như vậy ...).

Các nhà phát triển được chia thành hai nhóm, làm việc với một hoặc hai PO cho mỗi lần chạy nước rút. Thông thường, một dự án khách hàng được liên kết chặt chẽ với một trong các nhóm và PO.

Bây giờ vấn đề của chúng tôi: Khá thường xuyên, chúng tôi phá vỡ mọi thứ của nhau. Ai đó từ Đội A mở rộng hoặc tái cấu trúc tính năng cốt lõi Y, gây ra lỗi không mong muốn cho một trong các dự án khách hàng của Đội B. Hầu hết, các thay đổi không được công bố qua các đội, vì vậy các lỗi xảy ra gần như luôn luôn bất ngờ. Đội B, bao gồm PO, đã nghĩ về tính năng Y ổn định và không kiểm tra nó trước khi phát hành, không biết về những thay đổi.

Làm thế nào để thoát khỏi những vấn đề đó? Bạn có thể giới thiệu cho tôi loại 'kỹ thuật thông báo' nào?

Tôi khuyên bạn nên đọc Làm việc hiệu quả với Bộ luật kế thừa của Michael C. Feathers . Nó giải thích rằng bạn thực sự cần kiểm tra tự động, làm thế nào bạn có thể dễ dàng thêm chúng, nếu bạn chưa có chúng và "mã mùi" để tái cấu trúc theo cách nào.

Bên cạnh đó, một vấn đề cốt lõi khác trong tình huống của bạn có vẻ như thiếu sự giao tiếp giữa hai đội. Những đội này lớn như thế nào? Họ đang làm việc trên các tồn đọng khác nhau?

Hầu như luôn luôn là thực hành tồi để phân chia các đội theo kiến ​​trúc của bạn. Ví dụ, một nhóm cốt lõi và một nhóm không cốt lõi. Thay vào đó, tôi sẽ tạo các nhóm trên miền chức năng, nhưng thành phần chéo.

Phần tồi tệ nhất của chúng tôi chưa được kiểm tra (vì nó phải là ...).

Đây là vấn đề. Tái cấu trúc hiệu quả phụ thuộc rất nhiều vào bộ kiểm tra tự động. Nếu bạn không có những thứ đó, những vấn đề bạn đang mô tả sẽ bắt đầu xuất hiện. Điều này đặc biệt quan trọng nếu bạn sử dụng ngôn ngữ động như Ruby, nơi không có trình biên dịch để bắt các lỗi cơ bản liên quan đến việc truyền tham số cho các phương thức.

Các câu trả lời trước đây chỉ cho bạn các bài kiểm tra đơn vị tốt hơn là tốt, nhưng tôi cảm thấy rằng có thể có nhiều vấn đề cơ bản hơn để địa chỉ. Bạn cần các giao diện rõ ràng để truy cập mã lõi từ mã cho các dự án của khách hàng. Bằng cách này nếu bạn cấu trúc lại mã lõi mà không thay đổi hành vi như được quan sát thông qua các giao diện , mã nhóm khác sẽ không bị hỏng. Điều này sẽ giúp dễ dàng hơn nhiều để biết những gì có thể được tái cấu trúc "một cách an toàn" và những gì cần, có thể phá vỡ giao diện, thiết kế lại.

Các câu trả lời khác đã nêu bật các điểm quan trọng (nhiều bài kiểm tra đơn vị, nhóm tính năng, giao diện sạch với các thành phần cốt lõi), nhưng có một điểm tôi thấy thiếu, đó là phiên bản.

Nếu bạn đóng băng hành vi của lõi bằng cách thực hiện bản phát hành ¹ và bạn đưa bản phát hành đó vào hệ thống quản lý nhân tạo riêng tư ² , thì bất kỳ dự án khách hàng nào cũng có thể tuyên bố sự phụ thuộc của nó vào phiên bản lõi X và nó sẽ không bị phá vỡ bởi phiên bản tiếp theo X + 1 .

"Chính sách thông báo" sau đó chỉ giảm bớt việc có tệp THAY ĐỔI cùng với mỗi bản phát hành hoặc có một cuộc họp nhóm để thông báo tất cả các tính năng của mỗi bản phát hành cốt lõi mới.

Ngoài ra, tôi nghĩ bạn cần xác định rõ hơn "lõi" là gì và tập hợp con nào là "khóa". Bạn dường như (chính xác) tránh thực hiện nhiều thay đổi đối với "các thành phần chính", nhưng bạn cho phép thay đổi thường xuyên thành "lõi". Để dựa vào một cái gì đó, bạn phải giữ nó ổn định; nếu một cái gì đó không ổn định, đừng gọi nó là cốt lõi. Có lẽ tôi có thể đề nghị gọi nó là thành phần "người trợ giúp"?

EDIT : Nếu bạn tuân theo các quy ước trong hệ thống Phiên bản ngữ nghĩa , thì mọi thay đổi không tương thích trong API của lõi phải được đánh dấu bằng thay đổi phiên bản chính . Đó là, khi bạn thay đổi hành vi của lõi hiện có trước đó hoặc xóa một cái gì đó, không chỉ thêm một cái gì đó mới. Với quy ước đó, các nhà phát triển biết rằng việc cập nhật từ phiên bản '1.1' lên '1.2' là an toàn, nhưng đi từ '1.X' đến '2.0' là rủi ro và phải được xem xét cẩn thận.

^{1: Tôi nghĩ rằng đây được gọi là đá quý, trong thế giới của Ruby
2: Tương đương với Nexus trong Java hoặc PyPI trong Python}

Giống như những người khác đã nói, một bộ kiểm tra đơn vị tốt sẽ không giải quyết vấn đề của bạn: bạn sẽ gặp vấn đề trong khi hợp nhất các thay đổi, ngay cả khi mỗi bộ kiểm tra nhóm vượt qua.

Tương tự đối với TDD. Tôi không thấy làm thế nào nó có thể giải quyết điều này.

Giải pháp của bạn là không kỹ thuật. Bạn cần xác định rõ ràng ranh giới "cốt lõi" và gán vai trò "chó canh gác" cho ai đó, có thể là nhà phát triển chính hoặc kiến ​​trúc sư. Bất kỳ thay đổi nào đối với lõi phải thông qua cơ quan giám sát này. Anh ấy có trách nhiệm đảm bảo mọi đầu ra từ tất cả các đội sẽ hợp nhất mà không có quá nhiều thiệt hại tài sản thế chấp.

Là một sửa chữa dài hạn hơn, bạn cũng cần giao tiếp tốt hơn và kịp thời hơn giữa các đội. Mỗi nhóm sẽ sử dụng, ví dụ, tính năng cốt lõi Y, cần tham gia vào việc xây dựng các bản thử nghiệm được lên kế hoạch cho tính năng này. Kế hoạch này, về bản thân, sẽ làm nổi bật các trường hợp sử dụng khác nhau vốn có trong tính năng Y giữa hai đội. Khi tính năng này hoạt động như thế nào được đóng đinh và các bản thử nghiệm được triển khai và đồng ý, sẽ có một thay đổi bổ sung trong sơ đồ triển khai của bạn. Nhóm phát hành tính năng được yêu cầu để chạy thử nghiệm, không phải nhóm sắp sử dụng tính năng này. Nhiệm vụ, nếu có, điều đó sẽ gây ra va chạm, là việc bổ sung một bản thử nghiệm mới từ một trong hai đội. Khi một thành viên trong nhóm nghĩ về một khía cạnh mới của tính năng chưa được thử nghiệm, họ nên được tự do thêm một bản thử nghiệm mà họ đã xác minh chuyển qua trong hộp cát của riêng họ. Theo cách này, các va chạm duy nhất sẽ xảy ra sẽ ở cấp độ ý định và nên được đóng đinh trước khi tính năng tái cấu trúc được phát hành vào tự nhiên.

Mặc dù mọi hệ thống đều cần các bộ kiểm thử hiệu quả (có nghĩa là, trong số những thứ khác, tự động hóa) và trong khi các thử nghiệm này, nếu được sử dụng hiệu quả, sẽ nắm bắt được các xung đột này sớm hơn hiện tại, nhưng điều này không giải quyết được các vấn đề tiềm ẩn.

Câu hỏi cho thấy ít nhất hai vấn đề tiềm ẩn: thực tiễn sửa đổi "lõi" để đáp ứng các yêu cầu cho từng khách hàng và sự thất bại của các nhóm trong việc giao tiếp và phối hợp ý định của họ để thay đổi. Cả hai điều này đều là nguyên nhân gốc rễ, và bạn sẽ cần phải hiểu tại sao điều này được thực hiện trước khi bạn có thể khắc phục nó.

Một trong những điều đầu tiên được xác định là liệu cả nhà phát triển và nhà quản lý có nhận ra có vấn đề ở đây hay không. Nếu ít nhất một số người làm, thì bạn cần tìm hiểu lý do tại sao họ nghĩ rằng họ không thể làm bất cứ điều gì về nó, hoặc chọn không làm. Đối với những người không, bạn có thể cố gắng tăng khả năng dự đoán hành động hiện tại của họ có thể tạo ra vấn đề trong tương lai hoặc thay thế họ bằng những người có thể. Cho đến khi bạn có một lực lượng lao động nhận thức được mọi thứ đang diễn ra như thế nào, bạn không có khả năng khắc phục vấn đề (và có lẽ thậm chí là không, ít nhất là trong thời gian ngắn.)

Có thể khó phân tích vấn đề theo thuật ngữ trừu tượng, ít nhất là ban đầu, vì vậy hãy tập trung vào một sự cố cụ thể dẫn đến sự cố và cố gắng xác định xem nó đã xảy ra như thế nào. Vì những người liên quan có khả năng phòng thủ, bạn sẽ cần cảnh giác với những lời biện minh tự phục vụ và hậu hoc để tìm hiểu điều gì đang thực sự xảy ra.

Có một khả năng mà tôi ngần ngại đề cập vì rất khó xảy ra: yêu cầu của khách hàng rất khác nhau đến mức không đủ điểm chung để biện minh cho mã lõi được chia sẻ. Nếu điều này là như vậy, thì bạn thực sự có nhiều sản phẩm riêng biệt và bạn nên quản lý chúng như vậy, và không tạo ra một khớp nối nhân tạo giữa chúng.

Chúng ta đều biết rằng các bài kiểm tra đơn vị là con đường để đi. Nhưng chúng ta cũng biết rằng thực tế phù hợp với những thứ này vào cốt lõi là khó khăn.

Một kỹ thuật cụ thể có thể hữu ích cho bạn khi mở rộng chức năng là cố gắng tạm thời và xác minh cục bộ rằng chức năng hiện tại không bị thay đổi. Điều này có thể được thực hiện như thế này:

Mã giả gốc:

def someFunction
   do original stuff
   return result
end

Mã kiểm tra tại chỗ tạm thời:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

Chạy phiên bản này thông qua bất kỳ bài kiểm tra cấp hệ thống nào tồn tại. Nếu mọi thứ đều ổn, bạn biết rằng bạn đã không phá vỡ mọi thứ và sau đó có thể tiến hành xóa mã cũ. Lưu ý rằng khi bạn kiểm tra kết quả cũ và kết quả mới, bạn cũng có thể thêm mã để phân tích sự khác biệt để nắm bắt các trường hợp mà bạn biết phải khác nhau do thay đổi có chủ đích như sửa lỗi.

"Hầu hết, các thay đổi không được công bố qua các đội, vì vậy các lỗi xảy ra gần như luôn luôn bất ngờ"

Vấn đề truyền thông có ai không? Điều gì về (ngoài những gì mọi người khác đã chỉ ra, rằng bạn nên kiểm tra nghiêm ngặt) để đảm bảo rằng có giao tiếp phù hợp? Mọi người được biết rằng giao diện họ đang viết sẽ thay đổi trong phiên bản tiếp theo và những thay đổi đó sẽ là gì?
Và cung cấp cho họ quyền truy cập vào ít nhất một giao diện giả (với triển khai trống) càng sớm càng tốt trong quá trình phát triển để họ có thể bắt đầu viết mã của riêng mình.

Nếu không có tất cả những điều đó, các bài kiểm tra đơn vị sẽ không làm được gì nhiều, ngoại trừ chỉ ra trong giai đoạn cuối cùng có một cái gì đó vượt trội giữa các bộ phận của hệ thống. Bạn muốn biết điều đó, nhưng bạn muốn biết điều đó sớm, rất sớm và để các nhóm nói chuyện với nhau, phối hợp nỗ lực và thực sự có quyền truy cập thường xuyên vào công việc mà nhóm khác đang thực hiện (vì vậy, thường xuyên cam kết, không phải là một khối lớn cam kết sau vài tuần hoặc vài tháng, 1-2 ngày trước khi giao hàng).
Lỗi của bạn KHÔNG nằm ở mã, chắc chắn không phải ở mã của nhóm khác mà không biết bạn đang làm rối tung giao diện mà họ đang viết. Lỗi của bạn là trong quá trình phát triển của bạn, thiếu giao tiếp và hợp tác giữa mọi người. Chỉ vì bạn đang ngồi trong các phòng khác nhau không có nghĩa là bạn nên cách ly mình với những người khác.

Chủ yếu, bạn có một vấn đề giao tiếp (có lẽ cũng liên quan đến vấn đề xây dựng đội ngũ ), vì vậy tôi nghĩ rằng một giải pháp cho trường hợp của bạn nên tập trung vào ... tốt, giao tiếp, thay vì các kỹ thuật phát triển.

Tôi chấp nhận rằng không thể đóng băng hoặc rẽ nhánh mô-đun lõi khi bắt đầu một dự án khách hàng (nếu không thì bạn chỉ cần tích hợp trong lịch trình công ty của bạn một số dự án không liên quan đến khách hàng nhằm cập nhật mô-đun lõi).

Vì vậy, chúng tôi còn lại với vấn đề cố gắng cải thiện giao tiếp giữa các đội. Điều này có thể được giải quyết theo hai cách:

• với con người. Điều này có nghĩa là công ty của bạn chỉ định ai đó là kiến trúc sư mô-đun cốt lõi (hoặc bất kỳ biệt ngữ nào tốt cho quản lý cấp cao), người sẽ chịu trách nhiệm về chất lượng và tính sẵn có của mã. Người này sẽ hóa thân vào cốt lõi. Do đó, cô sẽ được chia sẻ bởi tất cả các đội và đảm bảo sự đồng bộ thích hợp giữa họ. Hơn nữa, cô cũng nên đóng vai trò là người đánh giá mã được cam kết với mô-đun cốt lõi để duy trì sự gắn kết của nó;
• với các công cụ và quy trình làm việc. Bằng cách áp đặt Tích hợp liên tục vào lõi, bạn sẽ biến mã lõi thành phương tiện truyền thông. Điều này sẽ đòi hỏi một số nỗ lực trước tiên (bằng cách bổ sung các bộ kiểm tra tự động trên đó) nhưng sau đó các báo cáo CI hàng đêm sẽ là một bản cập nhật trạng thái tổng thể của mô-đun lõi.

Bạn có thể tìm hiểu thêm về CI như một quá trình giao tiếp ở đây .

Cuối cùng, bạn vẫn có vấn đề với việc thiếu đội ngũ làm việc ở cấp công ty. Tôi không phải là một fan hâm mộ lớn của các sự kiện xây dựng đội nhóm, nhưng đây có vẻ là một trường hợp hữu ích. Bạn có các cuộc họp toàn nhà phát triển một cách thường xuyên không? Bạn có thể mời mọi người từ các đội khác đến hồi tưởng dự án của bạn không? Hoặc có lẽ đôi khi có một số bia tối thứ sáu?