(e como não ser um guru cujos conselhos deixam de trabalhar após a atualização)
“Os aplicativos só podem usar APIs públicas e devem ser executadas no sistema operacional de envio atualmente”. Diretrizes de revisão do aplicativo da Apple
Se você já começou a trabalhar com uma nova estrutura e se pegou pensando: “Agora vou entender tudo, a documentação é para os furos”-você definitivamente não está sozinho. Muitos desenvolvedores têm um instinto natural: primeiro tentativa, e só então – leia. Isso está bem.
Mas é nesta fase que você pode desligar facilmente o caminho certo e se encontrar em uma situação em que o código funciona … mas apenas hoje, e apenas “eu tenho”.
Por que é fácil “descobrir” – não é suficiente?
Freimvorki, especialmente fechado e proprietário, é complexo e multi -camada. Eles têm muita lógica oculta, otimização e recursos de implementação, que:
* não documentado;
* não garantido;
* pode mudar a qualquer momento;
* são um segredo comercial e podem ser protegidos por patentes
* contém bugs, falhas conhecidas apenas pelos desenvolvedores da estrutura.
Quando você age “em um palpite”, você pode facilmente criar arquitetura em observações aleatórias, em vez de suporte nas regras claramente descritas. Isso leva ao fato de que o código se torna vulnerável a atualizações e casos de borda.
A documentação não é uma restrição, mas suporte
Os desenvolvedores de estruturas criam manuais por um motivo – este é um acordo entre você e eles. Enquanto você está agindo como parte da documentação, eles prometem:
* estabilidade;
* apoiar;
* comportamento previsível.
Se você vai além dessa estrutura – tudo o que acontece se tornará exclusivamente sua responsabilidade.
Experimentos? Certamente. Mas no quadro das regras.
A curiosidade é a super -via do desenvolvedor. Explore, tente limites não padrão e de teste – tudo isso é necessário. Mas há um importante “mas”:
Você precisa experimentar a estrutura da documentação e práticas recomendadas.
A documentação não é uma prisão, mas um cartão. Ela mostra quais oportunidades são realmente planejadas e apoiadas. São esses experimentos que não são apenas úteis, mas também seguros.
CUIDADO: GURU
Às vezes você pode encontrar “especialistas” reais:
* Eles conduzem cursos
* realizar em conferências,
* Escreva livros e blogs,
* compartilhou “sua abordagem” à estrutura.
Mas mesmo que pareçam convincentes, é importante lembrar:
Se suas abordagens são contrárias à documentação, elas são instáveis.
Tais “padrões empíricos” podem:
* trabalhar apenas em uma versão específica da estrutura;
* ser vulnerável a atualizações;
* Break em situações imprevisíveis.
Guru é legal quando eles respeitam os manuais. Caso contrário, suas dicas devem ser filtradas através da documentação oficial.
um pouco sólido
Três idéias de princípios sólidos são especialmente relevantes aqui:
* Princípio aberto/fechado: expanda o comportamento por meio de uma API pública, não entre no interior.
* Princípio da Substituição de Liskov: não confie na implementação, confie no contrato. Distúrbios – tudo quebrará ao substituir a implementação.
* Inversão de dependência: os módulos de nível alto não devem depender de módulos de baixo nível. Ambos os tipos devem depender de abstrações. A abstração não deve depender dos detalhes. Os detalhes devem depender de abstrações.
O que isso significa na prática? Se você usa uma estrutura e ligado diretamente aos seus detalhes internos – você viola esse princípio.
Em vez disso, você precisa criar dependência de interfaces públicas, protocolos e contratos que a estrutura apóie oficialmente. Isso dá:
* o melhor isolamento do seu código das alterações na estrutura;
* a capacidade de testar e substituir facilmente as dependências;
* Comportamento previsível e estabilidade da arquitetura.
Quando seu código depende dos detalhes, e não de abstrações, você literalmente se incorporou em uma implementação específica que pode desaparecer ou mudar a qualquer momento.
e se o bug?
Às vezes acontece que você fez tudo certo, mas funciona incorretamente. Isso acontece – as estruturas não são perfeitas. Nesse caso:
* Reúna um exemplo mínimo reproduzido.
* Certifique -se de usar apenas API documentada.
* Envie um bug-port-Eles definitivamente o entenderá e, provavelmente, ajudará.
Se o exemplo for construído sobre hacks ou desvios, os desenvolvedores não precisam apoiá -lo e provavelmente seu caso simplesmente perderá.
Como espremer o máximo da estrutura
* Leia a documentação. Seriamente.
* Siga os guias e recomendações dos autores.
* Experimento – mas dentro do descrito.
* Verifique as dicas (até os alto -falantes mais famosos!) Através do manual.
* Dobre os bugs com casos mínimos e respeito pelo contrato.
Conclusão
Freimvorki não são caixas pretas, mas ferramentas que possuem as regras de uso. Ignorá -los significa escrever o código “aleatoriamente”. Mas queremos que nosso código viva por um longo tempo, encanta usuários e não rompe com a atualização menor.
Então: confie, mas verifique. E sim, leia os manuais. Eles são sua superpotência.
Fontes
https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM
