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


106

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.


93
O uso de uma estrutura deve ser mais barato, não objetivamente melhor. Os negócios sempre perguntam "por que não mais barato" porque esse é o trabalho deles. São necessários muitos anos de experiência para responder "por que essa estrutura não é essa, ou personalizada". Você não pode dar uma resposta significativa a essa pergunta como estudante / estagiário simplesmente porque não participou de projetos suficientes para testemunhar como uma determinada estrutura funciona para um determinado problema. Sem essa experiência, a única coisa que você pode fazer é se tornar vítima de um determinado marketing de estrutura.
Agent_L 6/1118

24
A única coisa que você sabe sobre o futuro é que você não sabe nada sobre isso. Então, continue vivendo no presente. O futuro encontrará maneiras de chutá-lo na merda, por quanto tempo você perder tentando evitá-lo!
Alephzero 6/11

20
"Tendo ficado apegado ao ... código que já escrevi" É nossa natureza nos apegar ao nosso trabalho e resistente a mudá-lo. Mas, mesmo se você fizer isso, ele vive no controle de versão. O software deve ser alterado, assim como o mundo real. Não tenha medo de excluir o código ou alterá-lo substancialmente ao criar um código.
bitsoflogic

8
Quanto ao descarte do projeto, eu desaconselharia. Normalmente, é ótimo começar do zero, porque você tem muito impulso para enfrentar muitos problemas que já resolveu. Eventualmente, porém, você está de volta a um novo problema que não se encaixa no modelo. Você sempre pode resolver gargalos depois de saber o que são.
bitsoflogic 6/11/19

6
@james_pic Você executa projetos da Web sem uma estrutura básica (por exemplo, o núcleo do asp.net no .NET e assim por diante)? Então, você reimplementa a lógica de roteamento e todas as outras coisas em cima de uma simples biblioteca http? Isso parece excessivo e não vejo qual vantagem isso deve lhe dar.
Voo

Respostas:


201

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 .


23
Bom ponto. Se você passar dois meses tentando torná-lo à prova de futuro para evitar uma eventual reescrita de 1 semana, você perderá 7 semanas do seu tempo. Aceite que haverá mudanças, e prova no futuro somente quando é quase certo que isso precisará ser feito.
Neil

83
YAGNI, baby, YAGNI #
Kevin

32
Outro caso de " Otimização prematura é a raiz de todo mal ". Talvez valha a pena mencionar que você não passará de 6 usuários para um milhão. Se 6 clientes forem suficientes para pagar por um desenvolvedor, mesmo quando você atingir 100 clientes, o código poderá precisar de uma estrutura diferente apenas para permitir que vários desenvolvedores trabalhem nele ao mesmo tempo. Isso é bem diferente de otimizar o desempenho e acontece muito mais cedo do que ter que manipular um milhão de usuários.
R. Schmitz

22
@ R.Schmitz Essa citação é usada nos dias de hoje em um contexto completamente diferente do que Knuth usou na programação de computadores como uma arte. Knuth é decididamente contra o todo "apenas comece a programar e se preocupe em otimizar mais tarde". O que ele está dizendo é que as pessoas otimizam as partes erradas do código na hora errada. Isso não significa que você não deva gastar algum tempo pensando em sua arquitetura para garantir que seja eficiente antes de começar a escrever o código. Você pode preferir o outro sentimento, mas não deve citar Knuth como defensor lá.
Voo

20
@ R.Schmitz Quando Hoare / Knuth fez essa afirmação, "otimização" significava contagem de ciclos e outras coisas que não fazemos mais hoje, não "pense em uma boa arquitetura antes de começar a codificar". Usar a citação como desculpa para simplesmente não pensar em um bom design de sistema simplesmente não é o que eles tinham em mente.
Voo

110

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.


9
Partindo do zero raramente é a escolha certa: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
Martin Bonner

10
@MartinBonner Enquanto isso certamente é verdade no contexto sobre o qual Joel fala nesse artigo, se este é literalmente o primeiro projeto em que você trabalhou, e você é a única pessoa que trabalhou nele, é muito possível que você seja capaz de escrever algo melhor. Lembro que reescrevi o primeiro grande projeto pessoal em que trabalhei, e essa provavelmente foi a decisão certa na época - o protótipo original estava quebrado além do reparo, porque não sabia o que estava fazendo quando o escrevi.
James_pic

4
@ Flater Concordo com a maior parte do que foi escrito aqui, exceto uma coisa: se você escolher uma estrutura e não souber nada sobre nenhuma delas, poderá pelo menos verificar o nível de adoção dessa estrutura. Por exemplo, quantas estrelas ele tem no github? Quantas questões existem? Quantos colaboradores? Quando foi a última atualização? Responder a estas perguntas pode pelo menos ajudar na escolha de um quadro para o qual você pode obter ajuda, contratar caras que sabem melhor, etc.
Jalayn

@Jalayn Supõe-se que um iniciante que não tenha conhecimento prévio provavelmente tropeça em estruturas conhecidas para começar.
Flater

3
Essa é uma ótima resposta, pois incentiva uma abordagem disciplinada e metódica. Demorei alguns anos para que eu pudesse apreciar plenamente esse conselho!
Kashiraja 7/11

18

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.


2
Quando penso em "framework", penso em coisas como jQuery, Angular ou React, que fornecem muitos blocos de construção para coisas que seriam irritantes para se implementar (e muitas vezes difíceis de implementar corretamente e compatíveis com vários navegadores).
macia

@fluffy O que, especificamente, você acha que o Angular ou o React faz por você é significativamente mais fácil do que fazer a mesma coisa no vanilla JS ou JQuery em 2018 em navegadores não móveis? O FF / Chrome / Edge tem mais do que suficiente área de superfície comum para criar aplicativos pequenos e totalmente funcionais atualmente sem calços.
Iron Gremlin 8/08

3
@IronGremlin Você está brincando? Você já usou ligações de dados bidirecionais ou modelos Angular / Vue / qualquer que seja? Para aplicativos em que esses recursos são úteis, eles são uma grande simplificação e permitem que você se livre de códigos quebradiços baseados em eventos. Em seguida, CPU. Certamente, o uso da estrutura JS geralmente requer alguma carga do servidor, mas é puramente um subproduto , e você diz que é a principal razão para eles. A seguir, "Arquitetura simples (...) parece melhor para este projeto". Bem, essa é uma afirmação absurda, dado o pouco que sabemos sobre o projeto.
Frax

2
Quero dizer, você diz que seu ponto principal é "nem tudo precisa ser ou deve ser um 'aplicativo js rico'". Eu concordo com este ponto. No entanto, acho que sua resposta falha em transmiti-la corretamente - seria muito melhor se você a editar.
Frax

1
Eu nunca ouvi falar sobre o descarregamento da CPU para o cliente como um motivo para usar o JS - eu diria que a tendência histórica do uso do JS no cliente sugere apenas isso (não estou dizendo o motivo (o único)) e pareceu crescer exponencialmente desde que o jQuery cortou o nó górdio de incompatibilidades do navegador.
Radarbob

7

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).


5

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.


3

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.


3

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.


2

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.


-1

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.