{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"N\u00e3o concorde em desenvolver o que n\u00e3o entende","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"N\u00e3o
\n
\nDesde o in\u00edcio de 2018, ocupo a posi\u00e7\u00e3o de l\u00edder\/cap\u00edtulo\/desenvolvedor principal na equipe \u2014 chame como quiser, mas a quest\u00e3o \u00e9 que estou completamente respons\u00e1vel por um dos m\u00f3dulos e por todos os desenvolvedores que trabalham nele. Essa posi\u00e7\u00e3o me proporciona uma nova perspectiva sobre o processo de desenvolvimento, pois estou envolvido em um n\u00famero maior de projetos e participo ativamente na tomada de decis\u00f5es. Recentemente, devido a essas duas circunst\u00e2ncias, percebi o quanto a profundidade da compreens\u00e3o influencia o c\u00f3digo e o aplicativo.<\/p>\n

A ideia que quero expressar \u00e9 que a qualidade do c\u00f3digo (e do produto final) est\u00e1 intimamente ligada ao n\u00edvel de consci\u00eancia das pessoas que projetam e escrevem o c\u00f3digo sobre o que realmente est\u00e3o fazendo.<\/p>\n

Voc\u00ea pode estar pensando agora: \"Obrigado, capit\u00e3o. Claro, seria bom entender o que se est\u00e1 escrevendo. Caso contr\u00e1rio, poder\u00edamos muito bem contratar um grupo de macacos para que eles batucassem aleatoriamente nas teclas, e assim ficarmos satisfeitos\". E voc\u00ea est\u00e1 absolutamente certo. Portanto, aceito como um fato: voc\u00ea entende que ter uma vis\u00e3o geral do que est\u00e1 fazendo \u00e9 essencial. Isso pode ser chamado de n\u00edvel zero de compreens\u00e3o, e n\u00e3o entraremos em detalhes sobre isso. Vamos explorar com mais detalhes o que exatamente precisa ser entendido e como isso afeta as decis\u00f5es que voc\u00ea toma todos os dias. Se eu soubesse essas coisas antecipadamente, teria poupado muito tempo desperdi\u00e7ado e c\u00f3digo duvidoso.
\n<\/a><\/noindex>
\nEmbora voc\u00ea n\u00e3o veja uma \u00fanica linha de c\u00f3digo abaixo, ainda assim considero que tudo o que foi dito aqui \u00e9 muito relevante para a escrita de c\u00f3digo de qualidade e expressivo. <\/p>\n

O primeiro n\u00edvel de compreens\u00e3o: Por que n\u00e3o est\u00e1 funcionando?<\/h4>\n

\nOs desenvolvedores geralmente alcan\u00e7am esse n\u00edvel nos est\u00e1gios iniciais de suas carreiras, \u00e0s vezes at\u00e9 sem qualquer ajuda dos outros \u2014 pelo menos, essa \u00e9 a minha observa\u00e7\u00e3o. Imagine que voc\u00ea recebeu um relat\u00f3rio de bug: alguma fun\u00e7\u00e3o no aplicativo n\u00e3o est\u00e1 funcionando, \u00e9 necess\u00e1rio consert\u00e1-la. Como voc\u00ea agiria?<\/p>\n

O procedimento padr\u00e3o \u00e9 o seguinte:<\/p>\n

    \n
  1. Encontrar o trecho de c\u00f3digo que est\u00e1 causando o problema (como isso \u00e9 feito \u00e9 um tema separado, que exploro no meu livro sobre c\u00f3digo legado)<\/li>\n
  2. Fazer altera\u00e7\u00f5es nesse trecho<\/li>\n
  3. Certificar-se de que o bug foi corrigido e que n\u00e3o surgiram erros regressivos<\/li>\n<\/ol>\n

    \nAgora vamos nos concentrar no segundo ponto \u2014 fazer altera\u00e7\u00f5es no c\u00f3digo. Existem duas abordagens para esse processo. A primeira: entender o que exatamente est\u00e1 acontecendo no c\u00f3digo atual, identificar o erro e corrigi-lo. A segunda: avan\u00e7ar no escuro \u2014 adicionar, por exemplo, +1 em uma instru\u00e7\u00e3o condicional ou la\u00e7o, ver se essa fun\u00e7\u00e3o come\u00e7a a funcionar no cen\u00e1rio desejado, tentar mais alguma coisa e assim por diante indefinidamente.<\/p>\n

    A abordagem correta \u00e9 a primeira. Como explica em seu livro Code Complete, Steve McConnell (ali\u00e1s, recomendo muito), sempre que fazemos alguma altera\u00e7\u00e3o no c\u00f3digo, devemos ser capazes de prever com seguran\u00e7a como isso afetar\u00e1 o aplicativo. Cito isso de mem\u00f3ria, mas se a corre\u00e7\u00e3o do bug n\u00e3o funcionar como voc\u00ea esperava, isso deve acender um alerta; voc\u00ea deve questionar todo o seu plano de a\u00e7\u00e3o.<\/p>\n

    Resumindo, para realizar uma boa corre\u00e7\u00e3o de bug que n\u00e3o prejudique a qualidade do c\u00f3digo, \u00e9 necess\u00e1rio entender tanto a estrutura do c\u00f3digo quanto a fonte do problema espec\u00edfico.<\/p>\n

    O segundo n\u00edvel de compreens\u00e3o: Por que isso funciona?<\/h4>\n

    \nEsse n\u00edvel \u00e9 compreendido de maneira muito menos intuitiva do que o anterior. Eu, ainda sendo um desenvolvedor iniciante, aprendi isso atrav\u00e9s do meu chefe, e depois, v\u00e1rias vezes, expliquei o conceito para iniciantes.<\/p>\n

    Desta vez, vamos imaginar que voc\u00ea recebeu dois relat\u00f3rios de bug ao mesmo tempo: o primeiro diz respeito ao cen\u00e1rio A, o segundo ao cen\u00e1rio B. Em ambos os cen\u00e1rios, algo est\u00e1 errado. Portanto, voc\u00ea come\u00e7a pelo primeiro bug. Com base nos princ\u00edpios que estabelecemos para o primeiro n\u00edvel de compreens\u00e3o, voc\u00ea se aprofunda no c\u00f3digo relacionado ao problema, descobre por que ele faz o aplicativo se comportar dessa maneira no cen\u00e1rio A e faz ajustes razo\u00e1veis que produzem exatamente o resultado esperado. Tudo corre bem.<\/p>\n

    Depois, voc\u00ea passa para o cen\u00e1rio B. Voc\u00ea repete o cen\u00e1rio na tentativa de provocar o erro, mas \u2014 surpresa! \u2014 agora tudo funciona como deveria. Para confirmar sua suposi\u00e7\u00e3o, voc\u00ea desfaz as altera\u00e7\u00f5es feitas durante o trabalho no erro A, e o bug B retorna. Sua corre\u00e7\u00e3o resolveu ambos os problemas. Que sorte!<\/p>\n

    Voc\u00ea n\u00e3o esperava por isso. Voc\u00ea encontrou uma maneira de corrigir o erro no cen\u00e1rio A e n\u00e3o tem ideia de por que isso funcionou para o cen\u00e1rio B. Nesse ponto, \u00e9 muito tentador concluir que ambas as tarefas foram realizadas com sucesso. Isso faz sentido: o objetivo era corrigir os erros, certo? Mas o trabalho ainda n\u00e3o terminou: voc\u00ea ainda precisa entender por que suas a\u00e7\u00f5es corrigiram o erro no cen\u00e1rio B. Por qu\u00ea? Porque pode ser que ele esteja funcionando com princ\u00edpios incorretos, e ent\u00e3o voc\u00ea precisar\u00e1 buscar uma sa\u00edda diferente. Aqui est\u00e3o alguns exemplos dessas situa\u00e7\u00f5es:<\/p>\n