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

1. Os princípios que você citou em sua pergunta são apenas isso ... princípios. Eles não são mandatos, leis ou ordens.
2. Enquanto as pessoas que surgiram com esses princípios são muito inteligentes, elas não são autoridades absolutas. Eles são apenas pessoas que oferecem seus insights e orientações.
3. Não existe uma maneira "correta" de programar. Isso é evidenciado pelo fato de que a maneira "aceita" como o fizemos mudou e continua a mudar radicalmente com o passar do tempo.
4. O envio de um produto muitas vezes pode ter precedência sobre o modo "correto". Esta é uma prática tão comum que tem um nome: Dívida técnica.

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

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

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

1. Adequação do estudo, ao invés de correção. A maneira "certa" de fazer qualquer coisa no desenvolvimento de software é a que mais atende às suas necessidades específicas.
2. Trocas de estudo. Tudo no desenvolvimento de software é uma troca. Você quer 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 sabem?

3. Estudo da intemporalidade. Alguns princípios resistiram ao teste do tempo e sempre serão relevantes. Sistemas de tipos são universais. Funções de primeira classe são universais. Estruturas de dados são universais.

4. Aprenda o pragmatismo. Ser prático é importante. A pureza matemática, as arquiteturas de catedral de cristal e os princípios da 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 aqueles que conhecem as regras e, em seguida, sabem como quebrá-los quando faz sentido fazê-lo. Eles são os únicos que ainda sabem como resolver problemas e pensam por si mesmos. Eles usam princípios para informar e orientar suas escolhas, não para ditá-los.
6. Escreva o código. Muito disso. Os princípios de design de software são otimizações prematuras até que você tenha escrito muito código e desenvolvido um instinto de como aplicá-los corretamente.

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

Mas o software é usado quase em todos os lugares nos dias de hoje, talvez principalmente em empresas que não são empresas de software. Eu trabalhei principalmente na indústria de transporte (automotivo e ferroviário), e há uma mistura de experiências. Mas nenhum deles estava nem perto da "ponta". Às vezes eles não podem ser; software de segurança relevante depende de ferramentas bem-avaliadas (atualmente estamos usando um compilador C ++ validado dos anos 90). Às vezes eles não têm as pessoas certas. Muitas vezes, o software é desenvolvido por engenheiros de outras áreas que acabaram de deslizar para o desenvolvimento de software em sua empresa quando o software se tornou cada vez mais importante. Não se pode esperar que eles saibam ou usem princípios de engenharia de software.

Outra coisa a considerar é o que é importante em um engenheiro no mundo real. Muitas vezes a tarefa em mãos é, literalmente, não a ciência dos foguetes. Os problemas comuns 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: ser confiável; organizar e documentar seu trabalho com responsabilidade; ser cooperativo; fazer boas estimativas de custo e tempo (a validade da estimativa é mais importante do que o custo e o tempo reais!); entenda o que você pode e não pode fazer. Faltam claramente aqui "conhecer e usar ferramentas e procedimentos de ponta". O que você descreve é uma empresa que estabeleceu um conjunto de ferramentas e processos que funcionam para eles. Eles provavelmente nunca produzirão algo 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.

Editar: 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 em 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 se deparam com problemas de gerenciamento de complexidade ou manutenção (os dois problemas mais virulentos abordados pelas inovações). Esteja preparado para oferecer melhorias quando houver uma oportunidade. Seja uma influência positiva e melhore gradualmente os métodos e ferramentas; espalhar conhecimento onde é apreciado.

They use C# .Net Webforms and do almost everything within the Code Behind with very little External Classes

Aqui está sua explicação. Se você não está ciente, código de Web Forms pronto para uso é praticamente o oposto de OOP, SOLID, DRY, YAGNI, Padrões de Projeto, SRP , etc. Mesmo os exemplos oficiais da Microsoft de alguns anos atrás faria você se encolher hoje.

O Web Forms empurra-se para um fluxo processual, com alguns "eventos" falsos acionados por cliques de controle e similares. Devs que passam muito tempo fazendo Web Forms geralmente também parecem relutantes em se afastar dela também, provavelmente porque gastaram tanto tempo aprendendo o ciclo de vida da página e como fazer controles renderizados dinamicamente que eles detestam jogar fora esse conhecimento agora diante de métodos novos / melhores. Uma versão inconsciente da falácia do custo irrecuperável. Esses desenvolvedores passaram os anos aprendendo a usar os formulários da Web e agora não se afastarão facilmente dessa experiência, daí sua conversa sobre o tempo de "manutenção".

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

How common is this within the software industry?

Muito comum. A mesma coisa que ter um encanador destrói seu encanamento, um carpinteiro entregando lixo ou um alfaiate barato fazendo um terno mal ajustado. Ou seja, é tudo humano.

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

Este não é um problema dessas pessoas, principalmente, mas geralmente das estruturas que envolvem o desenvolvimento de software nessa empresa. Por exemplo, uma empresa pode ter um monte de estagiários desenvolvendo seu software interno; mesmo que os estagiários sejam inteligentes e experientes, eles estarão lá apenas por algumas semanas ou meses, e a propriedade mudará com frequência.

Ou uma pessoa que é ótima no domínio, mas não um programador, pode hackear alguns aplicativos VBA, etc., porque parece ser bem fácil no começo.

Ou uma aplicação bem feita acaba na fase de manutenção, todos os bons desenvolvedores seguem em frente, e então continua a ser desenvolvida por poucas pessoas (no pior caso: uma) que sabem pouco sobre isso, que não têm documentação , etc.

