Uma empresa de software deve ter uma equipe dedicada para pesquisa e / ou bibliotecas de utilidades?

Trabalho em uma empresa que faz aplicativos da web para vários bancos e algumas lojas eletrônicas menores. Empregamos cerca de 20 desenvolvedores e temos 4-5 projetos em desenvolvimento a qualquer momento. Nossas equipes de desenvolvimento não interagem muito e muitos dos mesmos problemas são resolvidos de maneiras variadas (boas a ruins).

Fiquei pensando se seria uma boa idéia para uma empresa ter uma equipe de programadores que pesquisem as estruturas atuais e melhorem continuamente uma biblioteca comum de funções e uma estrutura comum para criar projetos atuais e futuros com muito mais rapidez e eficiência.

Qual o tamanho de uma equipe como essa?

Também deveria ter membros permanentes que treinam outras pessoas ou deveria alternar pessoas?

Atualização: Eu estava pensando em um projeto comum no qual as pessoas podem trabalhar por diversão que pode despertar algum interesse. Parece que quando as pessoas exercem pressão sobre o emprego, as soluções apresentadas não são as melhores.

Um ponto importante é que é impossível desenvolver uma boa estrutura em total isolamento. Boas estruturas crescem organicamente : quando um programador percebe que precisa de alguma funcionalidade específica, ele a adiciona à estrutura, e assim a estrutura cresce pouco a pouco - em vez de arquitetar uma "estrutura perfeita" na frente, o que nunca funciona, porque o arquiteto não pode estar ciente de que, eventualmente, aparecerão casos de uso.

É claro que o crescimento orgânico da estrutura tem a desvantagem de que sua integridade interna pode não ser muito boa e se transforma em espaguete. Se sua equipe mantiver uma boa comunicação interna, poderá combinar o melhor dos dois mundos: uma equipe de arquitetos separada, mantendo a integridade da estrutura, mas construindo para as necessidades reais dos usuários finais (desenvolvedores).

Meu sentimento é não.

O que eu suspeito que você encontraria se fizesse isso é que, em vez de equipes individuais produzindo bibliotecas que ninguém fora da equipe usava, você teria uma equipe especializada produzindo bibliotecas que ninguém fora da equipe usava (e fazendo isso a um custo adicional considerável).

Existem vários problemas com o tipo de equipe que você descreve, mas para mim o principal é que ele não trata do problema que você realmente tem.

O problema que você tem não é quem produz as bibliotecas (pelo som de coisas que você já tem muitas soluções para esses problemas, então como mais uma vai ajudar?), É que as equipes não estão conversando e interagindo.

Existem boas razões pelas quais as equipes não reutilizam o código umas das outras (por exemplo, que os problemas, embora superficialmente similares, são sutilmente diferentes, ou que o tempo do projeto simplesmente não permite a dependência adicional de desenvolver algo juntos), mas você precisa veja como você pode fazer com que eles interajam quando possível.

Eu sugiro:

• alternar equipes entre projetos
• realizar almoços entre equipes e grupos de discussão
• postar revisões do projeto abordando como os problemas foram resolvidos (com a participação de outras equipes)
• configure uma área do código de estrutura de tópicos da wiki que possa ser reutilizável (e com quem falar sobre isso)
• pense em incentivar uma boa reutilização - pague seriamente as pessoas a mais por isso. Se a reutilização de um componente economizar 5 dias e US $ 2000 em custos, por que não dar US $ 200 do que agora é lucro extra à equipe para uma noite no final do projeto (quando você validou a economia como genuína)

Uma equipe de bibliotecas seria, suspeito, sem custos adicionais.

Em termos de ser um projeto comum em que os desenvolvedores trabalham por diversão - nenhuma empresa deve confiar em programadores trabalhando nas coisas em seu próprio tempo. Isso é apenas horas extras não remuneradas e, de qualquer forma, não é confiável, pois provavelmente haverá grandes períodos em que ninguém deseja trabalhar nas coisas.

