Trabalho como desenvolvedor iOS há mais de seis anos. Eu trabalhei em várias empresas e equipes diferentes. Trabalhei tanto na terceirização quanto na terceirização, até tive a chance de participar da startup. E agora, após vários anos de desenvolvimento comercial, bem como alguns anos de programação na universidade, comecei a destacar alguns princípios ou regras para uma abordagem qualitativa ao desenvolvimento de aplicativos. No começo, foi um conselho para meu amigo. Dando-lhe conselhos, pensei que me faltava esse conselho quando estava apenas iniciando meu caminho de desenvolvimento. O que posso dizer, alguns momentos que percebi por mim há relativamente pouco tempo e outros já estão em um novo local de trabalho. Então surgiu a idéia de fazer uma lista de dicas que eu gostaria de compartilhar comigo cinco a seis anos atrás. Tenho certeza de que daqui a cinco anos terei algo a dizer para mim hoje. Mas provavelmente deixaremos isso para o futuro.
Seu código está ruim
E a primeira coisa que gostaria de dizer a mim mesma como antes é: "Seu código está ruim!". Nas pessoas comuns, "govnokod". E meus colegas estrangeiros no workshop de desenvolvimento têm "código de macaco".
Não, não foi isso que você pensou. Não quero enfatizar que costumava ser um codificador ruim e agora meu código é perfeito. Quero reformular esta mensagem e transmitir três pontos-chave no sentido deste conselho.
"Seu código foi e será ruim!"O primeiro momento: não existe um código perfeito, ninguém estabelece a arquitetura ideal e não existe um código em que não haja bugs. Eu acho que muitos se pegaram pensando que não poderiam descobrir a nova biblioteca ou a nova tecnologia. Ou alguns de nós tentamos escrever o recurso perfeitamente, seguindo todos os princípios de OOP, SOLID. O que, por sua vez, levou a muito tempo e, às vezes, a um beco sem saída. Às vezes, nas tentativas de escrever o código perfeito, nasceram monstros que carregavam uma lista completa de padrões que o desenvolvedor conhece, ou talvez até mais.
Com a minha frase, gostaria de transmitir a ideia de que você não deve se preocupar antes de tudo, ficar nervoso com a qualidade do seu código. É impossível prever tudo. E é melhor relaxar, escrever com mais facilidade e, como você sabe, do que sofrer e se preocupar em vão. Com a experiência, as decisões virão sozinhas. Às vezes é necessário "nagovodnodit", eles encontrarão problemas que esse código de merda causará e entenderá de uma vez por todas que é melhor não fazer isso.
O segundo momento, que mencionei anteriormente, é que é quase impossível prever tudo. Sim, com a experiência vem a compreensão do que você está fazendo E você pode prever o caminho de desenvolvimento do projeto. Mas isso vem com a experiência. E se a experiência não for suficiente, você não deve tentar tornar o código universal. Há casos frequentes em que seu recurso, que você pensou por um longo tempo e com tanto cuidado no início e depois escreveu, é simplesmente descartado do aplicativo. Além disso, há casos em que os aplicativos mudam apenas porque na mente do cliente tudo parecia diferente. E após longas horas de transferência meticulosa da interface do design para o código, 100.500 alterações aparecem repentinamente. Este é apenas o começo, porque após o primeiro refazer, mais e mais novas edições chegarão. E, no caso em que o desenvolvedor não tem experiência suficiente, esse processo pode levar não apenas muito tempo, mas também não traz as sensações mais agradáveis que são desencadeadas por pensamentos desagradáveis em algum lugar nos cantos secretos da mente, transformando o processo de desenvolvimento de uma lição divertida em uma dor infernal. Portanto, cuide dos seus nervos e não se adapte ao ideal. Às vezes você pode conversar um pouco.
Terceiro ponto: este é novamente um momento puramente psicológico, ou seja, críticas de outros desenvolvedores. Como todos sabem, todos os desenvolvedores domésticos consideram qualquer outro código de merda de código. Mesmo que lhe seja mostrado seu próprio código, que ele não reconhece, é provável que o chame de merda. Muitas vezes, essas críticas são acompanhadas pela satisfação moral do próprio crítico. Como observado por desenvolvedores experientes, são as pessoas que chamam mais frequentemente o código de alguém de govnodkod exatamente aquelas que ao mesmo tempo novnokovodil mais que. E quanto mais alguém grita "govnokod", mais seus "bolos" ele deixa em seu caminho.
Além disso, qualquer virgem que se lembre de jovem deve necessariamente admitir que ele foi um novocódigo da fama.
Portanto, recomendo que você use a expressão "Seu código foi e será uma merda", como um escudo contra as críticas nem sempre construtivas. Também quero observar que seu código sempre será uma merda, porque o desenvolvimento não fica parado. Todos os anos, a qualidade do seu código só melhora. Portanto, o código atual acabará se transformando em govnokod.
Dividir e conquistar
Não quero que pareça aconselhar apenas govnokod; portanto, começarei a dar conselhos sobre como evitar esse código incorreto. E gostaria de começar com o princípio que me anulei. Não, isso não é herança ou polimorfismo, e não é um dos princípios do SOLID. Eu chamo esse princípio de Divida e Conquiste.
Sim, existe decomposição.
Decomposição - a divisão do todo em partes. Além disso, a decomposição é um método científico que usa a estrutura do problema e permite substituir a solução de um grande problema por uma série de tarefas menores, embora interconectadas, mas mais simples.
Como a Wikipedia diz. Mas isso é apenas parte do que ponho no significado do meu princípio. Definitivamente sim, você precisa dividir o projeto e as tarefas em partes menores. Mas quero dizer a abordagem conceitual para a separação de grupos lógicos no projeto.
E a primeira coisa que me refiro a esse princípio é a separação da interface do usuário E da lógica de negócios do aplicativo. Parece que agora sou capitão direto de evidências. Mas! Na prática, esses limites costumam ser embaçados e o ViewController ou Activity contém uma parte da lógica de negócios.
Eu acho que um exemplo da tela "Login" será simples e compreensível. Aqui, o desenvolvedor começa a implementar a arquitetura MVC. Parece que há uma visão separada, como o Controller with Model também adiciona, como deveria. Mas em algum momento eles pensam: "Por que preciso adicionar várias classes para a tela com um único botão?" e, neste momento, recomendo abandonar esses pensamentos cruéis e seguir estritamente o princípio de "Dividir e conquistar" para separar a interface do usuário e a lógica de negócios. E mesmo que a arquitetura exija a adição de uma classe ViewModel, na qual haverá duas linhas de código, você deve fazê-lo. Porque geralmente há casos em que uma tela na qual havia originalmente um botão, ao longo do tempo, passa a dificuldades impensáveis. Se você seguir a separação dos componentes lógicos com antecedência, isso facilitará muito a vida no futuro.
Você pode sentir especialmente a essência da separação estrita da interface do usuário e lógica, nos casos em que é necessário transferir telas de um projeto para outro. Ou em uma situação em que, sob condições diferentes, algoritmos diferentes são usados na lógica de negócios. Por exemplo, dividindo a tela de autorização em componentes, podemos substituir um dos componentes no futuro sem afetar o outro. Podemos substituir View ou Model por novos métodos de autorização para os mesmos dados.
Não limite o princípio de “dividir e conquistar” apenas essas duas camadas. À separação estrita, eu acrescentaria a separação de telas e a lógica de navegação para aplicativos móveis. O que quero dizer com isso?
Minha prática me levou a facilitar a codificação de uma tela específica removendo a lógica de navegação separadamente. Uma tela, especificamente o View, para iOS é um UIViewController e, às vezes, um UIView, e para Android Activity ou Fragment, eles não devem estar envolvidos em uma função para exibir a si mesmos, bem como mudar para outras telas. Cada uma dessas classes deve se preocupar apenas com o que está acontecendo em uma tela específica, ou melhor, apenas para renderizar uma tela específica e interagir com uma classe de lógica de negócios (Presenter, ViewModel e outros).
Estes são apenas dois dos muitos exemplos em que você precisa seguir fundamentalmente a separação. Seguir esse princípio facilitará muito o trabalho adicional com o projeto. Mesmo se o govnokod for encontrado em algum componente separado.
Estilo único
Continuando perfeitamente com o conselho anterior, quero passar para o próximo, ou seja, a adesão estrita a um estilo único no projeto.
O que quero dizer com isso?
Para começar, a palavra-chave aqui é estrita, a partir da palavra. Inicialmente, selecionamos uma abordagem única para organizar um projeto, gerenciar arquivos, estilo de código e assim por diante. Isso melhorará significativamente a aparência geral do projeto e facilitará muito a navegação do projeto, a pesquisa por código e acelerará o processo de introdução de um novo desenvolvedor no projeto. Acho que não vale a pena lembrar que, depois de um tempo, nós mesmos podemos nos tornar essa nova pessoa com nosso código antigo.
A escolha da arquitetura e segui-la
Novamente, partindo do conselho anterior, prosseguimos sem problemas para o próximo, a escolha da arquitetura. E a principal idéia que quero transmitir não é falar sobre as melhores arquiteturas ou dizer que você precisa escolher essa e não outra. Não! Para começar, não há arquitetura ideal que cubra completamente todos os casos possíveis no projeto. Certa vez, ouvi estas palavras: "se houvesse uma arquitetura ideal, nós desenvolvedores seríamos despedidos como desnecessários e substituídos por scripts que gerassem a arquitetura ideal".
O ponto principal, acredito, não é a escolha da melhor arquitetura, mas novamente uma adesão estrita à arquitetura que já foi escolhida e começou a ser aplicada. Seja VIPER, REDUX, MVP ou MVC. É claro que existem prós e contras em cada uma das arquiteturas acima. Com o tempo, mais e mais novas abordagens para o design da arquitetura do projeto.
Vou dizer mais especificamente sobre a minha ideia. Se você já começou a usar o VIPER, siga rigorosamente seus princípios. Mesmo que pareça que, para uma tela de um botão, haja muitos arquivos para criar unidades de linhas de código, não ignore essas regras sob nenhuma circunstância. Porque, em momentos como esse, nasce o govnokod, que então, como uma bola de neve, tudo cresce e cresce.
Aconselho que você se familiarize com as arquiteturas mais populares e escolha a que mais gosta ou a mais popular antes de iniciar um novo projeto. Eu recomendo fortemente escolher a segunda opção, ou seja, começar com a arquitetura mais popular, como será fácil encontrar respostas para muitas perguntas. Ao escolher uma arquitetura, atenção especial deve ser dada aos desvantagens dessa arquitetura e, nos casos em que é recomendável usá-la.
Por exemplo, se você tem um projeto pequeno no qual existem dois desenvolvedores, não deve usar o VIPER devido ao fato de que essa é uma arquitetura bastante complicada que funciona muito bem em grandes projetos e em grandes equipes. Portanto, não há casos em que o código para a criação do VIPER é muitas vezes maior que o código da própria lógica de negócios.
Pessoalmente, agora prefiro a arquitetura MVVM + Router. Funciona bem em um projeto pequeno, onde sou um desenvolvedor único.
Conclusão: o principal não é qual arquitetura você escolheu, mas como exatamente você a segue.
Também quero acrescentar que, se o projeto não estiver sendo desenvolvido do zero, primeiro você precisa se familiarizar com a arquitetura atual e o estilo geral do projeto e começar a segui-lo. Você não deve começar a gritar que há govnokod (retornando ao primeiro conselho) e começar a refazer tudo. Uma exceção pode ser uma anarquia completa no projeto ou a falta de um estilo comum.
Pausas na refatoração
Concluindo, quero dizer que fazer uma pausa para refatoração é uma boa abordagem. A refatoração é uma parte muito importante do desenvolvimento de aplicativos de qualidade. Sim, não escrevemos o código perfeito imediatamente, mas deixá-lo como está também não é bom. Muitas vezes acontece que a implementação original não pode ser dimensionada quando você precisa introduzir novos recursos. Afinal, é quase impossível prever todas as alterações possíveis nas versões futuras do projeto. Além disso, nenhuma arquitetura garante 100% de cobertura de todos os casos. Portanto, é importante fazer alterações no código existente para adaptá-lo aos novos recursos.