Como você explicaria que a engenharia de software é mais especializada que outras áreas de engenharia? [fechadas]


9

Eu trabalho com alguém que insiste em que qualquer bom engenheiro de software possa se desenvolver em qualquer tecnologia de software, e a experiência em uma tecnologia específica não importa para criar um bom software. Sua analogia era que você não precisa ter conhecimento do produto que está sendo construído para saber como construir uma linha de montagem que fabrica o produto.

De certa forma, é um elogio ser visto com olhos de tal forma que "se você é bom, você é bom em tudo", mas de certa forma também banaliza a profissão, como em "Codemonkey, vá sling code". Sem experiência em certas estruturas de software, você pode ter problemas rapidamente, e isso é importante.

Eu tentei explicar isso, mas ele não comprou. Alguma opinião ou opinião diferente sobre isso para ajudar a explicar que minha experiência em uma coisa não se traduz em todas as coisas?


7
Se você está indo para o voto negativo, você poderia pelo menos comentar o porquê? Especialmente porque a sua entrada pode ajudar a reformular / reorientar a questão.
Spencer Kormos

11
primeiro, isso é um discurso retórico e não uma pergunta; segundo, um discurso retórico de suposição, isso precisa ser rejeitado e encerrado.

6
@JarrodRoberson Há uma pergunta legítima aqui, eu acho. Ele está pedindo uma boa explicação que pede uma explicação de por que alguns vêem a engenharia de software como mais ou menos especializada que outras áreas de engenharia.
Maple_shaft

7
@ SpencerK Sua pergunta é "algum cara aleatório fez uma analogia ruim, como eu respondo", e bem, isso não é realmente uma pergunta. Basta pedir evidências sólidas e / ou referências que apóiem ​​sua posição, você não é quem precisa provar a si mesmo aqui.
yannis

5
-1 porque eu discordo de sua premissa. A Engenharia de Software não é mais especializada do que outras áreas de engenharia. Ambos podem ser altamente especializados e generalizados. Um bom engenheiro eletromecânico pode não ser um bom engenheiro biomédico. Por outro lado, um bom eletricista pode trabalhar em casas e carros.
precisa saber é o seguinte

Respostas:


23

mas de certa forma também banaliza a profissão, como em "Codemonkey, vá sling code".

Eu argumentaria bem o oposto. Um bom engenheiro de software teria a capacidade de conceituar, arquitetar e projetar software de qualidade independente da tecnologia. O extremo oposto desse espectro é apenas o "codemonkey" do .NET ou Java ou PHP, que é bom para receber instruções ou especificações e utilizar a ferramenta para implementar o software.

Um engenheiro de software não precisa dominar todas as ferramentas, mas deve ter um bom entendimento de alto nível sobre o que a maioria delas é, o que elas trazem para a mesa e o que provavelmente será mais apropriado para o projeto em questão. . Eu esperaria que um macaco de código fosse apenas um mestre de sua experiência proclamada em uma ferramenta específica.

Eu não confiaria em um engenheiro da Ford que não sabe fazer o trabalho do mecânico.

Ainda assim, a engenharia de software é um desses campos em que, em muitos casos, devemos ser o engenheiro, o construtor e o mecânico, tudo ao mesmo tempo.


8
Eu também enfatizaria a importância de entender conceitos e princípios sobre linguagens e ferramentas.
Oded

+1 Uma das minhas irritações é a pessoa que diz "eu sou desenvolvedor de C # ...". E então apenas beba o kool-aid e aceite qualquer coisa da EM como evangelho. 10 anos de programação Eu aprendi mais de 11 linguagens de programação, e cada uma delas fez melhorias maciças em como eu programo nas outras linguagens. Aprenda engenharia de software! Não são plataformas que desaparecerão em 2 anos.
Timóteo Baldridge

+1 para referência do Ford Engineer. Eu nunca pensei sobre Engenheiros de Software x Programadores dessa maneira antes.
Dalin Seivewright

Um programador é um subconjunto de um engenheiro, e não o contrário.
Spencer Rathbun

11

Eu concordo até certo ponto com a pessoa com quem você trabalha. Um bom engenheiro de software lida com os princípios gerais de design e produção de software. As linguagens e estruturas reais são detalhes.

