Como evitar erros típicos de linguagem dinâmica?

42

Recentemente, coloquei algumas horas em JavaScript porque queria me beneficiar da enorme base de usuários. Fazendo isso, notei um padrão que a maioria das pessoas atribui às linguagens dinâmicas. Você faz com que as coisas funcionem muito rápido, mas quando o código atinge um determinado tamanho, você perde muito tempo com erros de digitação, ortografia e refatoração em geral. Erros que um compilador normalmente me pouparia. E não me procura erros na lógica quando acabei de digitar em outro módulo.

Considerando o incrível JavaScript e outras linguagens dinamicamente digitadas, sou levado a acreditar que há algo errado com a minha abordagem. Ou isso é apenas o preço que você tem que pagar?

De forma mais concisa:

  • Como você aborda um projeto JavaScript (ou qualquer outra linguagem dinâmica para esse assunto) com ~ 2000 LOC?
  • Existem ferramentas para me impedir de cometer esses erros? Eu tentei fluir pelo Facebook e pelo JSHint, o que ajuda um pouco, mas não detecto erros de digitação.
por TomTom 09.05.2016 / 15:43
fonte

5 respostas

37

Especificamente falando de JavaScript, você pode usar TypeScript . Ele oferece algumas das coisas que você está se referindo. Citando o site:

Types enable JavaScript developers to use highly-productive development tools and practices like static checking and code refactoring when developing JavaScript applications.

E é apenas um superconjunto de JS, o que significa que parte do seu código existente funcionará com o TS muito bem:

TypeScript starts from the same syntax and semantics that millions of JavaScript developers know today. Use existing JavaScript code, incorporate popular JavaScript libraries, and call TypeScript code from JavaScript.

    
por 09.05.2016 / 15:52
fonte
19

Existem algumas abordagens que podem ajudar:

Teste de unidade

Escreva testes unitários sempre que possível. Só confiar em testes manuais ou encontrar bugs na natureza é acertar e errar.

Use frameworks

Em vez de criar seus próprios e arriscar a introdução de bugs, use estruturas estabelecidas sempre que possível.

Prefiro CSS / linguagens de alto nível

Onde você pode ceder funcionalidade para CSS ou qualquer outra linguagem de alto nível em que esteja escrevendo.

Refator

Refatorize para reduzir a quantidade de código. Menos código = menos lugares para as coisas darem errado.

Reutilizar

Reutilize o código existente onde puder. Mesmo que o código não seja uma correspondência exata, pode ser melhor copiar, colar e modificar em vez de escrever algo de novo.

IDEs

Os IDEs modernos geralmente têm pelo menos algum suporte a Javascript. Alguns editores de texto também estão cientes do Javascript.

    
por 09.05.2016 / 15:56
fonte
2

Uma ferramenta que ainda não foi mencionada é a busca de texto simples, em todo o arquivo ou em todo o projeto .

Parece simples, mas quando você inclui algumas expressões regulares, é possível fazer uma filtragem básica para uma avançada, por exemplo, procure palavras localizadas na documentação ou no código-fonte.

Tem sido uma ferramenta eficaz para mim (além de analisadores estáticos), e dado o tamanho do seu projeto de 2k LOC, que não é particularmente grande na minha opinião, esperamos que funcione maravilhas.

    
por 10.05.2016 / 00:08
fonte
1

Atualmente estou refatorando vários milhares de linhas de código em um grande projeto AngularJS. Uma das maiores dificuldades é descobrir o contrato exato de uma determinada função. Às vezes, acabei lendo a documentação da API porque os elementos da resposta bruta da API foram atribuídos a variáveis que passaram por seis camadas de código antes de serem modificadas e retornadas por mais seis camadas de código.

Meu primeiro conselho é projetar por contrato . Obtenha informações específicas, produza resultados específicos, evite efeitos colaterais e documente essas expectativas usando o TypeScript ou pelo menos o JSDoc.

Meu segundo conselho é implementar tantas verificações quanto possível. Seguimos o padrão AirBnB e usamos eslint em toda a nossa base de código. Ganchos de confirmação confirmam que sempre seguimos o padrão. Naturalmente, temos uma bateria de testes unitários e de aceitação, e todos os commits devem ser revisados por um colega.

A mudança de um editor de texto (Sublime Text) para um IDE (WebStorm) também facilitou muito o trabalho com o código em geral. O WebStorm usará o JSDoc para dar dicas sobre os tipos de parâmetros esperados e aumentar o erro se você fornecer o tipo errado ou usar um valor de retorno errado.

Em JavaScript, novos recursos como símbolos e getter / setters podem ajudar a impor um certo nível de qualidade adicionando asserções à atribuição de variáveis (por exemplo, certifique-se de que o inteiro esteja dentro do intervalo ou que o objeto de dados tenha determinados atributos). / p>

Infelizmente, não acho que exista uma solução verdadeira para evitar erros dinâmicos de linguagem, apenas uma série de medidas que podem ajudar a reduzir sua frequência.

    
por 18.05.2016 / 13:00
fonte
0

Minha resposta à pergunta "Como você aborda um projeto JavaScript (ou qualquer outra linguagem dinâmica para esse assunto) com ~ 2000 LOC?"

Eu desenvolvo aplicativos de formulários em PDF. Abordo meu projeto de desenvolvimento de software JavaScript (independentemente do tamanho do código-fonte) usando os elementos líquidos e as anotações de Petri. O método não está vinculado a nenhuma tecnologia de linguagem de programação específica. Assim, pode ser usado para outras “linguagens de programação”.

Eu crio um diagrama da lógica do aplicativo. Para manter o diagrama organizado, adiciono a maioria das minhas anotações a um formulário que uso com o diagrama. As entradas no formulário incluem referências a propriedades ou funções. Em seguida, escrevo o código-fonte com base nas informações do diagrama e nas entradas do formulário. O método é sistemático porque todo código-fonte escrito é mapeado diretamente a partir do diagrama e das entradas no formulário. O código-fonte pode ser facilmente verificado porque também sigo as convenções de nomenclatura e codificação quando escrevo o código.

Por exemplo, escolhi uma convenção de que todas as funções são protótipos. Se o desempenho se tornar um problema, ele poderá ser melhorado declarando as funções no construtor. Para algumas propriedades, uso matrizes. Novamente, se o desempenho se tornar um problema, ele poderá ser aprimorado usando referências diretas.

Eu também uso o eval. Isso pode reduzir muito o tamanho do código-fonte. Devido a problemas de desempenho, eu uso eval no início ou parte de inicialização do meu aplicativo; Eu nunca uso isso na "lógica de tempo de execução" - essa é outra convenção de codificação que eu sigo.

    
por 25.07.2016 / 00:36
fonte