As práticas de programação ruins são típicas na indústria de software? [fechadas]

Acabei de iniciar meu primeiro emprego como desenvolvedor de software há mais de um mês. Tudo o que aprendi sobre OOP, SOLID , DRY , YAGNI, padrões de design, SRP etc. pode ser jogado pela janela.

Eles usam C # .NET Webforms e fazem quase tudo no Code Behind com muito poucas Classes externas, definitivamente não chamadas de objetos. Eles usam controles personalizados e os reutilizam. Sobre os únicos objetos usados ​​é pelo Entity Framework . Eles reutilizam o Code Behinds para cada cliente. Eles têm métodos com 400 linhas, fazendo todos os tipos de coisas. Para novos clientes, eles pegam o aspx e o aspx.cs, retiram o código do cliente e começam a adicionar o novo código específico do cliente.

A primeira desculpa seria acrescentar manutenção adicional e mais código significa mais manutenção. É uma pequena loja de três desenvolvedores, incluindo eu. Um desenvolvedor tem mais de 30 anos de experiência e o outro tem mais de 20 anos de experiência. Um costumava ser desenvolvedor de jogos e o outro sempre trabalhava em C e C ++.

Quão comum é isso na indústria de software? Como posso garantir que eu permaneço no topo da OOP e dos princípios relacionados? Pratico no meu tempo livre e sinto que realmente preciso trabalhar com um desenvolvedor mais experiente para melhorar o POO.

1. Os princípios que você citou na sua pergunta são apenas esses ... princípios. Eles não são mandatos, leis ou ordens.
2. Embora as pessoas que vieram com esses princípios sejam muito inteligentes, elas não são autoridades absolutas. Eles são apenas pessoas que oferecem suas idéias e orientações.
3. Não existe uma maneira "correta" de programar. Isso é evidenciado pelo fato de que a maneira "aceita" de fazê-lo mudou e continua a mudar radicalmente ao longo do tempo.
4. O envio de um produto geralmente pode ter precedência sobre fazê-lo da maneira "certa". Essa é uma prática tão predominante que possui um nome: Dívida técnica.

5. Algumas arquiteturas de software de uso comum não são ideais. As melhores práticas estão evoluindo de aplicativos monolíticos grandes para coleções de módulos pouco acopladas.

6. O contexto é importante. Muitos princípios de arquitetura só provam o seu valor quando você está trabalhando com programas grandes ou domínios específicos. Por exemplo, a herança é útil principalmente para hierarquias da interface do usuário e outras estruturas que se beneficiam de arranjos profundamente aninhados e fortemente acoplados.

Então, como você segue um caminho "certo", um caminho de princípios, para poder emergir do deserto?

1. Estudar a adequação, em vez de correção. A maneira "certa" de fazer qualquer coisa no desenvolvimento de software é a que melhor atende aos seus requisitos específicos.
2. Estude trocas. Tudo no desenvolvimento de software é uma troca. Deseja mais velocidade ou menos uso de memória? Você quer uma linguagem de programação muito expressiva com poucos profissionais ou uma linguagem menos expressiva que muitos desenvolvedores conhecem?

3. Estude a atemporalidade. Alguns princípios resistiram ao teste do tempo e sempre serão relevantes. Os sistemas de tipos são universais. Funções de primeira classe são universais. As estruturas de dados são universais.

4. Aprenda pragmatismo. Ser prático é importante. Pureza matemática, arquiteturas de catedral de cristal e princípios de torre de marfim são inúteis se você não puder enviar.

5. Seja um artesão, não um fanático. Os melhores desenvolvedores de software são os que conhecem as regras e, em seguida, sabem como quebrá-las quando faz sentido. Eles ainda sabem como resolver problemas e pensar por si mesmos. Eles usam princípios para informar e orientar suas escolhas, não ditá-las.
6. Escreva código. Muitos disso. Os princípios de design de software são otimizações prematuras até você escrever muito código e desenvolver um instinto de como aplicá-los corretamente.

Não é incomum. Uma coisa a perceber é que a indústria de software é incrivelmente diversa. Algumas empresas são de ponta. As principais universidades e empresas de software inovadoras (até alguns laboratórios das grandes!), Bem como pessoas ou grupos abençoados, como a quadrilha de quatro, analisam os problemas que ocorrem com as maneiras comuns de fazer as coisas e inventar novas linguagens, máquinas, ferramentas e padrões. Novas empresas, geralmente derivadas ou cindidas, tentam usá-las comercialmente e, às vezes, têm um sucesso incrível. Pense no Facebook ou no Google.

Mas o software é usado em quase todos os lugares hoje em dia, talvez principalmente em empresas que na verdade não são empresas de software. Eu trabalhei principalmente no setor de transporte (automotivo e ferroviário), e há uma mistura de experiências. Mas nenhum deles estava perto da "vanguarda". Às vezes eles não podem ser; O software relevante para segurança depende de ferramentas bem testadas (atualmente estamos usando um compilador C ++ validado da década de 1990). Às vezes eles não têm as pessoas certas. Frequentemente, o software é desenvolvido por engenheiros de outras áreas, que acabaram entrando no desenvolvimento de software em sua empresa quando o software se tornou cada vez mais importante. Não se pode esperar que eles conheçam ou usem os princípios de engenharia de software.

Outra coisa a considerar é o que é importante em um engenheiro no mundo real. Muitas vezes, a tarefa em questão não é, literalmente, a ciência dos foguetes. Os problemas do pão com manteiga em empresas que não são de software podem ser resolvidos com meios modestos de software. O que torna um engenheiro de software útil, talvez até bom, é em parte o que faz um bom engenheiro geral: seja confiável; organizar e documentar seu trabalho de forma responsável; seja cooperativo; faça boas estimativas de custo e tempo (a validade da estimativa é mais importante que o custo e o tempo reais!); entenda o que você pode ou não fazer. Conspicuamente faltando aqui é "conhecer e usar ferramentas e procedimentos de ponta". O que você descreve é ​​uma empresa que estabeleceu um conjunto de ferramentas e um processo que funciona para eles. Eles provavelmente nunca produzirão nada sexy ou extraordinário, mas atendem às demandas dos clientes o suficiente para gerar um fluxo constante de receita suficiente. Essa poderia ser a definição de engenharia ;-).

Então sim: o que você aprende na universidade não é comum em grande parte do campo.

Quero adicionar um pedaço de consolo ou uma nota mais otimista. O que você aprendeu não deve ser jogado pela janela. Você pode aplicar princípios melhores no seu trabalho diário, onde isso não quebra as coisas. Talvez haja uma janela de oportunidade para introduzir uma nova ferramenta ou padrão de design. As chances são melhores quando a maneira antiga de fazer as coisas é desagradável para os colegas ou se eles enfrentam problemas com o gerenciamento de complexidade ou manutenção (os dois problemas mais virulentos abordados pelas inovações). Esteja pronto para oferecer melhorias quando houver uma oportunidade. Seja uma influência positiva e melhore gradualmente métodos e ferramentas; espalhar conhecimento onde é apreciado.

Eles usam C # .Net Webforms e fazem quase tudo no Code Behind com muito poucas classes externas

Aqui está a sua explicação. Se você não está ciente, o código dos formulários da Web pronto para uso é praticamente o oposto polar de OOP, SOLID, DRY, YAGNI, Design Patterns, SRP , etc. Até os exemplos oficiais da Microsoft há alguns anos atrás faria você se encolher hoje.

Os Web Forms avançam em direção a um fluxo processual, com alguns "eventos" falsos acionados por cliques de controle e similares. Os desenvolvedores que passaram muito tempo criando formulários da Web também geralmente parecem relutantes em se afastar dele, provavelmente porque gastaram tanto tempo aprendendo o ciclo de vida da página e como executar controles renderizados dinamicamente que não querem jogar esse conhecimento fora agora em face de métodos novos / melhores. Uma versão inconsciente da falácia de custo irrecuperável. Esses desenvolvedores passaram os anos aprendendo a organizar formulários da Web e agora não se afastam facilmente desse conhecimento, daí a conversa sobre o tempo de "manutenção".

E isso é bastante comum no espaço do .NET Web Forms, btw.

Quão comum é isso na indústria de software?

Muito comum. Mais ou menos a mesma coisa que ter um encanador destruindo seu encanamento, um carpinteiro entregando lixo ou um alfaiate barato fazendo um terno mal ajustado. Ou seja, é tudo humano.

