Medo de o aplicativo da web não ser "à prova de futuro"

Sou desenvolvedor web de um pequeno aplicativo Web SaaS local. Atualmente, possui cerca de meia dúzia de clientes.

À medida que continuo projetando o aplicativo, fica cada vez mais difícil me convencer a comprometer-me a qualquer momento com o projeto, o que aconteceu na fase inicial. Tendo ficado apegado ao projeto e ao código que eu já escrevi, tenho medo de que todo o trabalho adicional que eu comprometo seja revertido em um futuro próximo, quando o aplicativo acabar não sendo bem dimensionado à medida que a empresa cresce.

Como estudante universitário que se candidatou a estágios, os empregadores questionaram minha escolha por não usar estruturas da web durante as entrevistas, o que só me levou a duvidar ainda mais do meu trabalho anterior. Simplesmente não conheço nenhuma estrutura da Web e não sei qual começar a usar.

Consegui um estágio como desenvolvedor full-stack em janeiro, onde começarei a aprender estruturas front-end, mas a pressão para concluir o aplicativo está aumentando, e estou pensando em abandoná-lo completamente e começar de novo, o que já fiz antes. Atualmente, o aplicativo é construído em PHP e jQuery (para chamadas AJAX) e usa o MySQL como banco de dados. Alguma idéia de como posso superar esse bloqueio mental e garantir que meu aplicativo seja escalável? Desde já, obrigado.

Perfeito é o inimigo do bem.

Ou, dito de outra maneira, não se preocupe com isso hoje. Se o seu aplicativo faz o que precisa, tudo bem. É não uma coisa ruim para reescrever partes do software mais abaixo da linha; nesse ponto, você 1) sabe mais claramente o que está tentando criar e 2) sabe quais bits são realmente o gargalo. Você poderia gastar uma quantidade enorme de tempo escrevendo um aplicativo que poderia ser escalado para um milhão de usuários, mas não seria melhor para seus seis clientes atuais do que o que você tem hoje .

Alguma idéia de como posso superar esse bloqueio mental e garantir que meu aplicativo seja escalável?

O cerne da questão não é escalabilidade. O cerne da questão é pensar que você acertará na primeira vez .

Você deve se concentrar em escrever um código limpo. Porque o código limpo maximiza a conveniência quando você (inevitavelmente) precisa alterar algo no futuro. E esse é o objetivo real que você deveria ter.

O que você está tentando fazer agora é tentar pensar no código perfeito para escrever. Mas mesmo se você conseguir fazer isso, quem disse que os requisitos não serão alterados ou que você talvez tenha tomado suas decisões com base em informações incorretas ou falhas de comunicação?

Você não pode evitar cometer erros, mesmo que a culpa não seja sua. Concentre-se em escrever um código no qual é fácil alterar as coisas posteriormente, em vez de esperar escrever um código que você não precisará alterar no futuro.

Tendo se apegado ao projeto e ao código que eu já escrevi,

Eu absolutamente simpatizo com esse sentimento. Mas se apegar ao código que você escreveu é um problema.

A única coisa que deve ser uma constante é o seu desejo de resolver um problema específico . Como você resolve esse problema é apenas uma preocupação secundária.

Se amanhã for lançada uma nova ferramenta que reduz a base de código em 80%, você ficará chateado por não ter mais o código usado; ou você ficará feliz em saber que sua base de código se tornou menor e muito mais limpa / mais gerenciável?

Se o primeiro, você tem um problema: você não está vendo a solução para o código . Em outras palavras, você está focado no código e não está vendo a imagem maior (a solução que ele pretende fornecer).

Estou com medo de que todo o trabalho adicional que eu comprometa seja revertido em um futuro próximo, quando o aplicativo não for bem dimensionado à medida que a empresa crescer.

Esse é um problema diferente para um dia diferente.

