Ao criar um aplicativo não trivial, é melhor se concentrar em fazer as coisas funcionarem rapidamente e em tomar atalhos no código, como misturar a lógica do modelo com suas visualizações, quebrar o encapsulamento - o cheiro típico do código? Ou, é melhor você dedicar um tempo adiantado para construir mais arquitetura, construí-la corretamente, mas correndo o risco de que todo esse código extra não seja usado, já que seu design é bastante fluido e você pode ter que jogá-lo fora se o feedback causar ir em uma direção diferente?

Por contexto, estou criando um aplicativo de desktop. Sou o único desenvolvedor e faço isso em part-time, pois tenho um emprego diário. Agora, para o trabalho, tento fazer as coisas da maneira certa, com a programação permitida. Mas, para este projeto, que espero se transformar à medida que receber feedback das pessoas, não tenho certeza de que seja a abordagem correta. Passei várias horas esta semana colocando em prática o design de um Model View Controller para comunicar alterações no modelo à visualização. Isso é ótimo em geral, mas não tenho certeza se preciso de várias visualizações para exibir os dados e sei que poderia ter as coisas exibidas mais rapidamente sem a arquitetura adicional. Com cerca de 10 a 15 horas por semana para gastar no projeto, acho que levará muito tempo para criar algo que eu possa demonstrar se seguir as boas práticas de software. Eu sei que meus usuários venceram ' Não importa se eu usei MVC internamente, eles só querem algo que resolva seu problema. Mas também estive na situação em que você incorreu em tanta dívida técnica por atalhos que o código é incrivelmente difícil de manter e adicionar novos recursos. Eu adoraria ouvir como outras pessoas abordam esse tipo de problema.

Construa bem .

Construí-lo "rápido" é uma falácia lógica, se você olhar para o quadro geral. Isso impedirá que você o construa bem e, eventualmente, você ficará atolado por bugs e falhas fundamentais da arquitetura que impedem a refatoração ou até tornam quase impossível adicionar novos recursos.

Construir bem é, na verdade, o oposto. No início, pode ser mais lento, mas, eventualmente, você perceberá os ganhos de eficiência ao dedicar algum tempo para fazer as escolhas certas com antecedência. Além disso, você poderá se adaptar a requisitos futuros com mais facilidade (refatoração, se necessário) e terá um produto final melhor devido, no mínimo, a menos bugs.

Em outras palavras (a menos que seja um contrato único), construa-o rapidamente = construa-o lentamente, construa-o bem = construa-o rapidamente .

Também há algo importante a ser percebido sobre "construí-lo bem" e projetar uma arquitetura. Você perguntou...

... mas correndo o risco de todo esse código extra não ser usado, pois seu design é bastante fluido e você pode ter que jogá-lo fora se o feedback o levar a uma direção diferente?

Esse não é realmente um risco real de "gastar tempo com a arquitetura". O design da arquitetura deve ser orgânico . Não gaste tempo projetando uma arquitetura para qualquer parte até que seja justificada. A arquitetura deve evoluir apenas de padrões observados e confirmados no seu projeto.

A lei de John Gall da Systemantics :

Um sistema complexo projetado do zero nunca funciona e não pode ser corrigido para fazê-lo funcionar. Você precisa começar de novo, começando com um sistema simples e funcional.

Rápido, então bem

Isto é da minha experiência pessoal, tendo tentado muitos métodos diferentes.

O problema de apenas trabalhar rápido (e liberar) geralmente é que você aderirá recurso após recurso ao seu aplicativo e, uma vez lançado, é muito difícil fazer alterações fundamentais em seu programa. Você paga um preço alto a longo prazo por nada ter uma arquitetura subjacente sólida, é como construir uma ruína em areia movediça.

O programa para fazê-lo bem é que você vai perder muito tempo e código. É como construir uma mansão sem plantas. Escrever aplicativos é um processo de aprendizado e quase (na minha experiência) impossível de projetar com antecedência. Isso significa que você fará muita refatoração e, se você escrever tudo "bem" o tempo todo, acabará jogando muito código.

Portanto, rápido, então tudo bem!

