Quando comecei a programar, contei bastante com fluxogramas (e gráficos de espaçamento da impressora). Enquanto estava na aula de COBOL, não pude começar a escrever nenhum código até que meu fluxograma fosse assinado pelo instrutor. Naquela época, eu tinha que fazer um fluxograma para tudo.

Hoje, vinte e cinco anos depois, me vejo apenas apresentando dois tipos de coisas. Algoritmos muito específicos em que a lógica é complicada ou conceitos muito gerais para garantir que eu receba todos os grandes passos definidos e na ordem correta.

Existem outros casos de uso para fluxogramas que eu simplesmente ignorei?

Absolutamente.

Sempre que estou implementando algo que não havia feito antes (e o algoritmo leva mais do que algumas etapas), mostrarei o gráfico. Acho que isso realmente me obriga a analisar toda a solução em um nível mais atômico e mais minucioso do que se não fosse traçado. Acho que existem três grandes benefícios para essa prática:

• Menos "oh craps" porque pensei em todo o algoritmo
• Libera qualquer possível embate em problemas que possam ocorrer em todo o resto do sistema
• Permite que eu conduza facilmente alguém através do algoritmo

As duas ocasiões diferentes em que eu as uso são:

• Algoritmos de baixo nível (ish). Quero dizer uma solução muito específica para um problema muito específico. Geralmente, eu passo isso pelos colegas antes da implementação.
• Fluxo do usuário. Não só posso usar isso para passar por um par, mas também o explicarei (de uma maneira não técnica) o fluxo para um especialista em usabilidade.

Dito tudo isso, não produzo fluxogramas diariamente (e mesmo quando terminam, geralmente é uma sessão de quadro branco, a menos que eu esteja escrevendo um documento de design técnico).

Nunca

Os fluxogramas - especialmente como praticados há mais de 25 anos - foram substituídos por técnicas de diagramação muito mais expressivas (cf. Diagramas de Ação, Gráficos de Sequência, Gráficos de Estado etc.).

Os próprios estudos da IBM mostraram que o uso de fluxogramas não teve efeito sobre a qualidade do design ou implementação de um sistema (embora fossem marginalmente úteis para a comunicação com usuários e outros desenvolvedores) [referência precisa não disponível, mas citada nas Técnicas de Diagramação de James Martin para analistas e programadores ].

Não desenhei um fluxograma clássico desde a minha primeira aula de programação em 1976, e não vejo mais ninguém criar um desde o início dos anos 80. Os fluxogramas foram úteis para comunicar a lógica do programa quando o código estava na linguagem assembly. No final dos anos 60, os programadores de linguagem assembly estavam usando pseudo-código. Ao programar em linguagens OO modernas, nem os fluxogramas nem o pseudo-código têm valor. Você também pode escrever código de alto nível na linguagem de implementação.

Ocasionalmente, desenhei diagramas UML, principalmente no papel, para expressar idéias de design, mas esses diagramas permanecem apenas até o final da discussão. Também desenhei diagramas de transição de estado de tempos em tempos e os converto em uma tabela de estados na linguagem de implementação.

Eu uso fluxogramas o tempo todo por vários motivos:

1. Eles são melhores que os diagramas de casos de uso UML na minha opinião. Eles podem refletir vários casos de uso diferentes e como eles interagem, e fazem um trabalho melhor em geral, reunindo a experiência e as decisões do usuário.

2. Eles são mais fáceis de entender e mais intuitivos. Sua mente segue naturalmente as flechas como um labirinto do começo ao fim. Você pode usar fluxogramas para finalizar e fazer referência a outro fluxograma para uma história de usuário diferente. Normalmente, posso imprimi-los em um livro numerado de página e virar rapidamente as páginas para navegar para o próximo fluxograma.

3. Eles são universais. Poucas pessoas fora da engenharia de software conhecem e entendem os diagramas UML, onde os diagramas de fluxograma são muito mais reconhecíveis pelos usuários e analistas de negócios. Eu tento comunicar casos de uso complexos a um cliente e, às vezes, eles tentam entender, eu traço um fluxograma para eles e eles entendem por que finalmente entendem todas as nuances que o tornam MUITO MAIS complexo do que eles pensavam.

Os fluxogramas são úteis quando as coisas precisam ser feitas em uma ordem específica. Onde eles realmente brilham em minha mente é mostrar onde as decisões são tomadas e garantir que cada decisão possível tenha um caminho. Isso evita a criação de programas onde é necessária uma aprovação do mamager, mas não há como lidar com ela se o gerente (que aprova 98% do tempo) diz não. Eles nos lembram que o caminho mais comum não é o único caminho. Acho-os úteis ao conversar com os usuários sobre requisitos, porque geralmente eles apenas indicam o caminho mais comum.

Os fluxogramas podem ser úteis para engenharia reversa de código muito mal estruturado. Especialmente se tiver gotos. Felizmente, eu não vi muito código goto-riddden recentemente.

Como outros observaram para se comunicar com os usuários finais. Classifico a inicialização de um transmissor de TV documentado por fluxograma. O pessoal de hardware e software tinha uma especificação comum para trabalhar.

O diagrama de atividades e o fluxograma da UML são úteis para mostrar a complexidade de baixa a média de um processo ou algoritmo.

Eles são muito bons ao se comunicar com usuários de negócios sobre regras de negócios.

Existe uma variação no formato do BPMN 2.0, que é muito útil no Business Process Modeling.

Algumas ferramentas BPMN podem gerar aplicativos da Web em execução a partir de gráficos.

Portanto, sim, os fluxogramas ainda têm um lugar, mas precisam ser usados ​​com sabedoria.

Eu não sou um programador. Eu sou um técnico de engenharia de hardware.

Faz sentido para mim, pelo menos, começar com comentários explicando os blocos lógicos que serão usados. Depois disso, aprimorando o esqueleto do programa com o código real. É semelhante a iniciar um script de filme com um storyboard e, em seguida, preencher os detalhes da ação e o diálogo posteriormente.

Nenhum empreendimento que valha a pena deveria ser cuidadosamente planejado? Na área de hardware, começamos com um documento de requisitos do cliente, depois escrevemos um documento de especificação de hardware, detalhamos o esquema, depois desenhamos um layout de quadro e, em seguida, apresentamos a documentação de montagem. Nós não apenas começamos a pegar as peças e soldá-las juntas, pois temos idéias para criar o produto final.

Não vejo como código eficiente pode ser gravado em um programa de 15 KB ou 15 MB sem muito trabalho de preparação antes de iniciar a codificação real.