Não consigo programar porque o código que estou usando usa estilos de codificação antigos. Isso é normal para programadores?

Tenho meu primeiro trabalho real como programador, mas não consigo resolver nenhum problema por causa do estilo de codificação usado. O código aqui:

• Não possui comentários
• Não possui funções (50, 100, 200, 300 ou mais linhas executadas em sequência)
• Usa muitas ifinstruções com muitos caminhos
• Tem variáveis que não fazem sentido (eg .: cf_cfop, CF_Natop, lnom, r_procod)
• Usa um idioma antigo (Visual FoxPro 8 de 2002), mas há novos lançamentos a partir de 2007.

Sinto que voltei a 1970. É normal que um programador familiarizado com OOP, código limpo, padrões de design etc. tenha problemas com a codificação dessa maneira antiga?

EDIT : Todas as respostas são muito boas. Para minha (des) esperança, parece que existe muito desse tipo de código em todo o mundo. Um ponto mencionado em todas as respostas é refatorar o código. Sim, eu realmente gosto de fazer isso. No meu projeto pessoal, eu sempre faço isso, mas ... não posso refatorar o código. Os programadores só podem alterar os arquivos na tarefa para a qual foram projetados.

Toda mudança no código antigo deve ser mantida comentada no código (mesmo com o Subversion como controle de versão), além de meta informações (data, programador, tarefa) relacionadas a essa alteração (isso se tornou uma bagunça, há código com 3 linhas usadas e 50 linhas antigas comentadas). Estou pensando que não é apenas um problema de código, mas um gerenciamento de problemas de desenvolvimento de software.

Ok, eu vou ser franco. Esse é um péssimo lugar para trabalhar ... Eu já estive nessas situações e geralmente termina com você sendo engolido por esse código. Depois de mais ou menos um ano, você se acostumará e perderá a noção de como as alternativas modernas podem ser usadas para realizar a mesma tarefa de maneira mais fácil, de maneira mais sustentável e também mais rápida em tempo de execução. na maioria dos casos.

Saí de um local de trabalho como esse, porque, depois de apenas um mês, senti que estava sendo arrastado para um código skool antigo. Eu tentei tentar, mas decidi não. Eu não conseguia usar código limpo e comecei a perder habilidades por falta de prática cotidiana. Qualquer abordagem moderna teve que ser aprovada por três camadas de desenvolvedores, o que nunca aconteceu, porque a idéia era que as coisas pudessem quebrar quando as abordagens modernas fossem usadas. E a natureza frágil do código que sai quando você não usa abordagens modernas é bastante assustadora.

Não me interpretem mal, há casos em que as pessoas projetam demais as soluções e sou totalmente contra. Mas ser arrastado para convenções e estilos de codificação de 80 por um período extenso de tempo interromperá seu progresso e, também, penso, oportunidades de carreira.

Então, novamente, você precisa ganhar dinheiro, então, às vezes, precisa fazer o que não gosta. No entanto, fique de olho nos sintomas de burnout e transforme a codificação em uma tarefa mundana.

Esse estilo de codificação (se você quiser chamá-lo de qualquer tipo de estilo) é um estilo de codificação ruim .

Pode-se escrever funções curtas com nomes descritivos de variáveis ​​e controle de fluxo são na maioria das linguagens modernas (o Visual FoxPro é moderno, sim).

Os problemas que você está tendo são com uma base de código ruim , nada mais, nada menos.

Essas bases de código existem e são muitas - o fato de você estar tendo problemas com elas atesta como elas podem ser ruins (e que você tem um bom treinamento).

O que você pode tentar fazer é melhorar as coisas, onde pode - variáveis renomear, extrato de pontos comuns e funções grandes dividir em partes menores etc ... obter uma cópia de trabalhar efetivamente com Legacy Code ...

Estou em um projeto C # com uma estrutura muito ruim, a menos de um quilômetro do que você descreve. Apenas combinamos 12 funções separadas (copiar e colar óbvias) em uma que aceita um único parâmetro.

Isso não é realmente "antiquado", exceto que as boas práticas (atuais) de design nem sempre eram tão populares. Isso é apenas um código ruim. Código incorreto atrasa qualquer pessoa. Você acaba se acostumando, mas isso é apenas porque você se acostuma a peculiaridades específicas em seu sistema específico. Dado um novo projeto, você pode encontrar maneiras totalmente novas de escrever códigos incorretos. O bom é que você já sabe como identificar esses odores de código.

