[ad_1]
Você já fez biscoitos e se perguntou por que a receita é exatamente assim e não outra? Se você mudasse esse ingrediente ou aquela temperatura, isso tornaria os biscoitos ainda melhores?
European certamente tive esses pensamentos. É a razão pela qual a maioria das coisas que ecu cozinho não são muito comestíveis…
Quando se trata de programação, esses pensamentos também surgem. E se ecu escrevesse esta parte como uma função separada? Se ecu codificasse esse bit ali, isso tornaria o código mais fácil? Posso reescrever essas dez linhas feias em duas elegantes?
Não há receitas na programação, mas existem as melhores práticas. Eles não são precisos como uma receita, mas são claros o suficiente para serem evidentes se você não os tiver implementado. Assim como nas receitas, algumas práticas recomendadas são repetidas por gerações de programadores. Às vezes, faz sentido fazê-lo; às vezes isso não passa de uma tradição. Programação de culto de cargase você quiser chamá-lo assim.
Mas, eventualmente, mesmo a tradição mais prison morre ou evolui para algo mais útil. O mesmo acontecerá com algumas, mas não todas, as melhores práticas de programação.
Simultâneo “não se repita” e a separação de preocupações não funciona
Recentemente, revisei alguns dos meus códigos antigos e notei que as mesmas quatro linhas de código apareceram três vezes no mesmo arquivo.
Agora, qualquer pessoa que tenha estudado qualquer ciência da computação formal (não ecu, fiz física) dirá que isso é bobagem porque você precisa manter seu código DRY. Do not Repeat Your self tornou-se uma espécie de mantra.
Não sou formado em ciência da computação, mas leio um pouco e internalizei esse mantra. Então ecu peguei essas quatro linhas e as coloquei em uma função.
Então notei que não poderia fazer isso tão facilmente porque aquelas quatro linhas não eram completamente idênticas. Uma pequena mudança na terceira linha significava que ecu teria que adicionar pelo menos uma opção à minha nova função. European também precisaria de uma cláusula if e talvez de um novo parâmetro booleano para invocar essa opção.
Isso tornaria o código tão complicado quanto antes.
Mas então notei que essas quatro linhas sempre são invocadas depois de chamar outras funções, duas funções diferentes em três lugares diferentes, e então pensei em adicionar as quatro linhas a essas funções. Isso funcionou bem porque a pequena alteração na terceira linha seria tratada por cada uma das funções anteriores, e uma das duas já continha um parâmetro correspondente.
Isso simplificou um pouco meu código. Acabei me repetindo, mas apenas duas vezes em vez de três vezes. E ecu violei o Princípio da Responsabilidade Única porque minhas duas funções estavam fazendo mais do que o anunciado.
Você poderia argumentar que ecu provavelmente escrevi um código ruim e que pode haver soluções muito mais elegantes para o que ecu estava tentando realizar. E essas soluções alternativas podem até ter satisfeito ambos os princípios.
Justo. É difícil refutar uma afirmação como essa.
Mas os programadores não são pagos para escrever o código mais elegante e bonito da década. Eles são pagos para fazer algo funcionar.
Meu projeto funciona. E mais cosméticos de código me custariam um pace valioso que prefiro gastar em outros projetos que ainda não estão funcionando.
Talvez ecu seja tão burro que não consiga nem fazer dois princípios de programação funcionarem. Mas ecu garanto a você que existem muitos programadores que estão em um nível semelhante ao meu.
Grupos de pessoas que também não conseguem fazer DRY e SRP trabalharem juntos.
É improvável que isso faça com que DRY seque (desculpe, o trocadilho tinha que ser). É um princípio extremamente útil, por exemplo, na programação funcional, que está ganhando força nos dias de hoje.
O Princípio da Responsabilidade Única, por outro lado, pode se tornar mais raro. Pense em redes neurais, por exemplo. Eles não descobrem uma única coisa. Os mais sofisticados entendem e reagem a, milhões de imagens diferentes, mensagens de texto ou proteínas complicadas. Isso é o oposto do SRP.
Em outras palavras… SRP está secando.
Por want, reinvente a roda de vez em quando
Assim como DRY e SRP, essa prática foi popularizada por pessoas com boas intenções. Mas isso não muda o fato de que nem sempre é sensato implementar.
A ideia é que se já existe uma solução para o seu problema, você deve usá-la. Provavelmente é menos problemático e mais eficiente do que sua solução caseira.
Existem alguns problemas com esse pensamento.
Em primeiro lugar, as soluções existentes raramente correspondem 100% ao seu problema específico. Portanto, é bem provável que você resolva, digamos, 75% importando uma solução ou um pacote que resolva seu problema. Mas você ainda terá que fazer uma parte substancial do trabalho braçal, além de testar, depurar e manter.
Em segundo lugar, as soluções existentes geralmente têm mais de um recurso. E você provavelmente não usará todos os recursos. Portanto, você estará introduzindo uma certa quantidade de código supérfluo em seu projeto, o que o torna mais difícil de entender e mais difícil de manter. Você poderia ter evitado isso criando o seu próprio.
Terceiro, cuidado com incorporando soluções de código aberto em projetos proprietários. Isso é uma violação de direitos autorais e pode, na pior das hipóteses, causar problemas legais. Se você united states código-fonte aberto em seu projeto, seu projeto também deve ser de código-fonte aberto.
Finalmente, reinventar a roda não garantirá a liberdade de insects de qualquer maneira. Mesmo que seja experimentado, testado e atualizado (o que é bastante raro), você ainda precisa incorporá-lo corretamente e escrever o código clichê em torno dele.
Então, por que não escrever sua própria solução personalizada, cometer alguns erros no processo e aprender com eles? Esses tipos de lições podem ser extremamente valiosas e farão de você um programador muito mais valioso a longo prazo.
Quantidade sobre qualidade
O escritor Sean Kernan (ele é ótimo, dê uma olhada nele) tem um grande peça sobre como você deve pressionar pela quantidade, não pela qualidade, quando está fazendo um trabalho criativo.
Para escrever, isso significa que se você escrever um artigo por mês e poli-lo até que fique ótimo, tudo ficará bem. Não é ótimo, porque você não usou muito seus músculos de escrita com apenas um artigo. Mas não é ruim, porque você poliu bastante.
Mas se você escreveu 30 artigos em um mês, é bem improvável que todos eles sejam apenas ruim-ruim ou adequate. Alguns deles serão ótimos, e um ou dois deles podem até ser excelentes.
Claro, você não teve pace para aperfeiçoar tanto seu trabalho, mas seus músculos de escrita serão do tamanho de Arnold-Schwarzenegger assim que o mês acabar. E você terá tido pace para cometer todos os erros possíveis, desde erros de digitação até pisar no pé de outras pessoas, e, esperançosamente, internalizar as lições.
Agora, você pode objetar que a programação é bem diferente da escrita livre.
Sim, programar é mais técnico do que escrever e você pode precisar de muito mais conhecimento prévio para começar. Mas a programação é, em sua essência, uma disciplina bastante criativa.
Programar é basicamente encontrar maneiras interessantes, elegantes e eficientes de resolver problemas com um computador. Isso é criativo!
Detratores poderia dizer que 100 pedaços de código medíocre ainda são medíocres e, portanto, um pedaço de código excelente é melhor.
Mas falando sério, se você tiver 100 tiros com certeza você vai atirar um na direção certa! Pelas leis da estatística, se 100 pedaços de código em média medíocres, dez serão ótimos e dois serão excelentes – e isso é melhor do que um pedaço de código ótimo.
Então codifique mais, cometa mais erros e aprenda mais.
As melhores práticas transformam você em um idiota complacente
Tudo se resume a isso: você é livre para seguir todas as práticas recomendadas.
Mas eles podem limitar seu pensamento e cegá-lo para soluções mais inovadoras.
Se você realmente quer se destacar de forma positiva, use as melhores práticas como diretrizes. Quebre essas diretrizes quando isso lhe parecer apropriado.
As pessoas que sempre seguem as regras tornam-se complacentes. E a complacência, com o pace, mata o sucesso.
Comece a quebrar as regras e você terá uma likelihood de se juntar às grandes cabeças.
Repita-se se isso for melhor para você.
Deixe suas responsabilidades emaranhadas se isso for mais fácil de manter.
Codifique suas próprias soluções em vez de importar as existentes que não se encaixam perfeitamente.
E codifique mais. Muito mais. Mesmo que seja ruim ou bugado. Haverá algumas pedras preciosas na bagunça que você criar.
Este artigo foi publicado originalmente no Medium. Você pode lê-lo aqui.
[ad_2]
Fonte da Notícia
