Bem, ou comece a fazer certo.
Se me pedissem para apontar um problema específico que matou a maioria dos produtos de software, definitivamente chamaria o desejo de que os desenvolvedores prevejam o futuro distante. Isso pode ser expresso de várias maneiras, mas o esquema geral é mais ou menos o seguinte:
"Precisamos implementar a solução {X}, apesar de existir uma solução muito mais simples e mais adequada para nós {Y}, porque quando {Z} acontecer no futuro, {X} funcionará muito melhor que {Y}” .Além disso, não existe e não pode haver informações exatas sobre a probabilidade da ocorrência do evento {Z}.
Aqui estão alguns exemplos:
- Precisamos usar kubernetes e docker! Sim, um único servidor lida com a carga atual e é fácil de configurar e manter, mas quando precisamos de uma dúzia de servidores, será mais fácil implantá-los com kubernetes e docker.
- Precisamos de uma arquitetura de processamento de dados distribuído! Sim, até agora um PC comum está lidando com tudo, mas quando temos uma solução de nível industrial e os clientes exigem um tempo de atividade de cinco noves no SLA, estaremos prontos para isso.
- Precisamos contratar uma equipe de desenvolvimento e criar um site do zero, apesar de ser muito mais rápido implantar algo baseado no wordpress, porque quando temos 100 vezes mais clientes do que agora, o wordpress não será tão conveniente.
- Precisamos usar herança em vez de composição, porque após 5 anos a base de código aumentará para que, sem ela, não haja como.
- Precisamos escrever esse código em C ++, apesar do Python ser várias vezes mais rápido, porque depois de anos ele processará terabytes de dados e o Python pode não ser capaz de lidar aqui.
Recentemente, escrevi
um artigo sobre problemas imaginários - aqueles cuja solução as pessoas se divertem, porque resolvê-los é mais interessante do que os reais. Isso também inclui essas tentativas de prever o futuro. Você pode até dizer mais - esse é o problema imaginário favorito da maioria das pequenas empresas iniciantes.
Mas não vamos reunir tudo: tentar se preparar para o futuro pode ser útil se você abordar isso com sabedoria. Mas poucas pessoas surgem com sabedoria - as pessoas têm fantasias, medos, emoções e outros sentimentos humanos.
Alcançar o sucesso é mais difícil do que viver com o sucesso já alcançado
Cada pessoa às vezes fantasiava sobre como tudo seria se fosse outra pessoa. Alguém rico, famoso, forte, dotado de poder. Pensar nisso é bastante interessante, e acontece de alguma forma por si só, involuntariamente. Então você viu uma foto na capa da revista - e pensou: o que eu faria no lugar dessa celebridade? Ah, então eu gastaria o dinheiro com isso, e se eu fizesse isso. E também isso. E se você ainda pudesse voar e possuir superpotências! Sim, isso seria ótimo!
Os desenvolvedores de software também são pessoas e também são passíveis de fantasias. Então, isso significa que o Facebook construiu sua plataforma em tais e tais tecnologias e é escalável para um bilhão de usuários ... Bem, não somos piores e as tecnologias estão disponíveis, vamos fazer tudo bem também, com uma reserva de um bilhão de usuários (embora até agora existam uma centena deles). Mas a mágica do Facebook não estava na tecnologia de escalar para um bilhão de usuários. Ela foi capaz de oferecer às pessoas o produto certo, na hora e no local certos. O software, capaz de escalar até um bilhão de usuários, era uma parte secundária e menos importante da empresa. Ele foi criado somente quando necessário e somente quando necessário.
A medalha tem dois lados:
a) Alcançar crescimento é mais desafiador do que manter escala.
b) A maioria dos programadores excepcionalmente qualificados e talentosos trabalha em produtos que precisam de boa escalabilidade.
O ponto
"a" é fácil de reconhecer. Pense por si mesmo - de todas as empresas de software já criadas, apenas provavelmente 0,05% atingiram o nível de milhões de usuários e bilhões de lucros. O resto caiu mais cedo ou recebeu menos.
Portanto, a maioria das fantasias sobre os recursos necessários no futuro para o software geralmente se resume a tentar resolver os problemas dessas 0,05% das empresas. "Aqui temos uma equipe de 1000 desenvolvedores, 10 milhões de usuários e uma dúzia de grandes clientes corporativos com seus requisitos complexos, e então precisaremos ..." Não, você não precisa. Com uma probabilidade de 99,95%.
Mas dizer NÃO a essas idéias tentadoras é difícil - porque destrói a fé nessas mesmas frações de uma porcentagem da probabilidade de sucesso. Temos que parar de nos apresentar como donos da nova Amazônia e voltar aos problemas de hoje. E hoje você tem 50 usuários, dos quais 30 são familiares e amigos. Sim, a conscientização do estado atual das coisas pode desmotivar.
O ponto
"b" também não ajuda a lidar com a obsessão. É claro que os melhores programadores trabalham nas principais empresas. Ou porque foram criados graças ao seu talento ou porque as principais empresas são capazes de contratar os melhores programadores. O princípio de Pareto funciona aqui contra nós: é melhor para os programadores escrever livros, fazer apresentações e projetar melhores sistemas. Cada um de nós ouviu essas histórias fascinantes sobre clusters tolerantes a falhas distribuídos por milhares de nós, processando petabytes de dados usando software otimizado para alguns números incríveis de desempenho. Mas a maioria de nós não precisa pensar em como criar esse cluster em nossa empresa aqui e agora. Ele simplesmente não é necessário.
Então, fechar os olhos e representar sua empresa em 5 anos é grande - isso não ajudará? É realmente necessário parar de pensar no futuro?
Claro que não. Pensar no futuro é bom. E projetar software com base no futuro também é útil, mas você precisa fazê-lo corretamente.
Projete com flexibilidade, implemente imperfeitamente
Melhor fazer menos, mas bom. Muito poucos produtos realmente atendem às necessidades de seus clientes. Para você fazer
A e 90% dos usuários precisarem exatamente de
A - nunca será. 90% dos seus usuários em potencial precisam de algum tipo de
B , e o seu
A é apenas a alternativa mais próxima de
B , e ninguém faz ou vende
B , então alguns dos compradores ficarão satisfeitos com um tit na mão.
O que é bom nesse cenário? Depois de conseguir os compradores, você ainda pode tentar entender o que eles realmente precisam e, eventualmente, perceber isso. Bem, ou uma alternativa um pouco melhor para isso. A base de usuários ajuda a estudar o mercado, encontrar nichos e preenchê-los. Assim que você tatear neste nicho, comece a trabalhar nele - aqui seu crescimento começa.
E essa abordagem é realmente produtiva. Você implementa algo pequeno, mas funciona bem, dá aos usuários - e depois ouve os pensamentos deles sobre o seu produto. Você não adivinha mais, não resolve problemas imaginários, não adiciona complexidade desnecessária. Você se adapta, adiciona algo, remove algo. E isso cria seu produto exclusivo.
E dessa maneira - quanto menor sua base de código originalmente, mais fácil é adaptá-la a algo novo.
"Eu odeio código e gostaria de ver o mínimo em nosso produto" - Jack Diederich
Se você fez algo funcionar perfeitamente, você fez errado. Você teve que fazer grandes sacrifícios ao longo do caminho. Talvez tenha sido um desperdício de tempo ou dinheiro, talvez você tenha desistido da flexibilidade, talvez de outra coisa. O ideal não é alcançado de graça.
Um software não ideal é mais viável. É possível criá-lo em um prazo razoável e a um preço razoável. Muitas vezes, faz tudo ou quase tudo o que é necessário. Por ser imperfeito, por definição, deixa espaço para seu desenvolvimento e liberdade de manobra.
Projeto de arquitetura de software otimista - o futuro pode despertar agradavelmente
É importante lembrar que o mundo ao seu redor não é estático. Os problemas que surgem diante de você depois de alguns anos podem ser facilmente resolvidos com a ajuda das tecnologias disponíveis depois de alguns anos. Muitas pessoas projetam algo, não apenas levando em consideração oportunidades futuras, mas geralmente confiando apenas em ferramentas que já têm décadas. Eles se limitam nem hoje, mas ontem.
Deixe-me falar sobre um exemplo específico: projetar sistemas distribuídos com a expectativa de estar pronto para qualquer crescimento. Um dos medos comuns que levaram à criação de tais sistemas é o medo de que, em algum momento, seu servidor não consiga atender a todos os usuários. E isso realmente acontece. As vezes Mas não em pequenas empresas, não em startups. Além disso, a maioria das pessoas que escreve software em 2018, por algum motivo, tem certeza de que ele funcionará em servidores criados em 2005. Os computadores melhoram a cada ano e bons servidores podem ser alugados não tão caros.
Deixe-me descrever um servidor "real" inicial:
- Dois Xeons E5-2680v4 (28cores e 56 threads, tocando de 2.4GHz a 3.3GHz)
- 512 Gigabytes de RAM DDR4-2400
- 2 SSDs NVMe de 1,2 TB cada (~ 3 GB / s de leitura e ~ 1,5 GB / s de gravação cada).
Sim, aposto que metade dos sistemas distribuídos do mundo funcionará completamente neste servidor, com todos os seus componentes e dependências, servindo normalmente toda a sua base de usuários existente. E isso está longe de ser o servidor mais legal até o momento. Isso pode ser cobrado por um preço de 800 a 1300 dólares por mês (dependendo de onde obtê-lo). Você pode alugar uma dúzia deles pelo salário de um engenheiro qualificado em Londres.
O que ainda é bom nesse servidor é que o preço do seu aluguel em 2 anos cairá 2 vezes.
Os computadores evoluem, evoluem de maneira muito linear e previsível e continuarão a evoluir conforme o previsto, em algum lugar até o final da década de 2020. É difícil adivinhar mais, mas é improvável que a humanidade invente algo novo. E as pessoas ainda se lembram do ferro do início do século e têm medo de que não seja suficiente para atender a alguns milhares de pedidos por dia.
Mas estamos falando de ferro. E pense em todo o software que aparece e se desenvolve ao redor. Poucas pessoas pensaram seriamente sobre controle de voz há 20 anos. E olhe para o mundo de hoje - "OK Google", "Olá, Alexa", "como está o tempo agora, Siri?" Qualquer um que começou a escrever uma interface de voz no ano de 2016 - acabou de conseguir o 2018.
O que começar a escrever em 2018? Ah, se eu soubesse :) Isso é algo que já apareceu no horizonte, mas ainda não se tornou tão grande que ofusca o sol. Olhe em volta, talvez você note algo assim?
O progresso no software é incrível. Completamente despercebido, com o advento do WASM, os navegadores se tornaram máquinas virtuais universais. Após 2 anos, você pode criar um aplicativo versátil, complexo e de alto desempenho, compilando-o para exatamente uma plataforma: montagem da Web. E isso começará em qualquer lugar.
Mas as pessoas ainda moram em algum lugar em 2012. Eles usam o Babel, embora 99% dos usuários tenham pelo menos um navegador com suporte ao ES6.
Novas linguagens de programação aparecem constantemente. E alguns deles são muito bons. Somente nos últimos 8 anos, encontramos Go, Rust, Scale e D - todos encontraram seu nicho. Nos próximos 2 anos, espero ver como Julia contribuirá para a programação científica. E é exatamente isso que me preocupa pessoalmente e o que sigo. A quantidade total de tecnologia e conhecimento é incrível.
Mas eu discordo ...
Inspirar o futuro é relativamente fácil. Mas, francamente, além do progresso linear do crescimento da produtividade, é difícil imaginar o que acontecerá em 2 ou 5 anos. Algumas idéias estão flutuando no ar, as equipes estão trabalhando em vários projetos de software e hardware, mas o que "disparará" disso?
No entanto, se você deseja preparar seu software para o futuro, você deve primeiro entender o presente. O que é bom no presente é que ele já existe, é observável, mensurável. E ainda permanece por um tempo. Tornar seu software pelo menos relevante hoje é uma boa idéia. Você não estará pronto para as realidades de 2020 usando as abordagens de 2000. Mas o software escrito com abordagens relevantes para 2018 pode funcionar muito bem em 2020.
Portanto, não se negue o prazer de desenvolver software com uma base para o futuro. Apenas faça mais corretamente. Considere não apenas o desenvolvimento do seu produto futuro, mas também o desenvolvimento do ecossistema circundante. Tudo o que pode ser projetado com flexibilidade deve ser projetado com flexibilidade. Isso lhe dará a oportunidade de manobrar no momento em que você descobrir de que maneira essa manobra deve ser concluída. E isso evitará que você gaste tempo se preparando para algo que nunca acontecerá.