Por que não uso o Builder de Interface – Sam Soffes
Postado em
Para o desenvolvimento do iOS, não uso o interface Builder. Eu não usei intencionalmente uma ponta (quando digo pontilhado, quero dizer, o arquivo de construtor de interface, não o formato específico) desde o iOS 2.0. No passado, trabalhei com algumas pessoas que realmente gostavam de usar o interface Builder. Este é um argumento que já tive repetidamente.
Em vez de discutir sem pensar de um lado ou de outro, aqui está o meu ponto para os pontos quando estou tentando conquistar alguém.
Escolhendo explícito em vez de implícito
Escolher ser explícito é o meu motivo número um para fazer as coisas em código. Se alguém novo na equipe abrir uma visualização ou controlador de visualização, poderá ver imediatamente onde tudo está e não precisar se perguntar se esse arquivo tem uma ponta.
Passei inúmeras horas procurando a fonte de um bug apenas para descobrir que é uma caixa de seleção em uma das meia dúzia de inspetores no Builder de Interface. Se estiver no código, é simples olhar para o código de exibição e ver a fonte do problema muito mais rápida.
Acoplamento apertado
É muito mais difícil usar o Builder de interface para visualizações reutilizáveis. Eu constantemente crio pequenas vistas e as reutilizo em todo o lugar. Esse é o ponto de trabalhar em um ambiente orientado a objetos. Se você usa o interface Builder e possui pontos de venda e esqueça de conectar a saída no segundo lugar em que o usa, você trava em tempo de execução. Isso é terrível. Isso apresenta uma classe totalmente nova de bugs.
Agora temos essa coisa que trava simplesmente porque estamos usando o interface Builder em vez de usar o código. Se fosse exatamente a mesma coisa no código, ele não falharia. Pior ainda, o compilador pode verificar isso para você.
Sem mencionar, se você usar muitas visualizações personalizadas, suas pontas serão apenas um monte de caixas invisíveis. Então agora você tem esse acoplamento apertado que é ainda mais difícil de trabalhar, se você o colocasse em código.
Você já se sentou olhando para algum código se perguntando por que não está trabalhando para perceber que você não conectou a saída ou ação? Eu odeio isso.
Trabalhando com outras pessoas
Você já teve um conflito de mesclagem em uma ponta. É o pior. (Concedido que o formato XIB ajudou, mas é horrível, em vez de impossível agora.) Se você estiver trabalhando em uma grande aplicação com vários desenvolvedores, perderá uma quantidade enorme de tempo lidando com esse problema.
A pior parte é que, se ele se fundir automaticamente errado, você pode não perceber até o tempo de execução. Com o código, você pode ler o diferencial e entender o que está acontecendo. Nibs (em qualquer formato) não são legíveis em humanos. Isso também torna inútil a história de um arquivo inútil. Se fosse o código, é apenas Objective-C. Somos bons nisso.
Faz parte do Xcode
Isso costumava ser mais um problema, mas acho que ainda vale a pena mencionar. Para dizer levemente, o Xcode não é o software mais estável do mundo. A parte de edição de texto funciona muito bem. Toda vez que recebo um acidente enquanto edito uma ponta, eu reclamo para mim mesma e desejo que fosse um código ainda mais.
Quanto menos eu tenho que usar o Xcode para mais do que qualquer coisa, exceto um editor de texto com conclusão e um compilador, mais feliz eu sou.
Localização, localização, localização
O código de layout não é difícil. O Auto-layout é um pouco mais de código do que o layout tradicional, mas ainda não é ruim. Tentar trabalhar com o Auto-Layout no Interface Builder é enlouquecedor. A configuração de tomadas para controlar restrições internas é apenas bobagem.
É tão simples apenas substituir layoutSubviews E faça o seu lugar. Pessoalmente, acho isso muito mais fácil de trabalhar do que a realização automática para a maioria das coisas.
Eu acho que esse é muito o maior medo de pessoas é trabalhar com layouts em código. Depois de pegar o jeito, é tão simples. Tornar seu aplicativo Universal se torna muito mais tribal do que fazer pontas separadas para iPhone e iPad. Você pode simplesmente reutilizar seu código em vez de criar esse acoplamento apertado.
Resumindo
O próprio construtor de interface não é ruim. Isso incentiva as más práticas, evita a reutilização, torna o trabalho com outras pessoas mais difícil e diminui seu fluxo de trabalho. Pessoalmente, evito o uso de interface (incluindo storyboards) o máximo possível. Todos os projetos em que trabalhei desde 2009 não tiveram pontas, a menos que estivesse fora do meu controle.
Eu acho que você deve economizar algum tempo, aprender algumas coisas e começar a se mudar para o código. Afinal, somos programadores.
Atualizar: Sem mencionar a localização. É uma enorme dor com o IB. Você acaba fazendo conexões com tudo. Muito mais fácil de fazer no código.
