Trabalho como desenvolvedor iOS em uma pequena empresa de terceirização em uma equipe de 4 pessoas. Trabalhamos em um projeto que começou alguns anos antes de eu e dois outros desenvolvedores ingressarmos na empresa. Antes disso, o projeto estava sendo realizado principalmente por uma pessoa.

Quando comecei a trabalhar no projeto, era uma bagunça completa. Houve muita repetição de código. Vi os mesmos 500 códigos copiados para 20 arquivos diferentes, com pequenas variações. Além disso, não estava exatamente bem organizado: todo o código de criação da interface do usuário foi misturado nos controladores de exibição juntamente com a lógica.

Eu tentei o meu melhor para refatorar as coisas aqui e ali, eliminar pedaços de código redundantes, melhorar a estrutura de arquivos do projeto e assim por diante. Parecia que o desenvolvedor anterior realmente não se importava com todas essas coisas ou não tinha a experiência. Houve um tempo em que trabalhei sozinho em um recurso bastante grande por alguns meses. Devido à natureza desse recurso, tive que digitar muito código em todo o aplicativo, por isso tentei fazer algumas melhorias.

Quando outros desenvolvedores ingressaram no projeto, notei que eles usam um estilo de codificação diferente (às vezes um estilo completamente diferente) e geralmente não usam recursos de linguagem moderna como acessadores de propriedades (isso é relativamente novo no Objective-C). Às vezes, eles inventavam suas próprias bicicletas em vez de usar recursos semelhantes da estrutura, ou transferiam conceitos de outras linguagens de programação ou padrões que aprenderam em nossa base de código. Muitas vezes, eles não podem nomear métodos ou variáveis ​​corretamente por causa do inglês ruim (o Objective-C é um idioma em que você cria nomes longos).

Às vezes, acho que se não fosse pelo IDE, acho que eles escreveriam todo o código sem recuo ou formatação.

Basicamente, eu odeio o código que eles escrevem. É mal formatado / organizado e, às vezes, é radicalmente diferente do resto do projeto. Fico muito chateado quando adicionam espaguete à minha obra de arte e isso afeta meu humor no trabalho e minha produtividade.

Parece cada vez mais que eles não podem se incomodar em aprender ou não se importam: eles apenas fazem o que é necessário com eles e vão para casa. Tentei dar algumas dicas a eles quando tive uma oportunidade (por exemplo, comentei o PR deles ou comete no GitHub). Uma vez pedi gentilmente que seguisse o estilo de codificação e a formatação da maioria dos códigos existentes (infelizmente não temos um documento formal de estilo de codificação). Mas não deu certo ...

Como posso resolver essa situação sem focar apenas na "má cultura da empresa", "graduados inexperientes" etc. etc. e realmente começar a melhorar a situação.

Ensine e pratique o que você prega.

Você sabe que essas coisas são importantes. Você sabe a desvantagem quando não é bem feito.

Agora, o desafio é convencer os outros. Isso não será feito por meio de uma única conversa, reunião, conversas no corredor, dicas ou dentro de uma solicitação de recebimento.

Isso precisa de:

• O público reconhece pela gerência que esses itens são importantes
• Organizadores para que as pessoas possam se reunir, discutir e concordar com o estilo e deixar os computadores fazer o policiamento
• Desenvolva líderes que comprem totalmente e estão dispostos a ensinar aos outros
• Reuniões, demonstrações, almoço e aprendizado, etc., para ensinar essas abordagens
• Pessoas avaliadas pelos itens de qualidade mencionados durante as resenhas
• Padrões documentados e publicados
• Solicitações Pull com muitos revisores
• Solicitações Pull que não estão sendo mescladas até que a qualidade do código seja alta
• Emparelhamento frequente de código
• Revisões de código de grupo para RPs complexos

Em palavras, requer

Liderança

