Làm cách nào để tìm hiểu phương pháp phù hợp để thực hiện một nửa tính năng? [đóng cửa]

Tôi lãnh đạo một nhóm phát triển và tôi muốn phát hành sản phẩm của chúng tôi thường xuyên nhất có thể (Giao hàng liên tục).

Trong nhiều trường hợp, chúng tôi phải triển khai một tính năng mất nhiều thời gian để thực hiện hơn thời gian giữa các lần phát hành. Tôi vẫn muốn mọi người cam kết mã của họ hàng ngày (Tích hợp liên tục).

Nhiều lần thực hiện một tính năng mới đòi hỏi phải thay đổi tính năng hiện có và tất nhiên, các tính năng hiện có vẫn cần phải hoạt động, ngay cả khi tính năng mới chưa kết thúc.

Nếu nhà phát triển sử dụng phương pháp phù hợp , họ có thể điều chỉnh các tính năng hiện có một cách cẩn thận và tất cả các điều trên không phải là vấn đề.

Tuy nhiên, đâu là cách tiếp cận đúng đắn? Tâm trí lập trình riêng của tôi cho tôi biết phải làm gì cho từng trường hợp riêng lẻ, nhưng tôi cần tìm hiểu thêm và tôi cần một số tài liệu đọc mà tôi có thể đọc và giới thiệu các thành viên trong nhóm để đọc. Hoặc bất kỳ phương pháp học tập đúng cách khác để học phương pháp này sẽ làm.

Vì vậy, đó là câu hỏi. Làm cách nào để đảm bảo các thành viên trong nhóm học cách tiếp cận đúng để thực hiện một nửa tính năng?

Tôi đã tìm kiếm những người tuyên bố có chiến lược liên quan đến vấn đề này, nhưng vẫn chưa tìm thấy nó, ngoại trừ những người viết một vài suy nghĩ ngẫu nhiên về chủ đề này. Có lẽ tôi không sử dụng đúng từ tìm kiếm hoặc có lẽ không ai đưa ra bất kỳ hướng dẫn chính thức nào về việc này.

Tôi có một cái nhìn khác với các câu trả lời khác ở đây rồi. Tôi đồng ý với bạn rằng bạn muốn tích hợp các thay đổi từ các nhà phát triển càng sớm càng tốt và để tiếp tục thử nghiệm kết hợp mã kết hợp.

Tuy nhiên, tôi không đồng ý rằng quyền gửi mã được phát triển sáng nay, chỉ vì chúng tôi sẽ phát hành vào chiều nay. Đó là một công thức cho những khách hàng thất vọng.

Giải pháp là có các nhánh trong cây điều khiển phiên bản của bạn và bạn có một quy trình riêng để quảng bá các vùng đồng bằng đã được xác minh từ nhánh phát triển sang nhánh phát hành.

Bằng cách đó bạn có được điều tốt nhất của cả hai thế giới. Bạn có các nhà phát triển thực hiện tích hợp liên tục và những lợi thế mang lại, bạn có mã vận chuyển ổn định thường xuyên cho khách hàng và bạn có một quy trình mới kiểm tra các tính năng đã hoàn thành trong nhánh nhà phát triển và nếu họ vượt qua thử nghiệm, hãy biến họ thành một phần của sản phẩm được phát hành .

Có hai công cụ mà tôi quen thuộc hỗ trợ tốt các loại quy trình này. Nếu cấu trúc phát triển của bạn đơn giản, thì git, với git-Flow thực hiện một cấu trúc phân nhánh tốt, hoạt động tốt trong các nhóm nhỏ đến trung bình (có thể là 20 nhà phát triển).

Đối với các nhóm phát triển lớn hơn hoặc khi cần một chiến lược phân nhánh phức tạp hơn để hỗ trợ nhiều "vòng quay" cho sản phẩm của bạn, thì chính xác là tốt nhất. Các nhà phát triển không tham gia vào việc quản lý các thay đổi sẽ phàn nàn rằng nó khó hơn phiên bản phụ, v.v ... nhưng nó hỗ trợ các môi trường phát triển phức tạp.

Có hai vấn đề ở đây: một là thực hiện một nửa tính năng; khác là giữ cho sản phẩm vận chuyển làm việc trong quá trình phát triển liên tục.