Isso não é trivializar a facilidade com que você pode pegar novas linguagens e estruturas. Sempre há uma curva de aprendizado associada a elas, mas o ponto é que é uma curva, não uma parede vertical para um bom engenheiro de software.

Um bom engenheiro de software tem uma ampla gama de experiência em várias ferramentas e tecnologias diferentes. Se não, como ele pode escolher a melhor ferramenta para o trabalho? Para expulsar o velho clichê, para um homem que sabe usar um martelo, todo problema parece um prego. Mesmo que você não seja um especialista em uma chave de fenda, vale a pena ter uma compreensão passageira deles, para que você possa reconhecer um parafuso como não apenas uma unha de aparência engraçada.


"Um bom engenheiro de software lida com os princípios gerais de design e produção de software". Produzir sistemas de controle incorporados e aplicativos da Web é quase exatamente o mesmo , certo?
Marcin

@ Marcin: Alguns dos princípios são, sim. O ponto que eu estava fazendo é que (por exemplo) projetar um sistema incorporado em C ou assembler emprega os mesmos tipos de princípios, mesmo que as ferramentas sejam diferentes.
JeremyP

Essas ferramentas não são tão diferentes e abordam domínios de problemas muito semelhantes. É por isso que isso é totalmente inútil.
Marcin

11
@ Marcin: obviamente você não programou em assembler ou não em C. Garanto-lhe que, apesar do mito comum, C não é assembler e a programação nessas ferramentas é tão diferente quanto (digamos) a programação em C e Ruby.
precisa saber é o seguinte

11
@ Marcin, claro, e o boliche é apenas uma questão de derrubar todos os pinos. Pedaço de bolo realmente. Embora a programação na Web e a programação incorporada possam compartilhar alguns princípios e práticas recomendadas de alto nível, o que realmente governa o trabalho diário são as restrições que governam a implementação dessas práticas. Embora você possa eventualmente treinar um programador da Web como engenheiro incorporado e vice-versa, eles não são fungíveis.
22812 Charles E. Grant

5

Versão TLDR: Outras disciplinas de engenharia precisam conhecer os materiais que estão usando (por exemplo, os arquitetos precisam saber quanta carga os materiais que estão usando em seu design podem suportar ). As linguagens e estruturas que usamos para engenharia de software têm certos limites e precisamos estar familiarizados com eles para projetar e desenvolver efetivamente contra eles.

Existem duas fases distintas no que fazemos. O primeiro é o design conceitual. Esse é o design do sistema de alto e baixo nível (por exemplo, usando UML). Projetos de alto nível podem teoricamente ser agnósticos de implementação (embora algumas vezes um projeto de alto nível precise levar em consideração especificações como plataforma de banco de dados, middleware de prateleira etc.). Projetos de baixo nível são um pouco mais complicados. Você pode projetar as especificidades da lógica de negócios sem colocar os detalhes da infraestrutura nelas e, novamente, elas podem teoricamente ser independentes de plataforma.

A segunda fase é a programação real. Enquanto alguns veem a programação como construção, outros (inclusive eu) argumentam que a codificação ainda é uma disciplina de design (no PPP , Bob Martin se refere a um artigo em que o autor apresenta um argumento muito bom para esse efeito, não o tenho com agora, mas atualizarei esta resposta com um link para esse artigo). A construção real acontece quando você pressiona compilar e, na verdade, é livre.

Assim como um arquiteto precisa levar em conta coisas como resistência à tração e à compressão dos materiais de construção que está usando, o engenheiro de software também precisa conhecer os recursos da plataforma em que está desenvolvendo ao escrever código. Eu argumentaria que um design de sistema de baixo nível não é muito eficaz se não levar em consideração as opções de plataforma também.


5

Como alguém que se formou em um programa de graduação em Engenharia de Software, posso dizer que seu colega de trabalho está parcialmente correto. Um bom engenheiro de software se concentra na aplicação de matemática, estatística, ciência da computação e experiência no domínio para construir um sistema. Os métodos que um engenheiro de software usa são tipicamente independentes da tecnologia e da linguagem - as ferramentas não importam tanto quanto os princípios subjacentes.

Dito isto, a analogia do seu colega de trabalho é falha. A compreensão dos problemas do domínio é essencial para qualquer disciplina de engenharia. Se você não entende completamente o problema que está tentando resolver e as pessoas que está tentando satisfazer, torna-se infinitamente mais difícil criar a melhor solução possível para os problemas deles.

