Diferenças entre programação na escola versus programação na indústria? [fechadas]

Na universidade ...

Seu professor lhe dá:

• Um problema bem definido e isolado, cuja solução pode ser fornecida dentro de um período de tempo curto e bem definido (e será descartado posteriormente)
• Um conjunto bem definido de ferramentas que você conheceu antes da atribuição
• Uma medida bem definida para a qualidade de sua solução, com a qual você pode determinar facilmente se sua solução é boa o suficiente ou não

No "mundo real" ...

• O problema é borrado, complexo e incorporado no contexto. É um conjunto de requisitos contraditórios que mudam com o tempo e sua solução deve ser flexível e robusta o suficiente para você reagir a essas mudanças em um tempo aceitável.
• As ferramentas devem ser escolhidas por você. Talvez já exista algo útil na base de código de 10 anos da sua equipe, talvez haja algum projeto de código aberto, ou talvez uma biblioteca comercial ou talvez você tenha que escrevê-lo por conta própria.
• Para determinar se a iteração atual do seu software é uma melhoria (porque você quase nunca é realmente feito com um projeto de software), você precisa fazer testes de regressão e teste de usabilidade, o último o que geralmente significa que os requisitos embaçados, complexos, contraditórios e incorporados ao contexto mudam mais uma vez.

Conclusão

A programação na escola e a programação no mundo real são tão inerentemente diferentes ao ponto em que há realmente muito pouca sobreposição. CS irá prepará-lo para o desenvolvimento de software do "mundo real", como o treinamento de atletismo prepararia um exército para a batalha.

Eles enfrentam um aspecto diferente do problema:

A Academia está focada principalmente na "ciência da programação", estudando assim a maneira de tornar eficiente o algoritmo particular ou o desenvolvimento de linguagens adaptadas para tornar certos paradigmas mais expressivos. A indústria está focada principalmente em produzir coisas que precisam ser vendidas. Tem que confiar em "ferramentas" que não são apenas as linguagens e os algoritmos, mas também as bibliotecas, os frameworks etc.

Essa diferença em "foco" é o que torna um mestre acadêmico em C praticamente incapaz de escrever um aplicativo do Windows (já que a API do Windows não está no padrão C99!), sentindo-se "incapaz de programar". Mas, na verdade, ele tem todos os recursos para aprender o que está perdendo. Algo que - sem estudos acadêmicos apropriados (não necessariamente feitos na Academia) - é bastante difícil de encontrar.

Boas respostas. Deixe-me acrescentar, a programação acadêmica tende a ser quase como um brinquedo em escala. Isso é bom para ensinar. Como professor, você está tentando transmitir ideias de maneira mais eficiente. A desvantagem é que a programação realista é tão qualitativamente diferente, é difícil preencher a lacuna.

Uma área de diferença está na análise de desempenho. Eu escrevi muitos posts tentando mostrar isso. A análise de desempenho é apenas superficialmente sobre algoritmos e medidas. Para fazer isso de maneira realmente eficaz, você precisa abordá-lo como um processo de depuração.

Outra área de diferença é a manutenção. Isso abrange tudo, desde estilo a design de idioma específico do domínio. Você não pode fazer isso efetivamente, a menos que você realmente saiba o que está tentando minimizar.

Essas coisas não são ensinadas e fazem uma enorme diferença na produtividade.

No mundo acadêmico, a maioria das pessoas estuda ciência da computação ou cursos relacionados. Dijkstra observou certa vez que "a ciência da computação não é mais sobre computadores do que sobre astronomia". Uma pessoa que estuda ciência da computação está aprendendo, em primeiro lugar, a se tornar um cientista e não um programador. Como programador, ele permanecerá amador e a transição para um programador profissional é bastante difícil.

Atualização: como se alguém estivesse lendo minha mente: Expectativas de pós-graduação versus realidade . ..

Minha opinião, dois outros fatores:

Tamanho do problema : Na academia, eu tive que desenvolver software "do zero", o que significava que na maior parte do tempo, o maior programa que eu encontrei era o maior que eu escrevi. Isso não enfatiza a capacidade necessária para lidar e lidar com a complexidade que surge de diferentes partes do software interagindo juntas. Se eu estivesse ciente do esforço necessário para compreender com complexidade, eu poderia ter escolhido não estar na indústria.

Leitura VS Writing : Outro efeito colateral do tamanho do problema é que muitas vezes, no "mundo real", estamos expostos ao trabalho que foi escrito por outros, seja para fins de manutenção (eu não fiz manutenção na academia em qualquer lugar), extensão ou simplesmente divisão do trabalho. Portanto, o código de leitura torna-se muitas vezes mais importante do que escrevê-lo.

