Como você codifica sem ofender?

O que quero dizer com isso é: como você desenvolve um código que compartilha com os desenvolvedores que trabalham nele há anos e estão familiarizados com isso?

Não quero pisar no pé de ninguém, mas não recebo reclamações tão sutis sobre a maneira como faço as coisas, seja como espaços em branco no meu código ou com que frequência faço check-in no SVN (com muita frequência). Então, embora eu possa mudar essas coisas facilmente - quero ser um desenvolvedor de equipe melhor em geral.

Não tenho certeza do que fazer, além de perguntar, mas talvez vocês tenham alguns pensamentos que eu possa colocar em prática.

ATUALIZAR

Não há nenhum guia de estilo para falar - apenas as pessoas não estão acostumadas a compartilhar a base de código. Todo mundo tem seu próprio mundo de código em silos.

Esta é uma loja perl, mas tenho certeza de que isso se aplica a qualquer idioma

ATUALIZAÇÃO 2

O CTO que mais tarde se tornou CEO era um megalomaníaco completo e era a principal fonte dessas reclamações. Se você não fez as coisas exatamente como ele gostava, se estava usando um Mac, ou Emacs, ou 4 espaços de tabulação em vez de 2 ou se vestia de uma certa maneira, você era inferior. Foi uma situação horrível que tentei corrigir, mas a única resposta correta para mim estava saindo.

Estou convencido de que esse foi um caso de bullying no local de trabalho e, posteriormente, estou mais ciente do que pode ser um bullying sutil e um comportamento inadequado no ambiente de trabalho.

Para qualquer desenvolvedor que esteja procurando respostas para uma situação como essa, saia imediatamente. Você não pode trabalhar em equipe para sair de uma situação ruim de equipe.

Peça. Ou seja, pergunte às pessoas com quem trabalha. Faça o seu melhor para manter o estilo estabelecido do código existente. Pergunte especialmente se há uma lista de documentos de padrões de codificação e siga-a. Se não houver, escreva um primeiro rascunho com base no que você observa no código e peça aos outros membros da equipe que o critiquem. Você prestará um serviço à empresa (e aos novos desenvolvedores que vierem depois de você), começando a documentar as práticas de codificação aceitas. O único risco é possivelmente ficar preso no meio se os veteranos não concordarem entre si sobre o que é ou o que não é aceitável.

Além disso, não tenha medo de ser você mesmo . Você pode ser o cara novo, mas você é um membro da equipe e suas opiniões são válidas. Se você puder pensar em maneiras melhores de fazer algo, sugira-o. Respeite os outros membros da equipe e a maneira estabelecida de fazer as coisas, mas não deixe que eles o pressionem. A empresa não o contrataria se não valorizasse sua contribuição.

Ajudará bastante se você encontrar alguém da equipe que pareça amigável e particularmente disposto a responder perguntas. (Se é uma boa equipe, deve ser todos, mas as equipes nem sempre são assim.) Seu chefe pode ter designado alguém para ajudá-lo a começar. Use essa pessoa como um recurso. Anote as perguntas à medida que elas ocorrerem e, em seguida, peça a essa pessoa útil que as responda de tempos em tempos.

Quanto à verificação do código "com muita frequência", por que não criar sua própria ramificação para suas confirmações periódicas e depois voltar ao tronco quando o código estiver pronto? Ninguém faz mal a ninguém e, quando seus colegas de trabalho vêem você obtendo benefícios do SVN que eles gostariam, eles podem seguir seu exemplo.

Em relação ao espaço em branco: basta fazê-lo, mas o código já o faz. Vá com o fluxo.

Em relação aos check-ins do SVN: documente-os com muita clareza. Isso ajuda as pessoas a entender o que está acontecendo no código. (Acompanhamento: Quais são as objeções deles aos check-ins frequentes?)

Em geral: comece a criar um documento padrão de codificação. Não tente preenchê-lo com 100 regras. Basta adicionar regras conforme elas surgirem.

