Como resolver qualquer problema de programação

Olá pessoal!

Hoje, sua atenção é convidada a traduzir, à sua maneira, um artigo insubstituível que o ajudará a abordar corretamente até o TK mais insidioso e não trivial, que você à primeira vista não entende. O principal é não desistir e formular perguntas de maneira inteligente. Justin Fuller, do Bank of America, gentilmente descreve como fazê-lo corretamente.



Boa leitura!

Então este dia chegou. Talvez este seja seu primeiro dia útil, ou talvez você esteja trabalhando neste local há dez anos - não importa. Acontece com todos: você finalmente encontra uma tarefa que simplesmente não entende.

O que fazer? Basta começar e esperar que tudo funcione por si só? Ou admitir ao chefe que você não pode fazer isso, porque você não entende?

Eu acho que você adivinhou que a resposta correta não é uma nem a outra!

Percebi que na programação, como em qualquer outra profissão, é quase impossível viver uma semana de trabalho (e às vezes um dia de trabalho) sem ter que enfrentar uma tarefa completamente incompreensível.

Mas não se preocupe! Há ótimas notícias. Você não apenas pode resolver esse problema, mas também pode beneficiá-lo.

Afinal, ao fazer isso, você terá que expandir seus conhecimentos e habilidades em comparação com tudo o que você fez e sabia antes.

A seguir, mostrarei como preencher a lacuna entre os requisitos que foram definidos para você e o conhecimento necessário para concluir a tarefa.

Sobre os "requisitos"

Como você já percebeu, eu uso a palavra "requisitos". Dependendo de onde exatamente você trabalha, essa palavra pode ter certas conotações.

Na minha experiência, em grandes empresas, eles gostam de requisitos e, em pequenas empresas, às vezes "não apresentam requisitos". Eu acho que é sobre isso que devemos falar aqui.

O fato é que, em última análise, todos os programadores fazem a mesma coisa: resolvem problemas.
Você pode obter um TK exaustivo de cem páginas sobre como resolver esse problema (uma vez participei de uma reunião de uma hora sobre o texto em um botão). Ou talvez desta maneira: o CEO passa por sua mesa e, como se perguntasse inadvertidamente - "você vai lidar com essa tarefa até sexta-feira?"
Nos dois casos - a tarefa está definida para você e você deve ter certeza de que a entende completamente; a única maneira de abordá-la direito!

Sobre as etapas

Nem todas as etapas listadas abaixo serão necessárias para qualquer tarefa. Somente as tarefas mais complexas podem exigir a conclusão cuidadosa de todas as etapas que serão discutidas neste artigo.

É possível que muitas perguntas não possam ser respondidas com base apenas em requisitos expressos ou devido à insuficiência de sua experiência pessoal.

Pode ser necessário consultar outros desenvolvedores, líder da equipe, proprietário do produto, analista de negócios ou até avó! E talvez com cada um deles, antes que o problema possa ser resolvido!

No entanto, isso é normal. Isso significa que você coletará conhecimentos díspares e reunirá-os em um único todo - e assim poderá obter o melhor resultado possível!

Finalmente, o último aviso: não exagere na formalização! A coisa mais importante aqui é entender rapidamente a tarefa. Não são necessárias barreiras artificiais e fitas vermelhas! Tudo o que é necessário é um plano sistemático para resolver um problema que você atualmente não entende.

Estágio Um: Analisar o Problema

Nesta fase, estamos tentando entender o que você foi solicitado a fazer. Até tentarmos decidir como vamos fazer isso!

É importante perceber essa diferença. Pode ser perigoso seguir para uma carreira sem perceber todas as consequências ou, pior, não entender completamente o que exatamente você foi solicitado a fazer.

Classificamos o problema

Classificar uma tarefa significa determinar que trabalho terá que ser feito para resolvê-la. Aqui estão alguns exemplos de tipos de tarefas:

• Bug fix
• Novo recurso
• Novo aplicativo
• Trabalho de pesquisa
• Otimização de desempenho

Lembre-se de que esta lista de opções não está limitada a.

Nesse caso, devemos decidir que tipo de trabalho é esperado de você. Isso é importante porque afetará diretamente o tipo de trabalho que você fará.

Esse estágio é especialmente importante com os requisitos difusos, por exemplo: "Precisamos de uma maneira de limpar os caches de nossos clientes após a atualização do site".

Aqui estão algumas interpretações possíveis desse requisito.

