A escolha da tecnologia, arquitetura e design em projetos de software - sem dinheiro

Amigos! Continuamos a série de publicações "sem cortes" sobre processos de design, tecnologias de TI e como trabalhar efetivamente. Hoje, falaremos sobre um tópico muito dolorido que causa azia no cérebro - a escolha de tecnologias, linguagens de programação, o papel de arquitetos, analistas, líderes de equipe e médiuns para resolver o problema épico: lançar uma solução de software, se possível, dentro de um prazo razoável. E vamos parar separadamente, para não ficar entediado, na análise da correlação dos tamanhos das partes do corpo de uma parte da equipe com a produtividade do cérebro da outra. Despeje o café e vamos lá!

Como se tornar especialista

Para entender objetivamente por que ainda não há clareza nas questões indicadas e há tantas disputas "religiosas" com sacrifícios humanos, você precisa se distrair, sorrir e desenhar a vida de um especialista em TI com uma faca de cozinha na forma de uma linha quebrada em uma mesa com quadrados que significam o conhecimento adquirido.


A diversão começa com o fato de que, geralmente, mesmo em universidades especializadas, não há conhecimento suficiente para a programação profissional e a competência de um especialista depende diretamente da luta mental com a preguiça: pegue um livro / código por algumas horas ou caia com uma lata de cerveja na frente da TV. Obviamente, apenas uma pequena parte é capaz de suportar redes sociais, séries de televisão, jogos on-line e aprender desinteressadamente, mas mesmo se, como os monges, eles constantemente e diariamente sacrificam uma parte de sua vida, eles podem entender facilmente uma, bem, às vezes duas linguagens de programação industriais e várias tecnologias relacionadas. E o bigode, a pensão começa e enquanto abelha para plantar abelhas.

Porém, com tanta dificuldade, o conhecimento adquirido para o sucesso ainda não é suficiente e é necessária uma especialização constante em projetos de desenvolvimento, preferencialmente com prazos infernais, porque as habilidades de escrita imediatamente e rapidamente são perdidas rapidamente e corretamente.

Como resultado, apenas alguns quadrados podem ser cortados com uma faca e, quanto mais à direita, menos quadrados, como regra, porque as crianças nascem, conhecidos aparecem, hobbies e você quer pelo menos viver um pouco pelo menos para si mesmo à noite e finalmente se cansar dos pequenos tanques.

Uma analogia muito compreensível de um especialista em TI, talvez, seja um especialista em artes marciais que, depois da escola, deixou Voronezh para a China, passou 10 anos em um mosteiro, colocou as juntas dos dedos nos ombros, cortou os genitais com uma espada e treinou 20 horas por dia. Um lutador vai até gostar de conhecer vários dialetos chineses, mas um dia ele encontrará um cara de pele escura que se dedicou à Capoeira . Provavelmente, no nível das placas, eles se entenderão e poderão escolher a tecnologia para um projeto de software, mas, infelizmente, na maioria das vezes você precisa conhecer fãs agressivos de cosplay e ficção científica - em um traje Jedi com um sabre de luz de plástico nas mãos.

Copiar e colar, estruturas e ficção científica

Obviamente, apenas alguns podem estudar e aprender a Verdade tão desinteressadamente, e na vida real, reuniões e disputas sobre tecnologias e linguagens de programação ocorrem principalmente entre fãs de diferentes e modernas "séries", que geralmente não sabem a diferença entre IP e TCP. O problema é agravado pelo marketing agressivo externo - a maioria dos grandes fornecedores de TI está ativamente "recrutando" seguidores para suas fileiras, usando canais de informação ampliados. Você não precisa ir longe para obter exemplos - a Mozilla está promovendo Rust, o Google está promovendo Go, a Oracle está interessada (?) Na promoção de Java, a Microsoft está desenvolvendo C #, JetBrains é Kotlin, os alienígenas são Haskell e a comunidade científica não se alegra com a aparência de AI e ML, um neurônio. e datatismo, pois muito dinheiro é vendido ... cursos acadêmicos empoeirados em teoria das probabilidades, régua e estatística para todo o sempre, amém :-)