Por fim, a engenharia de software (e qualquer disciplina de engenharia) trata da aplicação de vários conceitos para resolver um problema. Se você costuma usar as mesmas ferramentas, ficará mais experiente com essas ferramentas. Será mais fácil para você identificar os problemas que essas ferramentas podem resolver, os riscos ou armadilhas com o uso dessas ferramentas e depois usá-las para construir uma solução.


Os princípios subjacentes podem variar enormemente.
Marcin

11
@ Marcin Não, eles não. A ciência da computação não muda se as tecnologias mudarem. A matemática não muda. As estatísticas não mudam. Nem a análise de requisitos, o design do sistema, as práticas de gerenciamento de configuração, as estratégias de verificação e validação, os princípios da qualidade ...
Thomas Owens

Na verdade, "análise de requisitos, design do sistema, práticas de gerenciamento de configuração, estratégias de verificação e validação, princípios de qualidade" mudam entre os domínios problemáticos. Se você não reconhecer isso, é provável que faça um trabalho muito, muito ruim, trabalhando em um domínio que não conhece, porque é arrogante demais para perceber o que não sabe. Além disso, a matemática aplicável muda bastante, mas aposto que você imagina que também sabe tudo sobre matemática.
Marcin

@ Marcin Eu trabalhei em tudo, desde sistemas embarcados até aplicativos da web. Eles não mudam muito. As qualidades de um bom requisito não mudam com base no domínio. As ferramentas usadas para projetar um sistema não mudam. Como você mede e alcança sistemas de alta qualidade não muda.
Thomas Owens

11
Sim, você está certo, todo projeto de software no mundo é o mesmo e você descobriu como gerenciar cada projeto. Você provavelmente deve escrever um livro explicando o One True Way para escrever e gerenciar todo o software.
Marcin

4

Sua analogia era que você não precisa ter conhecimento do produto que está sendo construído para saber como construir uma linha de montagem que fabrica o produto.

Isso quase certamente está incorreto. Os engenheiros de produção especializados precisam entender bastante sobre os produtos sob seus cuidados.

De qualquer forma, uma analogia melhor é com os formandos dos cursos de engenharia mecânica: mesmo que todo mundo comece (tanto em mech quanto em software) com as mesmas habilidades, ninguém permanece "um engenheiro mecânico", mas é especialista nos tipos de coisas que eles constroem. Da mesma forma, o desenvolvimento de software também possui subcampos muito distintos.

Para retornar à analogia da linha de montagem, cada linha de montagem é diferente para cada produto, e diferentes tipos de desenvolvimento de software exigem metodologias diferentes - você não criaria seu software de segurança da mesma maneira que cria um jogo.


11
a construção de software no mesmo nível é a mesma, independentemente do produto de software. Apenas as chamamos de metodologias em vez de linhas de montagem , mas elas são conceitualmente a mesma coisa.

11
@JarrodRoberson Não. As linhas de montagem não são uniformes e as metodologias geralmente não são aplicáveis.
Marcin

2
Concordo com Marcin, você precisa ter conhecimento de um produto para montar uma linha de montagem para o produto. Você deve poder selecionar com precisão as ferramentas a serem usadas para obter o resultado final correto. No software, uma metodologia seria uma ferramenta ou tarefa específica. Se sua única tarefa é concluir uma tarefa específica, talvez você não precise do conhecimento do todo. Mas então você é um operador e não um engenheiro. Selecionar o conjunto correto de metodologias para formar a linha de montagem faz de você um engenheiro como qualquer outra engenharia. Não é mais especializado ou diferente.
RJay75

2

Há uma curva de aprendizado envolvida com diferentes especializações. Eu estou falando sobre diferenças entre programação Embedded / em tempo real, programação de aplicativos da Web, programação de sistemas / SO, programação de clientes espessos, desenvolvimento móvel, etc.

Alguém que é especialista em um tipo de programação pode não conseguir passar para outro imediatamente por causa de requisitos diferentes. Claro, um engenheiro de software tem o básico para fazer isso, mas leva tempo para se especializar em algo.


1

Concordo com a premissa que seu colega sugere, embora eu acrescentasse uma ressalva.