A boa notícia é que todas essas atividades são geralmente reconhecidas como boas práticas; portanto, quando você vai promovê-las ou recebe o apoio da gerência, deve ter uma boa chance de sucesso e ser capaz de defender o que é certo. A gerência ainda pode não aceitar, no entanto, esse é outro tópico e pergunta.

Eu escrevi muito sobre esse assunto no SoftwareEngineering.SE no passado e estava em situações semelhantes. Portanto, tentarei dar algumas dicas e destacar alguns problemas que notei ao ler sua pergunta.

Mas primeiro, vamos falar sobre um aspecto importante: seu papel na empresa.

Seu papel

Você pode ter um mandato explícito do seu chefe para aprimorar as coisas e também um lugar na hierarquia em que outros desenvolvedores precisam ouvir seus pedidos . Ou você pode estar entre colegas, tendo o mesmo papel e a mesma autoridade, sendo sua opção apenas ... bem ... uma opinião .

Nos dois casos, o que importa é menos o seu lugar na hierarquia e muito mais:

• O que outros desenvolvedores pensam de você. Se eles o tratam como um cara chato que pede coisas estúpidas, você não vai longe. Eu já vi muitos casos em que líderes técnicos e gerentes de projeto não tinham absolutamente nenhuma influência sobre a equipe, porque a equipe sabia (ou pensava) que esses "líderes" não tinham formação técnica necessária para tomar as decisões que estavam tomando. Por outro lado, vi vários desenvolvedores que foram realmente ouvidos por seus colegas, porque sabiam que esses desenvolvedores são hábeis e experientes.

• Quão sólida é sua equipe e o que as motiva. Imagine uma empresa em que todos os desenvolvedores sejam pagos por KLOC / mês. O que você diz sobre estilo é importante para seus colegas? Provavelmente não, porque raras são pessoas que querem receber menos. Em geral, se não for uma equipe, mas apenas um grupo de pessoas trabalhando no mesmo projeto, você não poderá melhorar nada.

Dependendo disso, você pode decidir se vale a pena fazer algum esforço. Se você não tem voz e não há coesão da equipe, basta procurar outro emprego. Se você é conhecido como um desenvolvedor talentoso e respeitado, e há um forte sentimento de equipe, poderá melhorar as coisas de maneira relativamente fácil, mesmo diante da hostilidade de seu chefe ou de outras equipes.

Em todos os casos, é essencial não pressionar a sua equipe. Trabalhe com eles, não contra eles. Não dê ordens a eles, mas guie-os para a meta.

Agora, as dicas.

Estilo

Uma vez pedi gentilmente que seguisse o estilo de codificação e a formatação da maioria dos códigos existentes (infelizmente não temos um documento formal de estilo de codificação). Mas não deu certo ...

Claro que não, pois não é assim que deve ser feito.

• Estilo é chato .

• O estilo a seguir é chato .

• Escrever documentos no estilo de codificação é chato ( e muito difícil ; nem tente fazê-lo, a menos que você tenha trabalhado com o idioma por mais de dez anos).

• O documento do estilo de leitura é chato .

• Revisar código para erros de estilo é chato .

• Trollar que meu estilo é melhor que o seu é emocionante , especialmente quando não há absolutamente nenhum benefício objetivo de um estilo em detrimento de outro. Sério, toda pessoa sã sabe que o jeito certo de escrever if (x)é o jeito que eu escrevi, não if(x)ou if ( x )!

Portanto:

• Não faça revisões de estilo. Este é o trabalho dos verificadores de estilo. Esses aplicativos atraentes têm alguns benefícios em seu cérebro: eles verificam o projeto inteiro em questão de milissegundos, não horas ou dias, e não cometem erros e não perdem erros de estilo.

• Não escreva seu próprio padrão de estilo. Você fará errado de qualquer maneira, e seus colegas de trabalho farão com que você tenha feito más escolhas.

• Não force os desenvolvedores a corrigir 2 000 erros de estilo.

