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

50

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'?

rdasxy
fonte
4
Eu diria que na academia você aprende em profundidade: aprende conceitos, faz perguntas a si mesmo, aprimora o pensamento abstrato. Na indústria, você aprende detalhadamente: aprende a usar muitas tecnologias diferentes sem fazer muitas perguntas, e precisa fazer as coisas. Através da experiência no setor, você também aprende a gerenciar projetos grandes e complexos: essa é uma questão muito prática que você não pode aprender na universidade por falta de tempo.
Giorgio
9
Esta pergunta é sobre acadêmicos no nível de doutorado, ou após a graduação, ou apenas um cenário geral de "sala de aula versus mundo real"?
Bob
@Prumo. Isso foi mais sobre a academia geral. Sala de aula / pesquisa / leituras / tarefas direcionadas vs. programação "mundo real" na indústria.
rdasxy
Está bem. Isso não ficou muito claro, porque existe uma "programação acadêmica" feita por pessoas que querem dizer, ajudar os biólogos a descobrir simulações celulares.
Bob

Respostas:

72

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.

Michael
fonte
18
Oh yeah, and you also have to be able to write code too, but that's, on average, only 40 - 60% of a software engineer's time.- Ou até 0-20% em lojas corporativas muito ruins e muito grandes.
Ritch Melton
11
+1 para uma resposta muito boa e +1 (deve ser mais) para Ritch. Se o engenheiro está gastando mais de 20% do ciclo de vida de um projeto em codificação, algo está muito, muito errado. Design de 50%, teste de 30%,% 20 para o resto ... tudo o resto, incluindo a codificação, parece certo. Com o design adequado, a codificação deve ser trivial. Sem ele, o que as pessoas chamam de "codificação" é realmente reescritas infinitas, tentando cortar juntos um projeto de algum tipo como eles vão junto </ discurso>
MAWG
36

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.

back2dos
fonte
11
Isso é basicamente o que eu ia responder. Na escola, você conhece o problema e a solução. No "mundo real", você raramente conhece a solução e muitas vezes nem conhece o problema real.
Bob
20

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.

Emilio Garavaglia
fonte
10

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.

Mike Dunlavey
fonte
11
Eu me pergunto como essas coisas poderiam ser ensinadas, uma vez que exigem muito tempo e experiência no campo para serem adquiridas. Eu estava participando de um curso de engenharia de software no qual equipes de 10 alunos cada tiveram que desenvolver um pequeno produto de software em poucos meses (dois semestres, de outubro a abril). Isso lhes permitiu ter uma idéia sobre programação, planejamento, priorização de requisitos e tarefas, comunicação e assim por diante. Mas, é claro, isso é pouco comparado ao que eles enfrentarão no mundo real. Mas você não pode passar 4 anos estudando apenas isso.
Giorgio
@Giorgio: Para desempenho, eu tenho uma base de código preexistente (não muito grande) que mostro como otimizar uma série de iterações, obtendo grandes fatores de aceleração. É uma habilidade fácil de ensinar. Para DSLs e manutenção, também tenho alguns exemplos favoritos que podem ser usados ​​para o ensino. Ambos poderiam facilmente caber em um curso semestral, com espaço de sobra. Então eu acho que poderia ser feito.
Mike Dunlavey
11
Ok, entendo: use exemplos grandes do mundo real e permita que os alunos trabalhem neles. Muito boa ideia.
Giorgio
@Giorgio: eu era professor há 30 anos, então ainda me lembro de como fazê-lo. Também coloquei essas idéias em um livro que vendeu mal, o que significa apenas que tive tempo para pensar e explicar como tudo se encaixa.
Mike Dunlavey
Não tenho tanta experiência, fui assistente de ensino por alguns anos durante meu doutorado. Agora trabalho em uma empresa. Em relação à programação na Universidade, IMHO a verdade está em algum lugar no meio: existe algum ensino muito útil na Universidade, mas é difícil cobrir todas as questões importantes que um engenheiro de software enfrentará ao longo de sua carreira. Com algum esforço, você pode realmente ensinar algumas coisas do mundo real, como indicou. Nem todos os professores universitários estão dispostos a fazê-lo, é claro.
Giorgio
8

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.