A principal coisa quando você começa é apenas colocar tudo no código, para definir todos os recursos e ver que tipo de arquitetura você precisa suportar. Outra coisa boa dessa metodologia é que eu vou mantê-lo motivado, pois você rapidamente terá algo em execução. Também é importante implementar algumas funcionalidades "de ponta", pois isso terá impacto na sua arquitetura geral. Não se preocupe em escrever testes de unidade ou trabalhar em detalhes nesta fase. Se você acha que precisará oferecer suporte a vários idiomas no futuro, uma arquitetura de plug-in de outros enfeites, implemente-a, mas rápida e suja. Faça alguma refatoração para manter o aplicativo gerenciável, mas nada excessivo.

Depois que você sentir que possui um "protótipo" funcional, é hora de começar a refatorar. Basicamente, você deseja refazer o aplicativo como faria se tivesse iniciado do zero sabendo tudo o que sabe agora. O importante é acertar a arquitetura , não reimplementar todos os recursos que você fez na fase um, mas você deve ter a arquitetura instalada para suportá-la posteriormente.

Dessa forma, você terminará com um aplicativo com uma arquitetura de som da maneira mais eficiente possível, de qualquer maneira, na minha experiência :)

Construa

Rápido se o tempo de colocação no mercado for mais importante que a qualidade

Bem, se a qualidade é mais importante que o tempo de lançamento no mercado

Construí-lo rapidamente trará benefícios a curto prazo e perdas a longo prazo.

Construir bem resultará em perdas de curto prazo, mas em benefícios a longo prazo.

Construí-lo bem exige paciência e sabedoria, mas você será recompensado.

Construí-lo rapidamente é bom apenas para prototipagem rápida e coisas descartáveis. Objetivos de longo prazo só podem ser alcançados com a atitude correta desde o início.

Para projetos que você planeja distribuir para uso de outras pessoas, sempre erro no lado do trabalho inicial. Uma arquitetura bem pensada é mais fácil de estender, se necessário. Tomar atalhos é apenas o modelo para acumular dívida técnica.

Às vezes, pode ser frustrantemente lento. Coisas que valem a pena valer a pena.

Construindo bem = construindo rápido

Os atalhos tendem a se virar e morder você ainda mais rápido do que você pensa. Às vezes até antes do almoço.

Sobre o seu contexto; não abstraia imediatamente. Atenha-se ao YAGNI e remova a duplicação. Implemente esse padrão com base em modo de exibição quando você realmente tem uma segunda visão, não porque acha que pode ter uma no futuro. Quando essa segunda visualização chega, a abstração criada é geralmente muito melhor do que a que você teria feito em torno dessa primeira ocorrência.

Bem, se você já sabe o que está fazendo, rápido, se não souber

Sou cientista pesquisador e escrevo muito código exploratório antes de ter alguma idéia de qual é o panorama geral ou como o projeto será desenvolvido. Nesses casos, é difícil até ver como "bem" deve ser definido. Além disso, geralmente é difícil ver todos os pequenos detalhes e maneiras pelas quais as coisas podem ser estendidas antecipadamente. Portanto, o velho ditado se aplica:

1. Faça funcionar.
2. Faça certo. Fazer o segundo certo tem a vantagem de que você pode definir melhor "certo" depois de ter a experiência de fazê-lo funcionar.

Construa-o bem .. sempre, mas dê a ilusão de ir rápido

mas para torná-lo rápido, apenas diminua. Crie um pequeno subconjunto do todo suficientemente significativo para obter feedback. A adição progressiva a ele em um ritmo constante trará praticamente o mesmo benefício de construir rápido, sem vender sua alma à reação em cadeia de noites sem dormir, brincando de bosta.

Eu acho que sempre deve ser "construído bem". Se o tempo de lançamento no mercado for uma grande preocupação, use um processo de desenvolvimento incremental. No pior cenário, você possui um produto com menos recursos, mas pelo menos possui um produto de alta qualidade que pode ser estendido em versões futuras de recursos.

Equilibrar

Não é prático projetar seu código com perfeição ou misturar alguns códigos em um instante, não é? É realmente sobre encontrar o equilíbrio certo. O que importa na minha opinião é o que você faz quando.

Acho que o mais importante aqui é garantir absolutamente que o núcleo do aplicativo, a estrutura fundamental, seja construído muito bem. Estanque ao ar. Uma vez que isso seja alcançado, dependendo das restrições de tempo, se você tiver pouco tempo, poderá reunir algum código e redistribuí-lo mais tarde, e poderá adquirir esse luxo porque teria tomado o cuidado de obter a base certo, e não faria mal em re-fatorar o código.