Primeiro, você constrói algo que funciona. Em segundo lugar , você aprimora o código para corrigir quaisquer falhas que ainda possam aparecer. No momento, o que você está fazendo é reter a primeira tarefa por medo de ter que fazer a segunda tarefa.

Mas que outra opção existe? Você não pode dizer o futuro . Se você gastar seu tempo pensando em possibilidades futuras, acabará adivinhando de qualquer maneira. Um palpite é sempre propenso a estar completamente errado.

Em vez disso, crie o aplicativo e prove que realmente há um problema. E quando o problema estiver claro, você começará a resolvê-lo.

Dito de outra maneira: Henry Ford nunca construiu um carro em conformidade com os padrões / expectativas de 2018. Mas se ele não tivesse construído o Modelo T, um carro defeituoso para os padrões modernos, ninguém teria começado a usar carros, não haveria indústria automobilística e ninguém teria um carro que eles pudessem tentar melhorar.

Os empregadores questionaram minha escolha de não usar estruturas da web durante as entrevistas, o que só me levou a duvidar ainda mais do meu trabalho anterior.

A parte importante aqui não é qual estrutura você está usando (qualquer empregador que julgue você que não está fazendo o trabalho corretamente). A parte importante aqui é saber o que você está fazendo e por que está fazendo .

Por exemplo, você pode evitar a estrutura existente especificamente, porque deseja aprender por que uma estrutura é útil, fazendo da maneira mais difícil primeiro. Ou você pode estar tentando criar sua própria estrutura.

A única resposta ruim aqui é "não sei", pois mostra a falta de tomar decisões informadas. Essa é uma bandeira vermelha para um empregador.

Simplesmente não conheço nenhuma estrutura da Web e não sei qual começar a usar.

O mesmo problema surge aqui. A solução não é pensar mais, mas agir:

• Pare de pensar na resposta perfeita .
• Escolha uma estrutura. A menos que você tenha uma preferência, escolha uma aleatória. Use um alvo, jogue um dado, jogue uma moeda, escolha um cartão.
• Use-o.
• Você gostou de usá-lo? Havia algo que você achou irritante?
• Veja como evitar esses elementos ruins. Você abusou da estrutura, ou é assim que a estrutura deve funcionar?
• Depois de sentir que tem controle sobre a estrutura (independentemente de você gostar ou não), escolha uma nova estrutura e repita o ciclo.

Para ler mais sobre isso, leia A mentalidade do fazer> a mentalidade do pensamento . O autor explica melhor do que eu.

mas a pressão para terminar o aplicativo está aumentando, e estou pensando em abandoná-lo completamente e começar de novo

A menos que a base de código atual seja uma bagunça absolutamente insustentável; você está tomando a decisão oposta.
Os desenvolvedores geralmente pensam que jogar fora as coisas seria a melhor escolha. É um sentimento muito comum. Mas raramente é a escolha certa.

Jogar código fora e começar do zero é como ficar preso no trânsito a caminho do trabalho, preocupando-se em chegar atrasado ao trabalho (não cumpra o prazo) e, em vez disso, volte para casa e tente dirigir pela mesma estrada novamente. Isso não faz sentido. Você pode estar preso no trânsito, mas ainda está mais perto do trabalho do que quando estava em casa.

Apesar da enorme quantidade de dinheiro que o Facebook e o Google investiram em marketing para convencê-lo do contrário, as estruturas de front-end existem por dois motivos principais:

• Primeiro, descarregando demandas de hardware / rede para operações do lado do cliente, colocando estado e lógica no cliente
• Segundo, pertinente à lógica adicional do cliente necessária para dar suporte ao primeiro ponto, eles fornecem contextos de execução isolados para que você possa inserir o código de outras pessoas em uma página sem quebrar nada.

Provavelmente, você só precisará procurar uma estrutura para resolver esses problemas se o aplicativo for inerentemente estável, se a quantidade de estados do aplicativo que você está salvando no lado do cliente for bastante complexa, se você espera muitos clientes com latência de rede ruim (móvel, ou distante do servidor) ou se houver uma forte necessidade comercial de oferecer suporte a CSS particularmente avançado ou à criação de elemento dinâmico.