Há uma boa razão para isso acontecer: pessoas que não são realmente treinadas (ou não entusiasmadas) tendo que implementar algo sob pressão.

Isso não é um problema para essas pessoas, principalmente, mas geralmente das estruturas que envolvem o desenvolvimento de software nessa empresa. Por exemplo, uma empresa pode ter vários estagiários desenvolvendo seu software interno; mesmo que esses estagiários sejam brilhantes e conhecedores, eles permanecerão lá por algumas semanas ou meses, e a propriedade mudará frequentemente.

Ou alguém que seja excelente no domínio, mas não um programador, pode hackear alguns aplicativos VBA etc. porque parece ser bastante fácil no começo.

Ou um aplicativo bem elaborado termina na fase de manutenção, todos os bons desenvolvedores seguem em frente e, depois, continua a ser desenvolvido por poucas pessoas (na pior das hipóteses: uma) que sabem pouco sobre ela, que não têm documentação etc.

Como posso garantir que eu permaneço no topo da OOP e dos princípios relacionados? Pratico no meu tempo livre e sinto que realmente preciso trabalhar com um desenvolvedor mais experiente para melhorar o POO.

Há duas respostas possíveis:

• Ou: discuta isso com seu chefe e certifique-se de entrar em projetos limpos. Se não for possível, encontre um novo chefe.
• Ou: assuma a responsabilidade por isso. Isso significa fazê-lo por conta própria - no seu tempo livre, ou se você puder, na empresa, mas conduzido por você (improvável).

Se a segunda resposta parecer cínica demais para você, deixe-me garantir que não. Um carpinteiro que tem uma loja de madeira em casa vai mais certamente ser um carpinteiro melhor do que aquele que não o faz.

Por exemplo, é absolutamente possível e muito divertido para algumas pessoas, por exemplo, cavar em um novo idioma como Ruby, aprender não apenas a sintaxe, mas também aprofundar aspectos especiais de OO dessa linguagem e realmente mergulhar fundo. Tudo no seu tempo livre, sem ter nenhuma conexão com o seu trabalho. Será apenas um hobby, mas, sendo o profissional treinado que você é, pode ser tão eficaz (ou mais) quanto ficar sentado ao lado de algum desenvolvedor líder e tentar seguir o que está fazendo. Isso será estritamente para seu desenvolvimento pessoal e sua própria diversão. Se você não se diverte fazendo isso, ou se acha que simplesmente não consegue entender nada, apague isso e retorne à primeira resposta.

Isso desenvolvedor líder que está treinando você tem bastante provável aprendi que coisas exatamente desta maneira ...

Eu acho que na Espanha é uma constante, porque quando um desenvolvedor passa muitos anos em uma empresa, ele geralmente é promovido para mais áreas de gerenciamento, como análise e gerenciamento de projetos. Como resultado, nenhuma revisão por pares é feita e o código geralmente é escrito por pessoas menos experientes.

As falhas dessas pessoas experientes nunca são corrigidas: em vez disso, o único foco é realizar o trabalho. Como resultado, práticas cada vez mais erradas são acumuladas no código.

Eventualmente, algum espertinho diz que a melhor "solução" é mudar para uma tecnologia emergente que irá gerar código mais limpo e mais sustentável, criando um novo aplicativo. Como se a tecnologia por si só pudesse fazer isso.

Novamente, programadores inexperientes são postos a trabalhar nessa nova tecnologia, ninguém revisa o código e o círculo é fechado novamente .... para todo o sempre ....

Algumas das "melhores práticas" que você aprende na escola não são práticas ou econômicas em projetos do mundo real. Uma das maiores mudanças que notei foi na formatação e nos comentários. A maioria dos meus professores enfatizou a importância de documentar extensivamente o seu código, mas, no mundo real, o bom código é muitas vezes (nem sempre!) Auto-explicativo e, mais importante, muitos chefes não querem pagar para que você gaste mais tempo escrevendo comentários.

Às vezes, você vê programadores pressionados pelo tempo usando atalhos e antipadrões que exigem menos informações do que as soluções de qualidade.

