Em que momento as críticas "construtivas" ao seu código se tornam inúteis?


39

Recentemente, comecei como desenvolvedor júnior. Além de ser uma das pessoas menos experientes da equipe, também sou uma mulher, que vem com todos os tipos de desafios próprios trabalhando em um ambiente dominado por homens. Ultimamente, tenho tido problemas porque sinto que estou recebendo muitas críticas pedantes injustificadas no meu trabalho. Deixe-me dar um exemplo do que aconteceu recentemente.

O líder da equipe estava ocupado demais para conseguir alguns ramos que eu fiz, então ele não chegou até eles no fim de semana. Verifiquei meu e-mail, não pretendendo fazer nenhum trabalho, e descobri que minhas duas ramificações haviam sido rejeitadas com base em nomes de variáveis, tornando as mensagens de erro mais descritivas e movendo alguns valores para o arquivo de configuração.

Não acho que rejeitar meu ramo nessa base seja útil. Muitas pessoas estavam trabalhando no fim de semana, e eu nunca disse que estaria trabalhando. Efetivamente, algumas pessoas provavelmente foram bloqueadas porque não tive tempo de fazer as alterações e reenviá-las. Estamos trabalhando em um projeto que é muito sensível ao tempo, e parece-me que não é útil rejeitar completamente o código com base em coisas transparentes para o cliente. Posso estar errado, mas parece que esses tipos de coisas devem ser tratados em confirmações do tipo patch quando eu tiver tempo.

Agora, vejo que em alguns ambientes, essa seria a norma. No entanto, as críticas não parecem igualmente distribuídas, e é isso que leva ao meu próximo problema. A base da maioria desses problemas se deveu ao fato de eu estar em uma base de código que outra pessoa havia escrito e estava tentando ser minimamente invasiva. Eu estava imitando os nomes de variáveis ​​usados ​​em outras partes do arquivo. Quando afirmei isso, me disseram sem rodeios: "Não imite os outros, apenas faça o que é certo". Esta é talvez a coisa menos útil que eu poderia ter dito. Se o código que já está registrado é inaceitável, como devo dizer o que está certo e o que está errado? Se a base da confusão vinha do código subjacente, acho que não '

Estou me sentindo realmente destacado e frustrado nessa situação. Fiquei muito melhor em seguir os padrões esperados e sinto-me frustrado por, por exemplo, quando refatorar um pedaço de código para adicionar a verificação de erros que estava faltando anteriormente, apenas me disseram que não o fiz. torne os erros detalhados o suficiente (e o ramo foi rejeitado nessa base). E se eu nunca o tivesse adicionado para começar? Como ele entrou no código para começar se estava tão errado? É por isso que me sinto tão destacado: constantemente corro para esse código problemático existente, que imito ou refatoro. Quando eu o imito, está "errado" e, se o refatorar, sou repreendido por não fazer o suficiente (e se eu for até o fim, introduzindo bugs, etc.). Novamente, se esse é um problema, não entendo como qualquer código entra na base de código,

Enfim, como faço para lidar com isso? Lembre-se de que eu disse no topo que sou uma mulher e tenho certeza de que esses caras geralmente não precisam se preocupar com decoro ao revisar o código de outros caras, mas sinceramente isso não funciona para mim , e está me tornando menos produtivo. Estou preocupado que, se eu falar com meu gerente sobre isso, ele achará que não posso lidar com o meio ambiente etc.


18
Eu sou um cara, júnior (nesta empresa), e senti um padrão duplo semelhante. A base de código geralmente parece uma porcaria, e ainda assim devo seguir um padrão muito mais alto. Bem, aconteceu que a porcaria chegou lá devido a "marchas da morte" que foram feitas no passado. Além disso, aparentemente eu pareço 5 anos mais jovem do que sou. Quando meus colegas descobriram minha idade real, fiquei muito mais esperto da noite para o dia. Os seres humanos são macacos imperfeitos. Ajuda se você compartilhar o almoço com eles e rir de suas piadas, mas não exagere. Caras interpretam TUDO como um flerte.
Job

4
@ Job: Bem, se a base de código é uma porcaria, deve ser melhor, portanto, seus commits devem ter um padrão mais alto. Caso contrário, ficaria ainda mais ruim, certo? :)
Macke