Se você está dizendo que seriam pessoas trabalhando no tempo da empresa entre os projetos, talvez possa funcionar, mas ainda não acho que seja o problema real. Você ainda precisa descobrir como vai levar as pessoas a usar as bibliotecas. Como eu disse, você já tem soluções para esses problemas que estão sendo desenvolvidos em cada projeto. Seu problema é por que eles não estão sendo compartilhados.

Esse é o trabalho de um arquiteto .

As principais responsabilidades de um arquiteto de software incluem:

• Limitando as opções disponíveis durante o desenvolvimento, escolhendo uma maneira padrão de buscar o desenvolvimento de aplicativos
• criando, definindo ou escolhendo uma estrutura de aplicativo para o aplicativo
• Reconhecendo o potencial de reutilização na organização ou no aplicativo Observando e compreendendo o ambiente mais amplo do sistema
• Criando o design do componente Tendo conhecimento de outros aplicativos na organização

Leia mais sobre: ​​- Arquiteto de software - Arquiteto de soluções - Arquiteto corporativo .

O ditado " Comer sua própria comida de cachorro " aborda esse problema. Se seu codificador top-cool-rockstar dá à luz uma biblioteca que ele nunca usou na prática, como ele pode dizer que é uma boa?

As principais razões para desenvolver funcionalidades em framework são:

1.É útil para o desenvolvedor
2. Existem alguns casos em que tem sido útil
3. Pode ser útil para outras pessoas

Quando você clica em 2, a funcionalidade já está lá, como você pode passá-la para outra pessoa?

Estou um pouco atrasado para o jogo, mas senti que ninguém estava abordando isso:

Suas equipes individuais que estão resolvendo problemas diferentes de maneiras diferentes definitivamente se beneficiariam da funcionalidade compartilhada, e há várias maneiras de conseguir isso de uma maneira que não dedique uma única equipe ao desenvolvimento, mas eu já vi muitas de lugares que fazem.

Na maioria dos casos, eu vejo isso como um "núcleo" da sua linha de produtos e, às vezes, há uma equipe encarregada de mantê-la, liderada por (como Amir sugeriu) um arquiteto. Geralmente, é assim que você pode encontrar maneiras de alavancar ou criar uma estrutura que segue os padrões mais rígidos que você define em sua organização, mas fornece apenas as funcionalidades mais simples que podem ou não precisar ser estendidas para os aplicativos de pleno direito que suas equipes de produtos individuais oferecem. Isso permite que você tenha o benefício de "dogfooding" seu código principal, implementando-o em todos os lugares individuais em que você o usa e, em seguida, também se ramifique para produtos diferentes que podem ter implementações completamente diferentes. Isso permite que todas as suas equipes contribuam para as bibliotecas principais, mas não atolem na funcionalidade necessária apenas para elas.

Eu acho que isso NÃO É UMA BOA IDÉIA , porque para as bibliotecas serem úteis, elas têm que ajudá-lo a resolver problemas reais do projeto, e você só as conhece, bem ... trabalhando em projetos reais.

Caso contrário, você pode terminar com uma biblioteca "teoricamente" muito boa!

Na única empresa em que trabalhei, realmente havia algo parecido, não parecia funcionar bem. As pessoas da equipe interna apresentavam uma idéia interessante e criavam um protótipo que funcionava principalmente; depois, ele ultrapassava os limites e era esperado que o transformassemos em um produto.

O que eu esperaria que acontecesse é que o grupo de ferramentas acabaria desenvolvendo seu próprio pequeno programa, produzindo funções que não eram realmente tão úteis, mas que sobrecarregavam a API e eram usadas o suficiente para que não pudessem ser facilmente removido. Eles não documentariam adequadamente.

Se o grupo de ferramentas estivesse suficientemente sob um arquiteto de sistema que estivesse em contato contínuo com as pessoas que realmente usavam as ferramentas, ele poderia funcionar. Se o grupo de ferramentas girasse com frequência (o que dificultaria muitas pesquisas externas), poderia funcionar. No entanto, eu teria medo de perder contato com as pessoas que pagam.

Quanto tempo você gasta em debater se o uso da estrutura será ou não um benefício em todos os casos? Um projeto fica atrasado ao aguardar a atualização da estrutura? Em algum momento, o uso da estrutura deve ser necessário para justificar sua existência.