• Aplique o estilo automaticamente ao confirmar. Código com erros de estilo não tem lugar no controle de versão.

• Faça isso desde o início do projeto. Configurar o controle de estilo em um projeto existente é difícil ou impossível.

Para saber mais sobre isso, leia a primeira seção de essa outra resposta sobre SE.SE .

Além disso:

• Não seja muito rigoroso. Por exemplo, escrever jslintcódigo compatível é bastante irritante, portanto deve ser feito exclusivamente quando absolutamente necessário (ou se todos os membros da sua equipe estiverem felizes em usá-lo). O mesmo vale para ferramentas de verificação estática; por exemplo, a Análise de código do .NET no nível máximo pode ser muito opressiva e deprimente, além de trazer poucos benefícios; o mesmo conjunto de ferramentas em nível moderado, por outro lado, mostra-se muito útil.

Revisões de código

Agora que você não precisa se preocupar com estilo durante as revisões de código, pode se concentrar em coisas mais interessantes: aprimorando (vs. corrigindo) o código-fonte.

Pessoas diferentes reagem de maneira diferente às revisões de código. Alguns consideram isso uma oportunidade. Outros odeiam isso. Alguns ouvem tudo o que você lhes diz, fazem anotações e não discutem, mesmo que possam estar certos. Outros tentam argumentar em todos os pontos. Cabe a você encontrar uma maneira de lidar com cada desenvolvedor de acordo com a personalidade dela. Geralmente é útil para:

• Faça análises de código em particular, especialmente quando o desenvolvedor é iniciante e escreve um código muito ruim.

• Mostre que não há nada pessoal: você está revisando o código, não as habilidades da pessoa.

• Mostrar o objetivo real de uma revisão de código. O objetivo não é mostrar o quão ruim é um desenvolvedor. O objetivo é oferecer oportunidades de melhoria.

• Nunca discuta. Você não está aqui para convencer, mas para fornecer seus conhecimentos.

• Nunca assuma que o revisor é o único que pode aprender algo com uma revisão. Você também está aqui para aprender, lendo o código e pedindo explicações sobre as partes que você não entende.

Depois que a revisão do código for concluída, verifique se a pessoa realmente aprimora seu código. Eu tive alguns casos em que os desenvolvedores pensaram que a revisão do código termina quando a reunião real termina. Eles saem e voltam aos seus novos recursos, tentando aplicar o que você compartilhou com eles apenas para o novo código. Ter uma ferramenta de rastreamento decente para revisão de código ajuda.

Observe que, independentemente de sua função específica na empresa e de sua experiência em comparação com outras, seu código também deve ser revisado. Você não deve ser o único a revisar o código de outras pessoas.

Em um projeto recente em que trabalhei como líder técnico, tive dificuldade em explicar aos meus colegas de trabalho que é seu papel fazer as revisões do código um do outro, incluindo o meu. O medo de um estagiário que está prestes a revisar o código de seu líder técnico desaparece assim que encontra os primeiros problemas no código - e quem de nós escreve um código sem falhas?

Treinamento

As revisões de código são uma excelente oportunidade para ensinar e aprender alguns dos aspectos de programação e design de software, mas outros requerem treinamento.

Se você for capaz de treinar seus colegas de trabalho, faça isso. Se sua gerência é hostil à idéia de treinamento, faça-o informalmente. Realizei essas sessões de treinamento em uma forma de reuniões informais ou, às vezes, apenas em discussões simples, às vezes interrompidas pela gerência e prosseguidas posteriormente.

Além do treinamento direto, certifique-se de conhecer bem os livros, como o Code Complete da McConnel , e converse sobre esses livros com seus colegas de trabalho. Sugira que eles leiam o código fonte de projetos de código aberto, dê exemplos específicos de código de alta qualidade. E, obviamente, escreva você mesmo um código de alta qualidade.