A maior coisa que você pode fazer é não propagar o problema . Não tome essas práticas ruins como uma convenção, a menos que sua equipe o faça. Mantenha o novo código limpo de maneira a não forçar um refator. Se é tão ruim e você tem tempo, considere um grande refator ... mas na prática você raramente tem esse luxo.

Considere adicionar comentários à medida que descobre as coisas e troque pequenos pedaços da maneira mais prática. A menos que você esteja codificando sozinho, precisará resolver isso com sua equipe; se não houver convenções, você deve dedicar algum tempo para elaborá-las e talvez comprometer-se a melhorar lentamente a base de código, se a estiver mantendo regularmente.

Se você encontrar uma função totalmente isolada com nomes de variáveis ​​inválidos e a estiver corrigindo de qualquer maneira, você também pode tornar os nomes de variáveis ​​úteis, refatorar os ifs. Não faça alterações nos recursos comuns, a menos que você refatore uma grande parte dele.

• não tem comentários - corrija-o conforme você o aprende
• não tem funções (50, 100, 200, 300 ou mais linhas executadas em sequência)

Isso provavelmente data de uma iteração anterior do código. Neste ponto, eu deveria ter cuidado com diferenças sutis entre blocos de código com aparência semelhante que se tornaram "recursos". Mas, independentemente de quão ruim seja essa ideia, é muito simples de entender ... então não tenho certeza de onde você teria problemas com isso.

• usa muitas declarações if com muitos caminhos - não tenho certeza do que você quer dizer aqui
• tem variáveis ​​que não fazem sentido (por exemplo: cf_cfop, CF_Natop, lnom, r_procod) -

Eu enfatizaria cautela com o bit 'renomeando variáveis'. Há uma boa chance de você simplesmente não entender a linguagem ainda, e os nomes das variáveis ​​farão muito mais sentido depois que você estiver lá por um tempo. Para não dizer que também não pode haver nomes de variáveis ​​problemáticos, mas seus exemplos parecem ter uma lógica para eles, se você soubesse quais são os acrônimos comuns em seu site. Obviamente, isso não é tão importante se você é um time de 1.

• usa um idioma que eu não conheço (Visual FoxPro 8 de 2002) - Esse é seu problema, não o código

Isso me parece uma oportunidade .

É claro que você já pode ver muitos problemas em como as coisas são feitas e gerenciadas. Você pode reclamar que é tudo lixo e que não pode fazer nada, ou pode usar isso como uma oportunidade de ouro para realmente mostrar ao seu empregador o seu valor.

Agora, isso não vai ajudá-lo se você for até o seu empregador e lhe disser que tudo precisa mudar. Portanto, o truque é seguir em frente por um tempo, fazer MUITAS perguntas e, quando você precisar escrever um código, precisará seguir as regras deles com todos os comentários, etc., pois precisará manter outros desenvolvedores informado usando o sistema que preferir atualmente, e ao mesmo tempo você pode introduzir refatorações sensatas que não arriscarão nada. Você pode extrair alguns métodos e, se o seu idioma suportar, introduzir alguns testes de unidade. Quando perguntado por que você fez dessa maneira, ou se lhe disseram que está fazendo algo "errado", evite ficar na defensiva ou argumentar enquanto faz uma boa apresentação de sua posição para o seu estilo preferido de codificação. Por exemplo, você pode consultar livros como o Clean Code de Bob Martin ou outros livros, artigos ou mesmo perguntas e respostas que você encontrou no Programmers.SE. Qualquer coisa que você considere útil para apoiar sua posição com fatos que podem estar além da sua experiência aos olhos das pessoas com quem você está trabalhando.

No que diz respeito aos comentários excessivos, parte disso pode ser esclarecida se você adicionar alguns nomes descritivos para as variáveis ​​e métodos, mas também poderá defender um bom sistema de controle de versão e usá-lo. para manter o registro das alterações e datas, etc., e para o uso de uma ferramenta para comparar as diferentes versões dos seus arquivos de origem, se ainda não houver um com o VCS escolhido.

Como eu disse, esta é uma oportunidade de contribuir para a melhoria de uma equipe de desenvolvimento que parece estar meio que perdida, por assim dizer. Você tem a oportunidade de se destacar como habilidoso e conhecedor, e como alguém que pode liderar pelo exemplo. Tudo isso é bom para ajudá-lo mais tarde, à medida que sua carreira avança.