Uma proposta para melhorar a educação em programação : a academia deve nos expor mais a situações do mundo real sem recair no treinamento vocacional. Os médicos têm que enfrentar um cadáver em algum momento para ver se eles são "feitos para isso" (eu ouvi histórias de pessoas deixando o curso depois dessa experiência). Se eu tivesse visto em meus vinte e poucos anos um projeto de 20K LOC composto de diferentes estilos de programação, que eu tinha que entender em um dia e corrigir um bug em três, eu poderia ter considerado outras opções de carreira - embora provavelmente não.

A maior diferença que encontrei entre a programação acadêmica e a industrial é a robustez. A maioria das pessoas experimentou o paradoxo "isso funciona para mim" em sua carreira, e essa é uma extensão dessa condição. Na academia, o foco está nos algoritmos e funções e pouca consideração é dada à usabilidade e estabilidade do software em condições cotidianas.

Por exemplo, no meu escritório, temos um engenheiro que aceita o software e é mestre em causar falhas nas condições de canto. Ele clicará em um botão o mais rápido que puder até que algo falhe ... se uma operação demorar muito, ele começará a clicar aleatoriamente ao redor da tela (por frustração? IDK ...)

Mudar nossas filosofias de programação para tornar as coisas "à prova de Steve" melhorou em geral a estabilidade de nosso aplicativo.

Eu não tenho experiência pessoal com treinamento em programação na escola - eu era um estudante de inglês. Pergunte-me sobre Keats e Byron! - mas recebi vários novos graduados e os criei como mentores no mundo do desenvolvimento profissional de software. Então eu posso falar dessa perspectiva.

Minha experiência é que realmente tudo que eles obtiveram de sua escola foi um interesse em programação. Suas habilidades variaram de zero a insignificantes. Sua capacidade de autodirecionar era inexistente mesmo nos mais habilidosos deles. Seu pensamento não era apenas de pequena escala; eles realmente pensaram em miniatura. Um sistema com mais de uma dúzia de linhas de código fez com que elas caíssem completamente em pedaços.

Mas você sabe o que? Eles adquiriram um interesse , e isso é um grande negócio. Um interesse é abundância . Eu posso trabalhar com alguém que esteja interessado. Eu posso transformá-los em um desenvolvedor, desde que eles venham até mim com interesse em ser um. Inferno, isso é tudo que eu comecei. Isso e uma apreciação para os romancistas americanos pós-modernos.

Na academia,

DRAWBACKS

• Temos prazos que são principalmente para marcar pontos.
• Os bugs não causam problemas, já que a maioria dos projetos nunca é usada em aplicativos do mundo real.

PLUSes

• Temos bastante tempo para pesquisas.
• O balanço dos objetivos iniciais não causa muitos problemas.

Na indústria,

• Trabalhamos em projetos que serão realmente usados por corporações.
• Trabalhamos sob estresse de requisitos sempre em mudança do cliente.
• Prazos são raramente flexíveis, pois isso pode levar a enormes perdas financeiras tanto para a empresa de Software quanto para os clientes.

Verifique isso:

link

A programação acadêmica é mais sobre codificar você mesmo. Isso é importante para aprender como funciona. Qualidade de código e controle de revisão não contam muito. Com exceções notáveis, o código não tem uma duração além da atribuição. O escopo dos projetos tende a ser bastante restrito, e é improvável que se infiltre.

No mundo real, você deve ter o menor código original possível. Muito código é desenvolvido pelas equipes. É melhor usar rotinas de biblioteca do que codificar você mesmo. A qualidade do código e o controle de revisão se tornam mais importantes. O código tende a ter uma vida útil muito além do que era originalmente esperado. O escopo do projeto é geralmente bastante amplo e tende a aumentar significativamente se não for gerenciado.

Na verdade,

é impossível distinguir completamente entre programação de nível acadêmico e programação do mundo real.

Eu diria que a maior diferença pode ser esta: na programação do mundo real - você precisa saber mais do que programar e deve ser capaz de se adaptar rapidamente.

Dependendo do setor em que você está trabalhando, você deve estar em conformidade com suas leis.

Em geral, você enfrentará pelo menos alguns desafios por assunto em um setor:

• Leis vigentes (ex. confidencialidade do cliente para médicos)
• Conhecimento do assunto (ex. sistema de faturamento-imposto, inventário, gerenciamento de recursos, esquemas médicos, padrões do setor)
• Requisitos do cliente inexistentes ou inexistentes ou diferentes dos padrões do setor / leis vigentes