E quando um fã de Game of Thrones começa a discutir com um fã do Clã Soprano sobre os benefícios da programação orientada a aspectos , mixins e fechamentos , tudo o que resta é rir sinceramente e polvilhar os debatedores com areia sagrada das batatas do Tibete e do McDonald's. Você não será capaz de esperar por conclusões úteis e objetivas e ficará confuso ainda mais - e, pior ainda, obterá um vírus viral e começará a andar com um casaco listrado.

Tradições e "correção"

O fato é que montar, por exemplo, um carro de ferro é uma tarefa bastante cara e longa: você precisa de material, soldagem, conhecimento, uma sala, um pôster de menina com as formas corretas etc. E escrever um programa, especialmente não sozinho, é bastante comum. Criatividade virtual - explodiu e continua a amassar e esticar o mundo. Um mar de conteúdo digital, muitas vezes sem noção e primitivo, onde todos os escritores e artistas inundaram a web. Como resultado da relativa simplicidade da "auto-expressão", no mundo, em um período relativamente curto de tempo, após a Segunda Guerra Mundial, apareceu um grande número não apenas de programas, mas também de linguagens de programação. Escrever uma nova linguagem de programação não é difícil, muito mais difícil - para ganhar popularidade. Aconteceu historicamente que as linguagens que aprenderam a “escrevê-las corretamente” (por exemplo, C ++, Java, ECMA262) são populares agora, e as linguagens que “mais tarde surgiram e parecem melhores” (por exemplo, C #, Python3, Rust, Kotlin) são muito menos populares. Ao escolher uma linguagem "mais correta", você corre o risco de não encontrar desenvolvedores suficientes que a conheçam, ou pode acontecer que a linguagem simplesmente pare de se desenvolver ou ascenda à eternidade, como Haskell. Portanto, guiados pelo senso comum, geralmente escolhem tecnologias tradicionais, por assim dizer, mesmo que não sejam "corretas" e consistentes, cheias de muletas e vestígios de crescimento, mas testadas, populares e desenvolvidas.


No contexto da graphomania de desenvolvimento ativo (especialmente na direção do front-end, embora o npm também seja divertido), gostaria de alertar contra o uso impensado de bibliotecas e estruturas . É importante examinar o histórico de desenvolvimento da estrutura, o contingente de desenvolvedores (quanto mais simples a tecnologia, mais surpresas existem) e a duração do suporte à versão.

Geralmente, em projetos de código aberto, não é habitual manter a estrutura por um longo tempo, por exemplo, 3-5 anos ou mais - isso é brega, caro e chato. Portanto, geralmente, depois de ganhar uma massa crítica de "muletas", a próxima versão é criada, em um ou dois anos, e eu recomendo que os usuários de suas versões anteriores transfiram seu projeto ... faça você mesmo, porque a versão anterior não será mais atualizada e os erros de segurança nela também não serão corrigidos. Exemplos dessa "irresponsabilidade" são simplesmente o mar.

Bibliotecas e estruturas comerciais, como regra , não sofrem de uma doença semelhante na infância (embora nem todas, você precisa examinar atentamente a documentação e estudar esse problema completamente) e manter a compatibilidade com versões anteriores por cinco ou mais anos. Preste atenção especial a isso, caso contrário você terá que reescrever sua solução da Web do zero!

Em geral, nesse ponto, é melhor usar um provérbio sobre um teta e um guindaste.

Novo ou ... concluído

Outro problema psicológico muito popular no desenvolvimento é a escolha entre "faça do zero" e "prepare-o". Vou lhe contar um segredo - todo mundo quer ser deuses, desenvolvedores iniciantes, o que, aliás, é normal, eles querem bombear e obter uma entrada no currículo e optar por "fazê-lo do zero". Mas, geralmente, eles saem por causa do tédio depois de seis meses ou um ano e, muitas vezes devido à falta de experiência, suas criações precisam ser reescritas repetidamente do zero. Monges experientes de Shaolin, geralmente, para se protegerem dos erros e surpresas das crianças, escolhem soluções e bibliotecas prontas e passam o tempo livre restante no desenvolvimento de padrões não exclusivos e exclusivos para essa funcionalidade de projeto da web. E não vai ser chato!


Uma boa associação pode ser a escolha de um banco de dados - o que levar para um projeto web, banco de dados Oracle ou banco de dados MySQL (sim, eu sei que eles estão sendo desenvolvidos por uma empresa). Segundo a experiência - 99% das tarefas de desenvolvimento da web, mesmo sob altas cargas, são resolvidas de forma excelente e em alta velocidade no MySQL. E se o resultado não diferir, por que ...? :-)