Concentre-se no contexto, não nas pessoas

Como posso resolver essa situação sem focar apenas na "má cultura da empresa", "graduados inexperientes" etc.

Esses graduados têm um objetivo: adquirir experiência, aprender coisas, tornar-se mais hábeis. Se, ano após ano, eles escrevem códigos ruins e não sabem nada sobre programação, provavelmente é porque sua equipe ou sua empresa não está dando a eles essa oportunidade.

Se você se concentrar no fato de sua equipe ter diplomados inexperientes, isso não ajudará. Em vez disso, concentre-se no que você pode fazer por eles e com eles. Revisões de código e treinamento são duas das técnicas para melhorar a situação.

A má cultura da empresa é uma fera diferente. Às vezes, isso pode ser alterado. Às vezes, não pode. Em todos os casos, lembre-se de que você faz parte desta empresa, portanto faz parte da cultura da empresa. Se você não pode alterá-lo e o achar inerentemente ruim, mais cedo ou mais tarde, terá que sair.

Acerte suas métricas

Como exatamente você mede o código agora? Você mede o número de confirmações por dia por desenvolvedor? Ou o KLOC por mês por programador? Ou talvez a cobertura do código? Ou o número de bugs encontrados e corrigidos? Ou o número de possíveis erros detectados pelos testes de regressão? Ou o número de reversões realizadas pelo servidor de Implantação Contínua?

As coisas que você mede são importantes, porque os membros da equipe estão adaptando seu trabalho aos fatores que são medidos. Por exemplo, em uma empresa em que tive que trabalhar alguns anos atrás, a única coisa que foi medida foi o tempo que passamos no escritório. Escusado será dizer que isso não foi encorajador para fornecer um código melhor, ou para trabalhar de forma mais inteligente, ou ... bem, para funcionar.

Descobrir reforços positivos e negativos e ajustar os fatores medidos ao longo do tempo é essencialmente a alavancagem que você tem dos membros da equipe. Quando feito corretamente, possibilita alcançar resultados que não serão alcançados por uma hierarquia simples.

As coisas que incomodam, tornam mensuráveis. Meça-os e torne os resultados públicos. Em seguida, trabalhe junto com outros membros da equipe para melhorar os resultados.

Por exemplo, vamos considerar que os membros da equipe cometem muitos erros de ortografia nos nomes de classes, membros e variáveis. Isso é chato. Como você pôde medir isso? Com um analisador, você pode extrair todas as palavras do código e, usando um corretor ortográfico, determinar a proporção de palavras que contêm erros e erros de digitação, digamos 16,7%.

Seu próximo passo é concordar com sua equipe sobre a proporção de metas. Pode ser de 15% para o próximo sprint, 10% para o próximo, 5% em seis semanas e 0% em dois meses. Essas métricas são recalculadas automaticamente em todas as confirmações e exibidas em uma tela grande no escritório.

• Se você não atingir a taxa de meta, sua equipe poderá passar mais tempo corrigindo erros de ortografia. Ou sua equipe pode considerar melhor calcular a proporção por desenvolvedor e exibir essas informações também na tela grande. Ou sua equipe pode achar que o objetivo era otimista demais e que você deveria revê-lo.

• Se você atingir a taxa de meta, o próximo passo é garantir que o número de erros e erros de digitação não aumente com o tempo. Para isso, você pode criar uma tarefa adicional em sua compilação que verifica erros de ortografia e falha na compilação se pelo menos um erro for encontrado. Agora que você se livrou desse problema, sua tela grande pode ser reutilizada para mostrar as novas estatísticas relevantes.

Conclusão

Acredito que todos os aspectos mencionados na sua pergunta podem ser resolvidos através das técnicas que incluí na minha resposta:

• Quando outros desenvolvedores ingressaram no projeto, notei que eles usam um estilo de codificação diferente (às vezes um estilo completamente diferente)

  Você tinha que aplicar o estilo automaticamente ao confirmar.

