Application Structure LIFT Principle

ou Princípio da estrutura LIFT na aplicação

LIFT

  • Estruture a sua aplicação de um modo onde você possa: Locate (Localizar) seu código rapidamente, Identify (Identificar) o código facilmente, manter a estrutura a mais Flattest (Plana) que você conseguir, e Try (Tentar) seguir o conceito de DRY (Don't Repeat Yourself - Não repita a si mesmo). A estrutura deve seguir essas 4 regras básicas.

    Por que LIFT?: Fornece uma estrutura consistente que escala bem, é modular, e torna mais fácil para aumentar a eficiência ao desenvolver, pois encontra-se o código rapidamente. Outra forma de verificar a estrutura da sua aplicação é se perguntar: Quão rápido é para você abrir e trabalhar em todos os arquivos relacionados com uma funcionalidade?

    Quando estou sentindo que não estou confortável com a minha estrutura, eu volto e revisito as regras do LIFT

    1. Locating (Localizar) nosso código é fácil
    2. Identify (Identificar) o código rapidamente
    3. Flat (Plano) - Deixar a estrutura a mais plana que conseguirmos
    4. Try (Tentar) se manter DRY (Don’t Repeat Yourself - Não repita a si mesmo) ou T-DRY

Locate

ou Localizar

  • Torne a localização do seu código: intuitiva, simples e rápida.

    Por que? Acho que isso é super importante para um projeto. Se a equipe não pode encontrar rapidamente os arquivos que precisam para trabalhar, eles não serão capazes de trabalhar da forma mais eficiente possível, e a estrutura precisa mudar. Você pode não saber o nome do arquivo ou onde os arquivos relacionados estão, por isso, colocando-os nos locais mais intuitivos e próximos uns dos outros, economiza uma boa parcela de tempo. Uma pasta descrevendo a estrutura pode ajudá-lo.

    /bower_components
/client
  /app
    /avengers
    /blocks
      /exception
      /logger
    /core
    /dashboard
    /data
    /layout
    /widgets
  /content
  index.html
.bower.json

Identify

ou Identificar

  • Quando você olhar para um arquivo, prontamente você deve saber o que ele contém e o que representa.

    Por que? Você gasta menos tempo caçando e procurando por código, e torna-se mais eficiente. Se isso significa nomes de arquivos mais longos, então que assim seja. Seja descritivo nos nomes de arquivos e mantenha o conteúdo do arquivo somente com 1 componente. Evite arquivos com vários controladores (controllers), múltiplos serviços (services), ou uma mistura. Existem exceções de 1 regra por arquivo quando eu tenho um conjunto de recursos muito pequenos que estão todos relacionados uns aos outros, eles ainda são facilmente identificáveis.

Flat

ou Plano

  • Mantenha uma estrutura plana de pastas o máximo que for possível. Quando você tiver 7 arquivos ou mais, comece a considerar separá-los.

    Por que? Ninguém quer pesquisar 7 níveis de pastas para encontrar um arquivo. Pense sobre menus em web sites - nada mais profundo do que 2 níveis deve ser levado a sério. Em uma estrutura de pastas não há nenhum número mágico, mas quando uma pasta tem 7-10 arquivos, pode ser a hora de criar subpastas. Baseie-se no seu nível de conforto. Use uma estrutura mais plana até que haja um valor óbvio (para ajudar o resto do LIFT) na criação de uma nova pasta.

T-DRY (Try to Stick to DRY)

ou Tente manter-se em DRY - Não repita a si mesmo

  • Mantenha-se DRY, mas não fique louco e sacrifique a legibilidade.

    Por que? Não ficar se repetindo é importante, mas não é crucial se acabar sacrificando os outros itens do LIFT, por isso eu chamo de T-DRY (Tente não ficar se repetindo). Eu não quero escrever session-view.html para uma view, porque obviamente é uma view. Se não é óbvio ou uma convenção, então eu renomeio.

De volta ao topo