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

Muitos estudantes, quando se formam e conseguem seu primeiro emprego, sentem que realmente não sabem programar, mesmo que tenham sido bons programadores na faculdade.

Quais são algumas das diferenças entre programar em um ambiente acadêmico e programar no 'mundo real'?

Em um programa tradicional de ciência da computação, você aprende apenas programação. Mas o mundo real não quer pessoas que são apenas programadores. O mundo real quer engenheiros de software reais. Sei que muitas descrições de cargos não parecem expressar essa distinção, o que apenas confunde o assunto. No mundo real, você precisa ser capaz de:

• Reúna e analise os requisitos quando eles não forem fornecidos diretamente a você
• Projete e analise a arquitetura com possibilidades quase infinitas
• Crie planos de teste e atue neles para avaliar e melhorar a qualidade de um sistema
• Trabalhe em colaboração com uma equipe de pessoas com diferentes formações e níveis de experiência
• Estime e planeje o trabalho, mesmo que você não saiba exatamente o que construir
• Comunique-se efetivamente com as partes interessadas que têm necessidades diferentes que não necessariamente se alinham
• Negocie cronograma, orçamento, qualidade e recursos sem decepcionar as partes interessadas

Ah, sim, e você também precisa escrever código, embora isso leve, em média, apenas 40 - 60% do tempo de um engenheiro de software.

Portanto, não é que os graduandos recém-formados em ciência da computação não saibam como programar (muitos são, na verdade, muito bons programadores). É que muitos deles não sabem fazer mais nada.

Na Universidade...

Seu professor lhe dá:

• Um problema isolado e bem definido, 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 às quais você foi apresentado 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 é embaçado, 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 utilizável na base de código de 10 anos da sua equipe, talvez exista algum projeto de código aberto, ou talvez uma biblioteca comercial, ou talvez você precise escrevê-lo por conta própria.
• Para determinar se a iteração atual do seu software é uma melhoria (porque você está quase nunca realmente feito com um projeto de software), você precisa fazer testes de regressão e testes de usabilidade, o último dos quais geralmente significa que o embaçada, complexa, contraditória , os requisitos incorporados ao contexto mudam mais uma vez.

Conclusão

Programar na escola e programar no mundo real são inerentemente diferentes ao ponto em que há realmente pouca sobreposição. O CS o preparará 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 se concentra principalmente na "ciência da programação", estudando, assim, o modo de tornar eficientes algoritmos específicos ou o desenvolvimento de linguagens personalizadas para tornar certos paradigmas mais expressivos. A indústria está focada principalmente na produção de itens que precisam ser vendidos. Ele precisa 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 de "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 assim como "incapaz de programar". Mas, de fato, ele tem todos os recursos para aprender o que está perdendo. Algo que - sem estudos acadêmicos adequados (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 brinquedo em escala. Isso é bom para o ensino. Como professor, você está tentando transmitir idéias com mais eficiência. A desvantagem é que a programação realista é tão qualitativamente diferente, que é difícil preencher a lacuna.

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

Outra área de diferença é a manutenção. Isso abrange tudo, desde o estilo até o design da linguagem específica do domínio. Você não pode fazer isso com eficiência, a menos que saiba realmente 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 uma vez que "a ciência da computação não é mais sobre computadores do que a astronomia é sobre telescópios". Uma pessoa que estuda ciência da computação está aprendendo acima de tudo a se tornar um cientista, e não um programador. Como programador, ele permanecerá amador, e a transição para um programador profissional é, portanto, 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 principalmente desenvolvi software "do zero", o que significava que, na maioria das vezes, o maior programa que encontrei era o maior que escrevi. Isso enfatiza a capacidade necessária para lidar com a complexidade que surge de diferentes partes do software que interagem juntas. Se eu estivesse ciente do esforço necessário para compreender com complexidade, poderia ter optado por não fazer parte do setor.

Leitura versus escrita : Outro efeito colateral do tamanho do problema é que, muitas vezes, no "mundo real", somos expostos a trabalhos que foram escritos por outras pessoas, seja para fins de manutenção (não fiz manutenção na academia em nenhum lugar), extensão ou simplesmente divisão de trabalho. Portanto, ler o código se torna 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 regredir ao treinamento profissional. Os médicos precisam enfrentar um cadáver em algum momento para ver se foram "feitos para ele" (ouvi histórias de pessoas que abandonaram o curso após essa experiência). Se eu tivesse visto, nos meus vinte e poucos anos, um projeto LOC de 20K composto por 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 é em relação à robustez. Quase todo mundo já experimentou o paradoxo "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 nas condições cotidianas.

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

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

Não tenho experiência pessoal em programação de treinamento na escola - eu era formado em inglês. Pergunte-me sobre Keats e Byron! - mas recebi várias graduações novas e as criei e as mentorei no mundo do desenvolvimento profissional de software. Então eu posso falar dessa perspectiva.