1. Você deve implementar rapidamente um certo mecanismo para limpar o cache, para que os clientes sempre recebam as atualizações mais recentes.
2. É necessário estudar todas as maneiras de armazenar esses caches de cliente e determinar as melhores opções para se livrar desses caches após cada atualização do site.
3. Os caches do cliente já devem ter sido limpos e você deve encontrar e corrigir um bug que impede isso.

Nesse estágio, se você não tiver certeza absoluta do significado da interpretação, precisará procurar esclarecimentos e só então continuar trabalhando.

Formule a essência do problema na forma de uma ou duas declarações simples.

Resuma o requisito complexo, como se estivesse respondendo à pergunta "no que você está trabalhando hoje?" Pode não ser tão simples, mas você deve tentar reduzir a essência do problema para uma ou duas frases.

Se resumir a tarefa dessa maneira falhar, isso pode significar que ela deve ser dividida em várias subtarefas. Em princípio, esta etapa se transforma em um teste decisivo, sinalizando se você conseguiu organizar suas tarefas na forma de fragmentos suficientemente pequenos.

Aqui está um bom exemplo desse resumo: "Ao atualizar um site, anexamos um número exclusivo aos arquivos, para que o navegador entenda que deve usar a versão mais recente do código".
Essa tarefa passou no "teste decisivo" por simplicidade e, talvez, não seja necessário quebrá-lo em fragmentos menores.

E aqui está um mau exemplo: "Ao atualizar um site, anexamos um número exclusivo aos arquivos, para que o navegador entenda que ele deve usar a versão mais recente do código. Também devemos enviar uma mensagem para a nossa CDN, notificando-a dessa maneira sobre a necessidade de atualizar arquivos. Também será necessário prever que os aplicativos para iOS e Android enviem uma atualização para o mercado de aplicativos. Mais ... "

Nesse caso, o teste é definitivamente um fracasso. É necessário muito trabalho, e talvez cada tarefa precise ser identificada e rastreada separadamente.

Destacar detalhes críticos

Agora você deve (de forma livre, o mais conveniente para você) fazer uma lista das principais coisas que precisam ser feitas.

Novamente, isso deve ser um aperto muito simples de cada um dos estágios principais.

Este não é um guia passo a passo ou detalhado para solução de problemas.

Lembre-se disso enquanto continua a analisar a tarefa atribuída a você. Nesta fase, recomendo tomar notas escritas. Pessoalmente, uso o aplicativo Notes para isso.

Nossa tarefa de armazenamento em cache é muito simples e, possivelmente, não é necessário descrevê-la dessa maneira. Vejamos um exemplo mais complexo neste caso.

Nossa próxima tarefa é realizar uma nova oportunidade: “Cada usuário deve receber publicidade direcionada de nosso produto interno. Este anúncio deve ser adaptado às necessidades do usuário com base nos dados que coletamos. ”

Para isolar os principais elementos dessa tarefa, devemos imaginar claramente o que precisa ser feito para implementar cada elemento.

• Nossos anúncios existentes precisarão ser distribuídos de forma que se correlacionem com algum parâmetro específico do usuário.
• Para o nosso departamento de marketing, precisamos fornecer uma maneira que nos permita correlacionar novos anúncios com uma ou mais partes de dados do usuário (nesse caso, os profissionais de marketing não devem programar nada!)
• O sistema precisará agregar parâmetros do usuário que sejam relevantes no contexto de nossa publicidade.
• Por fim, você precisa criar algum tipo de sistema que receberá um ID do usuário e exibirá anúncios.

A beleza dessas listas é que elas podem ser rapidamente acordadas com a equipe ou o chefe! Portanto, neste exemplo, você pode mostrar esta lista ao seu líder de equipe, e ele decidiu que outro ponto muito importante estava faltando na lista:

• Os usuários devem poder nos dizer que não querem mais ver determinados anúncios.

Afinal, no final, a última coisa que queremos irritar são nossos usuários favoritos! Dedicando o tempo e refletindo sobre a tarefa por apenas alguns minutos extras, pouparemos horas e dias de problemas no futuro. Portanto, é importante formular e planejar uma tarefa importante e só então prosseguir para o código.

Antes de prosseguir, gostaria de responder às suas possíveis críticas.

Talvez você pense: “Em uma empresa normalmente entregue, esse tipo de trabalho deve ser feito antes que os requisitos sejam colocados sobre a mesa do desenvolvedor” - e eu concordo plenamente com você!