Portanto, normalmente um projeto de software agora consiste em um monte de bibliotecas e estruturas prontas e testadas, com um bom período de suporte e apenas uma pequena parte do funcional específico para este projeto. E isso, IMHO, está correto.

Difícil e longo ou ... rápido e fácil?

Essa também é uma causa conhecida de inúmeras e intermináveis ​​disputas. De fato, as modernas tecnologias de TI e linguagens de programação são divididas, basicamente, em duas partes: simples para a maioria (sem necessidade de aprofundar, alguns dias para entender) e difíceis para a minoria (ela precisa de uma especialização longa e séria, meses para entender). Como vimos acima, a maioria das pessoas não gosta de aprender, por isso, se você implementar a tecnologia certa e confiável, não terá sucesso porque ninguém poderá entendê-la completamente e você jogará roleta russa com uma caixa preta. Um exemplo popular: a escolha entre redis ou cassandra - produtos de diferentes ordens de complexidade. Ou outro exemplo: python ou C ++.

Em linguagens simples, de fato, a programação geralmente é muito, muito mais rápida - compare um script python com 5 linhas e um código C semelhante com 100 linhas. Mas, geralmente, linguagens “simples” e tecnologias universais às vezes trabalham muito mais devagar e consomem muito mais memória RAM :-) Afinal, você precisa pagar por tudo.


No entanto, linguagens “simples” são cada vez mais usadas para resolver a maioria das tarefas de um projeto de software, onde não são necessários requisitos especiais para super velocidade e RAM. E o ferro se torna cada vez mais barato. Agora, o PHP é muito popular para o desenvolvimento rápido da Web e o python, com sua sintaxe muito clara e legível, para tarefas gerais e aprendizado de máquina. O JavaScript é muito conveniente para automatizar não apenas a interface da Web, mas também ... criar aplicativos de servidor realmente rápidos no Node.js. O Go, mesmo com sua sintaxe primitiva, permite dispensar tarefas Java mais poderosas, mas muito mais difíceis de entender nas tarefas do sistema, e um aplicativo móvel pode ser rapidamente criado por ordens de magnitude mais fáceis e acessíveis aos iniciantes no Kotlin. É possível, com riscos muito menores, executar um aplicativo de alta carga no Rust sem se aprofundar nos meandros do gerenciamento de memória em C ++. Mas ninguém em sã consciência escreveria um jogo em Java, lembrando o minecraft popular, que só pode ser jogado a uma distância de 10 metros da tela, apertando os olhos :-)

Portanto, para cada tarefa, é aconselhável escolher uma ferramenta popular específica, afiada por ela. Quanto mais ferramentas prontas usadas, melhor.

