Não vamos falar sobre preços da habitação, engarrafamentos e fumaça. . . Deixe -me falar primeiro sobre minha experiência usando o Node.js nos últimos seis meses. . . Todos são problemas encontrados no trabalho e lições sangrentas. .
1. Número preciso da versão
"Você deve ser preciso para o número específico da versão! Use * para rolar diretamente, ^ e ~ não estão bem!" Assim que chegamos à empresa de manhã, nosso servidor estava coberto de olhos de sangue (provavelmente foi a que horas da manhã ir para a cama) e reclamou para mim: "Droga, a versão no Código Package.json que escrevi antes é diferente da versão em execução no servidor. Instale o mais recente e depois relatasse um erro". Alguns milhares de palavras são omitidas aqui. . .
Tudo bem. Vou me dar um tapa na cara primeiro. Eu costumava usar apenas *. . . Na maioria das vezes, não há necessidade de escrever um número de versão morta e também é possível usar ^ e ~. Digitalize a cegueira:
Semver
Gerenciamento de versão em Node.js
2. Teste
Certifique -se de escrever casos de teste. Tome -me, por exemplo. A peça pela qual sou responsável contém a parte de filtragem (usando o texto do filtro do Shenma regular para extrair texto útil). Com os casos de teste, após cada alteração das regras de filtragem, é absolutamente verdadeiro no teste NPM. Escolha os módulos de teste a serem usados de acordo com suas preferências pessoais, Mocha, deve, fita adesiva, toque, supertest, etc.
Tente executar localmente e faça o upload para o servidor após o sucesso do teste. Modifiquei o código várias vezes (apenas mudei algumas linhas) e pensei que poderia haver um problema, mas assim que o servidor foi reiniciado, ele desliga. . Caramba, falta colchetes ou algo assim. . Esse problema também pode ser detectado usando plug -ins de editor, como JSLint ou JSHint.
Backup de código do servidor. O método que estou usando: a princípio, havia dois projetos idênticos no servidor (biblioteca Git, nomes de arquivos diferentes), um em execução e o outro como um backup. Quando houver alterações de código, vá para o projeto de backup para puxar o git, pare o programa em execução e inicie o programa de backup. Se o programa não falhar por um período de tempo, significa que parece relativamente estável, considere esse projeto como principal e outro projeto como a preparação. Quando houver outra alteração, repita as etapas acima e o interruptor principal e de backup para frente e para trás. Se o programa falhar, volte para um backup mais estável.
3. Use Debug
A depuração é inevitável ao escrever programas. Muitas pessoas gostam e estão acostumadas a usar o Universal Console.log (), inclusive eu. . Pessoalmente, depois de usar o console.log () para ajustá -lo, exclua -o ou comente. Pode ser usado mais tarde se você o excluir, mas é muito feio comentar. Você também pode usar o módulo de depuração neste momento. Nenhum inspetor de nó ainda foi usado, portanto, nenhuma avaliação é feita.
4. Mantenha o código simples
Tentar realizar mais coisas com menos código também é uma melhoria e teste de suas próprias habilidades. Inclui indentação correta, nomes de variáveis apropriados, organização de código claro, etc. O código é mais fino e bonito. Quando algo dá errado, é mais rápido verificar o erro. É melhor do que descobrir o que um código confuso faz e leva várias horas para fazê -lo.
Se a equipe não estiver usando o CoffeeScript, não o use. Primeiro, outros não conseguem entender seu código para ajudá -lo a corrigir erros. Segundo, o número de linhas que aparecem após um erro é diferente do número de linhas exibidas no código do café. . . Seu próprio projeto de código aberto pode ser usado.
5. Peça mais conselhos e continue pensando independentemente
Quando comecei a trabalhar, também fiquei confuso, incluindo deficiências técnicas e falta de lógica de negócios. Eu sempre perguntei aos caras grandes da equipe. Depois, tentarei compensar as deficiências técnicas e esclarecer a lógica de negócios. Mais tarde, eu queria projetar uma API de acordo com os requisitos do PM, que não apenas levou em consideração as necessidades dos usuários (a situação de vários clientes), as necessidades e o comportamento dos clientes, o design do banco de dados (como armazenar menos redundância, menos consultas, fácil de expandir, facilitar a modificação e as diferentes consultas) etc. . . Embora eu tenha discutido com você muitas vezes, isso sempre me dá lógica e não me diz o método. Mais tarde, finalmente encontrei uma solução muito boa. . Mais tarde, ele me disse que queria que eu continuasse pensando de forma independente para resolver problemas para que eu pudesse melhorar. .
6. Use bibliotecas existentes
Atualmente, existem quase 9W módulos de terceiros no NPM. Em teoria, tudo o que você deseja usar pode ser encontrado no NPM. Obviamente, existem muitos módulos excelentes no NPM, com documentação abrangente e uso muito conveniente, que geralmente atendem às necessidades. Se você achar que um módulo pode atender à maioria das necessidades, ele pode ser melhorado funcionalmente ou possui erros, você pode ir ao GitHub para adicionar PR. Se você achar que não consegue encontrar um módulo satisfatório, pode criar e publicá -lo no NPM para compartilhar com você. Obviamente, se você achar que um certo tipo de módulo que implementa uma determinada função é muito merda, você também pode publicar uma merda.
7. Mantenha -o simples
Se você deseja exibir um gráfico de pizza, basta usar a tela HTML5 ou CSS3. Não há necessidade de usar a biblioteca C ++ Canvas para desenhar uma figura "a biblioteca da qual depende é de mais de 400 MB", disse isso.
8. Boa documentação
A boa documentação é o canal mais importante para os clientes se comunicarem com as equipes do servidor. O documento está claramente escrito. Se o erro de solicitação do cliente ocorrer, você poderá verificar primeiro o documento (como o que cada código de erro representa), em vez de pedir ao servidor que discutisse toda vez que houver um problema. PS: Alguns exemplos de solicitação HTTP devem ser gravados em Curl, em vez de objetos em JS, etc. Você pode entender muito bem, mas o cliente não entende JS.
9. Arquivo de configuração
Crie um arquivo de configuração em cada diretório do projeto, como config.js/config.json. Em vez de escrevê -lo morto no código. como:
{
"App": 3000,
"Mongo": {
"Host": "localhost",
"Port": 27017
},
"Redis": {
"Host": "localhost",
"Port": 6379
}
...
}
10. Use PM2
O uso de ferramentas de gerenciamento de processos como o PM2 é muito conveniente e o processo pode ser reiniciado automaticamente se falhar. Não usei para sempre, sem avaliação. . Também há grunhido. Eu não usei antes, então não vou comentar.