Existe uma função de "grupo de refatoração / manutenção" nas empresas de software?

Então, eu trabalho em uma empresa que faz desenvolvimento de software incorporado, outros grupos se concentram no desenvolvimento principal de software de diferentes produtos e meu departamento (que está em outra localização geográfica), localizado na fábrica, também tem que lidar com o desenvolvimento de software , mas em todos os produtos, para que também possamos corrigir as coisas mais rapidamente quando as linhas caírem devido a problemas de software com o produto.

Em outras palavras, somos generalistas, enquanto outros grupos se especializam em cada produto.

O problema é que é meio difícil se envolver no desenvolvimento central quando você está distribuído geograficamente (bem, eu sei que realmente não é tão difícil, mas pode haver barreiras culturais / políticas não intencionais quando se trata da disciplina de colaborar remotamente )

Então eu percebi que, como atualmente estamos apenas apagando incêndios e sendo um pouco ociosos / subutilizados (mesmo sendo um departamento novo, ou talvez esse seja o motivo), pensei que um bom papel para nós poderia ser detectar áreas oportunidade de refatorar e refazer a arquitetura do código e todas as outras implementações que possam ter relação com a manutenção e a modularidade da administração. Outros grupos não estão focados nisso porque não têm tempo e têm prazos agressivos, que prejudicam a qualidade do código (história eterna de projetos de software)

O fato é que quero que meu grupo / departamento seja reconhecido oficialmente pela gerência e outros grupos com essa função, e estou tendo problemas para encontrar uma boa definição / identidade de nosso grupo para esse assunto.

Então, minha pergunta é: esse papel é algo que já existe? Ou sou o primeiro a inventar algo assim?

Edit : O que quero dizer é um grupo que dirige iniciativas de refatoração, não fazendo todo o trabalho de refatoração. Muito parecido com uma comunidade de código aberto para um produto de código aberto, agora que penso nisso.

Nunca ouvi isso em nenhuma empresa em que trabalhei ou entrevistei. Normalmente, as empresas desejam pagar por novos recursos ou alterações que tenham melhorias mensuráveis ​​para os usuários finais (como melhorias de desempenho). O código de refatoração não faz isso de uma maneira diretamente mensurável.

O que eu testemunhei em empresas que entendem e se preocupam com a qualidade do código é que os desenvolvedores são incentivados a refatorar o código enquanto trabalham. Se você quiser alterar um arquivo de qualquer maneira, é melhor limpá-lo enquanto estiver lá. Adicione testes de unidade, refatorar, execute uma ferramenta de análise estática, etc.

Isso tem dois propósitos. Primeiro, o código é aprimorado ativamente ao longo do tempo sem delegar essa tarefa exclusivamente a qualquer desenvolvedor. Segundo, o tempo é gasto apenas aprimorando o código que precisava ser alterado de qualquer maneira. Se você possui módulos de código que nunca serão tocados novamente, não faz muito sentido gastar tempo em mantê-los. Eles não vão precisar disso. Melhor gastar menos tempo refatorando apenas os módulos que provavelmente mudarão no futuro.

Se um programador souber que alguém refatorará seu código - NUNCA se preocupará em refatorar seu próprio trabalho. A criação de uma equipe separada para refatorar é como justificar o código de baixa qualidade existente em primeiro lugar. É como reconhecer que haverá problemas e depois modificar a estrutura organizacional da sua empresa para atender a ela. Admiro sua paixão pelo código de qualidade, mas talvez neste caso seja melhor dizer "não é meu trabalho". A refatoração deve ser feita pelo programador que escreve o código, não por um terceiro que não o escreveu.

Senhor não, não faça isso. pense em estar na outra posição - você escreve código, o compromete, faz algum outro trabalho e, em seguida, é solicitado a fazer algumas correções no código, para perceber que ele foi atualizado, confira e veja que ele possui sem semelhança com o que você escreveu originalmente.