@ Marcus, você está certo, mas o que seria realmente útil é se as regras fossem claramente definidas e as mesmas regras fossem aplicadas a todos. Além disso, há algo a ser dito sobre a combinação com os mesmos padrões de código, conforme mencionado pelo autor da pergunta. Eu vi um rapaz júnior sendo solto como bode expiatório. A gerência reclamou que os engenheiros produziram muitos bugs. Os engenheiros não puderam fazer um trabalho decente porque a gerência lhes deu prazos fixos. Então, quando algo dá errado, sempre há um cara mais novo com mais erros para culpar e deixar ir. pt.wikipedia.org/wiki/Dedovshchina
Job

3
Uma coisa que se destacou para mim é "Eles estão acostumados com caras, para que não usem decoro". Eu diria que você precisa aceitar isso, a menos que seja claramente uma questão de discriminação. Você iria a um canteiro de obras e esperaria ser tratado de maneira diferente do resto dos autores? Endurecer. Se você trabalha em um ambiente dominado por homens, precisa ser capaz de lidar e se adaptar às diferentes normas sociais da mesma maneira que deve. Não seja tão "sensível".
Rig

1
Sei que já é tarde de muitos anos, mas acho que esse é um tópico importante para futuros leitores. Não exclua a possibilidade de o líder da sua equipe simplesmente conhecer melhor; ele provavelmente é mais experiente e desenvolveu uma intuição por questões problemáticas de estilo - desafio qualquer pessoa nessa situação a tratar isso como uma oportunidade de aprender e crescer. Peça respeitosamente esclarecimentos sobre questões que você não entende e tenha cuidado para não interpretar mal a personalidade seca de um colega como maliciosa.
weberc2

Respostas:


41

Há uma chance de você ser apontado como mulher, mas também é possível que você seja apenas um desenvolvedor júnior e novo no trabalho.

A verificação de erros e as mensagens expressivas são importantes. Se você quiser adicionar algo ao código, verifique se está correto e se está de acordo com os padrões da equipe. Da mesma forma, se você estiver modificando o código de outra pessoa, tente melhorá-lo sempre que possível - não reescreva tudo, mas tente deixá-lo um pouco mais limpo do que o encontrado.

Existe uma versão escrita dos padrões de codificação que sua equipe segue? Caso contrário, pode ser uma boa ideia escrever tudo. Você pode liderar o esforço anotando os erros cometidos e formando-os em uma lista de verificação à qual pode se referir antes de enviar suas alterações para revisão. Como efeito colateral, você pode usar esse padrão escrito para apelar a futuras rejeições, se elas o contradizerem.

Parece que pode haver alguma falta de entendimento entre você e o líder da equipe. Pode ser útil pedir uma reunião individual com ele e discutir o que você pode fazer para melhorar. Você pode liderar com algo como "Eu sinto que ainda estou perdendo muitas nuances do que devo fazer. Como desenvolvedor júnior, quero crescer e melhorar. Você pode me ajudar a chegar lá?" e veja o que acontece.


As respostas de Anna são geralmente muito razoáveis. +1. Eu acho que trabalhar onde você trabalha me deixaria maluco. Sua gerência não se importa com o cumprimento dos prazos? Se o código funcionar, envie-o. Limpe depois. Caramba, você pode até limpá-lo na segunda-feira e avançar no próximo lançamento. Esse comportamento do seu gerente nunca voaria no meu local de trabalho, e estou feliz por poder me concentrar em cumprir prazos em vez de em política. Espero que sua situação melhore e que você encontre uma solução. :)
jmort253

11
@ jmort253 Obrigado. :) Dito isto, "se o código funcionar, envie-o" pode ser uma atitude perigosa de se ter. Código de trabalho nem sempre é um código bom (embora certamente seja melhor que código quebrado) e a qualidade do código é importante a longo prazo. Limpá-lo mais tarde quase nunca acontece, já que outros prazos aparecem e coisas mais urgentes surgem. Há um prazo para isso - "dívida técnica".
Adam Lear

@ Anna, concorde com a importância do código conforme. Eu li que o código não conforme é suficiente para Linus Thorvalds rejeitar um patch enviado para Linux no local (mas não consigo localizá-lo agora).

@ Anna / Thorbjorn - Às vezes você só precisa fazer o que o cliente deseja, se houver um prazo. Seu cliente não será muito compreensivo se perder US $ 15.000 em receita comercial, porque você simplesmente deseja limpar erros de capitalização. Infelizmente, nem sempre é possível tentar eliminar 100% da dívida técnica. Seria como esperar 40 anos para economizar dinheiro suficiente para comprar a casa dos seus sonhos, em vez de fazer uma hipoteca. Claro, você seria livre e claro, mas passaria a vida inteira lidando com proprietários obscuros.
jmort253

