Não há problema em não entender completamente a funcionalidade do código? [duplicado]

O único propósito das abstrações de software é ocultar detalhes funcionais. Se não fosse por essas abstrações, não seria possível avançar além de um certo ponto na computação, porque os sistemas simplesmente entrariam em colapso sob o peso de sua própria complexidade. O cérebro humano só pode compreender tanta informação ao mesmo tempo.

Considere o que acontece quando você escreve um método. Quando você escreve um método, o que você está fazendo é esconder um pouco da funcionalidade do software por trás de uma chamada de método. Uma vez que o método tenha sido escrito e provado que funciona ao escrever testes de unidade sobre esse método, você não precisa mais pensar sobre o que está dentro desse método a menos que precise alterar algo sobre sua implementação.

Grandes sistemas de software são construídos sobre muitas camadas dessas abstrações. Você tem uma camada de microcódigo no processador, código de máquina, endereço e data buses, compiladores de linguagem, orientação a objeto, estruturas de dados, domínio - idiomas específicos e assim por diante. Você tem bibliotecas construídas sobre outras bibliotecas, que por sua vez são construídas sobre um sistema operacional. Você não entende completamente como funciona qualquer uma dessas coisas, mas ainda é capaz de escrever com sucesso programas de computador que fazem algo útil.

Isso disse ...

Você não pode simplesmente copiar / colar o código sem entender como ele funciona . A pessoa que tenta fazer seu programa funcionar copiando o código que ele não entende está se preparando para falhar. Você precisa entender o código que você escreve. Isso não significa que você precisa saber como o WCF trabalha internamente, mas você faz precisa saber qual é o propósito do WCF. , como escrever código que o integre corretamente e como o código que você escreve funciona em conjunto com ele. Muitos programadores copiar / colar nem sequer têm uma compreensão decente da linguagem de programação que estão copiando / colando, e muito menos do conhecimento profundo das bibliotecas que estão usando.

Da mesma forma, os programadores que pensam que podem costurar um programa por meio de padrões aleatórios de software estão faltando o ponto. Nós chamamos essas pessoas de programadores Cargo Cult .

Eu acho que a resposta é contexto.

Uma das técnicas mais poderosas para gerenciar a complexidade do código - que é o trabalho real de um engenheiro de software, na minha opinião - é a abstração. Um engenheiro elétrico não precisa reprovar as equações de Maxwell para desenvolver um novo produto, e eu não preciso saber nada sobre um carro para usar um volante. Ambas são abstrações importantes porque nos permitem intuir e usar as coisas sem entendê-las. Isso, por sua vez, nos permite construir abstrações maiores.

Como um aparte, porque a abstração é tão importante, acho que às vezes é bom até impor isso a outros desenvolvedores. Por exemplo, em meu escritório, às vezes, um desenvolvedor escreve os testes de unidade para um bloco de código antes que o bloco de código seja escrito por um segundo desenvolvedor. Reforça a ideia de interfaces simples e abstrações claras.

Dito isso, a abstração não é desculpa para não entender como o código funciona quando é importante que você saiba como funciona . O código de refatoração é um cenário óbvio no qual os detalhes da implementação são importantes. Eu não preciso saber como um carro funciona para dirigi-lo, mas um engenheiro mecânico e um mecânico devem entender como funciona um carro, discutivelmente de maneiras diferentes.

Como um segundo à parte, uma das minhas primeiras lições no trabalho foi nunca tocar no código que eu realmente não entendia. Por exemplo, uma vez eu estava trabalhando em um novo recurso e notei outra linha de código no módulo que não fazia sentido, então eu "consertei" e então liberei um bug. Isso me ensinou uma lição bem grande, que é admitir quando não entendo prontamente um pedaço de código e reconhecer que um código bom e complexo e não trivial pode ser não óbvio. Eu sou muito novo no desenvolvimento de software, mas eu achei a idéia de que "bom código é fácil de ler" para ser um insidioso que nenhum desenvolvedor de software que eu conheço coloca em prática real. Claro, não escreva códigos obscuros ou ruins, mas problemas difíceis geralmente exigem código complexo. Não fique chateado se você precisar de tempo para entender as coisas. Minha citação favorita de Feynman é: "Mas não é complicado; há muito disso".

Então, quando você abstrai e quando você desmonta o relógio suíço? Eu suponho que depende de quando você está usando o relógio e quando você está construindo. Minha opinião pessoal é que as melhores pessoas em qualquer campo são em forma de T , o que significa que elas entendem seu trabalho de maneira mais ampla. contexto - algo que só é alcançado através da abstração - mas também sabe o que eles precisam saber profundamente.

Existem três partes diferentes para entender o software:

1. A primeira é entender por que existe um software (tão grande quanto um aplicativo ou tão pequeno quanto uma única função). Você precisa saber o motivo, por que foi escrito.
2. Em seguida, acho que está entendendo o que um código faz.
3. Finalmente, é sabido como funciona uma parte do código, como são as coisas internas e o que fazer.

Quais desses itens você precisa entender para entender um software diferente, dependendo do que você precisa fazer com esse código.

