Acabamos de encontrar uma daquelas situações que surgem ocasionalmente quando um desenvolvedor fica doente por alguns dias no meio do projeto.
Havia algumas perguntas sobre se ele havia cometido a versão mais recente de seu código ou se havia algo mais recente em sua máquina local que deveríamos examinar, e tínhamos uma entrega para um cliente pendente, portanto não podíamos esperar por ele voltar.
Um dos outros desenvolvedores fez logon como ele para ver e encontrou uma bagunça de espaços de trabalho, muitos aparentemente dos mesmos projetos, com registros de data e hora que deixavam claro qual deles era "atual" (ele estava prototipando alguns bits nas versões do projeto, exceto o seu "núcleo").
Obviamente, isso é um problema, mas a alternativa (que parece ser um padrão estrito para o modo como cada desenvolvedor trabalha em sua própria máquina para garantir que qualquer outro desenvolvedor possa entender as coisas com um mínimo de esforço) provavelmente quebrará muitos desenvolvedores de fluxos pessoais de trabalho e levam à ineficiência em nível individual.
Não estou falando de padrões para código de check-in, nem mesmo de padrões gerais de desenvolvimento, mas de como um desenvolvedor trabalha localmente, um domínio geralmente considerado (na minha experiência) quase totalmente sob o controle do próprio desenvolvedor.
Então, como você lida com situações como essa? É uma daquelas coisas que simplesmente acontece e você precisa lidar com o preço pago pelos desenvolvedores que podem trabalhar da maneira que melhor lhes convier?
Ou você pede aos desenvolvedores que sigam os padrões nessa área - uso de diretórios específicos, padrões de nomes, anotações em um wiki ou o que seja? E se sim, quais são os seus padrões, quão rigorosos eles são, como você os policia e assim por diante?
Ou há outra solução que estou faltando?
[Suponha, por uma questão de argumento, que o desenvolvedor não possa ser contatado para conversar sobre o que estava fazendo aqui - mesmo se pudesse saber e descrever qual espaço de trabalho é o que, da memória, não será simples e sem falhas e, às vezes, as pessoas realmente podem entre em contato e eu gostaria de uma solução que cubra todas as eventualidades.]
Edit: Eu entendo que passar pela estação de trabalho de alguém é uma má forma (embora seja uma pergunta interessante - e provavelmente fora de tópico - sobre o porquê disso) - e certamente não estou olhando para acesso ilimitado. Pense mais na linha de um padrão em que seus diretórios de código são configurados com um compartilhamento somente leitura - nada pode ser alterado, nada mais pode ser visto e assim por diante.
fonte
Respostas:
" Se não está no controle de origem, não existe. "
Essa é uma das poucas coisas em nossa profissão sobre as quais sou dogmático. Pelas seguintes razões:
Uma maneira possível de atenuar a questão de querer examinar o código nas estações de trabalho das pessoas é promover uma cultura de check-ins regulares. Eu trabalhei em uma empresa uma vez em que - embora não houvesse mandato oficial para fazê-lo - era uma espécie de orgulho sempre ter tudo registrado no fim de semana. Nas fases candidata de manutenção e liberação, os itens de RC foram deliberadamente muito refinados para permitir pequenas alterações visíveis de maneira limpa e check-ins regulares para acompanhá-los.
Além disso, era obrigatório ter tudo registrado antes de sair de férias .
Versão TL; DR : vasculhar as estações de trabalho das pessoas é uma má forma. Em vez de tentar fomentar uma cultura de facilitar o acesso às estações de trabalho das pessoas para encontrar o que queremos, é uma prática recomendada promover uma cultura de uso sensível do controle de fontes e check-ins regulares. Possivelmente até check-ins hiper-regulares e tarefas refinadas quando em fases críticas dos projetos.
fonte
Em vez de impor um padrão de como seus desenvolvedores organizam suas estações de trabalho, imponha um padrão em que todo o trabalho é verificado no final de cada dia . Os check-ins podem ser para filiais, se ainda estiverem incompletos.
Dessa forma, ninguém precisa acessar a estação de trabalho de outro desenvolvedor.
Eu imaginaria que essa política encontraria alguma oposição, mas nada comparado ao que eu esperaria se você aplicasse regras sobre a organização de uma estação de trabalho.
fonte
Vou lhe dizer a verdade que me sinto desconfortável com a própria idéia de que alguém fará logon na minha máquina e navegue pelas minhas coisas. Concedido, são os equipamentos e propriedades da empresa, mas é simplesmente uma coisa ruim a se fazer.
Na última vez em que saí para um fim de semana, os caras reconfiguraram os servidores com o banco de dados e o controle de origem e, por algum motivo, acharam necessário fazer login na minha máquina e reconfigurar o sistema para a nova configuração.
Pena que eles não tinham ideia do que estavam fazendo e apagaram um protótipo no qual eu estava trabalhando nos últimos dois meses.
Não teria acontecido se a comunicação adequada estivesse em vigor. É disso que você também precisa. Entre nesse desenvolvedor e descubra o estado das coisas. Melhor ainda, peça às pessoas um relatório antes que elas saiam, para que você tome uma decisão informada se precisa ou não de alguma delas.
Mas não mexa com as estações de trabalho das pessoas.
PS: Temos uma convenção para uma estrutura de diretórios, mas sua principal razão de existência é uma mistura de histórico / configuração - coloque-a em qualquer outro lugar e não será compilada.
fonte
Alguns meses atrás, eu estava trabalhando em um projeto bastante grande e tive que deixar o trabalho abruptamente quando descobri que estava sendo internado no hospital. Não tive tempo de verificar meu código mais recente para o projeto.
Felizmente, é uma convenção aqui (embora não seja "necessária") armazenar código
/var/www/ourdomain.compara imitar a produção. Com uma convenção tão lógica e fácil de seguir, foi fácil para um colega de trabalho fazer login na minha máquina e recuperar minhas alterações mais recentes.Eu acho que algumas convenções são boas. Embora eu concorde com Bobby quando ele diz
"Se não está no controle de origem, não existe."
Além disso, uma adição útil a qualquer espaço de trabalho de programadores pode ser uma unidade SATA de hot-swap de compartimento frontal na qual armazenar todos os projetos de origem e desenvolvimento. Dessa forma, se esse problema surgir, um funcionário poderá recuperar facilmente novas alterações de origem no projeto sem a necessidade de efetuar login na estação de trabalho dos desenvolvedores.
fonte
A primeira parte da sua pergunta identifica claramente os problemas de comunicação dentro da sua equipe. Você já tentou standups diários ?
Concordo com você quando diz que os padrões provavelmente levarão à ineficiência se forem muito rigorosos. Os padrões devem ser definidos pela equipe , envolvendo todos.
No seu caso, esperaria alguns dias após o desenvolvedor em questão retornar ao trabalho. Em seguida, organize uma reunião para conversar sobre esses padrões.
Para evitar bloqueios psicológicos e resistência, não nomeie pessoas ou coisas específicas que você viu. De maneira geral, o objetivo aqui é obter informações de todos, inclusive do desenvolvedor que você acha que deve melhorar sua maneira de trabalhar. O cara também pode considerar sua organização uma bagunça.
Durante a reunião, apresente o problema e pergunte claramente como a equipe pode melhorar a situação.
fonte
Esse usuário provavelmente estava sofrendo com a falta de ferramentas adequadas. Em particular, o uso de um sistema de controle de versão distribuído teria eliminado para ele a necessidade de ter diferentes diretórios de código em diferentes estados. Ele poderia ter mantido tudo isso em galhos e ter sido muito mais feliz.
Para o ponto principal, no entanto, não, não quero que sejam aplicados padrões sobre como eu organizo minha própria estação de trabalho. Atualmente, estou insistindo com a padronização de meu departamento em um IDE (meu chefe REALMENTE quer todos nós no Eclipse, porque é o que ele usa e conhece bem, embora a IMO não seja a melhor ferramenta para o meu trabalho).
Deixe os desenvolvedores fazerem o que os tornar confortáveis. Um desenvolvedor confortável é mais produtivo que um desconfortável. E se alguém NÃO é produtivo, e você suspeita que esteja mexendo localmente com as ferramentas, é uma oportunidade de treinamento, não um bom momento para fazer novas regras.
fonte
No meu antigo local de trabalho, tínhamos um sistema em que cada tarefa em nosso bugtracking tinha sua própria ramificação no controle de origem. Entendeu-se que na maioria das vezes, um bug / tarefa é esmagado por um desenvolvedor, permitindo que o código quebrado fosse verificado no controle de origem.
Uma vez que o código estava estável no ramo de desenvolvimento, foi feita uma nova reformulação, arrastando o código do ramo no qual você iria integrar. Depois de testar essa mesclagem, seria apenas o caso de confirmar o código para a ramificação de integração - não seria necessário mesclar, pois você já fez a mesclagem em sua ramificação.
Dessa forma, você salva o problema de os desenvolvedores se preocuparem em confirmar o código que está quebrado - e pode começar a aplicar a política social de tornar super aceitável fazer o check-in de código antes de sair do escritório à noite - agradável e seguro.
fonte
Em esta chamada situação particular da pessoa em casa, deixar bem claro que você não está duvidando de que ele está doente, mas você precisa ter alguém continuar o seu trabalho, e perguntar onde o material mais recente é e em que estado.
Então você precisa considerar o que fazer a partir daqui. Se o problema é que as pessoas fazem check-in muito raramente, considere usar um sistema de controle de fonte distribuído que permita que as pessoas trabalhem em filiais sem incomodar umas às outras.
Se o problema é que você não gosta de desenvolvedores com vários espaços de trabalho em suas máquinas, supere-os. O estilo de trabalho é individual e você deve basicamente ficar longe de seus sistemas, desde que funcionem bem com as regras do repositório de origem. Pessoalmente, faço check-out de uma nova cópia com muita frequência para projetos diferentes e só limpo de vez em quando.
Se o problema é que você não sabe o que seu desenvolvedor está fazendo, o problema é político, não técnico, e você precisa alterar seu estilo de gerenciamento. Lembre-se de que os desenvolvedores são pessoas altamente qualificadas que raramente gostam de microgerenciamento e você precisa delegar. Caso contrário, você afastará os indivíduos mais qualificados.
Portanto, eu recomendaria incentivar uma maneira melhor de trabalhar com o repositório de origem comum - diga que é bom que as pessoas trabalhem em filiais e permita que elas se comprometam com frequência, desde que sincronizem sua cópia local com o repositório principal diariamente (como sempre fará um trabalho de desenvolvimento em um ramo, isso não influenciará outros).
fonte
Você pode resolver esse problema com um sistema de controle de origem que suporte ramificações instáveis pessoais e mantendo confirmações frequentes. Uma consolidação não precisa ocorrer quando um problema inteiro é resolvido. Deve vir sempre que você se beneficia do controle de origem. O final do dia é um dos muitos pontos em que uma confirmação deve ocorrer, para que você possa ver onde suas alterações foram feitas, fazer backup delas e explicá-las ao seu futuro ou a outras pessoas.
Temos um imenso documento de configuração do ambiente que denota convenções, mas não um padrão. Os padrões são para código de produção e ambientes. No entanto, muitas de nossas ferramentas de desenvolvimento são configuradas para suportar as convenções e a maioria dos desenvolvedores não gasta esforços contrariando a tendência.
fonte