• e geralmente não usam recursos de linguagem moderna como acessadores de propriedades (isso é relativamente novo no Objective-C).

  As revisões de código e o treinamento estão aqui para transferir seu conhecimento do idioma.

• Às vezes, eles inventavam suas próprias bicicletas em vez de usar recursos semelhantes da estrutura

  As revisões de código e o treinamento estão aqui para transferir seu conhecimento da estrutura.

• ou transferir conceitos de outras linguagens de programação ou padrões que aprenderam em nossa base de código.

  Isso é uma coisa excelente. Parece uma oportunidade para você aprender com eles.

• Muitas vezes, eles não podem nomear métodos ou variáveis ​​corretamente por causa do inglês ruim

  As revisões de código também devem se concentrar na nomeação adequada. Alguns IDEs também possuem corretores ortográficos.

• Às vezes, acho que se não fosse pelo IDE, acho que eles escreveriam todo o código sem recuo ou formatação.

  Claro que sim. O estilo é chato e deve ser automatizado.

• Basicamente, eu odeio o código que eles escrevem.

  Lembre-se da parte das revisões de código: “O objetivo não é mostrar o quão ruim é um desenvolvedor. O objetivo é oferecer oportunidades de melhoria. ”

• É mal formatado / organizado e, às vezes, é radicalmente diferente do resto do projeto.

  Verificação de estilo automatizada .

• Fico muito chateado quando adicionam espaguete à minha obra de arte

  Espere o que?! Peça de arte?! Adivinha? Algumas pessoas (incluindo você em seis meses) podem achar seu código longe de ser uma obra de arte. Enquanto isso, entenda que considerar o seu trabalho como uma obra de arte e o trabalho deles como lixo não ajudará ninguém. Incluindo você.

• Parece cada vez mais que eles não podem se incomodar em aprender ou não se importam: eles apenas fazem o que é necessário com eles e vão para casa.

  Claro que eles farão o que é necessário deles. Lembre-se: contexto, não pessoas e acerte suas métricas . Se o contexto exigir deles que eles se tornem melhores no que fazem, eles o farão. Se o contexto exigir o maior número possível de KLOC por mês e nada mais, eles também o farão.

Implemente padrões de codificação e cumpra-os, padrões de design, biblioteca de trechos de código que podem ser usados ​​como diretrizes, etc.

Os padrões de codificação podem variar de decidir se usar espaços ou guias, quais padrões de design tentar usar, convenções de nomenclatura etc. Isso ajudará bastante, mesmo que todos codifiquem de maneira diferente.

Se possível, implemente padrões de codificação e revisões de código - para começar a revisar cada check-in. Com uma equipe pequena, será difícil vender para pessoas que não entendem que gastar 2x ou 3x extra em seu código antecipadamente economizará 20x ou 30x no tempo total de desenvolvimento, mas esse é outro conceito que vale a pena comprar -em diante.

Eu não tentaria implementar tudo de uma vez e tentaria o máximo possível para que eles apresentassem padrões - não apenas indentação, mas tentaria fazê-los pensar nas coisas que encontraram em seu código que tornou suas vidas mais fáceis ou mais difíceis.

Considere fazer uma reunião um dia por semana para ver o que deu certo ou errado para cada pessoa durante essa semana - você também pode oferecer a oportunidade de dizer o que outra pessoa fez e que foi mais útil naquela semana - coisas assim . Você pode procurar nos livros XP / Agile para obter mais idéias como essa. Sendo uma equipe pequena, novamente, isso poderia ser uma venda difícil.