O marketing de estrutura quer que você acredite que seu método especial de arquitetura aumenta a velocidade de desenvolvimento e facilita a manutenção. Isso não é verdade para pequenas equipes que trabalham em projetos simples. Isolar o código e organizar as importações pode ajudar uma grande equipe a lançar um produto no mercado mais rapidamente. Isso fornece muito menos para uma equipe de desenvolvimento de uma única pessoa trabalhando em um projeto já funcional.

Você gastará mais tempo aprendendo a ajustar o código funcional existente à estrutura do que implementando recursos, e é bem provável que alguém em algum lugar atualize algo, e o código escrito nessa estrutura deixará de funcionar dentro de 18 meses, a menos que alguém está lá para mantê-lo constantemente.

O Vanilla JS e, em uma extensão menor, mas ainda significativa, do JQuery, não sofrem com esses problemas. Com algumas exceções notáveis, os aplicativos JQuery + AJAX que não dependem de comportamentos específicos do navegador e renunciam às dependências externas onde for adequado, continuam a funcionar 10 a 15 anos depois de terem sido originalmente escritos com alterações muito pequenas.

As estruturas são ótimas para startups típicas que oferecem suporte a aplicativos da Web contínuos, complexos e voltados para o público. Eles permitem que grandes equipes coordenem bem juntas, integrem-se perfeitamente às estruturas de adição de fornecedores e apóiam novos widgets chamativos e paradigmas de design para ajudar você a se manter competitivo.

Nada disso importa para uma pequena ferramenta de software com um público fixo que você está prestes a abandonar. Adotar uma estrutura reduz a velocidade de desenvolvimento à medida que você se adapta a um novo paradigma e apresenta riscos desnecessários de compatibilidade. Manter o código do lado do cliente simples (e idealmente auto-hospedado) significa que a área de superfície do risco de compatibilidade cai significativamente. Os navegadores mudarão, os URLs da CDN deixarão de funcionar, as dependências ficarão desatualizadas - mas ninguém está tocando nesse servidor e ele continuará funcionando bem.

Não adote uma estrutura, a menos que ela resolva um problema arquitetural específico que você tem hoje ou possa prever em breve, e considere abordar essa preocupação por outros meios, se for possível.

A melhor coisa que você pode fazer para "proteger o futuro" do seu aplicativo é seguir as práticas recomendadas no design do seu sistema para maximizar o acoplamento solto e a separação de preocupações. Não há nenhuma parte do seu aplicativo que esteja a salvo de se tornar obsoleta, mas muito você pode fazer para isolar o código que se torna obsoleto pelo motivo X do código que não precisa necessariamente ser afetado pelo X.

No entanto, eu diria que sua preocupação deve ser menor para o crescimento / escalabilidade do seu aplicativo do que a taxa de crescimento de sua própria experiência e recursos. O bloqueio mental que você descreve me soa como aprender estagnação ou consciência de muitas incógnitas conhecidas, sem a estratégia ou as ferramentas para enfrentá-las.

As estruturas não são particularmente adequadas para solucionar o desafio "à prova de futuro", embora possam fornecer orientações iniciais relevantes para os inexperientes, geralmente por meio de padrões de design de alto nível como o MVC. Em vez disso, eles tendem a ser mais úteis como formas de acelerar o desenvolvimento, fornecendo forte coesão e frequentemente à custa de acoplamentos mais apertados. Por exemplo, suponha que você use algum sistema de mapeamento relacional de objetos fornecido pela estrutura em todo o aplicativo para interagir com seu banco de dados, completo com a integração do sistema de armazenamento em cache. Talvez mais tarde você precise mudar para um armazenamento de dados não relacional e agora tudo o que o usa é afetado.

A bagunça que você agora não veio do que você usou, mas onde você a usou (provavelmente em praticamente todos os lugares no back-end). Quanto melhor você ficará se o código que renderiza uma página nunca buscar os dados que renderiza.

