Padrões de como os desenvolvedores trabalham em suas próprias estações de trabalho

18

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.

development-process coding-standards

— Jon Hopkins
fonte

8

-1 por acessar a Gestapo no centro de comando de um programador.

— systemovich

17

Espere, como o segundo desenvolvedor soube a senha do primeiro desenvolvedor?

— TheLQ

12

+1 para uma excelente pergunta. "Ir para a gestapo" não é relevante em um ambiente corporativo, na minha opinião, pois os desenvolvedores estão trabalhando para a corporação e, portanto, renunciam aos direitos de acesso às máquinas locais. Você quer privacidade, use seu próprio hardware.

— Gary Rowe

4

Se o desenvolvedor pudesse ser contatado para obter a senha, por que você não perguntou qual versão era a atual?

— Ben L

2

@ Gary: o que? não, isso é um absurdo completo (e muito perigoso). É muito fácil (logicamente e legalmente) trabalhar de uma empresa para abrir mão de direitos pessoais de privacidade. Eu não chamaria a ação de Jon “vai Gestapo” (mesmo antes de ele explicou mais) mas as empresas não vão Gestapo, por vezes, e isso é algo que precisa ser prevenido e combatido em todos os níveis. Só posso falar para a Alemanha, mas aqui você fazer têm certos direitos de privacidade, mesmo quando trabalhando em hardware de propriedade da empresa.

— Konrad Rudolph

64

" 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:

Embora a estação de trabalho seja propriedade da empresa, vamos ser sinceros - existe uma regra não escrita de que a estação de trabalho de um programador é o seu castelo. Estou pouco à vontade com uma cultura no local de trabalho onde qualquer pessoa pode fazer logon rotineiramente e passar por ela.
Todo mundo tem seu próprio fluxo (como você disse também). Tentar forçar todos os desenvolvedores a organizar seus próprios espaços de trabalho locais de uma certa maneira pode contrariar seu modo particular de trabalhar, interromper o fluxo e torná-los menos eficientes.
Coisas que não estão no controle de origem são códigos incompletos. Se o código estiver pronto para o lançamento, ele deverá estar no controle de origem. Que volta novamente ao ponto principal ....
"Se não está no controle de origem, não existe."

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.

— Bobby Tables
fonte

10

+1: alguém está doente, mexer na estação de trabalho provavelmente vai custar mais do que valor. Uma pessoa já se foi. Agora, outro está perdendo tempo tentando descobrir o que está acontecendo. Pesadelo enorme da gerência para nenhum valor. Até que esteja no controle de origem, ele nunca existiu.

— precisa saber é o seguinte

1

Se ele estiver de folga? Sim, pelo resto da semana? Talvez por um mês? Sem chance. Esse é um daqueles problemas desagradáveis "tons de cinza" ... estamos de volta, novamente, para confirmar cedo, confirmar com freqüência - para que os padrões não precisem necessariamente ser estações de trabalho, mas usar controle de versão, mas claramente é algo vale a pena pensar.

— Murph

Quando você diz release, você quer dizer release para a compilação ou release para os usuários?

— Jeffo

2

@ Murph: Se as alterações forem confirmadas em algum lugar a cada X dias, a quantidade máxima de trabalho que pode ser extraviada vale X dias, e isso é verdade, não importa quanto tempo o desenvolvedor esteja inevitavelmente ausente. A coisa certa a fazer é ter políticas sobre o check-in com freqüência suficiente para que a quantidade de trabalho perdido fique dentro dos limites aceitáveis.

— David Thornley 11/01

1

David, meu comentário foi uma resposta à de S.Lott - em termos da discussão sobre "perdido". Bem, mais ou menos. Quero que as confirmações sejam atômicas no sentido de um conjunto completo de mudanças (estou começando a entender por que rebase é uma noção tão atraente) - então vejo "comprometer-se a salvar" como problemático (na instância geral e na ausência equivalente a rebase). E, em qualquer caso, deve haver backups automatizados diários da estação de trabalho, bem diferentes do controle de versão.

— Murph

22

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.

— Kris
fonte

1

Com que frequência você mesclaria o ramo? Toda vez que você sentiu que era estável?

— 91111 Jon Hopkins

2

@ Jon Hopkins: "Releasable" é mais fácil de gerenciar do que "Stable". Liberável inclui estável, assim como o proprietário do produto está pronto para isso. E você fará muito processamento de ramificação para lançamento. Filial para estável tem muito potencial para subjetividade e discussão "trabalhou para mim".

— precisa saber é o seguinte

2

-1 Não concordo com isso sem uma grande quantidade de qualificação; os check-ins devem ocorrer em um ponto lógico - e não arbitrariamente no final do dia. (Sim, devemos procurar não sair até chegar a um ponto de interrupção sensato, mas a vida nem sempre coopera.) Os backups devem ser distintos. E todos nós precisamos ser um pouco menos precioso sobre o acesso aos nossos caixas (não muda para, acesso a)

