Comparando engenharia de software com engenharia civil, fiquei surpreso observar uma maneira diferente de pensar: qualquer engenheiro civil sabe que Se você quer construir uma pequena cabana no jardim, você pode simplesmente pegar o materiais e ir construí-lo enquanto se você quiser construir uma casa de 10 andares (ou, por exemplo, algo como this ) você precisa fazer bastante algumas matemáticas para ter certeza de que não vai desmoronar.
Em contraste, falando com alguns programadores ou lendo blogs ou fóruns Muitas vezes encontro uma opinião generalizada que pode ser formulada mais ou menos da seguinte forma: teoria e métodos formais são para matemáticos / cientistas enquanto a programação é mais sobre como fazer as coisas .
O que normalmente está implícito aqui é que a programação é algo muito prático e que, embora métodos formais, matemática, teoria dos algoritmos, linguagens de programação limpas / coerentes, etc, podem ser tópicos interessantes, eles geralmente não são necessários se tudo que se quer é fazer as coisas .
De acordo com a minha experiência, eu diria que, embora você não precise de muito teoria de montar um roteiro de 100 linhas (a cabana), a fim de desenvolver uma aplicação complexa (o prédio de 10 andares) você precisa de um design, métodos bem definidos, uma boa linguagem de programação, bom texto livros onde você pode procurar algoritmos, etc.
Então IMO (a quantidade certa de) teoria é uma das ferramentas para fazer as coisas .
Minha pergunta é por que alguns programadores pensam que há um contraste entre teoria (métodos formais) e prática (fazer as coisas acontecerem)?
A engenharia de software (software de construção) é percebida por muitos como fácil em comparação com, digamos, engenharia civil (construção de casas)?
Ou essas duas disciplinas são realmente diferentes (além da missão crítica? software, a falha de software é muito mais aceitável do que a falha de construção)?
EDITAR
Obrigado por todas as respostas e pelo interesse neste tópico. Eu gentilmente peço que não publique novas respostas se você não tiver para adicionar alguma observação que ainda não tenha sido coberta pelas respostas existentes. Então, leia atentamente todas as respostas antes de postar novas.
Eu tento resumir o que eu entendi das respostas até agora.
Como consequência, é muito mais difícil determinar qual é a quantidade certa de design / teoria é apropriado em engenharia de software (muito pouco - > código bagunçado, muito - > eu nunca consigo terminar) porque não há regra geral e apenas (muita) experiência pode ajudar.
Então, se eu interpretar suas respostas corretamente, essa incerteza sobre quanto teoria é realmente necessária contribui para os sentimentos mistos de amor / ódio alguns programadores têm para a teoria.
Muitos programadores tiveram experiências ruins com a teoria fugitiva tornando-se um impedimento ativo para fazer as coisas (por exemplo, "UML executável", processos de desenvolvimento super burocráticos). Por outro lado, hacks e patches sujos podem te levar muito longe, embora lentamente no final. E como você observa em seu último parágrafo: as falhas geralmente não são tão finais e, portanto, não são tão problemáticas.
Engenharia de software e engenharia civil têm pouco em comum. Os esforços de engenharia civil são limitados pelas propriedades físicas de seus materiais e do meio ambiente. Os engenheiros civis gastam muito tempo aprendendo sobre as propriedades do solo e as características do material. O desenvolvimento de software é fisicamente limitado apenas pela velocidade dos processadores e pelo armazenamento disponível. Ambos são fáceis de entender e não gastamos muito tempo estudando-os. A principal limitação para o desenvolvimento de software é o intelecto humano. E não há dois desenvolvedores iguais. Este código é sustentável? Por quem? Uma implementação de três linhas de quicksort em Haskell pode ser obviamente correta para alguns, mas incompreensível para outros. Uma equipe de dois pode preencher um requerimento em um mês, enquanto outra equipe de dez se esforça para entregar em um ano.
O desenvolvimento de software é todo o design, os artefatos sendo projetados são ordens de magnitude mais complexas do que qualquer artigo fabricado e cada um é único.
Como um engenheiro mecânico mais ou menos honesto (p.ex. civil) virou programador, depois CS (AI) PhD, depois professor e depois programador novamente (desculpe-me, Engenheiro de Software
Na engenharia tradicional
Existe uma "física" que se aplica ao software - a teoria da informação, mas os engenheiros de software têm pouca exposição a ela e, certamente, nada é aplicado. A maior parte da teoria é de computabilidade e grande O.
Também estou continuamente impressionada com as pessoas que acham que saber programação é suficiente e não precisam entender o assunto do que são seus programas.
Além disso, a criatividade não é incentivada. É desencorajado, em favor de métodos de pensamento de grupo de denominador comum menor, disfarçado de "legibilidade". (Imagine se os engenheiros aeronáuticos ou nucleares fossem encorajados a não fazer nada que pudesse ser difícil de entender para seus colegas juniores.)
As coisas que eles aprendem, como programar aplicativos da web, são de grande valor. Assim é a habilidade de um encanador ou eletricista, mas não é engenharia.
Se eu cortar uma esquina no mais software, e fizer algo que não seja o melhor design, mas que faça o trabalho, ninguém vai morrer. É a mesma razão pela qual uma cabana no jardim não precisa dos mesmos padrões de um prédio de 10 andares. No entanto, eu posso criar um aplicativo muito grande como o facebook, e se ele estragar e perder alguns dados, ou o que for, não é realmente tão grande coisa. Também é mais simples consertar a base de um aplicativo grande depois do fato do que substituir a base de um prédio de 10 andares. Tudo se resume ao contexto e ao cálculo de risco.
Eu também posso, com segurança e simplesmente continuar adicionando a um aplicativo. Você não pode facilmente lançar em um terceiro andar de um edifício de 10 andares (tornando-se 11). Eu posso lançar um novo recurso para um aplicativo grande todos os dias, se eu quiser.
Agora, um bom design torna tudo isso mais fácil na programação. Mas não é impossível com um design ruim, e os riscos são ... software com bugs. Não geralmente morte.
Carregue comigo em um presente. Eu tenho um ponto.
Eu tive um professor que me disse uma vez que a procrastinação leva a mais procrastinação, mesmo que a maioria das pessoas depois de uma noite de escrever / enfiar-se / escrever em programas diga: "Eu nunca farei isso novamente. Da próxima vez, eu ' Vou começar cedo e terminar logo. " Em minha experiência como o procrastinador consumado, descobri que isso é verdade, e aqui está a explicação do professor: por mais desagradável que seja a experiência de procrastinar, na maioria dos casos, você consegue atingir um sucesso relativo. Esse é um comportamento de alto risco / alta recompensa. Depois de um tempo, você se esquece de todas as coisas desagradáveis e só se lembra da recompensa. Assim, a próxima tentação de procrastinar é ainda mais atraente, porque você conseguiu a última vez.
Eu acho que uma analogia pode ser feita aqui com a técnica de programação "faça as coisas acontecer" que muitas vezes vemos. Um programador ou uma equipe de programadores, talvez por ignorância, preguiça ou talvez por uma restrição de tempo genuína, adota a abordagem de "fazer as coisas acontecer" com a programação, jogando toda sua teoria, matemática e boas práticas pela janela. E sabe de uma coisa? Eles fazem as coisas. Não é elegante, bonito ou sustentável, mas faz o trabalho. Talvez um superior não técnico que não conheça um ponto-e-vírgula de um semáforo lhes dê alguns elogios por "fazer as coisas acontecerem". Assim, da próxima vez que o programador for tentado a usar essa abordagem da programação, é tudo mais fácil, porque, hey, funcionou da última vez, não foi? É a saída "fácil", a menos que seja a alma pobre e desafortunada que herda tal aplicação anos depois e tem que mantê-la.
Eu tenho sido essa pobre e infeliz alma, e provavelmente muitos de vocês. Eu imploro a todos vocês. Não tome o caminho mais fácil! :)
Sua premissa é falha. A principal razão pela qual os engenheiros civis usam a engenharia ao projetar grandes edifícios, pontes, túneis, etc. é garantir que eles usem uma quantidade mínima de material (concreto, aço estrutural, etc.) que satisfaça os padrões de segurança exigidos. É inteiramente possível construir um edifício alto sem muita matemática (por exemplo, as pirâmides das antigas civilizações egípcia e maia) se os custos de material e de trabalho não são objeto, mas uma vez construído, geralmente não há razão para modificar para que eles usem o material com mais eficiência.
Há uma dinâmica um pouco diferente no projeto de grandes sistemas de software. Se alguma coisa, eles são geralmente sub-projetado, mas isso é porque o design pode ser alterado dinamicamente como o trabalho prossegue, o que simplesmente não pode ser feito tão facilmente com projetos de engenharia civil.
O fator comum é o custo. O projeto em um projeto de engenharia civil tradicional reduz os custos (reais, em termos de material e potencial em termos de responsabilidade), enquanto há um ponto no desenvolvimento de software em que o custo do design aumenta além do valor retornado.
Eu também gostaria de destacar, além de várias outras respostas excelentes, que a humanidade vem fazendo o equivalente a "engenharia civil", já que facilmente o tempo dos egípcios nos permitiu ter muito tempo para aperfeiçoar a teoria geral de como as coisas devem ser feitas. Estamos construindo software para algo em torno de 70 anos ou mais (dependendo do que você considera o primeiro "software"); Quero dizer que não tivemos o mesmo tempo para desenvolver o mesmo tipo de experiência.
Os projetos de um arquiteto / engenheiro civil praticamente nunca são idênticos aos planos "as built". Algo SEMPRE muda. Por quê? Porque existem e sempre serão "desconhecidos desconhecidos". Há coisas que você sabe e pode planejar, coisas que você sabe que são desconhecidas e que você pode pesquisar e estimar, e então há coisas que você não sabe que não conhece; "surpresas". Você pretende eliminá-los na maioria dos sistemas, aprendendo tudo o que puder, mas tudo o que é necessário é uma pequena violação de código de construção (que pode ser baseada em uma regra que não existia dois anos atrás quando seu prédio estava sendo conceituado) O plano mestre de interconexão precisa mudar, às vezes de forma bastante drástica.
Software é muito parecido com isso; há sempre um desconhecido desconhecido. No entanto, ao contrário da engenharia civil ou estrutural, o desenvolvimento de software é inerentemente muito mais tolerante à mudança com base nos problemas que as incógnitas desconhecidas criam. Se você está construindo um prédio de 10 andares e superestimou a capacidade de suporte de carga da fundação que você colocou em seu projeto, você não pode construir o edifício para 10 histórias ou você tem que arrancar uma quantidade significativa de trabalho para volte para a fundação e reforce-a ou reconstrua-a. No entanto, no software, se você subestimou as demandas de uma camada específica da estrutura geral da solução, há muitas opções para corrigir essa camada que não envolvem a invalidação de todos os outros trabalhos. Você pode substituir um único servidor de banco de dados por um mais poderoso, ou um cluster de replicação / failover ou um cluster de balanceamento de carga / distribuído. O mesmo para o servidor da web. Se você codificou um algoritmo que é ineficiente, mas simples, baseado em suposições errôneas de tamanho de entrada, você pode quase sempre remover e reescrever a implementação de uma maneira relativamente cirúrgica, sem afetar outro código que tenha conhecimento do algoritmo ou espera uma saída dele).
Essa relativa facilidade de mudança permite que um engenheiro de software codifique com base no que ele sabe, sem se preocupar desnecessariamente com o que ele não sabe. Isso permite uma aplicação mais flexível da teoria e do design conceitual inicial; você mergulha e realiza, e ao longo do caminho você encontra as coisas que você codificou que precisam mudar, e as altera. Você ainda deve conhecer os conceitos e a teoria, porque quando um problema é descoberto, são as coisas que ajudarão você a identificar a causa e criar uma solução. Mas, você está autorizado a tomar uma decisão precipitada sem sucumbir à "paralisia da análise", porque se acontecer que você tenha tomado a decisão errada com base em algo que você não sabia ou não levava em consideração em seus "cálculos", erro é mais fácil de corrigir.
A diferença é principalmente devido aos requisitos conhecidos:
Além disso, quando se fala de "teoria", geralmente significa o lado da teoria da ciência da computação, em vez de engenharia de software. Esta é a parte da ciência da computação que consiste basicamente em encontrar algoritmos melhores e mais eficientes, provando se algo é ou não é possível (P e NP, por exemplo), e assim por diante. Embora seja bom tê-los em mente, eles não surgem no desenvolvimento de software com muita frequência.
Nós usamos bibliotecas para esse tipo de coisa tanto quanto possível.
Existem realmente alguns níveis de engenharia de software, dependendo do que o software que você está construindo está fazendo.
A NASA precisa de software para controlar naves tripuladas no espaço, portanto, naturalmente, o nível do processo de engenharia é muito mais rigoroso do que o de construir um site para mostrar fotos de foguetes.
Um dos meus colegas de trabalho que trabalhou para a NASA descreveu anteriormente seu processo de engenharia de software como escrevendo centenas de páginas de justificativas e centenas de horas de reuniões para justificar a escrita de uma única linha de código!
Não me entenda mal porque não estou tentando soar desrespeitoso quando digo isso, mas mesmo depois de todo esse custo de tempo, recursos e bilhões de dólares, o ônibus espacial explodiu.
Até mesmo engenheiros civis sabem que não importa o quanto de teoria eles ponham em um projeto, algo irá eventualmente quebrá-lo, então eles também precisam desenvolver planos de contingência.
Ao criar software, o custo de travar raramente causa perda de vida, por isso é muito mais fácil lançar coisas rapidamente e testá-las. Vamos concordar que fazer as coisas rapidamente resulta em código fraco. Mesmo que este seja sempre o caso, ver o software em ação é a melhor maneira para um desenvolvedor ver onde ele está fraco e precisa ser mais strong versus onde ele é fraco e ainda muitas vezes mais strong do que precisa ser para acompanhar a carga.
Para resumir, Premature optimization is the root of all evil
ou como meu chefe sempre diria Shipping is a feature!
Muitas boas respostas aqui, mas acho que a comparação entre Ciência da Computação e Engenharia Civil é falha.
Estritamente falando, o que os desenvolvedores profissionais de software fazem é mais como Engenharia de Software do que Ciência da Computação. Uma analogia melhor é que a Ciência da Computação é a Física para Engenharia de Software. Da mesma forma, o Civil Engieering é uma coleção de simplificações e aproximações da física para a construção de materiais.
Eu imagino que os Engenheiros Civis raramente têm que levar em conta a relatividade geral quando realizam seu trabalho. Grande parte da Engenharia Civil pode ser construída com segurança na Mecânica Newtoniana. Da mesma forma, a Engenharia de Software pode ser realizada com muito sucesso com uma compreensão aproximada da ciência da computação.
A grande diferença é que pontes, arranha-céus e outros produtos da Engenharia Civil são coisas razoavelmente bem entendidas. Os engenheiros de software estão construindo construções novas ou usando novos métodos para construir coisas bem entendidas. A engenharia de software é muito menos madura do que a engenharia civil, e isso provavelmente continuará a ser verdade no futuro previsível.
TL; DR : A teoria e a prática são diferentes na Engenharia de Software, assim como em qualquer outro lugar. A analogia apropriada é Engenharia de Software: Engenharia Civil :: Ciência da Computação: Física. Mas na prática, é um pouco mais complexo que isso:)
So my question is why do some programmers think that there is a contrast between theory (formal methods) and practice (getting things done)?
Construir software é diferente de construir uma ponte. No software, há muitos objetos a serem construídos que podem ou não ser definidos no início. Existem padrões para aumentar a facilidade de manutenção e colaboração do desenvolvedor, não para aderir a fórmulas matemáticas arbitrárias ou outros ideais. Por exemplo, ao selecionar o comportamento com base em uma variável, às vezes, faz sentido usar um switch, outras vezes, um padrão de fábrica. Depende da facilidade de manutenção e identifica pontos problemáticos, como problemas de desempenho.
Outro exemplo pode ser feito com manipulação de dados. Geralmente, faz sentido usar delegados no contexto do .NET. Não é tão fácil em Java, porque não tem suporte ao framework para o estilo de programação funcional que o .NET possui. Em outras palavras, no caso geral, simplesmente não é possível fazer X na situação Y. Isso se deve ao fato de que X e Y dependem do número N de fatores variáveis.
Is software engineering (building software) perceived by many as easy compared to, say, civil engineering (building houses)?
Não sei se "fácil" é o termo correto. A falta de evidências tangíveis pode levar à percepção de que nenhum trabalho está sendo feito. Ou, da mesma forma, que o trabalho existente é facilmente alterado.
Or are these two disciplines really different (apart from mission-critical software, software failure is much more acceptable than building failure)?
Engenharia tradicional e engenharia de software são muito diferentes pelas razões que eu já disse.
Sua percepção pode estar errada aqui, ou inclui muitos recursos de pessoas que não escreveram softwares suficientemente complexos.
Sua experiência está alinhada com o que a maioria das pessoas que conheço (que projetou e escreveu software suficientemente complexo) diria.
Dito isto, quando se trata da maioria dos programadores , quando a tarefa de escrever algo chega até eles, o design ("as matemáticas", como você diz) já foi feito pelo arquiteto / lead / etc. antes que a tarefa de escrever chegue a eles. Então, pode parecer assim do nível da linha de frente.
Acho que o motivo desse contraste é que o ciclo de vida de um projeto de software e hardware ou projeto de arquitetura é diferente. A maioria dos softwares evolui gradualmente, não é planejada do começo ao fim. Os desenvolvedores de software podem aplicar uma abordagem iterativa ao desenvolvimento: planejar, implementar e ouvir feedback. Se o feedback for positivo, continue, não - dê um passo para trás e reconsidere sua estratégia. É por isso que os desenvolvedores de software têm coisas como desenvolvimento ágil, produto mínimo viável e assim por diante.
Engenheiros civis não têm esse luxo. Para eles, uma vez que algo é planejado, você não pode mudá-lo tão facilmente, como com o software, porque o custo de tais mudanças pode ser terrível. Para o desenvolvimento de software, por outro lado, não custa muito, e isso pode ser usado para sua vantagem.
Mas nem todo ramo de desenvolvimento de software pode ter essa abordagem. A criação de software, por exemplo, para serviços médicos ou de aviação exige um planejamento muito cuidadoso e muitos cálculos prévios.
Parece o mesmo para mim. Você constrói um grande edifício a partir de blocos padrão, concreto de resistência padrão, aço padrão. Você cria um aplicativo grande com bibliotecas padrão.
Você não tenta e matematicamente prova formalmente que um aplicativo grande é correto da mesma maneira que você não tenta escrever a função de onda para um prédio de 100 andares
Eu era engenheiro mecânico e de manufatura antes de descobrir há 20 anos que minhas aptidões estavam no software. Eu simpatizo com muitos dos elementos que você expôs.
Eu suspeito que a verdadeira natureza do problema é sobre como fazemos as coisas. Temos agora dez ou mais anos de desenvolvimento ágil sob nossos cintos coletivos, e a mensagem é clara. Não progrida por camadas; progresso por recursos. Claro - haverá projetos quando você precisar progredir por camadas (por exemplo, construir sua pilha de rede antes de seu servidor web), mas para a grande maioria dos projetos do mundo real, aprendemos a lição que entregar recursos de trabalho, um ou alguns em uma vez, é muito mais eficaz construir enormes teorias não testadas e depois tentar implementá-las.
Então, vamos pegar seu exemplo de cabana (eu costumo falar de fazer uma ponte lançando um tronco através de um córrego contra uma ponte suspensa de um quilômetro de comprimento ... o que for!), e trazê-lo para o mundo da engenharia de software. A principal diferença que vejo é que no software, a maior parte do trabalho é de uma escala que não precisa de uma grande modelagem inicial para ter sucesso. O erro do iniciante é freqüentemente assumir que as coisas precisam mais disso do que elas realmente acontecem, e para a maioria de nós, tendo cometido esse erro algumas vezes, estamos tentando repeti-lo com muita frequência.Sem argumento - há projetos que precisam começar com um comitê de 17 arquitetos de software. Na verdade, eles são tão raros quanto os diamantes de 20 quilates.
Eu acho que a analogia é falha. Até onde sei, a engenharia civil não tem o mesmo tipo de base teórica que a ciência da computação; a ciência da computação nasceu da matemática teórica - como as máquinas de Turing. A engenharia civil é sobre a criação de estruturas que resistem à mãe natureza e talvez até pareçam bonitas. Mais uma vez, eu realmente não sei muito sobre engenharia civil, mas eu não acho que haja equivalentes de engenheiro civil de P contra NP, o vendedor ambulante, e outras coisas divertidas para esmagar seus cérebros. E definitivamente há um lugar para nossa teoria da ciência da computação - se alguém resolver o vendedor ambulante ou o problema da suspensão, teremos muitos novos avanços incríveis. Mas para um engenheiro de software, cujo negócio é arquitetar software, esses problemas são apenas divertidos e divertidos.
Agora, também acho que depende do que você entende por "teoria". Estamos falando de padrões de design ou de bombeamento de lema? Porque ter uma boa e sólida compreensão dos padrões de projeto é absolutamente essencial para ser um bom engenheiro de software. No entanto, ao arquitetar um grande sistema de software, teorizar sobre problemas de P / NP não é útil. Nesse sentido, acredito que exista um contraste muito grande entre engenharia de software e ciência da computação teórica.
Ou a teoria se refere a algoritmos? Você não gasta muito tempo escrevendo algoritmos que aprendeu em sua classe de algoritmos. Por quê? Porque você normalmente só precisa deles em casos particulares (e então procura e pesquisa), ou usa uma biblioteca já escrita para você. Não há necessidade de escrever outro classificador bayesiano. A abstração é um princípio importante na ciência da computação. Eu acho que os engenheiros de software tendem a não aprender como um algoritmo funciona até que eles precisem.
Outra razão é que existem atualmente vários métodos de desenvolvimento de software populares que são eficazes. Por exemplo, no desenvolvimento ágil, você não arquitetará um sistema inteiro de antemão. A razão para isso é porque você não sabe exatamente o que está construindo ainda - você quer que o que você está fazendo seja flexível e se adapte às novas informações e requisitos. Projetando tudo desde o início e depois construindo apenas que nem sempre produz o melhor software. No entanto, não é a solução para tudo. Por exemplo, digamos que você esteja projetando alguma coisa nova de computação distribuída, louca por cluster. Você não pode fazer alguns esboços de guardanapo e iniciar seu SCRUM.
TL; DR. Eu acho que há algum equívoco em torno da palavra "teoria". Tradicionalmente, a teoria refere-se aos aspectos matemáticos teóricos da ciência da computação. A menos que você esteja pesquisando novas formas de computação, a maior parte da ciência da computação teórica não faz parte do dia a dia de um engenheiro de software. Os engenheiros de software se preocupam com padrões de design e arquitetura do sistema. Detalhes específicos de implementação de certos algoritmos não são importantes. Muitas vezes, com ideias menos complicadas, é apropriado não projetar muito e começar a codificação. E eu acho que é daí que vem a ideia de que os programadores não gostam de teoria.
A diferença entre teoria e prática é muito grande no momento. Ao fazer a teoria, você recebe três axiomas e posteriormente é mostrado que um teorema de uma linha tem uma prova de mil páginas, ou nenhuma prova. Na engenharia de software, você recebe APIs inconsistentes de milhares de funções que fornecem uma infinidade de maneiras (ruins) de implementar um recurso não especificado.
A engenharia de software real levaria a maioria das pessoas no campo formal a loucura, e o verdadeiro desenvolvimento de software matemático leva os engenheiros à loucura. Ambos os campos exigem pessoas de diferentes aptidões, e não acho que as aptidões se sobreponham com frequência.Programação prática é sobre como resolver o problema certo (não o de design de software) no momento certo, para que seus colegas de trabalho possam fazer seu trabalho melhor / mais rápido / de forma que as receitas possam fluir para a empresa. . Muitos softwares não são como um produto, nunca são "feitos", mas mais como algo vivo, que começa altamente especializado para um nicho ecológico e pode ter uma vida útil muito variável, durante a qual ele precisa resolver problemas novos e imprevistos em um nicho ecológico. grande variedade de ambientes em constante mudança. No mundo dos negócios, com política e legalidades e competição e organizações, estruturas e tendências em constante mudança, os requisitos são muitas vezes ambíguos, complicados com todos os tipos de casos especiais, mal definidos e sujeitos a rápidas mudanças inesperadas. Eles não são analisáveis, previsíveis ou estáticos e nem sempre são lógicos ou razoáveis. O software tem a mesma probabilidade de ser irrelevante em 2 semanas e ainda estar em uso em 20 anos. Ela vem ao mundo sem saber muito ou ser capaz de fazer muito, e precisa ser nutrida, preparada e treinada durante toda a sua vida para crescer strong, flexível e capaz de se adaptar a seus ambientes em constante mudança e a novos problemas. Se você negligenciá-lo após o nascimento, ele se tornará selvagem se sobrevive por tempo suficiente e causa dor e sofrimento, resolvendo problemas com força bruta.
A teoria formal não atende às necessidades de muitos softwares comerciais do mundo real. Isso nos leva a acreditar que o software pode ser projetado e feito. Que é um produto que pode ser ocasionalmente consertado, polido ou ter as coisas pregadas, mas não uma coisa viva que precisa ser levantada adequadamente com cuidado e atenção constante durante toda a sua vida. Então, acabamos com um código de legado feroz realmente feio, mas a teoria formal provavelmente não teria ajudado nisso.
Tudo isso soa bastante negativo, mas na verdade eu adoro usar a teoria formal. Um belo design sempre traz um sorriso ao meu rosto. No entanto, isso é principalmente na minha programação amadora que não está sujeita às vicissitudes dos negócios. No trabalho, eu principalmente lidei com código orgânico e só espero que eu possa dar atenção suficiente para que ele cresça certo, me deixe orgulhoso, e não seja desagradável e rude com os outros que têm que lidar com isso.
Os riscos são menores, o trabalho é mais fácil e o gerenciamento raramente vê o valor em um bom design. A instabilidade, manutenibilidade e integridade do sistema são um problema de "TI" - não um problema de "negócios". Todos os executivos têm uma coisa em comum. Eles são 95% focados em dinheiro ou se reportam a alguém que é.
O restante da batalha é com seus colegas programadores. Muitos deles não podem ou não se comprometem a pensar em um problema antes de começar a codificação. Devido ao acima, muitas dessas pessoas são desenvolvedores seniores, tornando ainda mais difícil obter um bom design na produção.
Eu observei que o projeto leva anos inúteis, adicionando recursos ad-hoc e correções a projetos que eram complicados para começar, e depois abatendo todas as tentativas de trazer ordem ao caos com frases como "muito complicado" ou "perdendo tempo". " Não é agradável assistir a uma grande espiral de projeto à sua inevitável desgraça porque a administração não admitirá que está construindo sua própria prisão diariamente; no entanto, temo que seja uma infeliz realidade que muitos desenvolvedores tenham testemunhado e - para o bem ou para o mal - aprendido.
Eu tento encontrar um meio no meu trabalho. Eu não escrevo mais código em projetos "contaminados" do que é absolutamente necessário, e aproveito todas as oportunidades para mover a funcionalidade para fora deles. "Entre projetos", dedico tempo ao design e à limpeza dos projetos sobre os quais realmente tenho controle.
No final, é uma grande confusão de política e integridade pessoal que 75% dos programadores do mundo não têm estômago para isso. Eu mal consigo aguentar, eu mesmo.
Primeiro de tudo, eu amo essa pergunta. Eu escrevi como três respostas de 1000 palavras e elas estavam terrivelmente erradas quando cheguei ao fim delas.
O problema em tentar comparar os dois como análogos, eu acho, é que a programação é um processo de modelagem que pode ser tão abstrato ou strongmente ligado ao concreto como você quer.
A teoria da engenharia estrutural, por outro lado, está strongmente vinculada a conjuntos muito específicos de leis baseadas na realidade às quais você deve obedecer. Você não pode simplesmente alterar o contexto ou as leis. O problema em si está enraizado nessas leis. Na programação, no entanto, às vezes a solução está realmente alterando a natureza da questão ou simplesmente colocando-a em um contexto diferente.Se o padrão MVC, por exemplo, é um ajuste perfeito, tem muito a ver com esse contexto. Normalmente, um aplicativo de desktop lida apenas em um idioma e em um idioma, sem contar os arquivos de configuração.
O front-end de um aplicativo da web, por outro lado, consiste principalmente em dois idiomas declarativos (não-programação) e JavaScript. A única coisa física que você não pode abstrair completamente é o fato de que há sempre essa parede http para chuck as coisas entre o servidor e o navegador. Independentemente de como você o enterra no código, isso leva tempo e um design assíncrono.
Obviamente, você não pode usar um padrão popular e bem conceituado como o MVC para lidar com as preocupações do front-end na Web exclusivamente, sem alterar a maneira como você pode lidar com isso em um contexto de aplicativo de desktop. Na verdade, eu diria, você deve estar ciente do que torna o MVC útil, mas nem mesmo tentar implementá-lo de maneira particularmente exigente ou por atacado. O paradigma do aplicativo da web é único, pois todo o material "look-at-me" é manipulado pelo navegador do usuário e todos os dados / modelo-ish são tipicamente no servidor em algum lugar. Mas onde isso deixa o controlador? Tudo no servidor ou tudo no front end? Alguém tem que possuir isso. Ou talvez o MVC não seja 100% o melhor ajuste para o cenário. Não é um ajuste ruim para o material de back-end do .NET. Não é terrível no contexto de widgets da interface do usuário específicos. Mas tentar aplicá-lo a tudo por uma questão de consistência pode ser uma má jogada, IMO.
Construir uma casa resolve um problema. Problemas típicos de programação, no entanto, geralmente envolvem a solução de problemas dentro de problemas e, às vezes, a solução é redefinir o problema externo. A realidade não está especialmente interessada nessa ideia, infelizmente.
Glenn Vanderburg apresenta uma excelente visão sobre as diferenças entre engenharia de software e disciplinas de engenharia mais tradicionais: link
Se um engenheiro civil pudesse testar seus projetos sem nenhum custo antes de construir a coisa final, ele faria muito menos uso da teoria. Se em segundos ele pudesse construir uma ponte mil vezes para testar quando ela quebrasse, ele o faria em vez de gastar meses calculando quando poderia frear em teoria ...
No desenvolvimento de software, isso é exatamente o que você faz. Em vez de calcular o quão rápido seu algoritmo é, em teoria, você pode apenas testá-lo e saber a resposta dentro de segundos.
Na verdade, a maioria dos softwares atuais não é mais limitada por restrições físicas, como poder de computação ou memória. A limitação do software é a complexidade que equivale em sistemas cada vez maiores. Sua gestão desta complexidade, mantendo o sistema compreensível pelos seres humanos que faz o enorme desafio na programação hoje.