No entanto, um dos maiores problemas que notei em muitas equipes e projetos é a falta de vontade de aprender coisas novas. Muitos dos programadores mais antigos com quem conversei começaram suas carreiras em um período "selvagem do oeste" da engenharia de software, quando as qualificações começaram e terminaram com a vontade de escrever código. Eles geralmente se formavam em campos completamente diferentes e pulavam para a programação com pouca ou nenhuma educação formal quando surgia uma oportunidade (por exemplo, seu empregador não tinha um programador e precisava de alguém para aprender para criar software interno). Alguns desses programadores autodidatas da velha escola nunca se esforçam para aprender práticas modernas de codificação e continuam codificando praticamente o estilo que aprenderam décadas atrás. Quando eles se encarregam de novos projetos devido à antiguidade, tendem a reter os projetos e prejudicar a qualidade geral do código.

Obviamente, o que foi dito acima não se aplica a todos os programadores mais antigos, e os codificadores de nova geração podem ser igualmente culpados. Eu trabalhei com muitos programadores mais jovens que pegaram algumas ferramentas e bibliotecas recém-saídas da faculdade e depois pararam de aprender completamente. Eles fazem o download de um IDE ou biblioteca uma vez e nunca o atualizam, a menos que a empresa o exija (às vezes você pode adivinhar em que ano um programador se formou com base na desatualização de suas bibliotecas). Eles não acompanham os novos recursos nos idiomas de sua escolha e nunca aprendem novos idiomas. Eles não aprendem novas estratégias de programação e podem abusar de padrões ou paradigmas porque não conhecem alternativas mais apropriadas (oh MVC, quão fortemente você é abusado). À medida que o tempo passa, o fluxo de trabalho se torna cada vez mais desatualizado e eles se tornam mais um passivo do que um ativo.

Em resumo, duas das maiores causas de bases de código confusas são prazos apressados ​​e programadores com conhecimento desatualizado ou incompleto. Infelizmente, a responsabilidade por ambos os problemas pode recair pesadamente sobre o chefe ou o CTO, que deve garantir que os prazos sejam realistas e que os funcionários estejam atualizados sobre seus conhecimentos e habilidades. Se o chefe não souber nada sobre boas práticas de programação, o melhor que você pode fazer é tentar sugerir mudanças e esperar que estejam abertas a sugestões. Infelizmente, eles podem estar inclinados a confiar na palavra de um programador mais experiente que não entende OOP e gosta de escrever 10.000 aulas de linha.

Algumas das práticas ruins de programação resultam do trabalho com software legado que começou a ser desenvolvido décadas atrás. Se houver um software enorme e complexo, reescrever tudo pode não ser uma opção. Pode até ser extremamente difícil entender tudo o que o código está realmente fazendo. A melhor opção pode ser apenas copiar o que funciona e, ao mesmo tempo, tentar integrar melhores práticas de programação, se você puder fazer isso sem quebrar nada.

Eu acho que é importante não apenas dizer o certo do errado, mas conhecer as razões por trás de todo certo e errado. Quando você conhece os motivos, pode prever consequências. Por que usar esse ou aquele princípio não porque foi descrito em um livro, mas porque sabemos como isso ajuda e o que exatamente acontece, devemos quebrá-lo. Se você sabe o que acontece quando, pode pesar prós e contras e tomar uma decisão. Isso também ajudará você a discutir sua posição toda vez. O SOLID e o OOP também podem reduzir a manutenção se bem utilizados.

O SOLID, se usado de forma dogmática demais, leva a muitas classes e métodos, o que não é tão bom assim. Não exagere. Isso é em parte um grande problema com nossos livros e tutoriais, pois eles geralmente tentam promover idéias sem justificativa adequada. OOP também tem seus contras. Muitos princípios e paradigmas se contradizem. Você não precisa estar no topo, precisa tornar tudo razoável, justificado, elegante e simples.

Além disso, como este é seu primeiro trabalho, é provável que esses programadores não sejam muito qualificados. Mas, novamente, eles provavelmente estão confiando em tarefas não muito difíceis, que podem ser realizadas sem tanta habilidade e com salários mais baixos por codificadores mais baratos e menos qualificados. É assim que a economia funciona. Cada local de trabalho é diferente.

Eu entendo como você se sente. Não entre em pânico . Você precisará do que sabe, talvez não imediatamente, mas isso o ajudará. Talvez em um local de trabalho diferente, talvez em algumas ocasiões. Você tem tempo pela frente para ir mais longe.