A abundância de estruturas está atrapalhando os programadores? [fechadas]

Com todas as estruturas disponíveis atualmente, ORMs , injeção de dependência (DI), Inversão de controle (IoC) etc., acho que muitos programadores estão perdendo ou não têm as habilidades necessárias para resolver problemas para resolver problemas difíceis. Muitas vezes, vi comportamentos inesperados invadirem aplicativos e os desenvolvedores não conseguiram realmente descobrir e encontrar os problemas. Parece-me que uma profunda compreensão do que está acontecendo sob o capô está sendo perdida.

Não me entenda mal , não estou sugerindo que essas estruturas não sejam boas e não tenham movido o setor para a frente, apenas perguntando se, como conseqüência não intencional, os desenvolvedores não estão adquirindo o conhecimento e a habilidade necessários para um profundo entendimento de sistemas.

Acordado. Atualmente, trabalho em um pacote de software tão sobrecarregado por estruturas que torna quase impossível entender os negócios. Depois que as estruturas o impedem de realmente resolver problemas de negócios, em vez de apenas resolver o MVC , ele foi longe demais. Como você declara, muitos programadores da IMO tentam arquitetar / programar para resolver o ORM e o MVC, e raramente perguntam se isso realmente ajuda de alguma maneira a resolver o problema para o qual o software existe.

Sim, eu sei que ver algum SQL bruto em uma página JSP é um "não-não", mas se você é um consultor de campo, onde isso se encaixa em uma solução específica? E não, isso não significa que a estrutura não esteja correta, nem todos os clientes têm US $ 20 mil em cada turno para garantir que um ponto de dados menor seja projetado na página.

Este é um argumento que aparece regularmente, em muitos campos e de várias formas.

A forma geral desse argumento é:

Ter [x: ferramenta / tecnologia] piora as pessoas em [y: função afetada por x]?

Por exemplo:

• O software CAD cria engenheiros piores?
• As calculadoras do ensino médio tornam os alunos piores em matemática?
• O software social atrapalha as habilidades sociais pessoais das pessoas?
• O software de contabilidade produz contadores piores?

De memória, a resposta onipresente é quase sempre: na verdade não. Você sempre terá pessoas boas e ruins em fazer [y], mas agora elas são ruins em uma faceta diferente da habilidade.

Uma compreensão mais profunda dos fundamentos de qualquer trabalho ajudará, não importa o que você faça - mesmo trabalhos considerados "reparadores". O conhecimento sempre ajuda.

Abstração é um conceito-chave de programação de computadores e estruturas que ajudam os programadores a conseguir isso. Isto é uma coisa boa. Duvido que muitos de nós gostaríamos de desenvolver sistemas complexos em linguagem assembly! O problema vem, eu acho, quando os programadores têm pouca idéia do que a camada de abstração está mascarando. Em outras palavras, você precisa ter uma idéia do que acontece sob o capô, mesmo se você não interagir diretamente ou interagir com ele.

Lembro-me de desenvolver alguns dos primeiros sites dinâmicos em meados dos anos 90, usando C e CGI (numa época em que a maioria dos sites ainda era HTML estático). Não havia realmente nenhuma linguagem de script madura do lado do servidor (como PHP ou ASP) e muito poucas bibliotecas; portanto, você precisava escrever o fluxo de resposta HTTP inteiro no servidor com todas as páginas. A análise dos parâmetros GET e POST exigiu a gravação de sua própria biblioteca. Foi tedioso, lento, trabalhoso e propenso a erros. Eu não sinto falta nem um pouco!

No entanto, também sinto que estruturas como os formulários da Web do ASP.NET abstraem toda a natureza apátrida da web a um ponto em que muitos novos desenvolvedores da web têm poucas pistas do que realmente está acontecendo sob o capô. Isso leva a um código ineficiente e inchado que apresenta um desempenho ruim porque o desenvolvedor está unindo componentes usando uma metodologia "drag'n'drop" sem perceber o que está acontecendo no nível HTTP.

Portanto, acredito que as estruturas são essenciais para o desenvolvimento de software de alto nível, mas elas não impedem os desenvolvedores de entender o que está sendo abstraído. Sim, estruturas podem torná-lo burro, mas apenas se você não as entender.

A transmissão automática ou os limpadores de pára-brisa com sensor de chuva nos tornam condutores piores?

Eu não acho que a codificação sem estruturas necessariamente implique uma melhor compreensão dos sistemas subjacentes. Isso é evidenciado pelo fato de os empregadores terem que fazer perguntas simples de codificação em entrevistas, apenas para garantir que o candidato possa reunir um método coerente.

Em última análise, cabe ao desenvolvedor aprender. Os bons fazem, os maus não.

E de maneira semelhante, escolher uma estrutura apenas porque ela existe sem realmente analisar suas capacidades e prós / contras também é um sinal de más práticas de desenvolvimento.

Penso que o problema é que os novos programadores estão começando em níveis cada vez mais altos de abstração e, portanto, não são expostos aos bits e bytes das coisas "sob o capô". Portanto, eles não estão aprendendo alguns dos fundamentos de codificação realmente básicos que seriam as primeiras coisas aprendidas nos últimos anos.

Eu balanço minha cabeça toda vez aqui quando um programador obviamente novo está perguntando algo sobre, digamos, o armazenamento de alguns dados, e todos imediatamente os dizem para usar uma ferramenta ORM . Não, não, não, não, não ... eles precisam aprender a fazer eles mesmos primeiro.

