Muito do que parece completamente óbvio para um desenvolvedor experiente não é óbvio para um iniciante. Não estou falando de escrever código, conhecimento de padrões etc. Isso se aplica à maneira de pensar em geral: como resolver o problema, como perguntar, como não despertar a raiva dos mentores de seus anciãos . Hoje vamos tentar falar sobre isso.
Métodos de pensamento racional (aqui) são perguntas que devem ser feitas em cada estágio do pensamento sobre um problema. Com a ajuda deles, você pode rapidamente tomar a decisão certa e criar seu trabalho com mais eficiência.
Pergunta 1. Qual é o motivo?
De acordo com a lei da maldade, quando você inicia o aplicativo pela primeira vez, algo definitivamente não funciona. Primeiro você deve tentar determinar a causa do erro. A maneira mais fácil é olhar para o console. Talvez o texto do erro seja suficiente para entender como corrigi-lo.
Pergunta 2. Fiz tudo o que pude?
Mesmo que o texto do erro não tenha ajudado, não corra para as pessoas com uma pergunta. Primeiro você precisa ter certeza de que tudo o que é possível foi feito. Você pode verificar algo como isto:
- Verifiquei a documentação do aplicativo em busca de uma solução para esse problema
- Eu pesquisei e não encontrei nada
- Eu pesquisei em inglês e não encontrei nada
- Nenhuma das dicas encontradas me ajudou.
Se a resposta for sim em todos os lugares, vá para o próximo parágrafo.
Pergunta 3. Parece que estou confuso. Porque
Não há problema em pedir ao seu mentor / mentor / chefe / amigo uma solução. Talvez você tenha esquecido de contar sobre ela. No entanto, a pergunta não deve consistir apenas das palavras “algo não está funcionando”, todos os dados de entrada disponíveis devem ser incluídos nela. Uma pergunta bem construída economiza seu tempo de mentor e ajuda você a trabalhar com mais eficiência. Tente verificar a pergunta para "integridade":
- Texto de erro especificado
- É indicado um caso em que você encontrou um erro (até os comandos de inicialização)
- Métodos de solução comprovados são indicados.
Lucro! No menor tempo possível, você receberá uma solução para o problema e um profundo respeito dos colegas. Então, encaminhar para o desenvolvimento de tarefas.
Pergunta 4. Minha solução resolve completamente o problema?
Agora vamos falar sobre como concluir qualquer tarefa. Dica: a pergunta certa para você.
Se for um bug, vale a pena verificar: o problema foi corrigido ou mascarado? Por exemplo, há uma função que deve retornar um número, mas (de repente) retorna uma sequência. Ao converter o resultado no local da chamada de função, você pode mascarar o problema. Mas, talvez, valha a pena fazer a transformação dentro dela e, assim, corrigir completamente o problema.
Um recurso ou bug, não seja preguiçoso no final para verificar todos os casos possíveis. Como mostra a prática, a frase “deve funcionar” causa bugs terríveis e um descontentamento ainda mais terrível do lado receptor.
Pergunta 5. Por que tenho certeza disso?
Imediatamente, vamos dar uma olhada em um exemplo: é hora de integrar diferentes partes de um aplicativo grande. O backend associado à tarefa júnior foi desenvolvido há muito tempo. Ele lança um recurso ao seu lado e ... tudo trava! Muito rapidamente, ele determina que o back-end está congelado. Pode-se dizer imediatamente: “O problema não está do meu lado”, desista da tarefa e prossiga com os nossos negócios. Mas o Rational Junior pensará: “Se a tarefa de back-end estiver marcada como concluída, provavelmente foi testada. Por que tenho certeza de que o problema está no back-end? ” Não importa de que lado está o problema. É importante que ele não procure outro desenvolvedor sem verificar o comportamento do seu lado.
Pergunta 6. Por que isso foi feito?
Deveria ser dado como certo que pessoas razoáveis contornam e não escrevem bobagens (pelo menos de propósito). Quando parece que alguém escreveu uma linha no código que é supérflua, você deve pensar duas vezes antes de excluí-la. Mesmo que resolva completamente o problema. As maneiras mais prováveis de ignorar nada:
- Visualize a mensagem de confirmação mais recente modificando esta linha
- Exibir tarefa de confirmação (geralmente indicada na mensagem de confirmação)
- Veja quem fez o commit e pergunte a ele, depois de falar sobre sua tarefa
Concluindo, quero acrescentar uma coisa: não é necessário seguir todos os convênios deste artigo, mas é necessário pensar constantemente e pensar de forma independente .