Projetos de código aberto são diferentes dos projetos com fins lucrativos. Muitos projetos de código aberto podem ter padrões mais rígidos, porque nem sempre há lucro a ser obtido / perdido. Projetos proprietários têm objetivos diferentes e, às vezes, esses objetivos de negócios têm precedência. Não estou dizendo que o código não deve estar em conformidade, apenas que às vezes você precisa fazer o que precisa e ter a disciplina necessária para voltar e corrigir o problema após a implantação.
jmort253

25

Parece que você pode levar essas coisas um pouco para o lado pessoal. Não; esse tipo de coisa acontece o tempo todo.

As razões para rejeitar seu check-in (nomeação variável, qualidade dos comentários, local de configuração) parecem bastante padrão para mim.

O momento foi a decisão do líder da sua equipe, e eu não me preocuparia se fosse você. Se alguém for bloqueado no fim de semana, o líder da equipe poderá optar por permitir o check-in e solicitar que você o corrija posteriormente. Se ele achou apropriado retroceder, mesmo que isso possa bloquear outros desenvolvedores, é responsabilidade dele.

Quanto ao líder da equipe dizendo para você não imitar os outros, mas para fazer o que é certo, parece que ele está tentando lhe dar alguma iniciativa para melhorar a base de código. Esse é um bom sinal. Ele confia em você para usar seu julgamento, então vá em frente e faça o que você sabe que é certo. Isso não significa que você precise alterar o código de todos os outros, mas significa que você deve assumir a responsabilidade pela qualidade do código que escreve.


2
+1 Você está se concentrando nos relacionamentos e emoções. Os programadores com os quais você está trabalhando soam muito secos, mas estão focados apenas nos problemas de código. Isso é bastante comum nos ambientes de programação em que trabalhei. Vi isso independentemente do sexo, a propósito.
Michael Durrant

14

Uma adição às outras respostas:

Como desenvolvedor líder, geralmente sou mais exigente com os desenvolvedores juniores, porque eles são muito mais maleáveis ​​do que as pessoas que trabalham há alguns anos. (Minhas habilidades de pessoas não são tão boas ... ainda.)

É muito difícil mudar alguém que esteja trabalhando (e ganhando um salário decente) há algum tempo e esteja satisfeito com seu nível de código (mesmo que a qualidade possa ser melhorada). Esses caras não se importam se você tentar guiá-los a se tornarem melhores / ótimos programadores. Eles estão felizes trabalhando na fábrica de códigos.

Caras novos, como você, OTOH, geralmente anseiam por orientação e por saber o que é certo ou não. Além disso, eles são capazes de absorver o feeback e mudar seus caminhos para melhor. Eles não são definidos de outras maneiras.

Se você seguir esses conselhos com sinceridade e torná-los parte de sua vida cotidiana, descobrirá que em pouco tempo estará escrevendo um código que é superior a grande parte da base de códigos existente.

Tão ...

.. pode ser que você esteja recebendo mais feedback apenas porque tem o potencial de fazer algo a respeito. :)


Isso levanta muitos pontos positivos.
sevenseacat

13

É perfeitamente possível que você esteja sendo escolhido porque ... você é um desenvolvedor júnior.

Pela sua descrição, parece que você não seguiu o padrão conforme o líder da equipe o percebe .

A solução é simples:

  • Se esse é o padrão, siga-o.
  • Se você não entender o padrão, peça esclarecimentos.
  • Se a sua interpretação do padrão ou das instruções diferir da do líder da equipe, peça esclarecimentos

Não faça disso uma batalha; se você tentar fazer a equipe liderar "errado", mesmo se você vencer, você perde. Aprenda a lição apropriada e continue a crescer.


1
Tentar seguir algum "padrão" até o "T" quando se lida com idiotas como ela descreve não fará muito bem. Será um argumento interminável sobre definições e semântica.
MrDatabase

4
@ MrDatabase Eles não me parecem muito idiotas. Um pouco exigente, talvez, mas o diabo está frequentemente nos detalhes e, assim que você começa a adotar seus padrões, todo o seu aplicativo pode ir ladeira abaixo rapidamente.
Adam Lear

3
É verdade que os padrões devem ser respeitados. No entanto, ela demonstra claramente que não é realmente um padrão (os desenvolvedores anteriores não aderiram a ele). Portanto, seus colegas de trabalho que lhe impõem o "padrão" (sem dizer algo como "ei, olha ... sabemos que parece inconsistente, mas estamos realmente tentando melhorar nossa base de códigos") são hipócritas e inúteis. Quando os colegas de trabalho agem assim, você precisa adotar uma abordagem diferente e mais inteligente.
MrDatabase 6/02/11