Talvez a distribuição de "burrice" não tenha realmente mudado, e estamos simplesmente distribuindo maneiras maiores e mais complicadas para os desenvolvedores darem um tiro no pé?

Não são as estruturas que embotam os programadores. Programadores burros serão burros, independentemente de usarem estruturas ou não.

Certamente é verdade que entender o trabalho de baixo nível que uma ferramenta ou estrutura ajuda a otimizar faz de você um melhor usuário das ferramentas e estruturas. Você também pode depurar problemas com mais facilidade e solucionar as inevitáveis ​​lacunas de funcionalidade das ferramentas.

Por exemplo, participei de uma aula de Design de Compilador na faculdade, onde codificamos um analisador LR do zero em C, antes de aprender a usar geradores de analisador como lex e yacc. Foi muito educativo e, desde então, entendi e apreciei melhor todas as linguagens de programação que usei.

Mas não estou dizendo que todo programador é obrigado a se esforçar para encerar o carro do Sr. Miyagi por anos e anos antes que eles possam trabalhar em alto nível. Muito trabalho de programação é intelectual, decidindo o que o software precisa fazer , não o trabalho mecânico de codificação em uma linguagem ou ferramenta específica.

Esse trabalho intelectual é onde a inteligência versus a tolice é ainda mais importante.

Citando o excelente "dividendo de gastos de Moore" de James Larus (grifo nosso):

Trinta anos atrás, Bill Gates alterou o prompt do Altair Basic de "READY" para "OK" para economizar 5 bytes de memória. Hoje, é inconcebível que os desenvolvedores estejam cientes desse nível de detalhe de seu programa, muito menos preocupados com isso, e com razão, já que uma mudança dessa magnitude é hoje imperceptível ... Não há como produzir os sistemas atuais usando o artesão, práticas artesanais possíveis (necessárias) em máquinas com 4K de memória.

Eu acho que é provavelmente enganoso dizer que estruturas permitem evitar as habilidades necessárias para resolver problemas difíceis ou evitar um entendimento profundo. Em vez disso, a única razão pela qual somos capazes de construir os sistemas complexos atuais (cuja complexidade pode gerar problemas difíceis e desafiar o entendimento profundo) é porque temos estruturas (e linguagens de alto nível OO coletadas por lixo e IDEs com ajuda sensível ao contexto e verificação de sintaxe on-the-fly e todos os outros avanços no desenvolvimento de software que às vezes são criticados por emburrecer os programadores).

Estruturas são ótimas. Mas você precisa saber o que está por trás. Portanto, o problema é que os programadores confiam demais nas estruturas, sem ter conhecimento suficiente do sistema subjacente.

Um exemplo um pouco desatualizado é o MFC : um programador pode economizar muito tempo usando o MFC em vez da API do Windows, mas sem o conhecimento da API (que significa ter um plano de fundo do trabalho real com a API bruta), eles geralmente ficam presos . Quase nunca aconteceu, porque um programador MFC típico tinha conhecimento da API do Windows.

No entanto, com o Windows Forms no .NET , graças ao melhor encapsulamento e ao melhor modelo de objeto, um programador pode quase ignorar que está usando apenas outro invólucro da API do Windows. Portanto, há menos chances de ficar preso, mas quando isso acontece, pode doer.

Infelizmente, o tempo de colocação no mercado é sempre menor e os projetos são cada vez mais complexos, para que os programadores não tenham tempo para se aprofundar. Esse é o triste estado da indústria de software ...

Ele coloca a inteligência onde precisa estar. Não é necessário entender a mecânica quântica e a física newtoniana para estabelecer um mecanismo que solte uma bola do topo de um edifício. Cada nova camada de software deve se basear na última e remover o padrão da construção de aplicativos úteis.

Aqueles que precisam ou querem conhecer as "coisas" por trás da estrutura estudarão e investigarão por gancho ou trapaça.

Não, absolutamente não. As estruturas são, em sua essência, uma combinação de uma biblioteca de sub-rotinas e um modelo, duas ferramentas de programador testadas e comprovadas. Um trabalhador pobre culpa suas ferramentas ...

... e há muitos trabalhadores pobres usando e culpando estruturas.

Ao criar software, as estruturas economizam tempo. Ao aprender a criar software, as estruturas atrapalham o entendimento.

Eu acho que o problema é principalmente um dos computadores que ficaram muito poderosos. Para a maioria dos programadores, não há mais razão sensata para "voltar ao básico". Leva apenas mais tempo para fazer as mesmas coisas, e no tempo de execução não há diferença significativa. A única maneira de resolver isso é introduzir restrições artificiais, como competições como o js1k.

Talvez as escolas devam ter um assunto dedicado "design otimizado", onde você deve criar programas sob fortes restrições de espaço e tempo?

Não, aprender as estruturas melhora as habilidades de um programador. Framework é a extensão de uma linguagem de programação. Algumas linguagens já são baseadas em framework. Eu trabalho com PHP e Java. O PHP precisa de uma estrutura como o mecanismo de modelo (às vezes). Java não precisa de uma estrutura (na maioria das vezes), ele já possui muitos métodos e bibliotecas.

A maioria das estruturas terá funções que os programadores usam repetidamente.

Para aparentemente parecer o advogado do diabo aqui, acho que estruturas ("boas", de qualquer maneira) podem realmente percorrer um longo caminho para promover a educação de um programador. Uma estrutura bem projetada resolverá muitos problemas e, usando a estrutura, o programador pode entender quais problemas estão sendo resolvidos e como. Na minha opinião, uma estrutura é (/ deveria ser) uma cristalização das melhores práticas de programação e pode ensinar um programador por exemplo.