Infelizmente, porém, nosso mundo é imperfeito. Às vezes, os requisitos que caem para o desenvolvedor não são de forma alguma definidos nas prateleiras. Portanto, devemos fazer todos os esforços para avaliar corretamente os requisitos antes de iniciar o desenvolvimento.

Identifique o (s) problema (s) que você está tentando resolver.

Responda à pergunta: "por que alguém teria que usar isso?" ou "Qual é o problema real ou percebido que estou tentando corrigir neste caso?"

Espero que a resposta seja óbvia. Em nosso primeiro exemplo, fornecido aqui, a resposta é: "os usuários sempre verão as atualizações mais recentes". No segundo caso, com publicidade, "os usuários sempre verão notificações relevantes, não aquelas que não lhes interessam".

O uso de ambas as respostas deve ser óbvio! Para uma compreensão mais profunda da tarefa e de seus objetivos, você pode tomar decisões mais razoáveis ​​e fazer uma implementação que atenda adequadamente às suas metas de negócios. Se for possível identificar soluções ruins e tarefas sem sentido, será possível não perder tempo e energia em pesquisas que, por definição, não ajudarão a resolver o problema.

Etapa dois: interpretar e avaliar requisitos

Nesta fase, você já deve imaginar o que precisa fazer e por quê.
Em seguida, você precisa entender os detalhes do que você fará, como fará e por que fará dessa maneira.
Esclareça termos importantes relacionados à sua tarefa.

Esta etapa é provavelmente mais importante para um desenvolvedor iniciante como parte de uma equipe ou se você trabalha em uma grande empresa. Em ambas as situações, é muito provável que você encontre termos desconhecidos nos requisitos.

Podem ser conceitos de negócios, como nomes de produtos, clientes ou processos. Pode haver termos relacionados ao desenvolvimento - por exemplo, os nomes de ferramentas, aplicativos, modelos, serviços ou bibliotecas.

Você precisa certificar-se de entender todos os termos importantes de maneira absolutamente clara, para ter certeza de que está implementando a tarefa corretamente.

Talvez você já entenda que precisa inventar uma maneira de acessar informações agregadas do usuário, mas entende o que significa “adicioná-lo ao dao”?
Você provavelmente entende que precisa formatar os dados de publicidade, mas tem alguma idéia do que é “MADF” (marcação para feeds de notícias de publicidade)?

Eu não entendo nem um nem outro.

É por isso que você precisa isolar e definir todos os termos importantes. Confundir-se nas definições é o caminho certo para resolver um problema incorretamente.

Decida como a tarefa deve ser realizada.

Nesta fase, você já deve descobrir como a tarefa será executada. Os detalhes desse processo podem variar bastante, dependendo de onde você trabalha e de qual tarefa específica está atribuída.

Em algumas equipes, ninguém lhe explicará exatamente como implementar os requisitos, eles simplesmente dirão que funcionalidade deve ser obtida na saída.

Em outros, cada passo que você tomar será detalhado.

Muito provavelmente, você estará em algum tipo de situação intermediária.

Se a equipe não lhe fornecer instruções, nesse estágio você não poderá fazer quase nada. Se você recebeu instruções, comece a se familiarizar com os estágios pelos quais precisa passar.

Essa etapa parece completamente natural, mas é importante prestar atenção exatamente à ordem em que prosseguimos.

Naturalmente, gostaríamos de mergulhar em todos os detalhes da tarefa de uma só vez e estudá-los até que a meta que estabelecemos seja completamente clara para nós.

No entanto, como você já teve tempo para entender o problema, agora deve ter uma idéia mais clara de todo o problema, avaliando as etapas que precisam ser tomadas para alcançá-lo.

Determine se as tarefas estão sendo endereçadas.

Nesta etapa, as etapas de análise e interpretação se fundem. Na fase de análise, você se concentra em uma imagem holística e em objetivos de larga escala - o que fazemos e por quê.

Na fase de interpretação, concentre-se nos detalhes - como fazemos.

O segundo estágio é chamado de "interpretação e avaliação", porque agora você pode correlacionar "como" e "o que e por quê". Você interpreta os detalhes com base na imagem geral. Você avalia os detalhes e determina se o problema original foi resolvido.

Pergunte a si mesmo: as etapas que fui instruída a levar ao resultado, que foram designadas como o objetivo final da tarefa? O resultado planejado realmente resolve o problema original?

Se você tem certeza de que todos os problemas podem ser resolvidos e os detalhes são significativos, pode começar a trabalhar! Caso contrário, é necessário ir para o terceiro estágio para resolver todos os tipos de conflitos.

