Metamorfose

Naturalmente evoluindo, esse repositrio uma metamorfose ambulante

Esse aqui mais um daqueles repositrios sobre o workflow do Desenvolvedor de Software.

Meu fluxo de trabalho no Desenvolvimento de Software.

Por que um repositrio para nosso fluxo de trabalho?

Por que pode ser til para ajudar algum a melhorar o seu fluxo de trabalho, outras pessoas podem comentar sobre o nosso fluxo e com isso podemos melhorar e pode ser uma maneira de contribuir com quem tem dvidas sobre como o nosso dia a dia.

Como nosso workflow est sempre mudando, acho o GitHub o melhor lugar para deixar isso registrado, pois podemos ir atualizando sempre. Um post no Blog poderia ficar defasado em poucas semanas, por exemplo.

Experincia pessoal

Um workflow com o qual aprendi bastante foi o do @vitorbritto: https://github.com/vitorbritto/workflow-guide

Durante minha carreira percebi que vale muito a pena perguntar para outras pessoas o que elas esto usando e acompanhar o que grandes empresas esto fazendo.

Se voc quiser mais dicas sobre carreira, acompanhe esse repositrio.

ndice

Workflow

Meu fluxo de trabalho ao iniciar um projeto/tarefa tcnica:

Entender a tarefa/o projeto
Analisar o problema a ser resolvido
Planejar como resolver esse problema
Colocar a mo na massa

1. Entendendo a tarefa/o projeto

Podemos utilizar papel e caneta para levantar os requisitos de um projeto/uma tarefa ou o Wunderlist para essas notas depenendendo do que estiver nas mos no momento de buscar esse entendimento.

Vale a pena questionar o mximo quem lhe passou a tarefa at entender bem o que deve ser feito para que no fique nenhum n perdido, o que poderia gerar um retrabalho.

2. Analisar o problema a ser resolvido

Depois de levantar o mximo de informao sobre o que ser feito vem a parte de analisar o que ser feito.

Essa parte de analise pode ser para:

Classificar os tpicos por dificuldade
Estipular prazos para essas tarefas (normalmente j comeamos a criar pequenos planos mentais sobre como vamos resolver o problema)
Excluir tpicos que foram levantados, porm so inviveis (pode acontecer bastante)

3. Planejar como resolver o problema

Com os tpicos devidamente analisados podemos decidir, agora, por onde comear e como fazer.

Podemos iniciar por algo que v entregar valor a curto prazo, algo que v resolver um grande problema ou mesmo comear pelos mais fceis para agilizar grandes entregas ou entrega de volume, conforme foi analisado no tpico 2.

Agora vem a parte mais tcnica que planejar/modelar como codificar a soluo para o problema.

Algumas perguntas que voc deve fazer quando for codificar essa soluo:

Esse problema j foi resolvido por outra pessoa?
Podemos usar determinado padro de projeto para resolver esse problema?

4. Colocar a mo na massa

Enquanto estamos codificando a soluo, ideal que se pense o seguinte:

Outra pessoa vai entender o nome dessa varivel?
Outra pessoa vai entender o que essa funo/mtodo faz?
O assassino que est atrs de mim vai gostar desse cdigo? (tpico muito importante)

Quando todas essas questes esto satisfatrias, sinal que rolou um bom entendimento da tarefa.

Caso algo no esteja saindo como planejado, ideal que pea ajuda de um companheiro de servio. Uma segunda opinio sempre boa, um code review excelente. No importa nosso nvel, nem o tempo de experincia que possumos, sempre legal ouvir o que outras pessoas tem a nos dizer.

Seja curioso(a) e esteja sempre disposto(a) a aprender algo com outras pessoas, entender como as coisas funcionam.

Isso facilita seu workflow.

Ferramentas mais utilizadas durante essa fase: