Como concluir um projeto de software de forma simples?

O processo de desenvolvimento de software pode ser visto como um conjunto de atividades organizadas para definir, desenvolver, testar e manter software. Aqui estão alguns objetivos do processo de desenvolvimento:

definir as atividades a serem executadas;
quando uma atividade deve ser realizada;
o indivíduo ou grupo que realiza tais atividades;
Padronização durante o desenvolvimento.
desenvolvimento de software

Existem vários processos de desenvolvimento de software, mas a maioria dos processos existentes compartilham algumas atividades básicas, algumas das quais serão descritas neste artigo, como: levantamento de requisitos; análise de requisitos; projeto; execução; testes; implantação.

Era para ser só mais um projeto de software

O projeto de software parecia viável e muito promissor (até simples) no início, mas se tornou aquele que todos evitavam; ou trabalhavam reclamando e se arrastavam pelo teclado.

Solicitar alteração de item? sair da empresa? Mudar de carreira? Ou aprender com os erros do passado e não repeti-los?

Todos devem ter uma compreensão clara do escopo de um projeto de software

Quando um projeto de software é apresentado a uma equipe, nem sempre ele explica de forma clara e objetiva qual problema ele resolve, ou como vai resolver o problema.

É errado explicar o que o sistema vai fazer, mas não por que ele está fazendo isso e como ele pode ajudar a resolver problemas do mundo real.

No projeto de software de um sistema, quanto mais estruturada e previsível for a informação, melhor porque é mais simples.

Mas no mundo real, eventos e informações viajam de maneiras inesperadas e não estruturadas. Em outras palavras, é um ecossistema complexo.

É por isso que é importante que as equipes entendam o que está sendo abordado e como, para que possam criticar, aconselhar e imaginar gargalos futuros com os quais terão que lidar com antecedência.

Isso evita reunir estruturas de dados ou relacionamentos de classe que precisam ser modificados no meio do projeto no início do projeto, o que pode se tornar difícil.

Porém, se você não é um gerente de projetos e não tem um líder que valorize esse tipo de comunicação clara em primeiro lugar, tente se questionar e estudar a documentação disponível para entender melhor o projeto de software.

Seja um MVP e depois melhore

Comece fornecendo um front-end navegável onde os dados são processados ​​apenas no JavaScript do navegador.

Antes de prosseguir com as estruturas de dados e classes, é necessário saber, de fato, se o que se entende é o que o cliente realmente deseja transmitir.

Com um front-end navegável, os clientes podem até mudar de ideia no meio do processo.

Como resultado, muito trabalho de desenvolvimento potencialmente desperdiçado é poupado.

Concluído o front end, o cliente pode colocar o dedo na tela e dizer: “Quero esse botão do outro lado, em outra cor e com outro texto”.

Depois que o frontend for validado, implemente-o no backend.

Tente entregar uma versão executável de um projeto de software em que a funcionalidade principal funcione e tenha regras de negócios mínimas para navegar.

Em seguida, implemente regras de negócios mais complexas e, finalmente, regras de validação e disponibilidade.

De todo a parte

Ao desenvolver um componente, seja uma classe ou uma função, não tente implementar todas as melhores práticas desde o início.

Parece bobagem, mas não é.

Primeiro crie uma classe genérica onde você possa visualizar tudo o que o componente faz em um só lugar.

Assim, você pode fazer um mapa temático, ver como as partes se encaixam, categorizar e nomear as partes.

Em seguida, consolide e melhore.

Distribua o código em classes menores que representam etapas do processo e métodos que representam etapas do processo.

Dívida técnica ou sujeira debaixo do tapete

Um rascunho não equivale a uma solução final a ser revisada. Precisamos entender que código com alto débito técnico não deve ser enviado.

Quero destacar duas questões principais com a dívida técnica.

Comunicação ineficiente em design de software

Se uma classe, método ou função for mal escrita e mal comentada, até mesmo seus autores podem não entendê-la no futuro.

Ou se for muito grande e complexo, pode não ser possível decompô-lo e torná-lo mais simples.

Um projeto com o código não performático

No rascunho, as consultas ao banco de dados podem ser feitas em um loop ou em um loop. Mas se for para produção, pode demorar um pouco para ser detectado.

Se o baixo desempenho ocorre apenas quando há vários logs independentes e são poucos, pode ser que o log não indique claramente que a lentidão do sistema se deve a uma implementação de bugs muito específica feita às pressas.

Definir prioridade

Alguns gerentes de projeto de software ou clientes costumam dizer que “tudo é prioridade”.

Ele pode estar certo. Mas ninguém faz tudo ao mesmo tempo ou ao mesmo tempo.

Algumas etapas só podem ser entregues após a conclusão das etapas anteriores.

Portanto, se você estiver em uma situação em que um cliente ou gerente priorizou mais de uma coisa, faça a pergunta matadora:

Não é que outras pessoas não façam isso, é que as pessoas não conseguem pensar com clareza quando estão estressadas.

Você pode ajudá-los agora.

Classes e métodos específicos e independentes

Às vezes parece mais fácil escrever uma classe que faz muitas coisas ou um método genérico com muitos parâmetros, auto-ajustável e “inteligente”.

Esta não é uma boa prática.

É melhor criar uma classe para cada coisa e um método para cada etapa.

Em vez de passar vários parâmetros em um método, instancie um objeto em vários lugares e chame cinco métodos em sequência.

Por exemplo, é melhor e mais simples chamar:

Às vezes parece mais fácil escrever uma classe que faz muitas coisas ou um método genérico com muitos parâmetros, auto-ajustável e “inteligente”.

Esta não é uma boa prática.

É melhor criar uma classe para cada coisa e um método para cada etapa.

Em vez de passar vários parâmetros em um método, instancie um objeto em vários lugares e chame cinco métodos em sequência.

Por exemplo, é melhor e mais simples chamar software:

Mais complicado e obscuro do que usar a tabela abaixo

Faça funcionar primeiro, depois se precisar automatizar

Ouvimos tanto sobre o princípio DRY (não se repita) que achamos que qualquer coisa pode ser componentizada ou automatizada.

Mas isso deve ser considerado

Quando um conjunto de chamadas ocorre várias vezes, mas de maneiras muito diferentes ou com estruturas de entrada ou saída muito diferentes, é melhor manter o antigo copiar e colar

Pode ser muito caro manter um processo automatizado que apenas um gênio da computação pode manter porque qualquer iniciante pode resolvê-lo de maneira mais fácil.
Se a automação ou componentização é realmente estratégica para o negócio, ela deve ser feita em partes

Automatize primeiro as peças mais fáceis e previsíveis, testes e integração. Só assim a evolução incremental pode ser realizada.

Pronto, seu projeto de software será diferente! Que bom

No final, aprendemos que todo projeto de software, por mais simples que pareça, tem pelo menos um pouco de complexidade.

Portanto, aprender a resolver gargalos de maneira fácil é o que separa o programador médio do desenvolvedor profissional.

A varanda acima pode não parecer um grande segredo à primeira vista. Mas com prática e experiência, você descobrirá que os resultados podem variar muito.

Espero ter ajudado no desenvolvimento de sua carreira.