Suponha que você queira adicionar algum pequeno widget a uma página que exija scripts e recursos extras para funcionar corretamente. Se você estiver usando uma estrutura, poderá perguntar "Como é que eu quero adicionar as dependências a uma página para essa coisa?" Caso contrário, a pergunta é mais aberta: "Que preocupações técnicas estou abordando que deveriam ser separadas?" Essa pergunta leva mais experiência para responder, mas aqui estão algumas dicas:

• O que aconteceria se amanhã você movesse todos os seus recursos estáticos (scripts, imagens etc.) para um servidor separado, rede de entrega de conteúdo etc. ou tentasse empacotá-los todos juntos para melhorar o desempenho?
• O que aconteceria se você começasse a colocar esse widget em páginas diferentes ou em várias instâncias na mesma página?
• Como você pode começar a executar o teste AB em diferentes versões do widget?

Se nada disso soa esmagadora, então eu sugiro que você deve usar um quadro, por agora, não tanto por causa de seu aplicativo, mas o bem de seu próprio crescimento pessoal. Não necessariamente comece de novo. Em vez disso, use estruturas como currículo para ajudar a orientar a evolução do seu aplicativo.

Existem apenas duas maneiras de aprender. Um é por tentativa e erro, e o outro é aprendendo com a experiência de outros. Tentativa e erro não podem ser eliminados. O desenvolvimento de software é, por sua própria natureza, um campo de aprendizado contínuo e qualquer código que não faça algo novo ou diferente é, por definição, desnecessário. (Em vez disso, use o código que já está escrito.)

O truque é minimizá-lo, buscando proativamente conhecimentos pré-existentes (estratégias, práticas recomendadas e código / bibliotecas / estruturas) ao longo de todas as etapas do processo de desenvolvimento, para que você não se encontre constantemente reinventando a roda.

Quanto ao aplicativo que você está escrevendo, no entanto, sua primeira preocupação deve ser simplesmente fazê-lo com um mínimo de esforço comum (que é como o cheiro do código, mas para o processo de desenvolvimento). Dada a natureza da aprendizagem humana, a maneira mais rápida de obter alta qualidade é começar com algo . É muito mais fácil entender o objetivo quando você pode moldá-lo criticando algo que já possui.

Se você pode aceitar que grande parte do código que você escreve é ​​um processo de aprendizado descartável e necessário para encontrar bons designs, isso o motivará a continuar. Afinal, é o desafio da solução de problemas que torna o desenvolvimento de software envolvente, e esse desafio está sempre presente se o que você está fazendo vale a pena (consulte a declaração de "aprendizado contínuo" acima).

Acima de tudo, "desfazer a coisa e recomeçar" nunca é uma opção ... afinal de contas, você não disse que tem "meia dúzia de clientes?" Você já parou para considerar o que eles podem pensar do seu pronunciamento, já que eles estão agora (presumivelmente) "perfeitamente felizes com o seu trabalho ?!"

Aqui está uma analogia que eu gosto de usar:

• "Meu trabalho é construir casas para as pessoas morarem, pessoas para construir negócios e assim por diante". Meu trabalho é fazer "aqueles pedaços de areia impossivelmente pequenos e super glorificados " para fazer um trabalho útil. (Assim como os construtores de casas criam casas com papelão de gesso, ladrilhos de cerâmica, blocos de concreto e 2 x 4).

• No entanto, enquanto os "pregos" que os construtores de casas usam realmente não mudaram muito em duzentos anos (exceto para passar de "quadrado" para "redondo" e depois serem úteis com máquinas de pregar pneumáticas), a tecnologia o que usamos muda constantemente e às vezes sofre mudanças muito profundas. ("Assim vai.")

• "No entanto, cada casa, uma vez construído, será para sempre-após ser vivido dentro." Você não pode despejá-los. Depois de construí-lo e entregar as chaves, "não é mais a sua casa". É o que é agora e permanecerá por muito tempo.