Você mencionou problemas de idioma. Se esses trabalhadores são locais (contratados no local ou contratados em período integral), isso não deve ser um problema, mas se são contratados no exterior trabalhando remotamente - permita-me apenas dizer que, na minha experiência pessoal, isso nunca é um problema. vai ser consertado, resolva-o até que a gerência descubra que não vai funcionar ou pense em deixar a empresa. Não entre em uma situação em que você é responsável pelo trabalho deles e não perca tempo tentando consertar as práticas de desenvolvimento da equipe. Muito provavelmente o seu trabalho evoluirá para gastar 100% do seu tempo fazendo o código funcionar. Muitos contratados no exterior são ótimos programadores, a propósito, estou apenas me referindo ao caso em que a empresa contratada lhe enviou o tipo de talento que você descreveu.

Os sintomas que você descreve sugerem fortemente a falta de coesão da equipe .

Em tal situação, padrões de codificação, treinamento, procedimentos ou ferramentas não serão a bala de prata que poderia melhorar substancialmente a qualidade. Você primeiro precisa desenvolver um espírito de equipe, comunicação aberta e construtiva e uma propriedade compartilhada do produto.

Sintomas:

• "eles apenas fazem o necessário e vão para casa": soam desmotivados. Eles não estavam mais entusiasmados quando chegaram?
• "eles" contra "nós" / "eu" / "eu": falta de confiança mútua?
• "Dei algumas dicas: comentei PR sobre Git": o tom da crítica escrita às vezes é mal interpretado como agressivo ou arrogante, apesar da intenção construtiva. Por que não discutir isso cara a cara?

Você é uma equipe pequena: use esta vantagem! Algumas idéias para começar:

• Tome decisões importantes coletivamente. Discuta abertamente o desacordo. "Discutir" não é impor um ponto de vista, mas ouvir e tentar encontrar um terreno comum.
• Você refatorou partes importantes do código, para ter uma propriedade muito forte. Deixe-os comprar. Deixe-os ter uma palavra a dizer.
• E para tópicos muito sensíveis, mas altamente subjetivos, como formatação de código, apenas terceirize o serviço para uma bonita impressora automatizada que reformatará de acordo com o padrão e sem sentir em cada check-in.

Citação do dia:

Se você quer ir rápido, vá sozinho. Se você quer ir longe, vá junto

Sua pergunta pode ser respondida com "Alterar sua empresa ou mudar sua empresa". Para quem não sabe, isso significa que você fica e luta para trazer a mudança que deseja ver na sua empresa ou mudar a empresa para a qual trabalha (por exemplo, sair e trabalhar em outro lugar).

A segunda parte é a mais simples. Você sai e encontra uma empresa que compartilha os mesmos valores pelos quais trabalha. O primeiro não é tão simples por causa de ... pessoas.

O que você precisa fazer é mudar as pessoas. Pensar que eles estão quebrados e você precisa corrigi-los não vai funcionar. As pessoas são seres emocionais. Isso pode facilmente degenerar em guerras pessoais. Então...

Primeiro de tudo, você precisa descobrir por que a situação é do jeito que é. Fale com todo mundo. Descobrir. O que você vê agora é o resultado de decisões tomadas ao longo dos anos (ou talvez não tomando algumas decisões importantes no momento certo). Não julgue e não tire conclusões precipitadas.

Isso foi causado por desenvolvedores inexperientes? Isso foi causado pela gerência tentando reduzir custos contratando graduados baratos, em vez de desenvolvedores mais experientes e caros? É sobre pessoas preguiçosas e mal intencionadas ou pessoas derrotadas por um sistema quebrado? Os prazos estão forçando você a fazer "o que deve ser feito" para fazê-lo funcionar ou as pessoas perdem seu tempo e não se importam muito com o que estão trabalhando? etc.

O problema com esse campo de desenvolvimento de software é que as pessoas aprendem no trabalho. Se eles trabalham em um ambiente ruim, eles adquirem maus hábitos. E os hábitos tendem a permanecer e a ser difíceis de abalar. Então eles não sabem melhor, porque é tudo o que sabem. Nem todos os desenvolvedores são apaixonados pelo que fazem para investir tempo em melhorar ou procurar melhorar. Alguns entraram neste negócio por várias outras razões. Portanto, descubra por que as pessoas são como são.