— Murph

1

-1 porque isso não aborda cenários como "Sinto-me muito doente, estou indo para casa agora. Hum, é melhor fazer mais 30 minutos de preparação para não interromper a construção quando me comprometo".

— Gary Rowe

2

O @Murph Checkins no 'trunk' ou na linha principal (como você quiser chamá-lo) só deve ocorrer como você descreve. No entanto, não há nada de errado em ter os desenvolvedores 'salvando seu trabalho no final do dia' comprometendo-se com um ramo pessoal (embora isso seja muito mais fácil com o git ou mercurial do que com o SVN). E comparada à imposição de diretrizes sobre como as estações de trabalho dos desenvolvedores são configuradas (que foi nosso ponto de partida), é uma solução absolutamente sã.

— Kris

6

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.

3

@ Murph: Ficar "doente" acompanhado por uma necessidade urgente de obter algo do seu sistema é uma situação realmente rara. Pode não valer a pena nenhum esforço de padronização.

1

Entendo por que alguém deve ler seu e-mail e não deve alterar nada em sua máquina, mas e se fosse padrão compartilhar (somente leitura) seus diretórios de código? Isso contornaria a maior parte do que considero suas objeções, mas ainda permitiria às pessoas a possibilidade de chegar ao seu trabalho em caso de emergência.

— 91111 Jon Hopkins

3

Não há backup nesse protótipo?

— Jeffo

2

@ Art Developer, por que você não trabalhou em uma ramificação do sistema de versão?

1

@DeveoperArt, o que você quer dizer com "não usar essa opção"? Quer dizer que não havia como criar uma filial por conta própria? Eles de alguma forma desativaram a ramificação? Eu nunca ouvi falar dessa possibilidade. Mesmo assim, você poderia ter criado seu próprio repositório "git" (ou mesmo "svn") em sua própria máquina local (talvez com backup no Dropbox ou em uma unidade de rede) sem envolver mais ninguém. Eu simplesmente não consigo me relacionar pessoalmente com o trabalho em algo por 2 meses (ou até 2 horas , na verdade), seja "importante" ou não, e tendo apenas uma cópia.

— JoelFan

6

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.

— Craige
fonte

"... não existe". Para outros, é isso.

4

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.

A equipe (inteira) decide o que fazer.

2

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.

— Dan Ray
fonte

1

Como isso ajudaria? A questão ainda existiria, estaríamos apenas falando sobre qual ramificação dentro de seu repositório DVCS local e não sobre qual área de trabalho.

— Jon Hopkins

Não presuma que são as ferramentas - é também uma apreciação da melhor forma de usar as ferramentas que podem estar faltando. O que é óbvio para algumas precisa ser mostrado para outras. O anti-padrão de muitas cópias da árvore de origem é o que eu já vi algumas vezes. Sim, o DVCS pode ajudar - mas, nesse contexto, ainda temos um problema ao identificar a ramificação correta e - se quisermos ir além - disponibilizar essas ramificações do Work In Progress. @ O DVCS local deve enviar automaticamente o "backup" desse repositório para o usuário. No mínimo, se move o problema da sua caixa.

— Murph

@ Jon - Eu acho que o ponto é, seus diversos ramos estariam em algo que teria a funcionalidade de mesclagem incorporada a ele, em vez de apenas diretórios espalhados de arquivos divergentes. Além disso, levá-lo para o DVCS seria uma oportunidade de treinamento.

— Dan Ray

1

@ Dan - Mas alguns desses ramos são becos sem saída - provas de conceito, coisas com códigos de depuração variados, nas quais você não deseja mesclar versões mais antigas. O fato de você ter a funcionalidade de mesclagem não ajuda quando você não sabe o que deve ser mesclado.

— Jon Hopkins

@ Jon - Eu acho que é verdade. Talvez não se recupere de alguém realmente comprometido em fazer uma bagunça.

— Dan Ray

2

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.

— Spedge
fonte

2

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).

1

Eu disse especificamente na pergunta para supor que a pessoa não pode ser contatada.

— Jon Hopkins

@ Jon, nesse caso, considere seu trabalho inacabado perdido, atribua-o a outro programador e comece a refletir sobre por que isso aconteceu em primeiro lugar.

Há uma inconsistência lógica lá - "você não sabe o que seu desenvolvedor está fazendo" vs "você precisa delegar", o que significa que você sabe o que ele está fazendo, mas possivelmente não como - e, por sua vez, é por isso que você precisa obter o código ... (sim, a comunicação pode ajudar a resolver isso, mas se você confia em seus desenvolvedores para resolver um problema e é um problema pequeno - para um determinado desenvolvedor -, então "vá consertar isso, tchau!" pode ser tanto gerenciamento quanto possível. necessário).

— Murph

@ Murph, aplique uma regra de "confirmação frequente - em um ramo" e pressione a central pelo menos diariamente.

1

Então, como você lida com situações como essa?

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.

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?

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.

— Thomas Langston
fonte