@ user15859: se você está se referindo à minha resposta, essa não era minha intenção. Acredito que disse exatamente a mesma coisa que Anna disse em sua resposta. Nenhuma ofensa foi intencional. As violações de padrões que você mencionou são importantes para manutenção a longo prazo, e qualquer ambiguidade no escopo de aplicação dos padrões deve ser resolvida com o líder da sua equipe. Se você fosse preguiçoso, não teria postado aqui. Se você fosse incompetente, não se importaria tanto. Eu não acredito que você seja um desses.
Steven A. Lowe

1
Acho que ela está se referindo ao que o Woot4Moot disse ao usar "preguiça e incompetência" como uma frase em seu comentário. Acho que sua resposta é boa, pois dá ao OP algum recurso e espaço para agir com base na interpretação dela do que realmente está acontecendo.
jmort253

10

Nota do autor

Alguns anos depois; Eu editei isso para refletir com mais precisão como me sinto sobre a situação. Estou colocando mais nuances em minha resposta porque estou aprendendo mais sobre nuances nessas situações. É fácil reivindicar uma resposta em preto ou branco, mas todos sabemos que não é assim tão simples. Minha resposta agora reflete isso.

Pelo que você descreveu; o comportamento que você está enfrentando não parece ter nada a ver com o seu sexo. Isso não quer dizer que você não esteja passando por nenhum tratamento relacionado ao gênero (espero que não esteja), apenas que o que você descreve não parece estar relacionado ao gênero.

Quando eu era líder de equipe, tratava todos igualmente. Não há espaço na tecnologia para tratar mal alguém por causa de seu sexo. Não sei como lidar com isso, se estiver acontecendo com você.

É importante que você confie que seu líder de equipe trata homens e mulheres igualmente. Se houver evidências de que ele não está, o velho ditado se aplica: mude seu ambiente ou mude seu ambiente.

Igualmente, quero dizer que ele trata todos igualmente, sem deferência ao gênero. Se ele estiver fazendo seu trabalho corretamente, você não deve vê-lo criticar mais ninguém; e eles não deveriam vê-lo criticando você. Na frente dos outros, é muito importante que o líder da equipe mostre confiança, mesmo que ele tenha passado os últimos cinco minutos antes de corrigir o comportamento em particular.

Agora, vamos aos problemas que você levantou:

Você fez o check-in de um código que não atendia ao padrão que ele estabeleceu, e ele rejeitou sua filial. Se eu estivesse no lugar dele, não teria feito a mesma coisa da mesma maneira, mas garantiria que meus subordinados (palavra estranha; porque não considero um líder como 'superior' às pessoas que eles liderança, mas descreve com precisão (não adequadamente) a situação) sabe qual é a coisa certa a fazer. Se eles não sabem quais são os padrões, a culpa é minha como líder. Cabe a mim corrigi-lo. Nesse caso, você pode ter cometido um erro, mas o simples fato de que isso aconteceu significa que você 1) não foi informado sobre o que era certo ou 2) não foi orientado adequadamente. Nem é sua culpa.

Uma das partes mais importantes de ser um programador é perceber que a base de código em que você trabalha deve ser mantida por muitas pessoas diferentes. Quaisquer mensagens variáveis ​​ou outras coisas que prejudiquem a capacidade de ler o código não são transparentes para o cliente , porque leva mais tempo para corrigir problemas no código que é mais difícil de ler.

Se sua equipe tiver escrito diretrizes de codificação, siga-as. Caso contrário, deve haver algum tipo de convenção da comunidade para o seu idioma (para .NET e C #, a Microsoft tem um padrão que muitas empresas seguem).

Pergunte ao líder da equipe onde estão as diretrizes de codificação para garantir que você as siga. Faça dois check-ins em suas reuniões, onde dois outros desenvolvedores não seguiram consistentemente as diretrizes, para que, quando ele disser que não exista, você possa salientar que outros parecem estar tendo problemas com isso também, e todos se beneficiariam de ter essas orientações.

Se ele estiver tratando você de forma justa, ele verá isso e isso deve estar no topo de sua lista de coisas a fazer. Se ele não está tratando você de forma justa, então você tem munição, se isso continuar acontecendo.

Dizer "eu vou falar depois" é ruim. Mais tarde nunca acontece. Aproveite o tempo para fazê-lo corretamente. Não há mais tarde na programação.

É difícil quando você é um desenvolvedor júnior. Você se sente pressionado a executar e há muitas pessoas olhando para você, e todos os erros que você cometer estão ligados ao seu nome no controle de origem para sempre.


1
Vou colocar o comentário sobre "Vou falar mais tarde". Se eu tivesse um níquel por cada vez que ouvi isso, bem, eu não estaria aqui digitando esse comentário. :-)
Eric King