É cômico, mas nas realidades atuais, nem mesmo a escolha do idioma, mas a escolha dos recursos do idioma pode ter uma influência decisiva no sucesso. Por exemplo, tendo uma equipe que não possui experiência em programação orientada a objetos e conhecimento de padrões de design, você pode escrever um zoológico de objetos tão flagrante que pode ser mais fácil resolver o problema com 100 funções em um arquivo monolítico, compreensível para todos do que se esconder de centenas de objetos em um escritório monstros com uma posição em vez de uma cabeça e orelhas em vez de pernas. É por isso que, frequentemente, linguagens simples (como python, php, javascript, ruby) que não oferecem oportunidades redundantes para desenvolvimento de grafomania e perfeccionismo, focadas em clareza, inequívoca (python) e concisão (php), tornam cada vez mais possível o sucesso. Não é à toa que as histórias são tão populares quando um site foi criado em C ++ e que pesadelo ele se transformou mais tarde.

Uma boa analogia aqui é um exemplo de caro e difícil de "ajustar" cavaleiros medievais e ... hooligans com armas de fogo. Você pode treinar toda a sua vida e se tornar um samurai Java multiencadeado, mas pode repentinamente terminar sua vida quando encontrar um aluno com uma solução semelhante e muito mais simples em python ou Go.

ARQUITETURAS E ARQUITETURAS

De fato, há 10 a 15 anos, era necessário estudar e ler livros espessos por um longo tempo para entender os princípios de colocar objetos e sua interação em servidores e clusters separados (j2ee, corba, com). Ecos desse boom da arquitetura e dos arquitetos ainda podem ser encontrados em criações monstruosas como a primavera . Mas os tempos estão mudando, a tecnologia está se tornando mais poderosa e acessível. Ao implantar alguns servidores Web Apache gratuitos, banco de dados MySQL e fila RabbitMQ em algum lugar da Amazon , você pode resolver a maioria dos problemas anteriormente disponíveis em configurações de servidores de aplicativos compreensíveis para a minoria esmagadora.


Se a tarefa é oferecer suporte a conexões de rede massivas, você pode criar um cluster de máquinas Node.js. ou melhor, máquinas com Erlang e dormir tranqüilamente, do que escrever sua própria solução de servidor, por exemplo, Go ou C ++.

Se você precisar pesquisar constantemente, no fluxo, selecionando um dos 10 a 20 modelos de aprendizado de máquina e implantá-los rapidamente na nuvem para atendimento ao cliente, é claro que o python com um grande número de bibliotecas se tornará uma solução prática e conveniente, e assim por diante.

Obviamente, em projetos estritamente especializados, ainda é necessário um conhecimento profundo de OOP, FP , arquitetura, Ciência da Computação , mas cada vez mais é suficiente saber de quais blocos montar a solução e isso muitas vezes leva o sistema de software à meta muito mais rapidamente.

Correspondência de equipe

Com base no exposto, é óbvio que a equipe provavelmente desenvolverá apenas dentro da estrutura limitada do conjunto de tecnologias selecionadas para o projeto. As unidades começarão a pesquisar tópicos relacionados, e uma pequena proporção deles lerá literatura especializada, mas esse é, infelizmente, um caso excepcional. Portanto, recomenda-se selecionar aqueles já experientes nos idiomas / bibliotecas indicados, que podem ser conferidos no currículo e nas entrevistas. E apenas aqueles que realmente não podem ser derrotados por programas de TV e redes sociais podem ser levados para "crescimento" depois de receberem um contrato previamente assinado por sangue arterial :-)

No entanto, em projetos fora do padrão, você precisará encontrar pelo menos um desenvolvedor que saiba algo mais e que seja excelente, exceto python, ruby, php, javascript, go, perl, bash, chanson. As chances de o lutador conhecer os algoritmos, padrões de design, padrões de rede e OOP também são significativamente melhoradas.


Se o projeto estiver relacionado ao aprendizado de máquina e você precisar aprofundar algo, precisará encontrar um analista de matemática real, de preferência com um grau científico e conhecimento de python. Estou falando sério - para aprendizado de máquina, sem uma educação especializada, você precisa estudar muito por várias horas por dia (teoria das probabilidades, álgebra linear, método dos mínimos quadrados, estatística, teorema de Bayes e sua técnica) por vários meses, se não anos.

