Como comunicar eficientemente o design de software entre os desenvolvedores? [duplicado]

5

Recentemente, entendi que um problema sério no meu local de trabalho é a falta de comunicação entre os desenvolvedores. É estranho, porque somos uma organização totalmente aberta. Todos podem ir a todos e perguntar o que precisam, e a comunicação dificilmente é regulada. E, no entanto, isso não acontece sozinho ...

O tipo de falta que me sinto mais profundamente é entre mim (o arquiteto do sistema, mais ou menos) e o resto dos desenvolvedores (que geralmente trabalham em uma parte da funcionalidade necessária, não na estrutura). Sempre que crio algum componente ou uma convenção de nomenclatura ou qualquer outra coisa ... não há como dar a conhecer a todas as pessoas que precisam saber disso. No máximo, eu digo pessoalmente ao sujeito que me pediu, mas é sobre isso.

Como resultado, as rodas são reinventadas, quase não existem convenções no código (a maioria evoluiu de copiar e colar), ocasionalmente codificação de cultos de carga, etc. Eu tento limpá-lo sempre que tenho a oportunidade, mas com Sendo a carga de trabalho tão grande quanto é, raramente existem essas chances. : (

Não sei bem como resolver isso. Eu poderia tentar documentar todas as coisas que foram criadas (provavelmente levaria pelo menos uma semana - difícil de orçamentar tanto tempo) em nosso wiki interno, mas quem sempre lê esses lugares regularmente por notícias? E como você descobriria se algo que você precisa já foi implementado em algum lugar?

O que outras pessoas fazem para evitar essa armadilha? Quais métodos se mostraram eficientes?

    
por Vilx- 26.11.2014 / 11:16
fonte

7 respostas

2

Eu uso duas coisas - minha voz e um quadro branco.

Quero dizer, por mais que desenvolvedores odeiem reuniões, você faz precisa trabalhar em equipe. Standups são ótimos momentos para falar sobre coisas novas que você está fazendo no código (e para perguntar se algo já existe). Para grandes coisas, a reunião de planejamento do sprint é um bom momento para toda a equipe fornecer informações para o projeto, para que todos saibam o que está acontecendo. E a reunião de demonstração do sprint é um bom momento para entrar em detalhes sobre como o design mudou desde o início do sprint. Na minha experiência, um quadro branco é a melhor ferramenta para comunicar esse design entre os desenvolvedores. Poucos são proficientes o suficiente para ler o código e ninguém lê a documentação (rapidamente obsoleta).

E para coisas particularmente grandes / complexas / sutis, você provavelmente precisará ter uma reunião dedicada para divulgar essas informações.

As revisões de código podem ajudar a ser uma última linha de defesa contra o esforço duplicado ou uso indevido / modificação incorreta do código. Mas eles pegam coisas depois de todo o trabalho estar feito. Ao ter um bom trabalho em equipe, você evita que o trabalho perdido seja feito por completo.

Não usa agile / scrum? Primeiro, minhas condolências. Em segundo lugar, a premissa ainda é válida. Você precisa falar em equipe - diário para pequenas coisas. E você precisa coordenar as coisas maiores periodicamente para que você trabalhe em equipe.

    
por 26.11.2014 / 13:53
fonte
1

Não há uma resposta simples.

Imagens grandes colocadas nas paredes podem ajudar. algo como os diagramas 4C (Contexto, Container, Componente, Classe) link (embora a classe seja provavelmente muito detalhada) p>

Eles podem ajudar a orientar as pessoas no código e entender o que existe.

As revisões de código podem ajudar a difundir boas práticas, mas fazê-las bem é uma arte. O revisado não deve se sentir sobrecarregado, e não deve (na maioria das vezes) ser um único guardião do repositório (por causa do problema de acertar um ônibus se não houver outro)

Além disso, standups e cartões são métodos para compartilhamento de conhecimento dentro da equipe, e uma equipe bem envolvida que quer melhorar a si mesma é a chave para todo o esforço!

    
por 26.11.2014 / 12:31
fonte
1

A resposta mais simples é a revisão de código (e por código revisões, eu realmente quero dizer "tudo relacionado a mudanças de código incluindo o próprio código). Obviamente isso significa que você terá que ter documentação.

Eu conheço lugares onde as pessoas estão hackeando todo o lugar, último lugar em que meu cônjuge trabalhava toda vez que ele aparecia para consertar um bug que ele pegava o código mais recente e ... isso mudaria. Uma equipe colocaria mudanças nessa direção e outra equipe colocaria as mudanças em uma direção diferente. Às vezes as equipes mudaram de direção sozinhas e você acabou com o caos puro, onde nada foi feito para o produto, mas houve mudanças de código constantes e intensas.

É aqui que você precisa de alguma forma de controle de alterações do tipo não desenvolvedor. Se você implementar um sistema onde as mudanças são feitas de forma controlada, e com isso quero dizer que qualquer um pode mudar alguma coisa, é só que eles precisam de alguma razão para fazê-lo e alguma forma de autorização de que é bom progredir.

Assim, você pode exigir que nenhuma alteração seja aplicada, a menos que seja em resposta a um ticket de mudança. (qualquer pessoa pode criar um ticket descrevendo um problema que precisa ser mudado, é claro), mas esses tickets são atribuídos a uma pessoa ou equipe por alguém encarregado da direção do produto - um analista de negócios ou autoridade técnica de design ou até mesmo uma reunião de equipe. O importante é que a mudança seja feita de maneira não individual.

Uma vez que isso seja resolvido, alguém irá fazer alterações e, em seguida, será revisado. Isso significa que outra pessoa vê o código, mas também as alterações e a documentação do ticket. Então, se você quiser mudar o seu sistema de acesso ao banco de dados, tudo bem ... mas você precisa descrever o que é, por que foi alterado e como funciona agora. Sem essa documentação, a alteração não é revisada. Depois, você pode implementar 'treinamentos' internos, como bolsas marrons ou dojos de código, para garantir que o restante da equipe seja informado.

Algumas pessoas resistirão a isso, mas tendem a ser as que constantemente mudam o código, "cortando código" em vez de "trabalhando no produto". Esta é uma distinção importante a ser feita, como desenvolvedores, todos nós podemos ser pegos no conceito de que o código é o que é importante - não é. O produto que você está construindo é o que é importante e isso é muito mais do que apenas código.

A documentação não precisa ser extensa, apenas o suficiente para dizer a outra pessoa o que você fez ou como ela funciona. Pode ser um wiki ou até mesmo apenas notas nos tickets - como os ingressos envelhecem, eles desaparecem de vista e a documentação com eles, mas isso é ok, pois isso significa que apenas os documentos atuais são mantidos. Alternativamente, você pode ter um wiki de componentes, arquitetura e uso, e isso é mantido atualizado como parte de cada mudança de código. Ou (minha preferência) é armazenar toda a sua documentação técnica junto com o código como documentos de texto em um formato de marcação que é embutido em html pelo servidor de compilação e apresentado em um servidor web - assim qualquer um pode ver a documentação atual que é facilmente atualizada quando código é atualizado.

Um último recurso é obter uma equipe de arquitetura que tem a responsabilidade de documentar o sistema, mas eles também terão o poder de impedir que qualquer alteração seja feita, a menos que a documentação seja atualizada primeiro - muitas equipes mais soltas podem não gostar disso abordagem, mas se eles não podem fazê-lo funcionar usando minhas sugestões, então este é o sistema que então teria que ser implementado.

    
por 26.11.2014 / 12:39
fonte
1

Existem (pelo menos) dois problemas ocultos neste problema comum. O primeiro é ter um processo que garanta que as comunicações apropriadas estão ocorrendo, e o segundo é garantir que os desenvolvedores realmente sigam o processo - que muitas vezes estão estressados para entregar e empolgados com a escrita de código, impulsionado pelo ego (geralmente em um bom caminho) etc.

O último, penso eu, é mais fácil de conseguir na prática do que o primeiro: separar o desenvolvimento dos testes de implantação (integração final) das pessoas responsáveis pela codificação, e não aceitar nenhum código no branch master até que ele passe por todos testes. Em seguida, independentemente de quanto ou pouco os desenvolvedores escutam ou acompanham o processo de comunicação, quaisquer alterações feitas não terão impacto no código implantado se os testes existentes forem interrompidos. Se os testes forem uma expressão verdadeira de todos os requisitos (funcionais e não funcionais) - incluindo o teste de que a nova funcionalidade não é adicionada sem a confirmação do teste - então este processo reforça a comunicação porque senão o código do desenvolvedor nunca vai qualquer lugar! O seu trabalho mínimo é, então, para comunicar quaisquer novos requisitos para os escritores de teste e garantir que eles sejam implementados em primeiro lugar.

O primeiro - isto é, o processo real de comunicação pode então se desenvolver com o tempo. Inicialmente, o uso do gate de qualidade do teste de integração completa mencionado acima antes de comprometer o master for permitido forçará as pessoas a procurarem você para perguntar sobre a funcionalidade e os requisitos, etc. o código de ninguém nunca será implementado e os desenvolvedores são motivados pela implantação. Você poderia então começar a trabalhar com mecanismos apropriados para comunicação, por exemplo reuniões scrum, ou ferramentas de colaboração como o Trello, ou listas de e-mail, ou revisões de código, ou reuniões diárias de discussão da história do usuário ou o que quer que funcione para sua estrutura de equipes.

Coloque o gate de qualidade de implantação independente no lugar primeiro e o restante, eventualmente, seguirá.

    
por 26.11.2014 / 12:59
fonte
1

I could try and document all the stuff that has been created…

Tenho que começar em algum lugar.

…who ever reads such places regularly for news?

Em seguida, use o email para notificar as alterações. Mantenha o SNR baixo.

Você precisará envolver as pessoas nas mudanças (incluindo o gerenciamento) e, em seguida, torná-las conscientes das alterações à medida que elas forem adotadas. Você pode querer sua entrada em algumas alterações. Caso contrário, basta flutuá-los em um email / atualização. Para tópicos mais complexos, reserve alguns minutos para explicar e o Q + A não muito depois de ter sido divulgado.

And how would you find if something that you need has already been implemented somewhere?

As revisões de código seriam um bom começo. Se as pessoas ainda não estiverem reutilizando o código, você deve entrar em estágios anteriores (ou seja, antes que o código seja escrito).

As a result, wheels get reinvented, there are hardly any conventions in the code…

Essa é a parte difícil. Ninguém quer tomar a iniciativa. Minha abordagem típica é realizar a mudança eu mesmo, flutuar, discutir se necessário, empurrar e aplicar (permissão de ferramenta).

Então, se são convenções de codificação:

  • faça um teste da próxima mudança importante na sua lista de tarefas
  • se isso for bem sucedido, flutue a alteração para os engenheiros
  • se houver dúvidas / preocupações, detalhe o caso da alteração no e-mail ou na reunião
  • push
  • impor (permissão de ferramentas)

É assim que costumo fazer isso, de qualquer maneira. Às vezes, tarefas maiores são divididas.

    
por 26.11.2014 / 22:39
fonte
0

Para equipes que fazem projeto e implementação OO, parte da comunicação deve ser uma compreensão compartilhada do espaço do problema e ferramentas típicas usadas para resolver esses problemas.

A noção de padrões de design foi criada muito especificamente para criar um vocabulário compartilhado que pode ser usado como mão curta quando se fala sobre os espaços problemáticos.

Eu não quero dizer o uso de padrões de design como uma forma de estender os horários de reunião com um enfadonho "não é o padrão xyzzy!" argumentos. Em vez de precisar discutir detalhadamente alguma implementação específica, os padrões de design nos permitem discutir o quadro maior e como as peças se encaixam.

    
por 26.11.2014 / 21:10
fonte
-3

É aqui que o DevOps entra em cena. Na verdade, isso destrói os silos entre os desenvolvedores e o pessoal de infraestrutura de TI. Então, todo mundo sabe o que está acontecendo em um projeto. Ninguém é deixado para trás.

Para sua solução, tente implementar a cultura de DevOps na sua organização.

    
por 26.11.2014 / 12:18
fonte