Você também perde muita rastreabilidade no SCM - todos esses métodos movidos e renomeados significam que o código com o qual você termina não tem rastreamento direto para o original, geralmente parece alterado demais para usar as diferenças.

então, tudo o que você está fazendo é irritar as pessoas, para que você varra e clique em algumas ferramentas de refatoração no seu IDE e diga aos outros codificadores que você melhorou para eles. Como o Slashdot, onde você ocasionalmente leva as pessoas a responderem respostas sarcásticas à sua postagem com "lá, isso foi corrigido para você". Pode ser bom se for bem-humorado em /., Não seria se você fizesse isso com o meu código - eu diria que era sua a partir de então e você pode executar a manutenção.

Agora, se você está realizando um trabalho real no código, isso é diferente, mas refatorar por si só, mesmo sob o guia de "manutenção", vai irritar todo mundo, e isso vale duas vezes para o "quero meu grupo / departamento" ser reconhecido oficialmente pela gerência e outros grupos com esse papel "- você pode dizer" manobras políticas "? Você pode imaginar o que os outros departamentos dirão quando o código deles falhar no site do cliente? "Estava bom quando tocamos pela última vez, deve ter sido o departamento de refatores que quebrou, eles tocaram por último."

O que você pode tentar é convencer o gerenciamento de que várias partes do software precisam de mais atenção, trazer as partes ruins e ver se elas dedicarão tempo para melhorá-lo. Enquanto isso acontece, você pode sugerir que alguns dos grupos principais usem outra carga de trabalho para adicionar recursos ao produto principal. Duvido que você vá muito longe para reimplementar a funcionalidade principal para eles, mas aumentará a capacidade de seus departamentos de adicionar recursos que podem ser transferidos de volta ao grupo principal e obterá mais responsabilidade do desenvolvedor.

Depende do que você realmente quer dizer com refatoração e manutenção - tanto na teoria quanto na prática.

Costumávamos ter um grupo dedicado à limpeza de códigos e correções de erros. Não funcionou tão bem, porque, não surpreendentemente, bons desenvolvedores não querem gastar todo o seu tempo limpando código e corrigindo erros.

Algumas organizações optam por ter uma equipe dedicada de "engenharia de software", que tenderá a gastar bastante tempo na revisão de código e orientará os desenvolvedores menos seniores em boas práticas. No entanto, este não é um verdadeiro grupo de engenharia, a menos que esteja fortemente envolvido nos planos do projeto, arquitetura, planos de teste, processo de lançamento etc. É essencial ter essa abordagem holística e, de preferência, uma certa quantidade de treinamento em software ou outra engenharia, caso contrário, ele tende a se transformar na "limpeza" acima.

Resumindo, os desenvolvedores não são bons zeladores a longo prazo. E mesmo que você tenha um verdadeiro grupo de engenharia, essa abordagem tende a funcionar melhor com equipes multifuncionais; caso contrário, outras equipes podem começar a ignorar ou até se ressentir do esforço, vendo-o como uma torre de marfim.

Não tenha uma sala cheia de desenvolvedores que não fazem nada além de refatorar e re-arquitetar. Não vai acabar bem.

Geralmente, quando as pessoas fazem refatoração, todo mundo faz isso usando refatoração oportunista . Portanto, acho que você não encontrará um nome comum para uma prática tão incomum.

Mas, em sua situação incomum, mesmo que todo mundo refatorasse provavelmente seria o ideal, parece que faria sentido tentar.

No entanto, os mesmos problemas políticos que atualmente impedem as pessoas de refatorar seu próprio código provavelmente o derrubarão (o que provavelmente é parte do motivo pelo qual não há nome para o que você está pensando). Outras equipes ficarão bem com você "melhorando" o código delas? O que acontece na primeira vez em que você introduz um bug no curso de fazer algo que o gerenciamento não percebe como valioso em primeiro lugar? O que acontece quando outra equipe não gosta do seu novo design?