Por exemplo, use o método String.ToUpper () do .NET. Eu sei o que esse método faz, e por que você gostaria de usá-lo, mas eu não sei como está escrito (isso é um detalhe de implementação) e eu realmente não me importo - contanto que eu possa usar corretamente. Eu nunca precisarei modificar esse método, então minha compreensão dos internos não é necessária.

Se eu estivesse copiando o código da Internet, preciso ter certeza absoluta do que o código faz e por quê. Se eu estava apenas copiando e nunca modificando (improvável), não sinto necessidade de entender como funciona. Mas se eu fosse modificá-lo (provavelmente), então eu precisaria saber como isso funciona - caso contrário, estou apenas usando adivinhação para modificar o código, e isso provavelmente não terminará bem.

Não que eu discorde das outras respostas, mas deixe-me responder ao que eu li nas entrelinhas. Se seu chefe está lhe avisando que você não precisa entender como algo funciona, pode ser algum feedback que você está demorando para fazer algo. Algumas pessoas facilmente se distraem com detalhes sem importância e, para elas, é aconselhável trabalhar para permanecer no caminho certo.

Por outro lado, se a programação é sua profissão escolhida e você tem a curiosidade intelectual de se aprofundar em alguma tecnologia que é importante para o que você faz, então eu o encorajo a dedicar um tempo extra para seguir seus interesses quando possível. As percepções que você ganha, embora não imediatamente recompensadoras, pagarão dividendos a longo prazo. Ele ajudará você a entender a tecnologia, colocará você em condições de ampliá-la em muitos casos e preparará você para um entendimento ainda mais profundo no futuro. Com o tempo, isso é o que diferencia um especialista de um usuário casual.

No grande programador pragmático do livro, isso é chamado de "programação por coincidência" ( link )

Eu não concordo totalmente com a afirmação: "Você não pode simplesmente copiar / colar o código sem entender como funciona."

Perdoe minha estupidez, mas de um ponto de vista programático, não está incluindo uma biblioteca de métodos / funções que eu não sei que eles funcionam essencialmente como copiar / colar esse código no meu próprio?

Ou seja, se estou programando usando jQuery, incluo a biblioteca jQuery e a uso. Usando a resposta de Robert Harvey, isso é bom, já que o jQuery abstraiu todas as coisas que eu preciso usar sem ter que escrever o código ou mesmo compreendê-lo completamente. Eu realmente preciso saber exatamente como o jQuery trabalha nos bastidores antes que eu possa usá-lo?

Como na maior parte do tempo, tudo depende. No extremo, há o uso de uma biblioteca. Você não deveria saber ou se importar como isso funciona. Você deve saber o que colocar e o que sai, o que pode e o que não pode fazer.

No outro lado, você não sabe como fazer alguma tarefa porque você não fez isso antes. Você encontra dez linhas de código na internet, o que parece mais fácil do que encontrar as informações certas em sua documentação (e geralmente é). Nesse ponto, eu sugiro strongmente que agora é o momento certo para aprender como fazer essa tarefa. Então pegue o código, entenda, faça o seu próprio. Perceba que muitos códigos na Internet não são necessariamente escritos pelas pessoas mais inteligentes, então pode haver fraquezas e mal-entendidos, então aprendendo agora você pode ter certeza de que o código funciona. E no ponto em que você inclui essas dez linhas em seu projeto, elas são sua responsabilidade. Se o código não funcionar, a culpa é sua. Então você tem que entender, como se você tivesse escrito.

Então, qual é a diferença para a biblioteca? Essa não é sua responsabilidade também? O código da biblioteca não é. A escolha da biblioteca e o uso da biblioteca é. Se a biblioteca trava seu aplicativo dez vezes por dia, é porque você escolheu uma biblioteca que não é confiável. Você não precisa entender o código da biblioteca, mas precisa entender seus problemas de confiabilidade e agir.

O conselho do seu chefe pode funcionar bem, mas é arriscado. Existe o perigo de que, a longo prazo, você se envolva em problemas maiores, que poderiam ser evitados levando-se tempo para entender as coisas, em primeiro lugar. Se isso é uma coisa única, o risco é relativamente pequeno. Se você construir um sistema de software inteiro dessa maneira, terá uma bomba-relógio nas mãos. O que você não entende, você não tem nenhuma esperança de consertar ou mudar sem causar bugs.

Por outro lado, se você desobedecer seu chefe, seu próprio emprego pode estar em risco. Se você gosta do seu trabalho, tente resolver problemas técnicos antes de se envolver. Eu já tive um chefe que bagunçava as coisas sempre que ele se envolvia em decisões técnicas (embora ele fosse estelar nas vendas e nas relações com os clientes). A maioria da equipe técnica aprendeu a ouvir o que ele dizia, depois se virou e fez algo diferente. Enquanto o software funcionasse, ele nunca faria o acompanhamento e verificaria se o seu aconselhamento técnico foi realmente implementado. O trabalho pagou bem, mas estou feliz por não estar mais lá.

Se essa atitude for difundida no seu local de trabalho, eu consideraria, pelo menos, outras opções de trabalho.