How can I ensure that I stay on top of OOP and the related principles? I practice in my spare time and I feel like I really need to work under a more experienced developer to get better at OOP.

Existem 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 mesmo. Isso significa fazê-lo por conta própria - no seu tempo livre, ou se você puder, na empresa, mas impulsionado por si mesmo (improvável).

Se a segunda resposta parece muito cínica para você, então deixe-me assegurar que não é. Um carpinteiro que tem uma loja de carpintaria em casa certamente será um carpinteiro melhor do que aquele que não o faz.

Por exemplo, é absolutamente possível e um lote de diversão para algumas pessoas, por exemplo, mergulhar em um novo idioma como Ruby, aprender não apenas a sintaxe, mas também aspectos especiais OO de essa linguagem e realmente mergulhar fundo. Tudo no seu tempo livre, sem ter qualquer ligação ao seu trabalho. Será apenas um hobby, mas sendo o profissional treinado que você é, pode ser tão eficaz (ou mais) quanto sentar-se ao lado de algum desenvolvedor líder e tentar seguir o que eles estão fazendo. Isso será estritamente para o 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, então risque isso e retorne à primeira resposta.

Esse desenvolvedor líder que está treinando você provavelmente já aprendeu essas coisas exatamente dessa maneira ...

Eu acho que na Espanha é uma constante, porque quando um desenvolvedor passa muitos anos em uma empresa, ele (ou ela) é geralmente promovido a 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, seu único foco é ter o trabalho feito. Como resultado, práticas cada vez mais erradas são acumuladas no código.

Por fim, alguns especialistas inteligentes dizem que a melhor "solução" é mudar para uma tecnologia emergente que gerará código mais limpo e mais fácil de se manter, criando um novo aplicativo. Como se a tecnologia por si só pudesse fazer isso.

Mais uma vez, programadores inexperientes são colocados para trabalhar nessa nova tecnologia, ninguém revisa o código e o círculo é fechado novamente ... para 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 comentários. A maioria dos meus professores enfatizou a importância de documentar extensivamente seu código, mas no mundo real, o código bom é muitas vezes (nem sempre!) Autoexplicativo e, mais importante, muitos chefes não querem pagar para você gastar mais tempo escrevendo comentários.

Às vezes, você verá programadores que são pressionados pelo tempo usando atalhos e antipadrões que exigem menos chapa do que soluções de qualidade.

No entanto, um dos maiores problemas que tenho notado em muitas equipes e projetos é a relutância em aprender coisas novas . Muitos dos programadores mais antigos com quem conversei começaram suas carreiras em um período de engenharia de software "Wild West", quando as qualificações começaram e terminaram com a disposição de escrever código. Eles geralmente se especializaram em campos completamente diferentes e entraram na programação com pouca ou nenhuma educação formal quando surgiu uma oportunidade (por exemplo, seu empregador não tinha um programador e precisava de alguém para aprender a fim de criar software interno). Alguns desses programadores autodidatas da velha escola nunca se esforçam para aprender práticas modernas de codificação, e continuam a codificar em praticamente qualquer estilo que aprenderam décadas atrás. Quando acabam encarregados de novos projetos devido à antiguidade, tendem a atrasar os projetos e prejudicar a qualidade geral do código.

Claro que o acima não se aplica a todos os programadores mais antigos, e codificadores de nova geração podem ser tão culpados. Eu trabalhei com muitos programadores mais jovens que pegaram algumas ferramentas e bibliotecas recém saíram da faculdade e então pararam de aprender completamente. Eles baixam uma IDE ou biblioteca uma vez e nunca a atualizam, a menos que sua empresa exija (você pode, às vezes, adivinhar em que ano um programador se formou com base em quão desatualizadas são suas bibliotecas). Eles não acompanham novos recursos em seus idiomas de preferência 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 strongmente você é abusado). Com o passar do tempo, o fluxo de trabalho torna-se cada vez mais desatualizado, tornando-se mais uma desvantagem do que um ativo.

Em resumo, duas das maiores causas de codebases bagunçadas são prazos e programadores com conhecimento desatualizado ou incompleto. Infelizmente, a responsabilidade por ambas as questões pode recair strongmente sobre o chefe ou o CTO, que deve garantir que os prazos sejam realistas e que os funcionários estejam atualizados em seus conhecimentos e habilidades. Se o chefe não sabe nada sobre boas práticas de programação, o melhor que você pode fazer é tentar sugerir mudanças e esperar que elas 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.

Algumas das más práticas de programação resultam de ter que trabalhar 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 simplesmente copiar o que funciona enquanto também tenta integrar melhores práticas de programação, se você puder fazer isso sem quebrar nada.

Acho importante não apenas dizer o certo do errado, mas conhecer razões por trás de todo e qualquer erro. Quando você sabe as razões, você pode prever as consequências. Por que usar este 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 você pode pesar os prós e contras e tomar uma decisão. Isso também ajudará você a discutir sua posição a cada vez. O SOLID e o OOP também podem reduzir a manutenção se usados bem.

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

Além disso, como esse é seu primeiro trabalho, é provável que esses programadores não sejam muito habilidosos. Mas, novamente, eles provavelmente estão confiando em tarefas não muito difíceis, que podem ser feitas sem muita habilidade e com salários mais baixos por parte de programadores menos qualificados e mais baratos. É 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 irá ajudá-lo. Talvez em um local de trabalho diferente, talvez em algumas ocasiões. Você tem tempo à sua frente para ir mais longe.