Como evitar a reescrita de partes de um aplicativo

Estou trabalhando em uma empresa em um projeto para o departamento de vendas. É o meu primeiro trabalho de programação profissional, mas eu tenho codificado sozinho e aprendido há anos. Parte do projeto envolve pegar alguns dados e combiná-los com dados para produzir e representar graficamente. Em seguida, salve os dados ... e assim por diante. Então, eu escrevi o código para isso em pouco menos de um dia. No dia seguinte, mostrei meu supervisor de projeto e ele gostou, mas "e se tivéssemos isso", e queria que eu acrescentasse algo ao gráfico. Não foi uma grande mudança na aparência ou na função do programa, mas mudou drasticamente a maneira como eu precisava armazenar dados, processá-los etc.

Novamente, demorei um dia para reestruturar a tabela do banco de dados e reescrever o código basicamente do zero para dar suporte a essa nova solicitação. Levei de volta para ele novamente, e exatamente a mesma coisa aconteceu. Ele solicitou outra coisa que mudou drasticamente a forma como eu precisava processar os dados. Então, eu tive que reescrevê-lo novamente. Finalmente, ele assinou o contrato e, esperançosamente, não precisarei reescrevê-lo novamente.

Apenas fique claro, não estou atacando meu gerente ou algo assim. Ele é um cara legal e as coisas que ele estava solicitando não estavam fora deste mundo, eram apenas incompatíveis com o que eu havia feito anteriormente.

Só estou me perguntando se há algo que eu possa fazer no futuro para evitar reescritas completas. Entendo criar código flexível e estava tentando fazer isso, mas gostaria de saber sobre práticas ou coisas que eu poderia ter feito de maneira diferente para tornar isso mais fácil, para que, no futuro, não passe três dias em algo que deveria ter tomado 1.

Como eu comentei, tenho uma forte sensação de que os requisitos não foram claros na primeira vez ou provavelmente você perdeu alguns detalhes importantes.

Nem tudo pode ser tratado com melhores códigos, práticas recomendadas, padrões de design ou princípios de POO. Nenhum deles impedirá que você refaça o aplicativo inteiro se a implementação for baseada em suposições falsas ou premissas erradas.

Não se apresse em codificar a solução. Antes de digitar um único LOC, dedique algum tempo a esclarecer os requisitos. Quanto mais fundo você aprofundar os requisitos, mais o que se questões aparecem. Não espere o gerente surpreendê-lo com o próximo caso . Antecipe as coisas você mesmo. Este pequeno exercício pode reduzir significativamente o fator surpresa .

Não tenha medo de perguntar quantas vezes precisar. Às vezes, as árvores (detalhes) não nos deixam ver a floresta (a imagem geral). E é a floresta que precisamos ver primeiro.

Quando os requisitos são claros, é mais fácil tomar melhores decisões durante a fase de design.

Finalmente, lembre-se de que a imagem geral é uma meta. O caminho para esse objetivo não é claro nem direto. As mudanças continuarão a acontecer, portanto, seja ágil.

Não há como saber isso com base no que você deu. É mais rápido e sujo, e é disso que você precisa naquele momento. Mas então alguém gostou e está ficando complexo, então agora você está começando a ver que muitos problemas não aparecem até que a complexidade se manifeste. Há tantas coisas diferentes que podem ser feitas que é simplesmente avassaladora.

Existe o velho "No Silver Bullet", e é verdade. Novamente, não há como saber o que fazer com as especificações completas (ou melhores especificações contínuas do Agile) e a capacidade de usar bons princípios de programação e bons projetos. Os programadores adoram reescrever uma e outra vez . Não estou dizendo que você se enquadra nisso necessariamente por causa disso, neste momento, é pequeno.

Use esta oportunidade para aplicar alguns princípios básicos. Você descobrirá que eles funcionam, mas então alguém dirá: "Oh, não, isso é ruim" ou você terá outra coisa que quiser. Você não pode fazer tudo com o dinheiro da empresa, mas se eles lhe derem tempo para explorar, use-o como uma oportunidade. Há sempre alguém, algum fundamento, alguma pessoa, que tem o "melhor" maneira ou de alguma forma "nova" de fazer as coisas.

Seu gerente provavelmente estava certo em cada uma das etapas que você realizou. Não é porque ele é o gerente, mas porque ele está considerando os resultados, a usabilidade e provavelmente o número de transações anteriores com clientes ou solicitações de clientes.