Um bom engenheiro de software será capaz de criar um bom software em qualquer tecnologia ..... depois de aprender um pouco sobre a nova tecnologia.

Pode haver algumas peculiaridades que não são óbvias a princípio, mas um bom engenheiro de software as aprenderá em breve.

Eu acho que o que ele realmente quer dizer é que, só porque um desenvolvedor tem 2 anos de experiência sólida em C #, não significa um engenheiro de software melhor com experiência em Java, que nunca fez C # antes não poderia aparecer, aprender C # e rapidamente torne-se um desenvolvedor de C # melhor que o primeiro.

Em outras palavras, você não deve necessariamente desconsiderar o cara Java por um emprego, APENAS porque ele "fez o tempo" em C #.


Eu acho que isso é um dado, mas é realmente sobre ROI. Eu não contrataria um engenheiro com experiência primária em Java, se eu quiser obter um projeto C ++ em seis meses. No entanto, se você tiver um projeto Swing que precisa ser lançado em 6 meses, um engenheiro primário do lado do servidor ainda poderá se qualificar.
Spencer Kormos

@SpencerK concorda totalmente. Depende da rapidez com que você precisa do seu ROI. Se você tiver um período mais longo para esperar, o melhor engenheiro de software deve "vencer".
13/04

Além disso, menos duro se fosse você!
13/04

11
Não, eu não. Eu não voto negativo sem comentar o porquê. Eu tenho maneiras melhores que isso!
Spencer Kormos

1

Caso em questão: a estrutura de software que você considera essencial para ter experiência especializada provavelmente não existia 10 anos atrás ou sofreu uma transformação significativa, se existir. A própria natureza de nossa profissão torna impossível se especializar durante toda a carreira. Dependendo dos seus respectivos níveis de habilidade, sua especialização oferece uma vantagem entre 1 e 6 meses em relação a alguém que nunca usou sua estrutura específica. Depois disso, você está no mesmo nível.


2
Realmente? Suponho que você esperaria que um engenheiro de segurança iniciasse a codificação de jogos em 6 meses e seria indistinguível de um especialista experiente.
Marcin

Eu concordo com Marcin, não é apenas o conhecimento de uma linguagem ou plataforma de programação. Trabalhei em duas áreas diferentes e passei alguns anos em cada uma delas: leva um tempo até que você esteja familiarizado o suficiente para ser realmente profissional e produtivo em uma área. É claro que ser um especialista em software experiente acelera as coisas, mas eu consideraria 2, 3 anos em vez de 6 meses.
Giorgio

1

Eu trabalho para uma empresa de helicópteros e os engenheiros de aviação aqui são especializados pelo tipo de aeronave com a qual podem trabalhar. Eles precisam ser "classificados como". Tecnicamente, eles poderiam trabalhar em qualquer coisa, de um Robinson R22 a um Jumbo Jet, mas não sem o treinamento de conversão.

Eu acho que isso é bastante semelhante à engenharia de software, exceto que o "treinamento de conversão" é mais informal para os engenheiros de software.


1

Ao conversar com um pintor, você diria a ele que ele não teria problemas com a escultura?

Aprender um novo idioma ou especificidades para um novo domínio é semelhante a um artista que lida principalmente com lápis e tinta, aprendendo a pintar (ou vice-versa). É sobre isso que a maioria das outras respostas está falando, como seu amigo está parcialmente correto - muitos dos mesmos conceitos se aplicam.

Mas ensinar um pintor a esculpir um objeto 3D ou escrever um romance (Ambas as formas de expressão artística) é um animal completamente diferente. Esse é o ponto de vista de onde você vem.

O software baseado na Web requer um tipo de pensamento totalmente diferente do software de desktop. Ambos são completamente diferentes quando aplicados a jogos versus um ambiente de trabalho. Eu suspeito que trabalhar em um sistema operacional ou em sistemas integrados também exija pensar de uma maneira diferente (mas não tenho experiência com eles). E não tenho dúvida de que existem outros domínios que também exigem uma maneira diferente de pensar.

Resumo e exemplos:

"Arte" inclui esculturas, romances, quadrinhos e pinturas. As sobreposições de habilidades incluem:

  • Forma corporal e teoria das cores: esculturas, quadrinhos e pinturas
  • Comunicação textual: romances e quadrinhos

