Como aprendo a abordagem correta para implementar metade de um recurso? [fechadas]

Lidero uma equipe de desenvolvimento e quero lançar nosso produto o mais rápido possível (Entrega contínua).

Em muitos casos, precisamos implementar um recurso que leva mais tempo para ser implementado do que o tempo entre os lançamentos. Eu ainda quero que as pessoas comprometam seu código diariamente (integração contínua).

Muitas vezes, a implementação de um novo recurso exige que o recurso existente seja alterado e os recursos existentes, é claro, ainda precisam funcionar, mesmo que o novo recurso ainda não esteja concluído.

Se o desenvolvedor usar a abordagem correta , poderá ajustar os recursos existentes com cuidado e todas as opções acima não são um problema.

No entanto, qual é a abordagem correta, na verdade? Minha própria mente sintonizada em programação me diz o que fazer para cada caso individual, mas preciso aprender mais e preciso de algum material de leitura que possa ler e indicar os membros da equipe para ler. Ou qualquer outro método de aprender a maneira correta de aprender essa abordagem serve.

Então essa é a questão. Como garantir que os membros da equipe aprendam a abordagem correta para implementar metade de um recurso?

Procurei pessoas que afirmam ter estratégias em relação a isso, mas ainda não as encontrei, exceto pessoas que escrevem algumas idéias aleatórias sobre o assunto. Talvez eu não esteja usando as palavras de pesquisa corretas ou talvez ninguém tenha feito nenhuma orientação oficial sobre isso.

Eu tenho uma visão diferente das outras respostas aqui já. Concordo que você deseja integrar as alterações dos desenvolvedores o mais rápido possível e continuar testando a combinação combinada de código.

No entanto, não concordo que o seu direito de enviar código tenha se desenvolvido nesta manhã, apenas porque estamos lançando esta tarde. Essa é uma receita para clientes decepcionados.

A solução é ter ramificações em sua árvore de controle de versão e que você tenha um processo separado para promover deltas verificados da ramificação de desenvolvimento até a ramificação de liberação.

Dessa forma, você obtém o melhor dos dois mundos. Você tem desenvolvedores fazendo integração contínua e as vantagens que isso traz, você tem o envio estável de código regularmente para o cliente e possui um novo processo que testa os recursos completos na filial do desenvolvedor e, se eles passarem no teste, fazem parte do produto lançado .

Conheço duas ferramentas que suportam bem esse tipo de processo. Se sua estrutura de desenvolvimento é simples, o git, com o git-flow, implementa uma boa estrutura de ramificação que funciona bem em equipes de pequeno a médio porte (talvez 20 desenvolvedores).

Para equipes de desenvolvimento maiores, ou onde uma estratégia de ramificação mais complexa é necessária para dar suporte a várias 'rotações' do seu produto, o precisrev é o melhor que existe. Os desenvolvedores não envolvidos no gerenciamento das alterações irão reclamar que é mais difícil do que a sub-versão etc ... mas suporta ambientes de desenvolvimento complexos.

Existem dois problemas aqui: um está implementando metade de um recurso; o outro é manter o produto da remessa funcionando durante o desenvolvimento contínuo.

Implementando metade de um recurso

Um forte design abrangente ajudará com isso. Isso permite implementar o recurso com seus limites claramente definidos - por exemplo, APIs para bits de código adjacentes, expectativas sobre estruturas de dados e uma compreensão de como e quando o código implementado será chamado.

Os testes podem incluir versões simuladas do código para as outras partes do recurso; isso ajuda a facilitar a transição quando você implementa a segunda metade.

Manter o produto de remessa funcionando

Existem algumas opções aqui:

1. Desative o recurso no produto enviado. Só porque o código está no produto não significa que ele deve ser executado ou apresentado aos usuários. A desvantagem é que você não fornecerá valor incremental aos seus usuários e não receberá feedback.
2. Revele as bordas do recurso para seus usuários. Mostre o que você tem e forneça algumas indicações do que está por vir.
3. Permita que os usuários alternem entre funcionalidades novas e antigas. Às vezes, isso exige a manutenção de dois caminhos de código prontos para o usuário final.

Finalmente, se você estiver tendo problemas com alguma dessas soluções, considere se você dividiu o recurso nos limites corretos. Se você cortasse as coisas de uma maneira diferente, seria mais fácil separá-las?

Como garantir que os membros da equipe aprendam a abordagem correta para implementar metade de um recurso?

Ensinando-os. (duh)

O aprendizado envolverá a iteração: tentar algo, ver como funciona e, em seguida, modificar sua abordagem para obter melhores resultados. Para esse tipo de coisa, eu defenderia as revisões de design / código. Você vê como o meio-recurso é projetado / implementado e tem a oportunidade de dar feedback. "Isso e aquilo não funcionam porque eles quebram o nosso IC; que tal XYZ?", "Bom trabalho aqui, isso é realmente limpo."

Fazer as revisões em equipe ajudará todos a aprender o que você já sabe intuitivamente.

A principal coisa que o ajudará aqui é ter uma boa separação de preocupações, para que, na medida do possível, uma área do código não interfira na outra.

É um local em que o uso da Injeção de Dependências e a programação na interface realmente ajudam, para que você possa ter sua implementação atual do ISupportingFeature no site e, quando precisar criar o INewFeature que depende de uma implementação diferente, você pode apenas desenvolver com o nova implementação e mantenha a existente em produção até que seja bem testada e pronta para ser lançada. Supondo que você tenha seu DI trabalhando em algum tipo de sistema de configuração, isso permitirá que você tenha o mesmo código em paralelo em seu sistema e esteja usando código estável o tempo todo.

De fato, essa abordagem de configuração é descrita por Martin Fowler como uma alternância de recursos.

Claro, o problema só surge se você estiver implantando todos do código de todos os tempos. Esse é precisamente o tipo de cenário para o qual as ramificações de recursos foram projetadas e, embora eu reconheça que o Sr. Fowler as franja de sobrancelhas, não sei se elas são tão ruins assim, especialmente se forem criadas e usadas de forma planejada e pensada. através do caminho.