thiton
fonte
8

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.

Dimitrios Mistriotis
fonte
Para estender sua metáfora e a partir de minha própria experiência em medicina: os médicos aprendem conceitos gerais na faculdade de medicina, mas todos nós aprendemos os detalhes e os atalhos do mundo real no treinamento no trabalho como estagiários e residentes.
Hovercraft Cheio De Enguias
2
Este! Na primeira vez em que você mergulha em uma base de código de 1 milhão de LOC, você percebe que isso não será nada parecido com tudo que você fez na universidade. Fica claro rapidamente que você nunca compreenderá a totalidade dessa base de código, e o que quer que você compreenda deve vir da leitura e compreensão do código de outras pessoas, em vez de arquitetar e escrever o seu próprio.
Roman Starkov 02/12/2013
4

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.

Dave Nay
fonte
3

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.

Dan Ray
fonte
2

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

SHOUBHIK BOSE
fonte
Vou ter que discordar sobre a parte "realmente ser usada". No início dos anos 90, passei 5 anos em 3 empresas diferentes, grandes, pequenas e médias, e nada que escrevi entrou em produção. Eu não acho que isso seja incomum em uma experiência.
precisa
2

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.

BillThor
fonte
1

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 :)

Schalk
fonte
0

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.

NoChance
fonte
12
Você tem 15 itens na sua lista. Acho que poderia acrescentar outros 30. Não é tarefa da academia ensinar a você todas essas coisas, mas, sim, ensiná-lo a encontrar seu caminho através de todas essas coisas. E também, ter conhecimento de que ainda será utilizável quando todas as tecnologias atuais estarão obsoletos (em 10 anos a partir de agora?) Isso é o que toda a teoria é boa para e não um desperdício de tempo !
Giorgio
2
@Giorgio, obrigado pelo seu comentário, o seu ponto é válido. Afirmei explicitamente que "não se pode culpar totalmente as instituições". Embora a pergunta original não seja sobre a natureza da educação acadêmica, minha visão pessoal é de que existe uma enorme lacuna entre o que os acadêmicos ensinam e o que os negócios esperam. A conta para preencher a lacuna costumava ser paga pelas empresas em um oneroso treinamento no trabalho. Com a grande competição e os tempos difíceis pelas quais todas as economias estão passando, pergunto-me quem pagará o preço por preencher essa lacuna hoje?
NoChance
@Emmad Kareem: Sim, existe uma grande lacuna, eu concordo. Muitas vezes, os professores universitários não têm idéia do que está acontecendo no "mundo real", porque estão focados na pesquisa abstrata. No entanto, são essas habilidades de pensamento abstrato que agora me permitem aprender um novo idioma dentro de semanas (aprendendo Scala agora). Também entendo que talvez para você a questão do dinheiro seja sentida com mais força. Eu cresci na Itália e quando estudei taxas universitárias, cerca de 200 dólares por ano (além disso, tivemos que comprar os livros). Eu acho que isso é muito pouco comparado ao que você paga nos EUA.
Giorgio
3
Da mesma forma, se você estivesse estudando engenharia e aprendendo a construir um carro, ninguém lhe ensinaria a dirigir um carro específico: isso é apenas algo que eles esperam que você saiba ou aprenda sozinho.
Giorgio
11
Desperdiçado? Se você possui os diplomas que afirma ter, deve conhecer melhor. Mesmo se você não estiver sentado lá programando matemática avançada, as lições aprendidas ao estudá-la se traduzem diretamente em "ver" uma solução elegante e limpa.
Rig
0

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.

Jessica Brown
fonte
0

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.

Ken Liu
fonte