Uma grande parte da minha empresa atualmente é ajudar os clientes a lidar com o software que foi construído há dez, vinte, trinta ou mais anos atrás, usando as tecnologias "de ponta" que existiam naquele tempo - (e que, ahem, Lembro-me) - e que ainda estão em serviço (!) Hoje.

Garantir que algo é uma prova do futuro é quase impossível. Verificar se o aplicativo é escalável não é muito difícil. Você só precisa escrever um teste de desempenho para o aplicativo e ver quantos clientes ele pode suportar. Escrever testes definitivamente tornará seu aplicativo mais à prova do futuro, porque você poderá avaliar como ele se comportará depois de implementar mais alterações.

No quadro errado, eu não ficaria muito preocupado com o desempenho / escalabilidade. Isso é algo que você pode verificar facilmente e provavelmente corrigir. O maior problema é a segurança. As estruturas da Web geralmente ajudam a escrever código de autenticação adequado, cookies, proteção CSRF, etc. Especialmente devido à sua falta de experiência, concentre-se melhor nessa área.

Comecei a escrever um comentário sobre estruturas de aprendizado, mas acabou se transformando em algo que parecia mais uma resposta, então aqui está.

Não conhecer nenhuma estrutura parece um problema. Em basicamente qualquer trabalho do webdev, você precisará trabalhar com alguma estrutura. Aprender outro quadro depois que você sabe um não é que grande negócio, mas aprender o primeiro pode demorar um pouco - é por isso que os empregadores podem se preocupam com isso. Evitar estruturas pode indicar a síndrome não inventada aqui , que é uma abordagem amplamente impraticável.

Como o ponto principal de conhecer suas primeiras estruturas é aprender um idioma comum, talvez apenas tente aprender algo popular entre seus colegas. Você pode tentar modificar algum projeto simples escrito em uma estrutura. Iniciar um projeto do zero em uma estrutura que você não conhece é uma maneira muito ineficaz de aprender.

Agora, sua pergunta real era sobre um projeto específico e portá-lo para uma estrutura. Para isso, a resposta parece ser: depende, e não podemos realmente lhe dizer. No entanto, transportar coisas para uma estrutura que você não conhece é quase certamente uma má ideia, pois você nem sabe se faz sentido . Portanto, parece que você deve deixar como está e revisitar essa decisão em algum momento, depois de conhecer e gostar de alguma estrutura. Outras respostas contêm bons pontos sobre o que você deve procurar ao tomar essa decisão.

Este artigo chamou muita atenção no Hacker News há 2,5 anos: Escreva um código que seja fácil de excluir, não fácil de estender. Essa perspectiva pode ou não ajudá-lo a lidar com sua base de código atual, mas no futuro, pode ajudar a evitar frustrações resultantes do perfeccionismo / excesso de engenharia.

Se virmos 'linhas de código' como 'linhas gastas', quando excluirmos as linhas de código, reduziremos o custo de manutenção. Em vez de criar software reutilizável, devemos tentar criar software descartável.

Não preciso dizer que excluir um código é mais divertido do que escrevê-lo.

(ênfase minha)

O tópico do artigo no Hacker News também pode valer uma leitura.

No que diz respeito a torná-lo à prova do futuro e aplicar os princípios de escala e estrutura, é uma tarefa difícil a ser assumida por você, provavelmente não me preocuparia com isso, mas se você precisar:

Mantenha seu código limpo, siga os princípios do SOLID, DRY> google.

Aplique um balanceador de carga o mais rápido possível.

Levante pelo menos dois servidores Web, lide com cenários de balanceamento de carga no código.

E por último, mas não menos importante, existem melhores pilhas para lidar com um milhão de usuários do que o LAMP, mas tenho certeza que é totalmente factível.

Caso e argumento, consulte: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade O ponto é válido, mas 10gb é trivial como sujeito de teste.