Sou um desenvolvedor web de um aplicativo da web SaaS local pequeno. Atualmente, tem cerca de meia dúzia de clientes.
À medida que continuo a projetar o aplicativo, fica cada vez mais difícil para mim convencer-me a comprometer-se com o projeto, o que aconteceu na fase inicial. Tendo me apegado ao projeto e ao código que já escrevi, estou com medo de que todo o trabalho adicional que eu fizer seja revertido em um futuro próximo, quando o aplicativo acabar não se ajustando bem à medida que o negócio cresce.
Como um estudante universitário solicitando estágios, eu tive empregadores questionando a minha escolha em não usar qualquer estrutura web durante as entrevistas, o que só me fez duvidar ainda mais do meu trabalho anterior. Eu simplesmente não conheço nenhum framework web, e não sei qual começar a usar.
Eu consegui um estágio como desenvolvedor de pilha completa em janeiro, onde começarei a aprender estruturas de front-end, mas a pressão para concluir o aplicativo está aumentando, e estou pensando em descartar o aplicativo completamente e começando de novo, o que é algo que eu fiz antes. O aplicativo atualmente é construído em PHP e jQuery (para chamadas AJAX) e usa o MySQL para seu banco de dados. Alguma idéia de como posso superar esse bloqueio mental e garantir que meu aplicativo seja escalonável? Agradecemos antecipadamente.
Ou dito de outra forma, não se preocupe com isso hoje. Se o seu aplicativo faz o que precisa fazer, tudo bem. Não é uma coisa ruim reescrever partes do software mais adiante; nesse ponto você 1) sabe mais claramente o que você está tentando construir e 2) sabe quais bits são realmente o gargalo. Você poderia gastar uma quantidade enorme de tempo escrevendo um aplicativo que chegaria a um milhão de usuários, mas não seria melhor para seus seis clientes atuais do que o que você tem hoje .
Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
O ponto crucial do problema não é escalabilidade. O cerne da questão é pensar que você vai acertar na primeira vez .
Você deve se concentrar em escrever código limpo. Porque código limpo maximiza a conveniência quando você (inevitavelmente) tem que mudar alguma coisa 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 diz que os requisitos não vão mudar ou você talvez tenha tomado suas decisões com base em informações erradas ou falhas de comunicação?
Você não pode evitar cometer erros, mesmo que não seja sua culpa. Concentre-se em escrever códigos nos quais é fácil mudar as coisas mais tarde, em vez de esperar escrever código que não será necessário alterar no futuro.
Having grown attached to the project and the code I've already written,
Eu absolutamente simpatizo com esse sentimento. Mas ficar ligado ao código que você escreveu é um problema.
A única coisa que deve ser uma constante é seu desejo de resolver um problema específico . Como você resolve esse problema é apenas uma preocupação secundária.
Se amanhã uma nova ferramenta for lançada que reduza sua base de código em 80%, você ficará chateado por seu código não ser mais usado; ou você vai ficar feliz que sua base de código se tornou menor e mais limpa / mais gerenciável?
Se o primeiro, você tem um problema: você está não vendo a solução para o código . Em outras palavras, você está se concentrando no código e não vendo o quadro maior (a solução que ele pretende fornecer).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
Esse é um problema diferente para um dia diferente.
Primeiro, você constrói algo que funciona. Em segundo lugar , você melhora o código para corrigir quaisquer falhas que ainda possam aparecer. O que você está fazendo atualmente é segurar a primeira tarefa por medo de ter que fazer a segunda tarefa.
Mas qual outra opção existe? Você não pode dizer o futuro . Se você gastar seu tempo ponderando possibilidades futuras, você 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 uma vez que o problema esteja claro, você começa a abordá-lo.
Em outras palavras: Henry Ford nunca construiu um carro que atenda aos padrões / expectativas de 2018. Mas se ele não tivesse construído o Modelo T, um carro defeituoso pelos 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 pudesse tentar melhorar. / p>
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
A parte importante aqui não é qual estrutura você está usando (qualquer empregador que julgue você em que não está fazendo o seu trabalho corretamente). A parte importante aqui é saber o que você está fazendo e por que você está fazendo isso .
Por exemplo, você pode estar evitando o framework existente especificamente porque você quer aprender por que um framework é útil ao fazer isso da maneira mais difícil primeiro. Ou você pode estar tentando criar sua própria estrutura.
A única resposta ruim aqui é "Eu não sei", pois mostra uma falta de tomada de decisões informadas. Isso é uma bandeira vermelha para um empregador.
I simply don't know any web frameworks, and don't know which one to start using.
O mesmo problema surge aqui. A solução não é pensar mais, mas sim agir:
Para ler mais sobre isso, leia A mentalidade fazendo > a mentalidade de pensar . O autor explica melhor do que eu.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
A menos que a base de código atual seja uma bagunça absolutamente inatingível; você está tomando a decisão oposta.
Os desenvolvedores geralmente pensam que jogar fora seria a melhor escolha. É um sentimento muito comum. Mas raramente é a escolha certa.
Jogar código e começar do zero é como ficar preso no trânsito no seu caminho para o trabalho, se preocupar em se atrasar para o trabalho (perder o prazo) e, em vez disso, dirigir para casa e tentar dirigir pela mesma estrada novamente. 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 no marketing para convencê-lo do contrário, os frameworks front-end existem por dois motivos principais:
Você provavelmente só precisará procurar uma estrutura para resolver esses problemas se seu aplicativo for inerentemente stateful, se a quantidade de estado do aplicativo que você está salvando no lado do cliente for bastante complexa, se você esperar muitos clientes com latência de rede ruim (móvel ou distante do servidor), ou se houver uma strong necessidade comercial de suportar CSS especialmente avançado ou criação de elementos dinâmicos.
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 é claramente falso para pequenas equipes que trabalham em projetos simples. Isolar código e organizar importações pode ajudar uma grande equipe a colocar um produto no mercado mais rapidamente. Ele oferece muito menos para uma equipe de desenvolvimento de uma única pessoa trabalhando em um projeto já funcional.Você passará mais tempo aprendendo como encaixar código funcional existente na estrutura do que implementará recursos, e as chances são muito boas de 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 esteja lá para mantê-lo constantemente.
Vanilla JS, e para uma extensão menor, mas ainda significativa, JQuery, não sofrem com esses problemas. Com algumas exceções notáveis, os aplicativos JQuery + AJAX não dependem de comportamentos específicos do navegador e renunciam às dependências externas quando forem sensatos, continuem a trabalhar 10 a 15 anos depois de terem sido originalmente escritos com pequenas alterações.
Frameworks são ótimos para startups típicas que suportam aplicativos da Web contínuos, complexos e voltados para o público. Eles permitem que as grandes equipes se coordenem bem juntas, integrem-se muito bem com as estruturas de adição de fornecedores e suportem novos widgets chamativos e projetem paradigmas para ajudá-lo a permanecer 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 de compatibilidade desnecessários. 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 mudam, as urnas CDN param de funcionar, as dependências ficam desatualizadas - mas ninguém toca nesse servidor e ele continuará funcionando bem.
Não adote uma estrutura a menos que ela resolva um problema arquitetural específico que você tenha hoje ou possa prever em breve, e considere enfaticamente abordar essa preocupação por outros meios, em vez disso, se isso for sustentável.
A melhor coisa que você pode fazer para "provar no futuro" seu aplicativo é seguir as práticas recomendadas no design de seu sistema para maximizar o acoplamento flexível e a separação de interesses. Não há nenhuma parte do seu aplicativo que esteja segura de se tornar obsoleta, mas muito você pode fazer para isolar o código que se torna obsoleto por motivo X do código que não
No entanto, afirmo que a sua preocupação deve ser menor para o crescimento / escalabilidade da sua aplicação do que a taxa de crescimento da sua própria experiência e capacidades. O bloqueio mental que você descreve parece-me como aprendizado da estagnação ou da consciência de muitas incógnitas desconhecidas sem a estratégia ou as ferramentas para lidar com elas.
Frameworks não são particularmente adequados para resolver o desafio do "future-proofing", embora possam fornecer orientação inicial relevante para os inexperientes, geralmente através 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 uma strong coesão e, muitas vezes, com a despesa de um acoplamento mais estreito. Por exemplo, suponha que você use algum sistema de mapeamento relacional de objeto fornecido por estrutura em todo o aplicativo para interagir com seu banco de dados, completo com integração de sistema de armazenamento em cache. Talvez mais tarde você precise mudar para um armazenamento de dados não relacional e agora tudo que o usa é afetado.
A bagunça que você tem agora não veio de o que você usou, mas onde você 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 um pequeno widget a uma página que requer scripts e recursos extras para funcionar corretamente. Se você estiver usando um framework, você pode perguntar "Como quer que eu adicione as dependências a uma página para essa coisa?" Se você não é, então a questão é mais aberta: "Quais preocupações técnicas estou tocando que devem ser de alguma forma separadas?" Essa pergunta leva mais experiência para responder, mas aqui estão algumas dicas:
Se tudo isso parecer esmagador, sugiro que você use uma estrutura por enquanto, não apenas pelo bem do seu aplicativo, mas também pelo crescimento pessoal. Não necessariamente começar de novo embora. Em vez disso, use estruturas como currículo para ajudar a orientar a evolução do seu aplicativo.
Existem apenas duas maneiras de aprender. Uma é por tentativa e erro, e a outra é aprender com a experiência dos 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 o conhecimento preexistente (estratégias, melhores práticas e códigos / bibliotecas / frameworks) em 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 momento, sua primeira preocupação deve ser simplesmente fazê-lo com um mínimo de esforço mundano (que é como um cheiro de código, mas para o desenvolvimento processo). 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 você já tem.
Se você puder aceitar que grande parte do código que você escreve é um processo de aprendizado descartável e necessário para encontrar bons projetos, isso irá motivá-lo a continuar. Afinal de contas, é o desafio da resolução de problemas que torna o desenvolvimento de software atraente, e esse desafio está sempre presente se o que você está fazendo valer a pena (veja a declaração "aprendizado contínuo" acima).
Acima de tudo, "descartando a coisa e começando de novo" é nunca uma opção ... afinal, você não disse que tem "meia dúzia de clientes?" Você já fez uma pausa para considerar o que eles podem pensar em seu pronunciamento, dado que eles estão agora (presumivelmente) " perfeitamente feliz com o seu trabalho ?! "
Aqui está uma analogia que eu gosto de usar:
"Meu trabalho é construir casas para as pessoas morarem, para as pessoas construírem negócios e assim por diante." Meu trabalho é fazer com que "aqueles pedaços de areia impossivelmente minúsculos e excessivamente glorificados" façam um trabalho útil. (Assim como os construtores de casas constroem casas de gesso cartonado, telha cerâmica, bloco de concreto e 2x4).
No entanto, enquanto os "pregos" que os construtores de casas usam realmente não mudaram muito em duzentos anos (exceto para ir de "quadrado" para "redondo", e então ser útil com máquinas de pregar pneumáticas), a tecnologia que usamos está sempre mudando e às vezes sofre uma mudança muito profunda. ("assim vai.")
"No entanto, cada casa, uma vez construída, será para sempre depois de ser vivida ." Você não pode despejá-las. Depois de construir e entregar as chaves, "não é mais a sua casa". É o que é agora, e vai durar muito tempo.
Hoje em dia, grande parte do meu negócio é ajudar os clientes a lidar com o software que foi construído dez, vinte, trinta ou mais anos atrás, usando as tecnologias de "estado da arte" existentes naquela época - (e que, a mim, eu me lembro) - e que ainda estão em serviço (!) hoje.
Garantir algo é 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 manipular. Os testes de redação definitivamente tornarão seu aplicativo mais preparado para o futuro, pois você poderá avaliar como o aplicativo se comporta depois de implementar mais alterações nele.
wrt framework, eu não estaria muito preocupado desempenho / escalabilidade sábio. Isso é algo que você pode verificar com facilidade e, provavelmente, corrigir. O maior problema é a segurança. As estruturas da Web geralmente ajudam você a escrever códigos de autenticação adequados, cookies, proteção contra CSRF, etc. Especialmente devido à sua falta de experiência, melhor foco nessa área.
Eu comecei a escrever um comentário sobre os frameworks de aprendizado, mas eventualmente ele se transformou em algo parecido com uma resposta, então aqui está.
Não conhecer nenhum framework parece ser um problema. Basicamente, em qualquer trabalho webdev, você precisará trabalhar com a estrutura alguns . Aprender outro framework depois que você sabe que não é um grande negócio, mas aprender o primeiro pode demorar um pouco - e é por isso que os empregadores podem se importar com isso. Evitar quadros pode indicar a síndrome não inventada aqui , que é uma abordagem amplamente impraticável.
Como o principal ponto de conhecer seus primeiros frameworks é aprender uma linguagem comum, talvez apenas tente aprender algo popular entre seus colegas. Você pode tentar modificar algum projeto simples escrito em uma estrutura. Começar um projeto do zero em uma estrutura que você não conhece é uma maneira muito ineficaz de aprender.
Agora, a sua pergunta atual foi sobre um projeto específico e portá-lo para uma estrutura. Para isso, a resposta parece ser: depende, e não podemos dizer a você. No entanto, portar coisas para um framework que você não conhece é quase certamente uma má idéia, já que você não pode nem mesmo saber se faz sentido. Assim, parece que você deve deixá-lo como está e revisitar essa decisão em algum momento, uma vez que você conheça e goste de alguma estrutura. Outras respostas contêm pontos positivos sobre o que você deve procurar ao tomar essa decisão.
Este artigo chamou muita atenção no Hacker News há 2.5 anos: Escrever código que é fácil de apagar, não é fácil de extender. Esta perspectiva pode ou não ajudá-lo a lidar com a sua base de código atual, mas no futuro, pode ajudar a evitar a frustração do perfeccionismo / engenharia excessiva.
If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.
I don’t need to tell you that deleting code is more fun than writing it.
(ênfase minha)
O tópico do artigo no Hacker News também merece uma leitura.
No que diz respeito a provas futuras e aplicação de escala & princípios do framework, é uma grande tarefa assumir sozinho, eu provavelmente não me preocuparia com isso, mas se você precisa:
Mantenha seu código limpo, siga os princípios SOLID e DRY > google.
Aplique um balanceador de carga o mais rápido possível.
Coloque em pé pelo menos dois servidores da Web, manipule os cenários de balanceamento de carga no código.
E, por último, mas não menos importante, há pilhas melhores para lidar com um milhão de usuários do que o LAMP, mas tenho certeza de que é totalmente factível.
Caso e ponto, veja: link O ponto é válido, mas 10gb é trivial como assunto de teste.