Muitas vezes me perguntaram por que eu prefiro usar linguagens de programação como Haskell e Rust, porque não são as ferramentas mais utilizadas e populares. Este post foi escrito com a intenção de desmistificar o que se passa na minha cabeça quando penso nas opções de tecnologia.
O desenvolvimento de software com os requisitos de operação de longo prazo e um certo nível de confiabilidade é, em certo sentido, semelhante a um jogo de xadrez. Variantes do desenvolvimento de eventos em ambos são bastante difíceis para o cérebro humano compreender, o papel da experiência é de grande importância e cada movimento / escolha pode ser crítico. A semelhança continua no sentido de que, como o xadrez, o desenvolvimento é muito "posicional" - toda uma série de movimentos pode ser destinada a preparar uma manobra que levará à vitória do peão. Pode parecer que este é apenas um peão, mas para um jogo sério, isso pode ser uma vantagem significativa. Semelhante ao jogo posicional do tabuleiro de xadrez, durante a concepção e desenvolvimento de grandes projetos, constantemente tomamos decisões que visam resolver problemas maiores ou atender aos requisitos do projeto.O efeito de cada solução, mesmo uma pequena, tende a se acumular no final do jogo, ou no momento em que o produto de software está em operação. A diferença, que agrava a situação, é que o desenvolvimento de software, ao contrário do xadrez, não se resolve em um computador, e você não pode simplesmente pegar e encontrar os melhores movimentos rodando um motor de computador. Portanto, é necessário tomar muitas decisões que nos levem gradativamente a esse objetivo, e todos os meios para melhorar nossa "posição" estratégica são bons.e você não pode simplesmente encontrar os melhores movimentos rodando um motor de computador. Portanto, é necessário tomar muitas decisões que nos levem gradativamente a esse objetivo, e todos os meios que aprimorem nossa "posição" estratégica são bons.e você não pode simplesmente encontrar os melhores movimentos rodando um motor de computador. Portanto, é necessário tomar muitas decisões que nos levem gradativamente a esse objetivo, e todos os meios que aprimorem nossa "posição" estratégica são bons.
As soluções podem ser simplificadas em várias categorias: arquitetônicas, metodológicas e instrumentais. Arquitetos falam sobre como estruturamos um projeto. Os métodos determinam como organizamos o processo de trabalho, garantindo a qualidade e a correção da implementação. As ferramentas determinam o que a equipe de desenvolvimento precisa trabalhar para obter o resultado. Para um ciclo de desenvolvimento completo, um grande número de ferramentas é usado hoje: você precisa formalizar os requisitos, o processo de desenvolvimento, você precisa escrever o código do programa e testá-lo, construir uma versão, etc. Apesar de tal abundância de tarefas, o a escolha de uma linguagem de programação pode desempenhar o papel mais importante, pois determina um conjunto dos seguintes parâmetros:
- Linha de base na velocidade do software.
- , .
- , . , .
- // , .
- , , .
- .
Além disso, a escolha de uma linguagem de programação também pode afetar significativamente questões metodológicas, por exemplo, as ferramentas do ecossistema da linguagem podem determinar como e em que medida os testes de unidade são escritos. Uma boa infraestrutura para testes de propriedade pode dar um impulso nessa direção, e a falta de uma boa infraestrutura para testes de unidade pode dificultar sua escrita e manutenção.
As ferramentas também afetam questões de arquitetura - a reutilização de módulos no sistema está ligada à conveniência de dividir blocos conceitualmente e estruturar o código. Por exemplo, trabalhar explicitamente com sistemas de efeitos permite generalizar mais o código e garantir que o módulo de código não execute operações de E / S, como trabalhar com rede e disco, o que permite raciocinar sobre segurança e arquitetura.
Com base nisso, você deve estar ciente de que escolher a linguagem de programação certa para um projeto e equipe pode ter consequências de longo alcance. Tendo em mente a analogia do xadrez, lembramos que todo pequeno plus irá para o cofrinho da linguagem e pode desempenhar um papel significativo em um grande desenvolvimento. Também vale a pena mencionar que estamos falando em escolher uma ferramenta de desenvolvimento para situações em que não haja restrições estritas na escolha de tecnologias em conexão, por exemplo, com um grande ecossistema já escrito em algo. Na Typeable, somos guiados pelas seguintes considerações para linguagens de uso geral:
- . . , , .
- — , , . . - , , , .
- . GIL (Global Interpreter Lock) . .
- , . , , , .
- . , CS . « » , IT , .
- , .
Como resultado de tudo isso, há blocos suficientes em nossa caixa de ferramentas que nos permitem assumir uma posição confiante em muitos projetos. Voltando à analogia do xadrez, esses são os nossos princípios que nos permitem jogar um jogo posicional. O jogo posicional é um jogo que visa criar uma posição de longo prazo que abre oportunidades para o jogador e minimiza as fraquezas. Opõe-se a um jogo de ataque, "certeiro", onde existe uma grande parcela de risco, e o jogador atacante tenta completar este jogo antes que seu oponente possa assumir uma boa posição defensiva. O desenvolvimento "afiado" é a programação de olimpíadas, MVP para experimentos de marketing, muitas tarefas em ciência de dados e, frequentemente, a criação de software que acompanha as publicações da ciência da computação. Eles estão unidos pelo fato de que muitas vezes não requerem suporte de longo prazo,eles só precisam trabalhar em um determinado momento. O jogo posicional é um jogo de longo prazo, onde a capacidade de manutenção e atualização são indicadores-chave. Isso é o que estamos fazendo e precisamos de uma boa base para termos confiança no desempenho de longo prazo do software que escrevemos e atualizamos. Esses projetos também podem começar com MVP, mas são feitos com pré-requisitos completamente diferentes.
Por que a lista de considerações para a escolha de tecnologias é exatamente assim? Há várias razões para isso. Em primeiro lugar, é desejável excluir as questões da moda e tendências da tecnologia, a fim de aumentar a previsibilidade por um longo período de tempo. Um compilador com uma longa história e uma comunidade ativa é, embora uma escolha conservadora, mas confiável, ao contrário das coisas novas e brilhantes que aparecem a cada ano. Certamente alguns deles passarão da última categoria para a primeira, mas descobriremos sobre isso mais tarde, provavelmente em anos. Em vez de tendências, estamos tentando usar a Ciência da Computação fundamental e uma grande quantidade de pesquisas neste tópico que encontraram aplicação nas linguagens de programação que usamos. Por exemplo: a teoria dos tipos é uma disciplina relacionada de matemática e ciências da computação que lida com as questões fundamentais de formalização de requisitos. Isso é exatamente o queo que precisamos para escrever software. Além disso, essa é a experiência cumulativa de outras pessoas engajadas nas ciências exatas, e é de alguma forma estúpido, em minha opinião, negligenciar essa experiência. É melhor tomar essa disciplina como base do que nada, ou tomar uma opinião subjetiva baseada na experiência de vida de uma única pessoa.
Em segundo lugar, estamos procurando a implementação do maior número de princípios que adotamos em linguagens de programação e compiladores. Por isso, além do nosso querido Haskell, o Rust começou a aparecer em nossa caixa de ferramentas. Com requisitos de tempo real e limites rígidos de uso de memória, precisamos de algo de baixo nível o suficiente. A rigidez da digitação em C ainda deixa muito a desejar, portanto, se for possível usar o Rust para tal tarefa, preferiríamos fazê-lo.
Terceiro motivo: fazemos software principalmente para nossos clientes e gostaríamos que eles fossem protegidos de nossos preconceitos. Portanto, ao escolher um instrumento, o risco não pode ultrapassar um determinado nível, que deve ser acordado com o cliente. Mas mesmo com tais condições, temos tecnologias bastante marginais como GHCJS, porque com a análise combinada dos pontos fortes e fracos, o quadro ainda era atraente para nós e nossos clientes. Já escrevemos sobre como chegamos a essa decisão: Elm vs Reflex .
Ao trabalhar com grandes bases de código e software complexo, todos os meios e justificativas teóricas são bons, porque você precisa ser capaz de, de alguma forma, manter essa complexidade sob controle. Nossa ideia da abordagem certa é defender cada peão, melhorar sua posição com suavidade e precisão, para que o projeto sobreviva em boas condições até o momento em que possa ter um papel decisivo no negócio de nossos clientes. Desejamos a você o mesmo.