Além disso: faça perguntas aos seus colegas desenvolvedores. Isso lhes dá a oportunidade de avaliar antes de fazer algo que eles não vão gostar. Além disso, constrói relacionamentos. Além disso, você aprende mais sobre como a loja funciona.

No que diz respeito ao estilo de formatação do código (espaço em branco, guias, onde os chavetas vão etc.), você deve seguir o padrão predominante no código. Se não houver, acho que eles não têm muito do que reclamar. Quando se trata disso, se você coloca chaves na sua própria linha ou não, coloca espaços em torno das listas de parâmetros de métodos, etc. é uma preferência pessoal, e você deve ceder ao estilo predominante, porque a longo prazo, isso realmente não acontece. importa . O que importa é ser consistente.

Quando se trata de verificar código no SVN, eu tentava evangelizar o que considero o caminho certo para fazer as coisas, em vez de me deixar levar pelo vapor. Não faço check-in do meu código, a menos que ele crie e passe nos testes, e se estou fazendo várias alterações não relacionadas, divido meu trabalho em várias confirmações. Se algo ficar quebrado por um tempo, eu crio um ramo e faço meu trabalho lá. As confirmações recebem comentários descritivos. Isso funciona melhor na minha experiência do que o método "verificar uma pilha de alterações na sexta-feira às 5:00" e parece ser a "melhor prática" predominante, de acordo com a maior parte do que li aqui e em outros lugares.

Leia primeiro o documento das convenções de codificação (se eles não tiverem um, peça que escrevam um para que você possa segui-lo)

Então observe e faça um esforço consciente para seguir isso e o que eles dizem. Pode parecer que eles estão sendo severos, mas os padrões de codificação são importantes, é melhor apontar agora o que está errado, em vez de deixá-lo se transformar em um problema mais tarde, quando você estiver fazendo alterações maiores.

Tenho certeza de que você fará o mesmo em um ano ou dois quando algum novato estiver pisando no seu pé :)

Peça os padrões da empresa. Preste mais atenção aos detalhes. Se você vir outras pessoas seguindo uma forma muito específica de espaço em branco e padrões de chaves, siga-as. Como Sr., você pode argumentar que isso é exigente, mas como Jr. ou novato em um projeto, você precisa mostrar que pode seguir antes de liderar.

Além disso, entenda que qualquer novo desenvolvedor de um projeto terá um tempo necessário para "acelerar". Então não se preocupe com isso.

A melhor coisa que você pode fazer é seguir os conselhos que eles lhe dão. Não há como dizer com antecedência o que eles querem. A menos que você seja psíquico.

No entanto, eu sugeriria que, conforme as pessoas o aconselham, você o documenta. Você tem um wiki? Se sim, use-o. Caso contrário, um arquivo de texto registrado com o código-fonte pode ser uma boa ideia. Crie um guia de programação bem organizado. Isso ajudará você a se lembrar de como fazer as coisas e, se alguém contradizer os conselhos anteriores que você recebeu, fornece um ponto de referência para discutir a inconsistência. Além disso, quando a próxima pessoa se juntar à equipe, ela não terá que passar pelo que você está passando.

Eu sugiro que você não atribua o conselho no documento a indivíduos (portanto, "os blocos de código devem ser recuados por três espaços", não "Bill me disse que os blocos de código devem ser recuados por três espaços"). No entanto, se você puder registrar essas informações de maneira discreta (por exemplo, no comentário de confirmação, escreva "regra adicional sobre indentação com base nos conselhos de Bill"), poderá ser útil para resolver contradições, pois é possível obter imediatamente dois pontos de vista Em algo. O que estou pensando aqui é que, se você receber conselhos contraditórios, precisará evitar se tornar uma bola de futebol sendo chutada por dois colegas que discordam de algo. É uma abordagem um pouco disfarçada, mas pode ser prudente.

Uma maneira fácil é encontrar o guia de estilo e segui-lo. A maioria não tem nada muito ofensivo, e impedirá que você ofenda os outros.