Lidar com código legado ajuda a evoluir como programador? [fechadas]

Sou desenvolvedor Java com um pouco mais de um ano de experiência, o que me coloca em algum lugar acima de um júnior, mas ainda não entre os desenvolvedores de nível médio. Recentemente, me ofereceram um projeto de longo prazo, que consiste em estudar um código de aplicativo bancário existente por 4 meses e depois introduzir alterações quando necessário. Como um programador não tão experiente, estou procurando maneiras de desenvolver e me pergunto o que esse projeto pode dar.

Você consideraria lidar com um aplicativo grande e provavelmente não tão bem escrito como uma boa prática para iniciantes?

A solução de problemas do código existente é uma excelente maneira de desenvolver como programador. Se o código estiver incorreto, você aprenderá o impacto dos erros que eles cometeram e talvez evite alguns deles ao fazer o design. Se o código for bom, você aprenderá algo sobre como criar um aplicativo sustentável.

Você também aprenderá a lidar com a complexidade de um aplicativo de negócios real. Como esse é o setor bancário, você aprenderá sobre coisas como regulamentação federal e controles contábeis internos nos quais você talvez nunca tenha pensado. Essas são boas coisas para saber quando você é solicitado a criar outra coisa no mundo financeiro. E a programação financeira pode ser um setor bastante lucrativo para se trabalhar, portanto, obter experiência bancária pode ser muito bom para você.

Você pode até aprender que, apenas porque algo foi escrito há 15 anos, em um idioma que você prefere não usar, não é necessariamente ruim. Afinal, ele está sendo executado com sucesso esse tempo todo.

Se, como na maioria dos aplicativos herdados, o aplicativo não possui teste de unidade, você realmente precisa ter certeza de que uma alteração não afetará outra coisa. Você pode aprender como adicioná-lo e vender o gerenciamento sobre o motivo de adicioná-lo. uma boa ideia.

Eu acho que é uma excelente prática para qualquer um iniciante . Aprender com a experiência de outras pessoas pode ser muito eficaz.

O verdadeiro desafio não é encontrar erros, mas entrar na cabeça do outro desenvolvedor e tentar descobrir que whyo código foi escrito dessa maneira. Às vezes é porque eles eram desleixados, e às vezes é porque eles tinham uma boa razão. Suponha que o desenvolvedor seja pelo menos tão bom quanto você, mas pode ter mais conhecimento de domínio.

Essa é uma boa prática para qualquer desenvolvedor em qualquer momento de sua carreira. Se você pode revisar e analisar o software existente e encontrar maneiras de aprimorá-lo, demonstrará que é um desenvolvedor valioso. Você não apenas aprenderá como os outros projetaram e desenvolveram software, mas ao longo do caminho, aprenderá o que não fazer, que é um conhecimento valioso por si só.

Se você está pronto para o desafio, aceite este projeto e melhore-o.

Isso absolutamente o ajudará, mas você precisa ter cuidado.

Você precisa aprender com o código legado. Como você sabe o que é bom e o que é ruim? Talvez você possa reconhecer os prós e os contras de diferentes padrões / métodos, mas se você fosse um desenvolvedor iniciante, talvez não consiga.

E fique muito tempo no primeiro emprego, e talvez você não esteja aprendendo ou desenvolvendo habilidades suficientes e acabe preso lá.

Legado pode significar qualquer coisa, exceto com base no seu comentário 'não tão bem escrito', vou assumir que Legado significa tecnologias e padrões 'ruins' ou pelo menos 'desatualizados'. Se o código legado for bom, não se detenha e aprenda todas as suas linhas.

Eu não acho que haja avisos claros o suficiente contra o tipo de trabalhos e projetos que desviam sua carreira e o deixam preso em buracos sem valor nesse segmento até o momento.

Alerta de analogia esportiva: você acha que um defensor de linha na NFL aprende mais e se torna mais valioso jogando no time com o pior registro ou o melhor? Minha resposta: Eles não apenas são mais valiosos por terem jogado pelas melhores equipes, mas provavelmente adquiriram as melhores práticas e conhecimentos e evitaram práticas e atitudes de final de carreira.

Há muitos códigos terríveis anti-padrões por aí que realmente funcionam para os negócios e pagam muitos salários dos desenvolvedores. Proponho que um desenvolvedor que não tenha visto código suficiente feito da maneira "correta" possa confundir código anti-padrão com uma solução legítima para um problema. A empresa pode dizer que a solução funciona, mas não é aquela que você deseja em seu currículo ou que gostaria de se gabar para outros desenvolvedores. Isso também é relevante apenas se o seu caminho de crescimento pessoal incluir ganhar o respeito de seus colegas de engenharia e não apenas aumentar temporariamente a renda de qualquer empresa em que você trabalhe (parece ruim, mas, no final, a melhor engenharia ganha absolutamente o máximo de dinheiro IMO) .