Bem vindo a selva !

Infelizmente, muitas vezes começar a trabalhar em uma empresa significa começar a enfrentar esse tipo de situação, a menos que você trabalhe para uma empresa estruturada e bem organizada, essas situações são bastante comuns ...

Meu conselho é:

1. Comece a aprender e se familiarize com: linguagem de programação usada (Clipper / dBase) e ambiente (Visual FoxPro)

2. Leia e analise a base de código e comece a comentar

3. organizar / refatorar o código (abordar o problema de muitas linhas executadas em sequência)

Tendo problemas para enfrentar uma base de código semelhante, é normal, mas pode se tornar um grande desafio, tentando melhorar a qualidade do código e dar "seu toque" ao programa, melhorando a base de código e talvez tornando-o um programa melhor ...

Para responder à sua pergunta: Sim, pessoas / empresas em todos os lugares utilizam infraestrutura que pode ser construída com códigos ruins. Ao se integrar a essas situações, pode ser muito difícil de lidar.

No verão passado, trabalhei como estagiário desenvolvendo um aplicativo para ser usado pela equipe de controle de qualidade ligada a um departamento específico. A equipe de controle de qualidade usou muitos scripts independentes (VBScript, Perl, Bash) para executar testes em bancos de dados e outros, e queria reuni-los em um único aplicativo. O problema com isso, no entanto, é que esses scripts foram usados ​​em outras partes da empresa (portanto, os nomes das principais funcionalidades / variáveis ​​não puderam ser alterados) e o código foi "adicionado a" por quase 10 anos; muita porcaria se acumulou.

Aqui está o que você pode fazer sobre isso:

1. Peça ajuda: seus colegas de trabalho que tiveram que procurar, embora esse código provavelmente esteja familiarizado com suas idiossincrasias. O que é obtuso e confuso para você é perfeitamente adequado para eles. Então peça ajuda!
2. Refatorar sempre que possível: se você precisar observar / manter esse código por um longo período de tempo, refatore-o sempre que puder. Mesmo se você estiver executando uma busca e substituição em um nome de variável, tudo ajudará. A empresa que estagiei no último verão teve um problema semelhante ao usar nomes de variáveis ​​ruins. Sempre que possível, eu corria o código deles através de um pente fino, alterando nomes de variáveis, otimizando a lógica (agrupando várias funções em 1, por exemplo), etc. Faça o mesmo sempre que tiver oportunidade!

Como é o caso em todos os lugares, desde que os recursos externos do código funcionem corretamente, não importa como os internos funcionam.

Vou fazer alguns comentários diferentes de muitos dos respondentes aqui. Muitos dos meus comentários podem ser óbvios para você, mas é preciso dizer de qualquer maneira.

• Seja cauteloso ao alterar o código que você não entende, até entender.
• Se você estiver trabalhando em um ambiente de equipe, com o código no qual seus colegas trabalham, discuta suas alterações com eles antes de fazer as alterações. Ninguém gosta de um "atirador solitário" para entrar e mudar o código com o qual todos os outros estão familiarizados. Isso não quer dizer que suas alterações não sejam garantidas ou a coisa "certa" a ser feita.
• Obtenha adoção de suas idéias. Junte todos os participantes com suas idéias e use as habilidades de sua equipe para refatorar, em vez de sobrecarregar toda a carga de trabalho.
• Ganhe adesão da gerência. Eles podem alocar fundos para você re-fatorar o código.
• Fale com a gerência nos termos que eles entenderem sobre os benefícios de refazer sua base de códigos. Um código mais sustentável significa menos tempo gasto resolvendo bugs, adicionando recursos etc. O que significa desenvolvimento econômico. Tempo de resposta mais rápido etc.

É fácil adicionar codificação pura, sugestões de práticas recomendadas sem entender a política do seu ambiente. As pessoas com quem você trabalha podem não querer mudar ou alocar tempo para alterar sua base de código, mas tente vender a ideia para todos antes de entrar e mudar tudo (que tem riscos inerentes).

Espero que isto ajude.

Uma das coisas que se destaca é o seu comentário editado

Todas as alterações no código antigo devem ser mantidas comentadas no código, além das meta-informações (data, programador, tarefa) relacionadas a essa alteração (isso se tornou uma bagunça, existem códigos com 3 linhas usadas e 50 linhas antigas comentadas). Estou pensando que não é apenas um problema de código, mas um gerenciamento de problemas de desenvolvimento de software.