A interface do usuário é difícil, geralmente, 5 pessoas têm 15 visualizações diferentes. E a estruturação e análise de dados e dados tendem a mudar e se multiplicar pelo fator 10 :). A interface do usuário é como moda, algumas combinações são legais, algumas são terríveis ou faltam ao bom senso.

Sem mencionar que, por exemplo, durante o processo LEAN, nada é imutável. Você está experimentando algo como avaliação iterativa e, durante cada etapa, é pouco melhor ou o caminho errado é evitado.

A resposta é tão simples que não existe reescrita.

O desenvolvimento iterativo (que é o que você fez basicamente, embora as iterações de um dia) geralmente é assim. As primeiras tentativas de soluções costumam ser errôneas e, ao obter feedback, o sistema converge para uma solução. Emprestarei a Figura 2.2 do material do instrutor de Craig Larman para o seu livro Aplicando UML e Design Patterns .

No início de um projeto, você aprende a conviver com as aparentes versões instáveis. Discordo das respostas que dizem "você precisa obter mais requisitos desde o início", porque esse é o pensamento do Waterfall. É verdade que você deve se esforçar para obter o máximo possível em termos de requisitos, mas por muitas razões, não é possível ter requisitos completos e precisos.

Isso não quer dizer que você não pode reduzir o quanto precisa reescrever depois de receber feedback. Uma coisa que costuma ser verdadeira é que é muito provável que a interação humano-computador do software mude, porque essa é uma parte difícil de acertar na primeira vez.

Pense no Microsoft Word e como seu formato de dados (.doc) não evoluiu muito ao longo dos anos. Isso ocorre porque um documento de texto como domínio de problema realmente não evoluiu muito (uma página ainda é uma página, um parágrafo ainda é um parágrafo etc.). No entanto, a interface do usuário do Word evoluiu muito (e continua a). O código da apresentação ou entrada tende a ser instável entre as versões; portanto, é melhor não ter as outras partes do sistema acopladas diretamente a elas (para isolá-las da reescrita).

As arquiteturas de software que podem separar a apresentação da lógica subjacente e os dados sobre o problema permitem menos reescrições. Muitos padrões de software, como a separação do Model-View, surgiram por causa de pessoas como você, que sofreram muitas reescritas e procuraram uma maneira melhor.

Isso pode parecer muito budista, mas você tem sorte de ter sofrido essas reescritas! Muitas pessoas aprendem sobre padrões MVC ou outros padrões de design sem "sofrer" os pesadelos de reescrita que os padrões devem evitar.

Não tenho uma resposta, mas um exercício - que você provavelmente terá que fazer no seu próprio tempo, embora, dependendo da sua organização, você possa obter permissão para fazê-lo durante o horário de trabalho.

Redesenhe sua primeira solução para fazer exatamente o que fez, mas facilite a adição das 2ª, 2ª e 3ª etapas. Não adicione essas etapas, não as remova. Basta criar uma solução que atenda a todos os requisitos originais, mas possa ser facilmente atualizada para incluir o novo recurso. Faça o mesmo para a sua segunda solução.

Os requisitos mudam, isso é um fato da vida. Em retrospecto: a primeira solução poderia ter sido diferente para que o tempo total de programação fosse menor? É isso que você aprende a fazer com a experiência.

Essa é a primeira curva de aprendizado acentuada. Quando você gerencia isso, haverá o segundo desafio: como você lida com os requisitos alterados quando os usuários armazenam um ano de dados que eles não desejam jogar fora?

A partir da sua história, é óbvio que os requisitos e as decisões arquiteturais preferidas não foram comunicados suficientemente bem. Portanto, um de vocês, ou talvez ambos, são maus comunicadores.

Pode ser o arquiteto também, já que alguns arquitetos conquistam o status alto por boas realizações ao programar sozinhos, ou por uma excelente educação (que também costuma ser estudada sozinha) ou por ser o primeiro desenvolvedor da empresa (obviamente sozinho) e não é necessário bom em comunicação com a equipe. Não é incomum que eles continuem se concentrando muito na programação, em vez de documentar projetos e apoiar a equipe.

No entanto, também neste caso, você pode tentar compensar conversando mais, fazendo perguntas e fazendo anotações. Você pode até escrever uma especificação pequena e pedir ao arquiteto que a aprove.