Infelizmente, há muito código e muito tempo que pode passar antes que a dívida tecnológica seja revelada. E essa dívida tecnológica geralmente é reconhecida exatamente quando é tarde demais. Quem quer que tenha tentado parar com a dívida de tecnologia ou antipadrões antes, poderia ter sido marginalizado devido à despesa extra percebida ou à falta de entendimento do ect de escalabilidade. É nosso dever, como engenheiros, expor imediatamente as dívidas de tecnologia. Projetos sem engenheiros experientes correm o risco de atingir uma parede de tijolos em algum momento, na verdade todos os projetos, mesmo com desenvolvedores talentosos. A maioria das empresas vê "algum ponto" como tempo suficiente para corrigi-lo mais tarde. Isso torna as opções de trabalho para desenvolvedores iniciantes um assunto muito complicado. Também aponta os objetivos e as mentalidades totalmente diferentes entre desenvolvedores e empresas, e quão complicado é preencher a lacuna.

O objetivo dos engenheiros é 'incluir' o trabalho científico real e a consideração do projeto, enquanto o objetivo dos negócios é 'excluir' custos e tempo desnecessários. Como os engenheiros geralmente não sabem qual é o nível de esforço e tempo até que o estado final seja realmente concluído, o desenvolvimento de software ocorre como qualquer bom drama, com personagens como ágil, scrum e kanban desempenhando papéis principais.

Uma solução pode ser ficar longe do código incorreto até que você tenha visto código bom o suficiente para não ser "corrompido". Adoro dizer que desenvolvedores seniores criam soluções simples para problemas complexos. Da mesma forma, os desenvolvedores juniores de nível intermediário criam soluções complexas para problemas simples e complexos.

Outra vantagem é que você precisa trabalhar com códigos bons E ruins em diferentes pontos para obter entendimento. Se você não o fez, então vá em frente e esteja preparado para desaprender tudo quando encontrar um sistema melhor. Eu acho que essa é provavelmente uma trajetória mais comum para a maioria dos desenvolvedores.

Sou tendencioso este ano porque sinto que estou escalando uma montanha extremamente complicada de 'molho secreto'. Enquanto aumentarei minha capacidade de decifrar alguns dos piores padrões que já vi, é tão "personalizado" e "único" que não acredito que minha luta aumentará minha comercialização ou minha habilidade utilizável definida no meu futuro.

A fim de manter minha sanidade mental, estou apenas caminhando em ritmo constante e abraçando todos os bloqueios de estrada como par para o curso. Tendo acabado de revisar minhas metas anuais com meu chefe, que incluem cavar esse buraco legado, estou pensando que pode ser uma escalada sacrificial. Eu poderia sobreviver ao processo com críticas ruins e lentidão percebida. Este é um aviso realista e agourento para aqueles que se perguntam que trabalho tomar.

Disclaimer: Este post vai durar muito mais tempo do que minhas opiniões, então leve-o com um pouco de sal. Amanhã eu posso amar o código legado! (Duvido).

Depende muito de como você define "legado" neste contexto. Deixe-me dar um exemplo de C e C ++. Muitos programadores de C ++ consideram uma má prática usar seqüências de caracteres C em aplicativos C ++, outros não exigem mixagem, enquanto outros, por sua vez, afirmam que é simples e totalmente inútil usar qualquer parte do código C porque eles são antigos, ou seja, " código legado ". Alguns vão mais longe e evitam usar idiomas padrão pré-C ++ X (substitua o 'X' pelo número apropriado), estilo - isto é sintaxe, pois é estilo "legado".

Deixando de lado os problemas de desempenho de fluxos e seqüências de caracteres C ++ e algumas peculiaridades de STL, é uma boa prática dar uma olhada no que está dentro de sua diretiva de pré-processador, tão amada #include <string.h>. Se você seguir o caminho para a implementação e se encontrar em uma máquina unix / linux em /usr/include/string.h(e obter fontes de implementação libc, por exemplo, no gnu.org ) e ler strcmp.cou strlen.cou strtok.c, aposto que você ouvirá "Que mundo lindo "entrando em fase.

Há, no entanto, uma ressalva a essa prosa - a saber, classes e métodos obsoletos. Em Java, muitas coisas herdadas ainda são acessíveis em um ambiente recente, mas, se bem me lembro, nem tudo. No setor de IB, pela minha própria experiência, bem, nem todo software é escrito por bons programadores. Muitos graduados tiveram praticamente zero exposição à programação do mundo real antes de começarem na posição de analista / desenvolvedor. Mas não generalize esta afirmação. Conheço muitas pessoas que empregam Java e C # no núcleo de ambientes de alto rendimento e baixa latência. Não concordo com eles, mas, felizmente, isso é problema deles. Se eles tivessem se tornado verdadeiros HFT, seriam empurrados para trás na fila. Mas novamente, facilmente deduzida dessa sentença é a suposição (e em muitos casos o fato) de que o código Java é altamente otimizável. E se você pode se destacar na otimização, se necessário, não apenas corrigindo isso ou aquilo, você se tornará inestimável como desenvolvedor. É muito gratificante a maneira de perceber quanto você contribuiu. Eu aceitaria.