Estágio Três: Abordamos o problema criticamente

Nesse estágio, você deve poder afirmar com confiança que entende a tarefa e a solução. Tudo o que resta saber é se esta decisão está correta.

Para criar produtos da mais alta qualidade, todos devemos ser capazes de assumir responsabilidades e falar se algumas coisas estão claramente erradas.

Por outro lado, não faremos reivindicações inadequadas. Não se pode dizer que algo está errado, porque "parece que sim" ou simplesmente "não gosta". Argumentos concretos e bem projetados devem ser avançados.

Então, descrevemos as regras básicas de desacordo competente

Saiba quando discordar

• A discordância é inaceitável, até eu descobrir o problema completamente.
  Dizer "isso está errado" só é possível com certeza absoluta de que você entende o que não concorda /
  Se você não conseguir formular com confiança um problema e uma solução planejada, não poderá discordar. Se você não tiver certeza de que entendeu tudo corretamente, não poderá discordar. Apenas tendo a certeza de entender o problema nos mínimos detalhes, você pode se dar ao luxo de discordar.
  Se você acha que não possui todas as informações necessárias, talvez seja hora de parar e revisar todas as etapas que foram concluídas antes de afirmar que os requisitos estão incorretos.
• Não se pode deixar de concordar por razões subjetivas. Procure problemas potenciais genuínos.
  "Eu não gosto de como isso é feito" é um julgamento subjetivo. "Isso levará a problemas de desempenho, porque muitas operações estão envolvidas" é uma razão objetiva. Exemplos de outras razões subjetivas: "E em outro projeto, fizemos de forma diferente" ou "Eu teria implementado essa solução de maneira um pouco diferente, mas isso, é claro, é uma questão de gosto".
• Você deve ter explicações bem pensadas prontas para apoiar suas reivindicações.
  Se você não consegue explicar por que algo está errado - pode ter certeza de que está realmente certo? Aconselho que você anote as razões pelas quais a decisão lhe parece errada e formule como ela pode ser corrigida.

Se você não pode oferecer uma solução desse tipo, fale-a claramente desde o início.

Tenha cuidado ao discordar dos outros. Leva muito tempo para ouvir todos e entender tudo - e só então você não pode concordar.

Se até esse momento você seguiu cuidadosamente todas as etapas descritas, é muito provável que você seja versado em tudo. No entanto, tente não se prender aos seus cálculos - você pode ter perdido alguma coisa!

Eu gosto de começar a discussão com as palavras: "Não que eu não concorde com você, eu ainda não entendo". Mais tarde, se necessário, uma forte discordância pode ser expressa, mas para começar - para descobrir isso.

Saber discordar corretamente

Para garantir que nosso desacordo seja objetivo, tomaremos várias medidas para nos ajudar a entender se nossos argumentos são justificados.

A discordância objetiva nos permite demonstrar pelo menos um dos seguintes fatos:

• A decisão não está bem informada
• Decisão incorreta
• A tarefa ou solução é ilógica
• A solução está incompleta

A falta de informação não é motivo para ressentimento; significa apenas que, ao criar a solução, você veio de dados incompletos. Talvez os redatores do TK não soubessem sobre o sistema já existente, capaz de executar as ações necessárias.

Estar mal informado significa criar uma solução baseada em informações incorretas.

Este é um caso em que, na opinião dos redatores de TK, o sistema existente pode fazer algo, mas, na realidade, essa possibilidade não está prevista nele. Por exemplo, a equipe de SEO solicitou que o Google indexasse a página com a conta de usuário em seu aplicativo. O Google não pode fazer isso. Isso significa que seu seokhniki não entende bem as funções do robô de pesquisa do Google.

Uma tarefa ilógica ou solução ilógica é simplesmente sem sentido. Um exemplo típico (do ponto de vista do desenvolvedor) é implementar um recurso que derrubará outro recurso. Esse requisito pode ser considerado ilógico, pois é mais provável que cause danos do que ajuda.

A solução está incompleta e, às vezes, é feita de propósito. No desenvolvimento de software, geralmente tentamos criar MVP (produto mínimo viável) para começar. Isso significa que, na primeira operação, você pode atrasar intencionalmente a implementação de um funcional que não é absolutamente necessário.

De fato, uma decisão pode ser considerada incompleta apenas se não resolver o mesmo problema definido para você, ou se as etapas acima não forem suficientes para criar um produto viável ou uma oportunidade completa.