Faça a coisa mais simples que possa funcionar. No seu caso particular, seu programa não se tornará muito grande, sendo você a única pessoa trabalhando nele em período parcial. Eu não estou defendendo maneiras ruins, como ir ao abuso, nomes de variáveis ​​indefinidos etc., mas você não deve torná-lo mais complexo do que deve ser. Talvez o MVC seja apenas um exagero para o seu projeto em particular.

que espero que se modifique à medida que recebo feedback das pessoas

Você mesmo disse:

Mas também estive na situação em que você incorreu em tanta dívida técnica por atalhos que o código é incrivelmente difícil de manter e adicionar novos recursos.

Se você tiver pouco tempo, não tenha medo de pedir mais tempo para concluir o projeto do seu empregador usando o mesmo raciocínio. Tenho certeza que eles concederão a você. Dito isto, entendo como às vezes pode parecer frustrante trabalhar tanto em algo e não ser capaz de mostrar muito resultado. Mas não se preocupe, você chegará lá, e construí-lo bem certamente valerá a pena quando você o fizer.

Normalmente, gosto de construir bem a estrutura e economizar tempo não me preocupando com detalhes específicos da implementação. Como você diz, eles vão mudar de qualquer maneira. A idéia por trás da construção de uma subestrutura bem feita é que as mudanças podem acontecer muito rapidamente, uma vez que a base seja construída. Tento me concentrar em ser o mais genérico possível em minhas aulas e torná-las reutilizáveis ​​sempre que possível. Normalmente, dou ao usuário um aplicativo bem construído que satisfaz apenas os requisitos mais básicos de usabilidade. Os usuários recebem todos os tipos de Idea quando uma ferramenta está disponível, então não adianta pensar muito à frente.

Construa bem . Se você não tiver tempo, reduza o conjunto de recursos.

Projete o mais universal possível. Por exemplo, projete uma arquitetura de plug-in, mesmo que você saiba, apenas um plug-in será usado pela primeira vez. Use esquemas de configuração universal (configuração extensível, linguagem de organização), mesmo que haja apenas um parâmetro no começo. É um investimento muito bom , e você pode fazer esse investimento apenas no início do projeto.

é melhor se concentrar em fazer as coisas funcionarem rapidamente e tomar atalhos no código, como misturar a lógica do modelo com suas visualizações, quebrar o encapsulamento - o cheiro típico do código? Ou você está melhor aproveitando o tempo para construir mais arquitetura

Em meus ouvidos, do jeito que você coloca lá, você está listando os dois extremos. A primeira opção, quebrar o encapsulamento, colocar a lógica do modelo nas visualizações, é apenas uma programação preguiçosa. IMHO, resolver esses problemas não é o mesmo que colocar mais arquitetura. Talvez, a menos que você esteja falando, o código da interface do usuário esteja executando instruções SQL. Mas então eu não diria que constrói mais arquitetura, então eu diria que você tem uma completa falta de design e arquitetura e deve obter uma.

No que diz respeito à arquitetura, eu escolheria a mais simples que soluciona seu problema agora e depois expandia à medida que surgissem problemas.

Por exemplo, é do que você precisa agora para ter a funcionalidade de retornar dados de uma única tabela de banco de dados, não me preocuparia com problemas como carregar dados de tabelas relacionadas, mesmo sabendo que o problema acabaria surgindo. Eu começaria a me preocupar com isso quando implementasse essa funcionalidade.

Portanto, para meus próprios projetos de desenvolvimento doméstico, eu adotaria a seguinte abordagem: Crie a solução mais simples possível que resolva o problema com o qual estou trabalhando agora, mas crie-a bem. Eu refatoraria a solução à medida que mais complexidade fosse necessária. As práticas TDD a seguir tornam a refatoração segura e também ajudam a evitar odores de código (é difícil criar bons testes de unidade, se você estiver quebrando o encapsulamento).

Aliás, essa é também a abordagem adotada ao trabalhar profissionalmente. ;)

Eu recomendaria que primeiro você levantasse o software, cubra todos os aspectos e o suporte primeiro e gradualmente decore e melhore seu desempenho

Você geralmente quer estar no meio dessas duas arestas:

Construa-o bem = software em tempo real, essencial para a vida, do qual a vida das pessoas depende. ou seja, controle de software: reatores nucleares, máquina de diálise, máquinas de ressonância magnética , etc.

Crie rápido = software inútil que ninguém realmente usa.