Níveis de qualidade no front-end (tradução) | Blog do Sérgio

Blog do Sérgio | Desenvolvedor front end


fev/10

17

Níveis de qualidade no front-end (tradução)

O trabalho de um programador front-end é um desafio. Nosso trabalho não é uma das regras, mas de recomendações e melhores práticas. Com cada projeto, tentamos melhorar nossas habilidades e esperamos ficar melhores no que fazemos, mas o caminho para o sucesso nem sempre é muito claro. Podemos aprender muito com nossos erros do passado, mas dicas de como melhorar a nós mesmos podem ser igualmente estimulantes. Este artigo irá dizer-lhe por onde começar.

Como definir a qualidade:
Se você já teve que julgar o código de alguém que você já deve saber o quão difícil é colocar uma espécie de grade sobre ele. Não só por causa das diferenças de estilos de codificação, mas também porque a qualidade do código final pode não estar a altura de sua face. A maneira mais rápida para julgar é dar uma olhada no código fonte do HTML, CSS e JavaScript, isso irá dizer-lhe muito.
Não estou muito interessado em definir uma escala de classificação, uma vez que é completamente impossível de qualquer maneira. Eu acho que é mais importante para definir que áreas e escopos existem para definir a qualidade do código front-end. Na minha experiência, existem quatro níveis importantes que precisam ser levados em consideração. Vou começar com o mais fácil e a mais simples, trabalhando a minha maneira.

1. Criando uma página:
Eis onde começa tudo. Você faz ou recebe um projeto, sente-se na frente de seu computador, você escolhe seu navegador favorito e começa a trabalhar. Escrever um HTML, CSS e JavaScript para combinar com um design funcional é um desafio no início. Como um não-designer que me levou algum tempo para entender as delícias de um bom design e de traduzir os para uma página da web. Por outro lado, esta é provavelmente a parte mais fácil do trabalho.
Para além das questões de design, você também tem que se preocupar sobre como escrever um código válido e você tem que ter certeza que sua página é acessível a pessoas que não utilizam navegadores regulares. Para a maioria das pessoas isso vai abrir portas para um mundo novo e desconhecido, mas é essencial dar uma qualidade global ao seu código.
Verificar a qualidade deste primeiro nível é bastante fácil. Validadores de código, uma rápida olhada em toda a fonte e rapidamente a digitalização da página com CSS desabilitado irá dizer-lhe muito. Mas claro, isso é só o começo.

2. Fazendo um trabalho de cross-browser e cross-platform:
Tempo para diminuir o zoom. Fazer uma única página para trabalhar em seu navegador favorito é uma coisa, ter certeza que ele funciona bem em uma variedade de navegadores e sistemas operacionais é um desafio completamente diferente. Primeiro de tudo, é importante notar que não é necessário que a página apareca exatamente do mesmo jeito em todos os navegadores. Para navegadores mais antigos, basta fazer o olhar e trabalhar bem, só que sem as coisas extravagantes. É importante certificar-se de que todas as funcionalidades ainda estejam lá. Sacrificar a funcionalidade essencial não é simplesmente feito.
Normalmente se preocupar com a compatibilidade do navegador é algo que acontece depois, mas é realmente importante ter isso em mente quando você começa em um projeto. Algumas técnicas funcionam melhor que outras, alguns problemas são mais fáceis de resolver do que outros. A escolha de um navegadorfuncional é muito importante de inicio. Conhecendo as entradas e saídas de navegadores e mudar um pouco o seu curso de código para afastar das grandes questões é um processo longo e cansativo, mas ajuda a melhorar a qualidade do seu código, um grande negócio.
Medir a qualidade real deste nível é um pouco mais difícil, embora o comprimento do navegador na fase de testes é uma boa indicação disto. Quando mais cedo você começa, mais fácil será para resolver os problemas do navegador, a realização destas terefas farão com que todos os browsers mostrem a página em uma forma aceitável. Mas, mesmo assim, alguns erros extremamente obscuros podem mantê-lo acordado a noite toda (ou a semana toda).