Você não pode garantir que nunca custará a outra equipe algum tempo. E quase todo argumento de que você terá um efeito positivo líquido também pode ser aplicado para permitir que eles se refatorem.

É possível que o que você está propondo seja aceitável, mas não permita que todo mundo refatorar, mas a única maneira de imaginar isso é se todos concordarem basicamente que a refatoração é uma coisa boa que economiza tempo a longo prazo, mas leva tempo no curto prazo e que sua equipe seja a única com tempo livre suficiente no curto prazo. E se outras equipes confiam em você para fazer as refatorações e estão dispostas a lidar com qualquer problema que isso lhes cause.

Ter um grupo que se concentra exclusivamente na refatoração e manutenção e implementá-lo às custas de outros grupos de desenvolvimento é perigoso para sua organização. É preciso haver um compromisso da alta gerência, testadores e todos os grupos de desenvolvimento para melhorar a qualidade do código via refatoração para melhorar a manutenção e minimizar os erros. Deve ser responsabilidade de todos melhorar o código. Quando a refatoração precisar ser feita, ela deverá ser incluída no cronograma de lançamento, juntamente com os novos recursos. Os gerentes precisam ser instruídos e entender que dedicar tempo para melhorar o código será recompensado a longo prazo, porque a dívida técnica é o que trará um produto a uma parada estridente se não for pago como parte do processo de desenvolvimento em andamento. Se tudo o que você está fazendo é combater constantemente incêndios devido à constante correção de bugs,

O grupo parece mais um grupo de funcionários de arquitetura / software dedicado ao desenvolvimento da arquitetura da próxima geração que será mais sustentável. Seu grupo provavelmente deve se concentrar em como demonstrar que a refatoração compensa aos tipos "de cabelos pontudos", incentiva os desenvolvedores com novos métodos e processos e educa as principais partes interessadas no gerenciamento a adotarem uma melhor qualidade de código e fazer com que elas se comprometam. para o processo. Crie um plano para migrar produtos para uma arquitetura melhor, se for o caso, estabelecendo uma base simples primeiro. Tire as dolorosas lições que todos estão aprendendo do suporte aos seus produtos e elabore um plano para mitigar essa dor no futuro.

Isso é bastante comum. Eu trabalhei em uma empresa de software onde essa era a norma. Você tinha equipes dedicadas à implementação de novas funcionalidades. Havia uma equipe de manutenção que corrigia bugs, causando problemas para os clientes. A equipe de manutenção pertence ao ramo de consultoria / suporte da organização.

Nesse caso, houve benefícios para os desenvolvedores, ou seja, eles trabalharam mais de perto com os clientes, passando um tempo no local. As equipes de produto que estavam desenvolvendo um novo desenvolvimento não interagiram com os clientes (uma situação odiosa).

Parece mais comum em empresas de software e fornecedores terceirizados do que em provisões internas. Estou no setor financeiro e só consigo pensar em um banco que usou essa estrutura no passado. Dito isso, é comum que as equipes táticas abordem esse tipo de problema como parte de suas atribuições. Não é exatamente o mesmo, mas semelhante.

Se sua equipe está sendo subutilizada, você precisa ter um pouco de cuidado. Subutilizado pode ser traduzido em "custo desnecessário" com bastante facilidade, para que seu time do X possa se tornar um time do X-1 rapidamente.

Uma abordagem preferível pode ser gastar um pouco mais de tempo nas correções e incorporar algum tempo de refatoração não escrito no tempo de correção de erros.

Depende de como sua empresa trabalha. O interessante é que você realmente não sabe, por isso, se você tem um líder de equipe, vale a pena discuti-lo com eles. Se eles não souberem, peça que conversem com a próxima pessoa na cadeia (envolva-se nisso, não o entregue). Se eles não souberem se isso se encaixaria com o que a gerência espera, você poderá cair ainda mais na categoria de custo, e não na categoria de ativo.