Depois, há gerenciamento. A gerência não tem conhecimento da situação ou simplesmente não se importa? Descobrir. Você absolutamente precisa do apoio da gerência para melhorar as coisas. Se algo que levou 3 meses para construir de repente começar a levar 4 meses, porque agora você precisa escrever testes, fazer revisões de código, discutir no quadro branco com a equipe para decidir sobre boas soluções, emparelhar programas, etc. Certifique-se de que a gerência notará a diferença de horário. Algo que muda de 3 para 4 meses é fácil de observar e medir. Ter uma base de código sólida, um produto sustentável, boa arquitetura estável e outras coisas que contribuem para uma melhor estrutura do produto não é tão fácil de medir. Quanto tempo as melhores práticas compram a longo prazo não podem ser mensuradas antecipadamente, talvez nem mesmo após o fato. Por outro lado, um atraso de um mês é um acéfalo. Portanto, tenha suporte gerencial nisso. Prepare-se para fazer uma venda difícil.

Veja também o contexto do negócio. Isso está afetando a maneira como você trabalha? Você tem oportunidades que devem ser seguidas a qualquer custo, incluindo o sacrifício da qualidade do código ou das melhores práticas?

Vamos mudar de perspectiva por um momento.

Fico muito chateado quando adicionam espaguete à minha obra de arte e isso afeta meu humor no trabalho e minha produtividade.

Desculpe ... o que é? Arte? Eu sei que a maioria de nós está aqui para o reconhecimento de nossos colegas e você só consegue isso se for um bom desenvolvedor, mas o seu código é exibido em um museu ao lado de uma pintura? Isso tem que causar emoções nas pessoas que estão olhando? Lágrimas de alegria e bem-aventurança? Sim, sou sarcástico e exagero deliberadamente porque quero dizer para manter um senso de realidade. Não se apegue emocionalmente ao seu código.

Eu costumava trabalhar com um cara que jogaria alegremente a equipe, o projeto e a empresa sob o ônibus apenas para impor sua "arte" a todos. Ele era o "detentor da verdade" e, por definição, todos eram apenas inexperientes, cegos, dispostos a aprender, não se importavam, ou simplesmente estúpidos. Não se torne esse cara. Como desenvolvedor de software, seu trabalho é escrever um bom código, código testado, código de manutenção, código que agrega valor aos negócios e pode continuar a fazê-lo sob constantes mudanças futuras. E você precisa fazer tudo isso sob restrições de orçamento e tempo. É isso que significa ser um desenvolvedor de software profissional. A menos que você seja uma galeria de arte, a arte é ruim para os negócios. Seja pragmático e mantenha uma visão equilibrada das coisas. " Como ignorar o código incorreto que meus colegas escrevem e focar no trabalho"encerrou sua pergunta por causa da maneira como você estruturou o problema. Volte e veja a coisa toda.

Como posso resolver essa situação sem focar apenas na "má cultura da empresa", "graduados inexperientes" etc. etc. e realmente começar a melhorar a situação.

TL; DR: Examine atentamente a situação para descobrir por que as coisas acabaram nessa situação. Aceite que a situação é assim e veja como você pode melhorar a partir daí. Descubra qual é a opinião de todos sobre isso. Escolha suas batalhas. Forçar mudanças não funciona. Colabore para fazer as alterações. Você deve tentar mostrar como as coisas podem ser melhoradas e não mostrar o quanto elas são ruins. Convença a todos que o que você quer fazer é para um bem maior a longo prazo. Coloque-os a bordo.

E faça isso em pequenos passos.

Se você mudar demais de uma vez, as pessoas se sentirão desencorajadas e desistirão. Mudanças levam tempo. Mude sua empresa ou mude sua empresa. Boa sorte!