Se você comparar um projeto de programação de nível de phd de pesquisa com um de mundo real, as chances são de que eles são muito semelhantes em dificuldade, conhecimento de nível de entrada e tal.

A única diferença real é que o projeto do mundo real

• tem um cliente
• tem orçamentos (tempo, dinheiro, recursos de pessoas)

É diferente quando alguém faz as regras:)

Se você olhar para os assuntos estudados em TI na academia, você encontrará metade do tempo perdido em matemática, ciências, disciplinas eletivas, etc. e a outra metade em assuntos acadêmicos, tais como: Design de compiladores, Teoria dos algoritmos, Arquitetura de Computadores, Otimização, Sistemas Operacionais, Eletrônica Digital e alguns outros cursos relacionados à indústria, como programação em C e Programação na Web.

A maioria dos assuntos mencionados acima é boa de se conhecer, mas não fornecerá diretamente um strong conhecimento sobre o que é necessário na TI do dia-a-dia.

Siga os requisitos do Microsoft Web Programming (isto é, áreas exigidas por alguém para ser um membro produtivo da equipe em uma organização):

1- C # .NET ou VB.NET

2- ASP.NET

3- HTML e CSS

4- SQL Server (ou outro banco de dados)

5- Programação e design de aplicativos OO

6- Java Script

7- framework MVC

8- Alguma exposição a ferramentas de controle de fonte

9- Alguma exposição a ferramentas de teste automatizadas

Ferramenta de rastreamento de 10 bugs

Conceitos do 11-E-Commerce (opcional)

12-ORM

13-Algumas habilidades de análise de negócios

14-Algumas habilidades de comunicação

15-Provavelmente, alguns fundamentos da computação em nuvem

Como você pode ver, a maioria dos requisitos acima raramente é focada (você pode obter um curso em alguns, no máximo) durante a faculdade / universidade.

A maioria dos itens acima da Microsoft não ajudará ninguém que queira desenvolver aplicativos em Java.

O verdadeiro problema é que nem uma das pilhas de tecnologia que são necessárias para os negócios hoje é sempre coberta por completo.

O texto acima aborda a questão da adequação dos formandos aos trabalhos de negócios, como programação em ambiente de negócios. As necessidades dos laboratórios de pesquisa, etc. não são cobertas por esta resposta. Além disso, outras áreas exigem mais habilidades do que as descritas acima, como desenvolvimento de jogos, desenvolvimento incorporado, desenvolvimento de sistemas em tempo real, etc.

Escala & Foco
De minhas experiências, em um ambiente acadêmico, geralmente a escala do aplicativo em que você está trabalhando é muito menor, algo que pode ser concluído em um dia ou semana, ou talvez até o semestre por um ou dois progamadores - tipicamente tudo você escreve será código descartável que é descartado após o termo. No mundo real, você pode se ver trabalhando em um aplicativo que uma equipe maior levou meses, senão anos, para desenvolver completamente. Você gasta muito mais tempo e depurando o código de outras pessoas e tentando entender a infra-estrutura de uma base de código, fazendo malabarismos para não quebrar as partes existentes para adicionar algum requisito novo ou modificado.

Requisitos, integração, clientes
Além disso, há aspectos no desenvolvimento de código, como análise de requisitos, testes de integração, etc., que tendem a ser menos representados em projetos acadêmicos. Por uma questão de classificação justa, normalmente os requisitos já estão estabelecidos para você pelo instrutor e não são decididos em colaboração nas reuniões. Você não tende a ter que "vender o cliente" em uma abordagem específica que não é exatamente o que eles queriam, mas ao contrário de seus desejos é realmente viável do ponto de vista técnico. Em um ambiente acadêmico, seu cliente (o aluno ou o instrutor) tende a ter uma ideia bastante concreta do que quer, no mundo real, você pode encontrar clientes que realmente não sabem o que querem e precisam escolher o cérebro para entender o que querem. deve ser construído.

Manutenção & Manutenção

No meio acadêmico (pelo menos no nível de graduação), o software é construído com objetivos de curto prazo em mente, geralmente para concluir algum trabalho de casa ou projeto a termo. Quando a tarefa estiver concluída, o código é descartado e nunca mais visto.

Em um cenário profissional, a maioria dos softwares é escrita com o uso de longo prazo em mente; O software destina-se a ser usado por pelo menos alguns anos e precisa ser construído para ser facilmente mantido e atualizado ao longo do tempo.

Relacionado com isso é o trabalho de manutenção. A maioria dos trabalhos de programação profissional envolve a atualização ou manutenção de software existente. Os chamados projetos de "campo verde" são a exceção, e não a norma.