Thực hiện một nửa tính năng

Một thiết kế bao trùm mạnh mẽ sẽ giúp với điều này. Điều này cho phép bạn triển khai tính năng với các ranh giới được xác định rõ ràng - ví dụ: API cho các đoạn mã liền kề, kỳ vọng về cấu trúc dữ liệu và hiểu cách thức và thời điểm mã được triển khai sẽ được gọi.

Việc kiểm tra có thể bao gồm các phiên bản giả lập của mã cho các phần khác của tính năng; điều này giúp làm trơn tru quá trình chuyển đổi khi bạn thực hiện nửa sau.

Giữ cho sản phẩm vận chuyển làm việc

Có một số tùy chọn ở đây:

1. Tắt tính năng 'tắt' trong sản phẩm được vận chuyển. Chỉ vì mã trong sản phẩm không có nghĩa là nó phải được thực thi hoặc trình bày cho người dùng. Nhược điểm là bạn sẽ không cung cấp giá trị gia tăng cho người dùng của mình và bạn sẽ không nhận được phản hồi.
2. Tiết lộ các cạnh của tính năng cho người dùng của bạn. Hiển thị những gì bạn đã có, và cung cấp một số dấu hiệu về những gì sẽ đến.
3. Cho phép người dùng chuyển đổi giữa chức năng mới và cũ. Điều này đôi khi yêu cầu duy trì hai đường dẫn mã sẵn sàng cho người dùng cuối.

Cuối cùng, nếu bạn gặp sự cố với bất kỳ giải pháp nào trong số này, hãy xem xét liệu bạn có phân chia tính năng theo đúng ranh giới hay không. Nếu bạn cắt mọi thứ theo một cách khác, nó sẽ dễ dàng hơn để tách ra?

Làm cách nào để đảm bảo các thành viên trong nhóm học cách tiếp cận đúng để thực hiện một nửa tính năng?

Bằng cách dạy chúng. (tât nhiên)

Học tập sẽ liên quan đến việc lặp lại: thử một cái gì đó, xem cách nó hoạt động và sau đó sửa đổi cách tiếp cận của họ để đạt được kết quả tốt hơn. Đối với loại điều này, tôi sẽ ủng hộ đánh giá thiết kế / mã. Bạn có thể thấy cách một nửa tính năng được thiết kế / triển khai và có cơ hội đưa ra phản hồi. "Cái này và cái đó sẽ không hoạt động vì chúng sẽ phá vỡ CI của chúng ta, còn XYZ thì sao?", "Làm tốt ở đây, điều đó thực sự sạch sẽ."

Thực hiện các đánh giá như một nhóm sẽ giúp mọi người tìm hiểu những gì bạn đã biết bằng trực giác.

Điều lớn nhất sẽ giúp bạn ở đây là có một sự phân tách tốt các mối quan tâm để càng nhiều càng tốt một lĩnh vực mã không can thiệp vào một khu vực khác.

Đây là nơi sử dụng Dependency Injection và lập trình cho giao diện thực sự hữu ích, để bạn có thể triển khai ISupportingFeature hiện tại của mình trên trang web và sau đó khi bạn cần tạo INewFeature phụ thuộc vào cách triển khai khác, bạn chỉ cần phát triển với triển khai mới và duy trì cái hiện có trong sản xuất cho đến khi nó được thử nghiệm tốt và sẵn sàng để đi vào hoạt động. Giả sử bạn có DI làm việc với một hệ thống cấu hình nào đó, điều này sẽ cho phép bạn có cùng mã song song trong hệ thống của mình và luôn luôn sử dụng mã ổn định.

Trong thực tế, cách tiếp cận cấu hình này được Martin Fowler mô tả là Chuyển đổi tính năng.

Tất nhiên, vấn đề chỉ phát sinh nếu bạn đang triển khai tất cả các mã mọi lúc. Đây chính xác là loại kịch bản mà các nhánh tính năng được thiết kế và mặc dù tôi thừa nhận rằng ông Fowler cau mày với chúng, tôi không biết rằng tất cả chúng đều tệ, đặc biệt là nếu chúng được tạo ra và sử dụng theo kế hoạch và suy nghĩ- thông qua cách