Para .Net há um policial de estilo. Ative-o, para que o código não seja criado até que StyleCop esteja feliz. Isso remove a subjetividade humana e o bullying da força de trabalho. Veja bem, a tecnologia pode ajudá-lo a decidir se Michael Phelps era o número 1 ou o número 2. Na patinação artística, no entanto ... figureskating.about.com/od/famousskaters/tp/scandals.htm Ser um líder de equipe não deve ser apenas uma questão de poder. Não deve haver [dis] favoritos em uma equipe. É preciso ter cuidado para garantir que essa impressão não seja formada. Uma boa maneira de fazer isso é ativar as regras que verificariam o código e forneceriam uma resposta imparcial.
Job

3

Em nenhum lugar do seu post você menciona como outras pessoas são tratadas. Você fica repetindo que "sente" que está sendo "destacado" porque é "uma mulher".

Eu acho que você está sendo tratado como um programador júnior, independentemente do seu sexo, e deveria ser grato por isso, porque é isso que igualdade significa. Eu também sinto que você está fazendo um barulho enorme com pequenas mudanças estéticas de código de 5 minutos que você está sendo solicitado a fazer agora, em vez de colocá-las em uma lista de tarefas e nunca chegar a elas.

Em nenhum lugar do seu post você mencionou que recebeu ordens para fazer essas coisas no fim de semana. Pode ser perfeitamente bom verificar as correções na segunda-feira de manhã.

O líder da sua equipe pode ser um pouco pedante para o meu gosto, mas no seu post não vejo nada de errado com os pedidos dele.

Pare de jogar a carta de gênero por nada . Eu sinto que isso é indigno e mina o conceito de igualdade de gênero.


1

Não acho que rejeitar meu ramo nessa base seja útil. Muitas pessoas estavam trabalhando no fim de semana, e eu nunca disse que estaria trabalhando. Efetivamente, algumas pessoas provavelmente foram bloqueadas porque não tive tempo de fazer as alterações e reenviá-las. Estamos trabalhando em um projeto que é muito sensível ao tempo, e parece-me que não é útil rejeitar completamente o código com base em coisas transparentes para o cliente. Posso estar errado, mas parece que esses tipos de coisas devem ser tratados em confirmações do tipo patch quando eu tiver tempo.

É difícil dizer algo útil como alguém que não viu seu código nem sabe algo sobre o cronograma de seus projetos. Mas, se o seu lead se comportar de maneira responsável e fizer um bom trabalho, ele sabe que outros não foram realmente bloqueados e o sprint não será tarde. Então, não se preocupe com isso. Talvez você anule o impacto no seu commit. Caso contrário: se o seu projeto é crítico em termos de tempo e passa em todos os testes, seria muito difícil rejeitar o código, que pode ser corrigido após o lançamento em um piscar de olhos.

Faça o trabalho Faça o certo Faça rápido

Portanto, se seu líder tomou a decisão de rejeitar seu comprometimento, como profissional, ele deveria saber o que estava fazendo.

Agora, posso ver que em alguns ambientes, essa seria a norma. No entanto, as críticas não parecem igualmente distribuídas, e é isso que leva ao meu próximo problema. A base da maioria desses problemas se deveu ao fato de eu estar em uma base de código que outra pessoa havia escrito e estava tentando ser minimamente invasiva. Eu estava imitando os nomes de variáveis ​​usados ​​em outras partes do arquivo. Quando afirmei isso, me disseram sem rodeios: "Não imite os outros, apenas faça o que é certo".

Como Junior, é difícil encontrar um caminho para a base de código das empresas.

Melhor: existem padrões de codificação documentados - e esperamos que você aprenda a se familiarizar com eles.

Normalmente: existem padrões de codificação não documentados - e você precisa aprender por tentativa e erro ou devo dizer confirmar e rejeitar? Isso é muitas vezes doloroso (como no seu caso). Às vezes, isso é perigoso em termos de qualidade do código e pode levar à programação de cultos de carga , onde não apenas imita a nomeação de variáveis, mas copia e cola estruturas e padrões da base de código de boa fé, e isso deve ser feito dessa maneira. Não faça isso! Nem imite a nomeação de variável existente.

