Trabalho, portanto, em minha pesquisa sobre as dificuldades de apoiar o Legacy e percebi um ponto óbvio que perdi completamente de vista.
Usuários e desenvolvedores de IDE têm problemas para entender suas ferramentas. Usado de forma intuitiva e de qualquer maneira. Surpreendentemente (agradável), esse uso quase não entra em conflito com a ignorância, embora dê origem a holívoros correspondentes nos fóruns.
Agora, analisaremos como as coisas estão em desenvolvimento com ferramentas, o que há de errado com o conceito de "IDE" e quais ferramentas deveriam aparecer, mas ainda não foram desenvolvidas.
E
Não será uma descoberta que o ambiente seja diferente para projetos diferentes. Mesmo se eles trabalharem em uma pilha. Pode ser usado:
- Diferentes maneiras de interagir com o usuário, o que dá uma grande discrepância em como o projeto começa e como é testado. (CLI, TUI, focinho da web, GUI no sentido de Qt, GTK etc.)
- Diferentes estruturas de teste (unittest em um projeto, pytest em uma adjacente, no contexto de Python). As ligações de testes multiníveis (por exemplo, combinando as conclusões de testes independentes e integração por meio da TAP) também se enquadram aqui.
- VCS diferentes, mas em algum lugar pode haver híbridos (Git, como cliente do Subversion em um caso especial).
- Dentro do mesmo projeto pode ser usado, incluindo vários editores. Por exemplo, Vim ou nano para editar um script de rebase interativo no Git, para editar pedaços com registro parcial de alterações. Ou para editar configurações abaixo da raiz.
E essas estão longe de todas as opções, acho que qualquer desenvolvedor com experiência em 2 ou mais projetos pode dar exemplos mais semelhantes. Frequentemente, eu os ouço na forma da história "Como passei dois dias para montar um projeto para um novo emprego".
A partir disso, podemos concluir que o layout e a configuração do ambiente de desenvolvimento estão em qualquer caso com o usuário.
Integrado?
Dado o exposto, faz sentido considerar ambientes não "integrados", mas "integráveis" .
Então, do ponto de vista do usuário, uma boa ferramenta de integração é quando:
- O ambiente é configurado rapidamente.
- Sua configuração pode ser armazenada e transferida.
- Capacidade de aumentar o ambiente de trabalho "um botão".
Por exemplo, Unixoids experientes costumam reduzir a "transição para o modo de trabalho" para uma equipe.
"Rápido" aqui não significa "fácil para iniciantes" . Pessoalmente, minha posição sobre esse assunto é: a dependência da complexidade da solução do problema e da complexidade da tarefa em si deve ser pelo menos linear.
Outro ponto não óbvio: a interface pode não ser uniforme.
O exemplo mais comum é usar a GUI e a CLI em um projeto.
Falei sobre o uso de vários editores ao trabalhar no mesmo ambiente em um projeto.
Desenvolvimento
Agora podemos prosseguir diretamente para as próprias ferramentas.
Navegadores de reatores
É impossível criar um refator de navegador poderoso e universal simplesmente porque a refatoração não existe agora, como, condicionalmente, uma disciplina acadêmica.
Afinal, o livro de Fowler é construído em torno de Java com etapas mínimas para o lado. Além disso, as técnicas de refatoração estão tão ligadas ao contexto da "biblioteca de linguagem de estilo" que são geradas no local por cada programador.
Acredito que os princípios básicos da refatoração podem ser descritos do ponto de vista de percorrer a árvore de dados em seções de código, e técnicas específicas já podem ser extraídas delas . Para fazer isso, a implementação do refator do navegador deve ter:
- Interface facilmente extensível (para exibir as técnicas criadas pelo desenvolvedor para suas necessidades específicas)
- Os analisadores, a base (os princípios mencionados acima) e o esquema de edição devem ser ocultados para deixar ao desenvolvedor a oportunidade de expandir o conjunto de técnicas sem ter que se preocupar com o editor. Ou seja, DSL para descrever técnicas de refatoração.
- Como a extensibilidade será seguida por um aumento acentuado no número de recepções, para exibição, é necessário levar em consideração o escopo do contexto para exibir no menu de seleção apenas as operações aplicáveis em uma situação específica.
Análise de árvore de dados de tempo de execução.
Esse aspecto é sobre a combinação de depuração e edição de texto. De fato, para a grande maioria dos idiomas, para verificar como as mudanças afetam o programa, é necessário um reinício explícito do programa. Muito mais fácil e mais visual (e, como resultado, com menos erros possíveis), será possível ver em um único espaço como a matriz de dados inteira na seção depurada do código muda conforme o código é editado .
O desenvolvimento dessa ferramenta para diferentes idiomas diverge bastante em complexidade, e isso não é apenas uma questão de sintaxe, sistema de tipos e recursos de desempenho, mas também a essência de cada idioma individual. Para uma linguagem orientada a dados, criar isso é muito mais fácil. Exemplo: construtores de expressão regular, onde no processo você pode ver imediatamente quais partes do texto o texto regular cobre.
O mais, na minha opinião, o item mais importante nesta lista incompleta.
Dividimos todas as informações que o desenvolvedor precisa, programando diretamente em dois grandes grupos
- Documentação
- Recepções \ heurísticas de desenvolvimento.
Primeiramente, para simplificar o trabalho do programador, o acesso à documentação deve ser diretamente da janela do editor.
Vários IDEs e editores resolvem bem esse problema: IDEs específicos da linguagem da Microsoft, Emacs, com seu modo Info, Frescobaldi, Sunny Builder; tanto para integrado na fonte quanto para externo. No entanto, muitas bibliotecas e estruturas agora carregam sua documentação apenas na rede e / ou usam formatos diferentes para armazená-la, o que complica a possível integração em uma única interface.
O segundo grupo é muito mais interessante.
Ele abrange conhecimentos, programação e desenvolvimento como um todo, e métodos específicos para uma determinada linguagem / pilha. No momento, esse nicho é quase completamente capturado pelo Stack Overflow, e existe até sua integração no IDE, mas a qualidade do conhecimento geralmente é baixa . Para o bem, será muito mais eficiente selecionar boas decisões, erros, truques e reduzi-lo a uma determinada base com a qual o usuário possa entrar em contato quando precisar resolver seu próprio problema.
Além disso, os analisadores modernos permitem avisar sobre possíveis erros ainda não confirmados . Na verdade, temos, de um ponto de vista técnico, tudo o que precisamos para criar sistemas especializados para desenvolvedores que oferecem soluções à medida que escrevemos / editamos código. O que falta são apenas as bases / métodos / erros de decisão.
Conclusão
Então, o resumo:
- O desenvolvimento de navegadores de refatoração deve basear-se em operações na árvore de dados e ser reduzido a uma descrição de scripts do tipo DSL para edição automatizada de código.
- Os analisadores de tempo de execução devem exibir instantaneamente as alterações de dados durante a edição e gravação de um programa. Ou seja, a abordagem JAI pode ser aplicada a outras linguagens de programação.
- Remova o navegador da Web dos casos do usuário como uma maneira de pesquisar e ler a documentação.
- Precisamos desenvolver sistemas especializados de plug-in (devido ao fato de o ambiente ser diverso) que ajudarão o desenvolvedor a tomar decisões no processo.