3. fazer um site:
Tempo para diminuir o zoom, mais uma vez. Um site é mais do que uma simples coleção de páginas. Você notará que vários componentes serão apresentados em páginas diferentes dentro do site, você vai notar também que arquivos CSS e JavaScript será utilizado em várias páginas dentro do site. Manter seu código consistente em todas as páginas pode ser muito mais difícil do que você imaginava.
A chave é pensar em componentes. HTML é uma linguagem descritiva, de forma independente da visualização ou do contexto, um bloco de “determinados conteúdos” deve sempre ser construído usando o html mesmo. Um exemplo que eu gosto de usar é o de um artigo de notícias. Isto pode aparecer em um bloco de focos separados, em uma lista resumida, como um resultado de pesquisa ou como um todo em uma página de detalhes. Basicamente é sempre a mesma coisa (um artigo de notícia), para a parte semântica do HTML (também acho que nomes de classes) devem ser os mesmos para todas essas instâncias. Variações no projeto devem ser baseados no contexto, pela definição de variantes (adicionando uma classe base extra para a diferenciação). Uma vez que você tem tudo isso coberto, a escrita correta do CSS e JavaScript deve ser muito mais fácil e a duplicação de código será reduzida.
Este nível é bastante fácil de controlar. Basta tomar algumas páginas de um site, destacar alguns componentes com variantes de design claro e verificar como são construídos e decorados. Se não houver uma base comum, esta certamente irá afetar a qualidade do seu site a longo prazo.

4. estabilidade e flexibilidade:
Os três níveis acima são todos importantes, mas, mesmo combinados todos os três critérios, a qualidade do seu código ainda pode ser bastante duvidosa. Seu código só será realmente brilhante quando ele se mostra estável e flexível. O problema é que você pode apenas usar esta medida quando se é efetivamente demasiado. Você pode olhar para vários indicadores embora.
O primeiro é quando você estiver chegado ao ponto de “os 5 últimos bugs”. Estas são alterações de última hora ou bugs com prioridade ligeiramente mais baixa que você adia porque eles são muito difíceis de corrigir. Você sabe que fez um bom trabalho quando você pode eliminá-los rapidamente. Por outro lado, se a fixação desses erros introduz novos ou requer retrabalhos de seções completas, ainda há muito espaço para melhorias.
Outro bom indicador é a “fase 2″. Como você está bem preparado para incorporar as alterações de design funcional sem arruinar seu site. Você pode deixar cair um componente existente em outro lugar sem ter que refazer todo o css? Você pode fazer a sua coluna da esquerda mais adaptando o mínimo de valores CSS e sem qualquer images recutting? Você pode criar uma variante de concepção de um componente sem ter que entregar o código HTML novo? Como é que fácil trocar de lugar com os componentes? O que se mede uma trilha de duas linhas? Todos estes elementos são indicadores da estabilidade e flexibilidade de seu código.

Conclusão:
Se o nível de qualidade alcançado for 4, sua missão não foi cumprida, pode custar-lhe muito tempo, esforço e dinheiro. Perguntas simples de seu cliente teram que ser respondida por respostas técnicas complicadas, seu cliente realmente não importa. Levará a horas extras, prazos não cumpridos, o estresse e um declínio na relação com seu cliente.
É um sério processo de aprendizagem que, como flexibilidade e estabilidade são apenas alcançados por dominar os 3 primeiros níveis e evoluir a partir daí. Se você quer melhorar suas habilidades, olhar para tráz e rever seu conceitos são uma boa dica. Veja onde você escorregou e pense em maneiras de se certificar de que não acontecerá novamente. Se você fizer isso com cada projeto, o céu é o limite.

Este artigo é uma tradução, o documento original pode ser encontrado em: front-end quality levels (http://www.onderhond.com/blog/work/front-end-quality-levels)

· · · ·



12 comentários

Deixar um comentário

<<

>>