... E assim por diante. Mas, como mencionado acima, é improvável que um artista de quadrinhos faça bem em seu primeiro romance. Eles precisam pensar de maneira diferente.

Da mesma forma, há sobreposição em diferentes campos da engenharia de programação / software, mas a maioria deles é muito distinta para ser capaz de entrar. Por exemplo:

  • Algoritmos: sistemas operacionais / jogos integrados, jogos e outros locais que você geralmente precisa otimizar para velocidade ou memória. Raramente um grande negócio em desenvolvimento web
  • Design: em qualquer lugar do desenvolvimento da Web, mas não muito importante em sistemas integrados sem uma interface do usuário.
  • Software cliente / servidor: a mentalidade "não confie no cliente", que não existe necessariamente em alguns domínios (jogos para um jogador e outro software de desktop independente, que, admito, é mais raro atualmente).

Sempre argumentei que a programação e o design de software são tanto uma arte quanto ciência ou engenharia. Eu acho que este é outro exemplo de como eles são semelhantes.
Izkata

Ah, e antes que alguém me morda por isso, por "Algoritmos", estou falando dos de alto nível CS-y. Montes de Fibonacci e Timsort são dois que vêm à mente. (Eu quase nunca funcionam nesse nível de complexidade algorítmica, então eu sei pouco sobre o assunto em tudo)
Izkata

0

Todos os trabalhadores da construção de estradas podem usar todos os equipamentos e máquinas no local de trabalho? A resposta é não. Existem peças de máquinas que eles conhecem e provavelmente estão familiarizadas com as outras. O mesmo deve ser verdadeiro para os engenheiros de software, há um número de idiomas e estruturas que você conhece porque trabalha com eles todos os dias, mas não se deve esperar que saibam as operações exatas de outras pessoas sem algum treinamento. É como pegar o trabalhador da britadeira e atribuir a ele a tarefa de dirigir o misturador de cimento.

Linguagens e estruturas de programação são apenas ferramentas no cinto de ferramentas de engenheiros de software. Existem algumas ferramentas que você conhecerá melhor do que outras por causa da experiência. Por fim, a melhor ferramenta é entender os principais conceitos e princípios da computação. Escolher idiomas e estruturas é apenas selecionar qual chave de fenda usar em qual parafuso.


2
Essa é uma péssima analogia, eles estão falando de engenharia, não de trabalhadores da construção, embora misturem as metáforas da questão. Para esse fim, espera-se que todos os engenheiros civis que construam estradas sejam capazes de construir qualquer tipo de estrada! Assim como qualquer motorista de caminhão basculante que transporta o asfalto para o referido canteiro de obras deve poder dirigir qualquer tipo de caminhão basculante.

11
@JarrodRoberson Concordo que é uma analogia ruim, mas não tenho certeza de que sua afirmação de engenheiro civil seja melhor. Certamente, qualquer engenheiro civil deve poder ler os planos de qualquer estrada. Mas se você está construindo uma pista ou uma estrada de gelo, quer contratar alguém que passou anos construindo rodovias ou quer alguém com experiência específica em pistas ou estradas de gelo?
Caleb

0

Esse tipo de coisa acontece muito onde eu trabalho.

Eu gosto de comparar com a profissão do tio da minha esposa - um mecânico de automóveis.

Ele é especialista em Mercedes, ele pode aplicar seu conhecimento a outras marcas de carros, e ele faz - alguns deles bastante raros, mas isso não significa que ele possa reparar imediatamente o X, porque você diz que está fazendo barulho.

Eu programo em alguns idiomas, mas isso não significa que eu sei por que o Safari no seu MacBook recarrega as páginas toda vez que você muda de guia (chamada estranha de hoje). Vou tentar descobrir o porquê, mas não vou saber de nada, porque o campo da computação é ENORME .

Nos dois casos, depois de passar algum tempo analisando nossos respectivos campos, provavelmente poderíamos encontrar a resposta, mas não nos dez segundos que as pessoas pensam porque "mas você trabalha com carros" ou "mas você trabalha com computadores".

As pessoas dizem essas coisas ao médico local (como "Estou com dor de cabeça, que doença tenho?") - aposto que sim, porque a maioria das pessoas realmente não entende que existe mais em qualquer profissão do que as expectativas imediatas. da referida profissão.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.