Minha experiência é que realmente tudo o que eles obtiveram da escola era um interesse em programação. Suas habilidades variaram de zero a insignificante. Sua capacidade de se autodirecionar era inexistente, mesmo nos mais qualificados. O pensamento deles não era apenas em pequena escala; eles realmente pensaram em miniatura. Um sistema que compreende mais de duas dúzias de linhas de código as fez cair completamente em pedaços.

Mas você sabe o que? Eles adquiriram um interesse , e isso é um grande negócio. Um interesse é suficiente . Eu posso trabalhar com alguém que esteja interessado. Eu posso transformá-los em um desenvolvedor, desde que eles venham a mim com interesse em ser um. Inferno, foi tudo o que 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 realmente não causam problemas, pois a maioria dos projetos nunca é usada em aplicativos do mundo real.

PLUSes

• Temos tempo suficiente para pesquisar.
• Afastar-se dos objetivos iniciais não causa muitos problemas.

Na indústria,

• Trabalhamos em projetos que serão realmente utilizados por empresas.
• Trabalhamos sob pressão de mudanças constantes nos requisitos dos clientes.
• Os prazos raramente são flexíveis, pois isso pode levar a enormes perdas financeiras para a empresa de software e para os clientes.

Veja isso:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

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

No mundo real, você deve ter o mínimo de código original possível. Muito código é desenvolvido por equipes. É melhor usar rotinas de biblioteca do que codificá-lo 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 esperado originalmente. O escopo do projeto geralmente é bastante amplo e tende a aumentar significativamente se não for gerenciado.

Na realidade,

é 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 essa: na programação do mundo real - você precisa saber mais do que programar e deve se adaptar rapidamente.

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

Michael apenas tocou a ponta do iceberg ao declarar tarefas relacionadas à programação, que eu classificaria como fáceis (se você vale a pena receber uma quantia em dinheiro).

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

• Leis vigentes (por exemplo, confidencialidade do cliente para fins médicos)
• Conhecimento do assunto (por exemplo, sistema de imposto sobre faturamento, inventário, gerenciamento de recursos, esquemas médicos, padrões do setor)
• Requisitos do cliente ausentes ou inexistentes ou diferentes dos padrões da indústria / leis aplicáveis

Se você comparar um projeto de programação de pesquisa em nível de doutorado versus um projeto do mundo real, as chances são de que 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 humanos)

É um jogo de bola diferente quando alguém faz as regras :)

Se você observar as disciplinas estudadas em TI na academia, encontrará cerca de metade do tempo desperdiçado em matemática, ciências, eletivas etc. e a outra metade em disciplinas acadêmicas, como: Design de compiladores, Teoria de algoritmos, Arquitetura de computadores, Otimização, sistemas operacionais, eletrônica digital e alguns outros cursos relacionados à indústria, como programação C e programação Web.

A maioria dos assuntos mencionados acima é interessante, mas também não fornece diretamente uma sólida experiência no que é exigido no dia-a-dia da TI.

Aceite os requisitos de programação da Microsoft (ou seja, á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- Script Java

7- Estrutura 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

11 Conceitos de comércio eletrônico (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 1 curso em alguns, no máximo) durante a faculdade / universidade.

Não se pode culpar totalmente as instituições, pois existem muitas pilhas de tecnologia e elas continuam mudando.

A maioria dos itens acima da Microsoft não ajudará quem deseja desenvolver aplicativos em Java.

O verdadeiro problema é que nem uma das pilhas de tecnologia necessárias para as empresas hoje é totalmente coberta.

O exposto acima aborda a questão da adequação dos graduados a trabalhos de negócios, como a programação no ambiente de negócios. As necessidades dos laboratórios de pesquisa etc. não são cobertas por esta resposta. Outras áreas também exigem mais habilidades do que as anteriores, como desenvolvimento de jogos, desenvolvimento incorporado, desenvolvimento de sistemas em tempo real etc.

Escala e foco
Das 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 durante o semestre por um ou dois programadores- tipicamente tudo o que você escreve será um código descartável que é descartado após o termo. No mundo real, você pode estar trabalhando em um aplicativo que uma equipe maior levou meses, se não anos, para se desenvolver completamente. Você gasta muito mais tempo depurando o código de outras pessoas e tentando entender a infra-estrutura de uma base de código, tentando não quebrar as partes existentes para adicionar algum requisito novo ou modificado.

Requisitos, integração, clientes
Além disso, existem aspectos no desenvolvimento de código, como análise de requisitos, teste 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á foram estabelecidos para você pelo instrutor e não são decididos em colaboração nas reuniões. Você não costuma "vender o cliente" em uma abordagem específica que não é exatamente o que eles queriam, mas, diferentemente 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 idéia bastante concreta do que deseja. 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 e 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 algumas tarefas de casa ou projetos de longo prazo. Depois que a tarefa é concluída, o código é descartado e nunca mais é visto.

Em um ambiente profissional, a maioria dos softwares é escrita com o uso a longo prazo; o software deve ser usado por pelo menos alguns anos e precisa ser construído para ser facilmente mantido e atualizado ao longo do tempo.

Relacionado a isso é o trabalho de manutenção. A maioria do trabalho 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.