Processos ou tecnologias?

Muitas vezes, é possível encontrar projetos de software grandes e duradouros escritos em linguagens de programação ou conjuntos de bibliotecas aparentemente "inadequados". Por exemplo, muitas vezes encontramos scripts de controle de bash enormes ou estruturas e bibliotecas científicas maciças para cálculos precisos em ... python com tipagem de pato Dodbyba. O segredo está em processos e práticas rigorosos. Usando:

• projeto preliminar, teste de estresse e análise de risco
• teste automatizado de unidade e integração (de preferência 100% de cobertura)
• padrões comuns de codificação
• boa documentação de componentes de código e sistema
• comunicação transparente máxima dentro da equipe
• monitoramento e análise do ambiente do servidor

Você pode criar uma solução de software, em princípio, com qualquer tecnologia que viverá por anos e encantará os clientes. E vice-versa, trabalhando com "exibições" caras demais com caixas pretas, sem se aprofundar nos detalhes da tecnologia, encorajando negligência e interesses pessoais em vez dos da equipe, você pode tentar iniciar um projeto por meses, corrigindo um erro e gerando dezenas - infelizmente, essa situação é bastante comum.

Sumário

Para resumir e priorizar:

• Cada vez mais, é possível observar uma situação em que exatamente a velocidade de lançamento de um projeto de software é um fator decisivo para o sucesso. Fazer algo desnecessariamente longo e difícil é pior do que liberar rapidamente uma solução útil para os clientes e obter feedback para o próximo idiota
• Um início rápido é possível apenas ao usar o máximo de componentes, estruturas e bibliotecas prontos com um período de suporte adequado (levando em consideração a vida útil esperada do seu sistema da web)
• Infelizmente, o conhecimento algorítmico e arquitetural é menos requisitado. Mais frequentemente, a experiência na solução de problemas semelhantes e a prática de usar caixas de ferramentas e os pontos fortes dos provedores de nuvem são bem-vindos.
• Não há necessidade de se limitar e fazer tudo com uma tecnologia e apenas uma, a MELHOR, linguagem de programação - uma arma de fogo nas mãos de uma criança é mais eficaz do que um estudo de artes marciais realizado pelo samurai em toda a vida consciente e inconsciente. O perfeccionismo e a idealização matam os sistemas de software. Escolha a arma certa para cada tarefa no projeto. Pegue o final e concentre os esforços restantes no não-padrão.
• As tecnologias selecionadas devem ser simples, claras e acessíveis à maioria da equipe. Veja o que eles escrevem sobre um projeto semelhante e assuma essa pilha de tecnologia. Não automatize a hospedagem com Haskell e não escreva sites em C ++ :-) Se o seu projeto "decolar" e começar a se desenvolver, somente então você poderá reescrever suas pequenas partes em tecnologias e linguagens de programação mais complexas. Mas, geralmente, os projetos de software não atingem esse estágio ou atingem alguns anos depois.
• A estrutura permite acelerar o lançamento de um projeto de software por ordens de magnitude. Verifique a disponibilidade de boa documentação e especifique o período de suporte para a estrutura, para que não haja problemas com uma reescrita completa em 2-3 anos. Este é um caso muito frequente de nossos clientes.
• Não acredite na capacidade da equipe de aprender - há muitas distrações na vida e a situação está apenas piorando. Estude cuidadosamente seu currículo, verifique certificados e exames e tente se concentrar o máximo possível no resultado prático. Coloque a prática acima da teoria, pelo menos no momento da criação da primeira versão de uma solução funcional.
• Tecnologia e linguagem (s) de programação não são fatores críticos de sucesso. Concentre-se na criação dos processos mais necessários e na implementação das principais práticas de desenvolvimento e design. Os processos corretos, como regra, são garantidos para levar ao resultado "correto". « » « », . , 2-3 .

, , !