Atenha-se ao código limpo . É uma boa prática e oferece uma posição fácil de defender. Se for um código legível, testável e sustentável, você venceu qualquer discussão.

E isso leva a outro (o último) conselho: Siga a regra dos escoteiros !

Sempre deixe a base de código em um estado melhor do que estava. Mesmo se o código ao redor do qual você estiver trabalhando for desagradável, limpe o seu - e se você tiver tempo, conserte o ambiente.


0

Reserve um tempo para aprender as várias nuances da personalidade de seus colegas de trabalho. Na minha experiência, você pode evitar críticas irracionais, desnecessárias, inconsistentes ou simplesmente inúteis se você resolver as peculiaridades de seus colegas de trabalho.

Por exemplo, alguns colegas de trabalho podem estar de ressaca às segundas-feiras. Eles podem estar muito irritados e ansiosos demais para rejeitar certas ramificações ou confirmações de código. Se você tiver que trabalhar com alguém assim, tente evitar o código às segundas-feiras.

Por outro lado, um colega de ressaca pode ser muito lamentável para se preocupar com a verbosidade das mensagens de erro ... portanto, segunda-feira de manhã pode ser o momento perfeito para confirmar seu código :-p

As peculiaridades da personalidade no escritório ou no local de trabalho são literalmente infinitas. Espero que você possa aprender quem evitar e quando evitá-los. Também não seja muito duro consigo mesmo :-) Você sempre pode sair e encontrar outro emprego!


1
Encontre o emprego antes de sair, muitos gerentes de contratação nem sequer entrevistarão se você não estiver empregado.
Woot4Moo 6/02

-2

Eu nunca trabalhei em um ambiente em que o código é rejeitado com base em que certas convenções não são seguidas. Se eu estivesse no seu lugar, ficaria tentado a procurar emprego em um lugar onde tenho mais poder para tomar as decisões certas e onde o cliente é o foco principal, não o código.

Não estou dizendo que códigos e padrões limpos não são importantes, mas o cliente e a linha do tempo do produto não devem sofrer por causa de um erro de ortografia em algo que nenhuma pessoa, cliente ou executivo não técnico jamais verá.

Com isso dito, parece que você pode estar trabalhando em um ambiente em que as expectativas não são claras ou você não entende completamente os requisitos, por qualquer motivo.

Independentemente da situação, cabe a você assumir o controle e fazer perguntas esclarecedoras. Seja proativo, se você ainda não é. Os membros da sua equipe e o líder da equipe provavelmente o respeitarão mais por fazer perguntas para esclarecer as regras para o check-in. Você também pode solicitar uma "revisão pós-ação", na qual você e o líder da equipe discutem o que deveria ter feito e como pode dizer a diferença quanto a quando executar determinadas ações e quando não.

Sugiro que dedique algum tempo, já que você é novo, para ver se consegue superar os obstáculos e resolver esses problemas com experiência, comunicação e aprendizado dos padrões. No entanto, se após vários meses a situação não mudar e o ambiente ainda estiver atormentado pela ambiguidade, talvez seja hora de procurar emprego em outra empresa.

Nem toda organização é draconiana e você pode encontrar outros ambientes de trabalho mais adequados aos seus requisitos de personalidade, estilo e comunicação.


2
Isso não parece "draconiano"; a consistência é um componente importante na manutenção, a manutenção é um componente importante na qualidade e o software de qualidade tem uma chance muito maior de ser entregue no prazo e a um custo menor do que o 'código de comprometimento'. Pode ser encorajador que cerca de 80% das empresas de software estejam ansiosas por comprometer a qualidade e sofrer as conseqüências, para que não pareça haver escassez de oportunidades de emprego "não draconianas". :)
weberc2

1
Eu não gostaria de trabalhar em um ambiente em que as convenções básicas não sejam aplicadas. Se um projeto desistir de defender suas diretrizes de codificação, está fadado a se tornar insustentável a longo prazo. Nomear especialmente variáveis ​​não é uma coisa mesquinha: não importa quanto código existente chame uma determinada matriz A, eu nunca aceitaria um commit que chame outra matriz Bpor consistência. Obviamente, eu não sei o que o OP significava "imitando [...] nomes usados ​​em outros lugares" precisamente, no entanto, dada a qualidade de algum código que eu vi, pode ser nesse sentido.
C6
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.