Também tenho um projeto em que herdei uma base de código FoxPro herdada com muitos dos problemas que você descreve. Uma das primeiras coisas que apresentei ao projeto foi um bom repositório de código-fonte. O FoxPro pode se integrar ao SourceSafe, mas esse produto é difícil de usar.

Peguei uma cópia da ferramenta scx de Paul McNett http://paulmcnett.com/scX.php e a integrei ao meu ciclo de desenvolvimento. Ele faz um bom trabalho ao extrair o código binário do FoxPro para um formato de texto que pode ser colocado em um repositório de origem, como Subversion, Mercurial ou até git. (Você pode encontrar o projeto SubFox em http://vfpx.codeplex.com útil.

Essas ferramentas fornecem o histórico e permitem que os programadores continuem com o trabalho de manter o código. Definitivamente, leva algum tempo para aprender a usar essas ferramentas, mas como todas elas são gratuitas, não faz sentido não investir algum tempo nelas. (mesmo que você não consiga que os projetos de trabalho se movam dessa maneira).

Vou concordar fortemente com a resposta do funkymushroom. Se você é um ambiente de equipe, certifique-se de que outras pessoas saibam que você está refatorando ou reorganizando o código, se você planeja obter boas atribuições futuras.

Por experiência pessoal, sei que, embora não seja seu estilo de codificação, se você estiver mantendo um código, que outros também modificam e mantêm, permanece no estilo do código existente. Adicionar comentários e esclarecimentos é bom, mas o layout e as convenções básicas devem permanecer. Os velhos gurus / armas do projeto esperam que o código seja semelhante ao que vêm vendo há anos.

Quando um cliente está gritando sobre um bug, sua gerência recorre às armas antigas para corrigir o problema o mais rápido possível. Se essas armas antigas, sob pressão, descobrirem que você “limpou o código” e agora elas precisam dedicar um tempo para descobrir onde você mudou ou renomeou que uma variável que eles conhecem precisa de ajustes, seu nome na empresa será alterado para “ lama".

Depois que a crise terminar, primeiro a arma antiga o culpará lentamente pela atualização crítica. Em seguida, você descobrirá que mantém o código limpo durante o tempo em que estiver na empresa. Finalmente, quando novos projetos interessantes estiverem disponíveis, seus gerentes perguntarão aos gurus sobre quem deve trabalhar no projeto e, se você os ferrou uma vez, nunca o fará no novo projeto, até que sua forragem seja lançada no final cumprir um prazo.

Se você aprendeu na faculdade a maneira "certa" de codificar e agora está no mercado de trabalho, esqueça a maneira "certa". Estes não são trabalhos de faculdade, esses projetos não duram apenas um semestre, eles podem viver por anos e terão que ser mantidos por um grupo de pessoas com diferentes níveis de conhecimento e diferentes níveis de interesse na última tendência de CS. Você tem que ser um jogador da equipe.

Você pode ser a maior programação hot shot da escola, mas no local de trabalho, seu primeiro emprego, você é um novato com zero crédito de rua. As pessoas que estão programando há anos não se importam com a escola ou com as notas, é o quão bem você brinca com os outros e quanta perturbação você traz à vida deles.

Nos meus 20 anos, pareço vários programadores ace despedidos, principalmente porque eles exigem fazer as coisas da maneira "certa". A menos que você traga algo muito, muito, muito exclusivo para o trabalho, você é substituível. Você pode ter sido o melhor da sua turma, mas no próximo ano alguém será o melhor da turma e estará procurando emprego.

Eu vejo isso como seu trabalho principal, é mantê-lo, até você decidir mudar de emprego. Para manter seu emprego, você precisa se divertir no playground que alguém construiu e pagou.

Sei que soo negativo, mas sempre há esperança. À medida que você ganha experiência, obtém sucesso, ganha influência e pode mudar as coisas de uma maneira melhor. Ao escrever um novo código ou em um novo projeto, pressione as alterações que você procura. Se for um código novo, as armas antigas não esperam que seja do jeito que deixaram, e quando virem as vantagens, poderão aprender e adaptar o novo caminho.

O sistema antigo pode mudar, mas leva tempo. Mudar algo introduz riscos e os negócios aborrecem, e você precisa dedicar tempo e trabalho para tornar a empresa confortável com a mudança.