Quais são algumas boas práticas antes de verificar o código-fonte? [fechadas]

47

Minha equipe usa o Team Foundation Server para controle de origem e hoje corrigi alguns bugs e teste de fumaça antes de fazer o check-in, mas esqueci de comentar algum código. (Esse código tornou a interface do usuário um pouco estranha.)

Quero saber quais são as boas práticas antes de fazer o check-in do código - não quero cometer esse tipo de erro novamente.

anônimo
fonte

Respostas:

149

Uma coisa que eu tenho o hábito de fazer é sempre olhar as diferenças de todos os arquivos que estou prestes a fazer o check-in, imediatamente antes de fazer o check-in.

crudcore
fonte
46
O +1 é óbvio, mas se alguém por aí não está fazendo isso, está fazendo errado!
David Heffernan
6
+1 Na verdade, não é tão óbvio, mas se você não fizer isso, lamentará.
Nemanja Trifunovic
14
+1 Além disso, se você acha que isso é muito trabalho, provavelmente está cometendo muito de uma só vez.
8119 mpeterson
5
Além disso, observar as diferenças torna mais fácil saber o que colocar na nota descritiva sobre o que você está tentando alcançar com suas alterações, especialmente no caso de você ter feito várias correções.
Jonas
4
Se não vale a pena olhando através, não é provavelmente vale a pena check-in.
Robert Jeppesen
63

Você nunca deve fazer o check-in do código comentado. Se você possui um código que precisa ser comentado antes do check-in, está fazendo algo errado.

Quanto às regras:

  1. Receber as últimas
  2. Corrigir conflitos de mesclagem
  3. Construir

    3.1 Corrigir erros de construção

  4. Executar testes

    4.1 Corrigir testes quebrados

  5. Vá para 1 (até que não haja nada novo para obter)

Somente faça check-in quando todas as etapas estiverem concluídas.

Veja a dança do check-in .


Outras boas práticas:

  • Revise a lista de arquivos para fazer check-in para garantir que eles sejam os arquivos esperados.
  • Revise as alterações para cada arquivo (exclusões / adições / diferenças)
Oded
fonte
Eu fiz duas vezes aqui. Talvez você queira dizer "código comentado"? Eu mesmo, eu me inclinaria para nunca verificar código não comentado!
Pontus Gagge
11
+1 - é uma lista bastante completa! NÃO QUEBRA O CONSTRUTOR !!
ozz
1
@ Phillip - Desde que você saiba que isso não é uma boa prática e contanto que seja um intermediário simples de curto prazo , esse é um dos poucos casos que violam essa regra. Acho muito mais preocupante quando as pessoas fazem check-in com código comentado para que "não o percam".
Oded
2
@ Philip, é por isso que o git é bom. Você pode confirmar essas alterações WIP localmente, quantas vezes quiser, antes de enviar para o repositório principal rebase -ie limpar seu histórico local, esmagando as confirmações conforme necessário, para que a linha principal não tenha confirmações feias de trabalho em andamento.
Alex Budovski
20

Não estou tentando ser muito exigente aqui, mas a suposição nesta pergunta (e todas, exceto uma das respostas) se aplica principalmente ao VCS centralizado, como TFS, SVN, Perforce, etc. É
justo, é isso que o OP está usando.

Por outro lado, no entanto, ao usar o DVCS (como Mercurial e Git), você normalmente não deve esperar para fazer o check-in, e a maioria das coisas mencionadas nas respostas - como diffs, obter as últimas, mesclar etc. - não são necessárias . Mesmo coisas como revisões e testes de código são melhores após o check-in (embora talvez antes de enviar, dependendo ...)
A única exceção que vi aqui (até agora) é a associação a um item de trabalho. Claro, comentar sobre o check-in também é bom ...

Ávido
fonte
5
+1 para comentar sobre o check-in. Não é política em minha loja, mas tento sempre deixar uma nota descritiva, mesmo que apenas para movimentar minha memória mais tarde.
PSU
Concordo - imagino que o fluxo de trabalho de Oded possa se beneficiar muito do controle de versão entre cada uma das etapas ou, no mínimo, entre cada um dos loops.
Kevin Vermeer
7
Todas essas etapas não passam de quando você faz o check-in para quando você pressiona?
13138
@ user13278 alguns deles, mas de maneira diferente. Por exemplo, mesclar é uma experiência completamente diferente - e, enquanto você pressiona, não há necessidade de um ciclo de obter a última mesclagem e a tentativa. E você pode fazer isso por vários conjuntos de alterações, e não precisa repetir todos os check-in. Em geral, muitas dessas etapas não têm muito a ver com o check-in - por exemplo, você puxa quando deseja, não porque está fazendo check-in (ou pressionando). Claro que você ainda precisa testar - mas isso pode estar no seu próprio prazo. Empurrar ainda permanece muito mais leve, mas é claro que você quer ter certeza de não empurrar porcaria.
AviD
2
+1. A associação a um item de trabalho é a única coisa difícil de fazer no Git ou Hg. Você precisará executar um pacote inteiro, como o Kiln. Essa é a (única) área em que o TFS é bom. É prejudicial para o controle de versão.
Robert Jeppesen
8

Três coisas que não vi em outras respostas:

Incluir novos arquivos

  • Procure novos arquivos que não fazem parte da sua lista de alterações
  • Pode ser específico para SCMs como o Perforce - você precisa contar tudo o que está em sua alteração.

Reverter arquivos inalterados

  • Eu odeio quando estou olhando para as mudanças de outras pessoas e há uma lista de alterações com nove arquivos, mas apenas três deles foram modificados.
  • Também reverto arquivos com espaço em branco ou alterações sem sentido.

Verifique seu commit enviado

  • Certifique-se de que a construção permaneça verde após o seu commit.
  • Eu costumava ter uma segunda máquina que sincronizava, construía e executava após minhas confirmações, para que, se algo desse errado, eu pudesse entrar e consertar facilmente.

Duas coisas quando eu uso o Git:

Compromissos atômicos:

  • Encene apenas alterações funcionais individuais para confirmação.
  • Faça confirmações o menor possível. Facilite a correção, a reversão e a compreensão.
  • Eu uso git add --patchpara dividir minha alteração em várias partes, se necessário.

Exibir diferenças ao resumir

  • Eu sempre faço check-in git commit --verbosepara que eu possa ver um diff da minha alteração enquanto digito minha mensagem de confirmação. (Ou eu uso meu git-vim corrigido para mostrar a diferença.)
  • Isso facilita muito as alterações e a descrição de todo o commit. Ocasionalmente, eu pego mudanças indesejadas nesta fase. A descrição de sua alteração ajuda você a pensar sobre isso.
idbrii
fonte
+1 por ser a única pessoa a mencionar confirmações atômicas.
Stephen Paulger
7

Alguns itens de 'boas práticas' que eu aplico nos servidores da minha equipe são bastante simples. Primeiro, antes de fazer o check-in, você deve sempre obter as atualizações mais recentes e executar uma compilação local, para garantir que ninguém mais tenha verificado nada em que o seu código colidir. Além disso, cuide de qualquer conflito de código na sua máquina local, não no servidor. Depois que seu código, com o código mais recente baixado, tiver sido confirmado para compilar e funcionar corretamente, você estará pronto para a próxima etapa. Execute todos os testes automatizados e inicie o check-in para garantir que eles ainda funcionem corretamente. Então, só para ter certeza, obtenha as últimas novamente.

Como administrador do TFS, é possível aplicar comentários em todos os check-ins. Eu recomendaria sempre colocar comentários de check-in para o seu trabalho, independentemente de ter sido aplicado ou não. Se você tiver a opção de fazê-lo, imponha-o. Certifique-se de que os comentários sejam, no mínimo, um resumo geral do que você alterou desde a última vez em que inseriu seu código. Dessa forma, se algo der errado, você poderá examinar os check-ins e ver, grosso modo, o que foi alterado nesse check-in. Isso torna a depuração de uma compilação quebrada muito mais fácil.

Além disso, se você tiver privilégios de administrador do TFS, imponha builds contínuos nos check-ins (para garantir que todos saibam imediatamente se o check-in deles quebra alguma coisa) e você pode configurar o servidor para realizar um check-in fechado ( se o código com check-in interrompe a compilação, o servidor a rejeita) ou você pode simplesmente criar um bug e atribuí-lo a quem quebrou a compilação.

Existem algumas outras opções que você pode ativar ou desativar para manter tudo bem em ordem ou sugerir ao administrador do TFS que mantenha as coisas boas e limpas ... mas elas são em grande parte preferência

guildsbounty
fonte
Eu gosto desta resposta. Como controle de qualidade, às vezes rastreamos um bug até o commit que o fez aparecer, e é bom ter comentários descritivos disponíveis. Também no momento do lançamento, nossa loja cria algo chamado "release nores", que é uma destilação de novos recursos e alterações, e as notas de check-in são uma fonte importante dessas informações.
Omega Centauri
7

Pesquise e substitua palavrões ;-)

Throwback1986
fonte
Apenas não se engane.
Tullo_x86
4

Se você estiver fazendo check-in no Windows, verifique se o seu código não possui esses caracteres ^ M invisíveis - os editores do UNIX geralmente fornecem erros / avisos por causa disso.

Tente também substituir abas - usuários diferentes acabam vendo tabstops de maneira diferente, alguns com 4 espaços, outros 8 e não são bons para a legibilidade do código.

Melhor abordagem O IMHO é fazer com que um script predefinido verifique seu código em relação às diretrizes de codificação da sua organização. Cargas de sistemas de controle de origem têm essa funcionalidade.

Fanatic23
fonte
4
A verificação dos caracteres ^ M só faz sentido se uma caixa UNIX estiver realmente envolvida no processo de desenvolvimento de alguma forma. Algumas empresas são lojas totalmente Windows.
Dima
1
Exatamente. É por isso que você não usa guias.
Alex Budovski
Alguns SCMs lidam com terminações de linha para você (alguns se saem melhor que outros). Perforce ( kb.perforce.com/?article=063 ), git (core.eol na configuração do git), svn (svn: estilo eol), etc.
idbrii
@ Alex: Ou você sempre usa guias em todos os lugares. Não importa o que você faz, desde que seja consistente .
Donal Fellows
@donal, não. Aqui está o problema; As guias estão sujeitas à configuração do seu editor e, portanto, inerentemente inconsistentes. Alguns "editores" são inconfiguráveis, como o cmd.exe e a maioria dos consoles Linux, portanto você pode até ser inconsistente consigo mesmo.
21711 Alex Budovski
4

Na minha empresa, usamos revisões de check-in. Isso não precisa ser detalhado, mas apenas mostrar a alguém as diferenças na lista de alterações e conversar com elas às vezes destacará o erro de digitação que você perdeu nos testes.

Nosso servidor de controle de origem não permitirá que você faça check-in, a menos que anote o nome do revisor nos comentários (no formato! Iniciais, por exemplo! BW, se Bruce Wayne fez sua revisão). O revisor recebe um email informando que ajudou na revisão. Isso está aberto à exploração óbvia, mas parece funcionar muito bem.

tenpn
fonte
4

Sempre que possível, gosto de associar um check-in a um item de trabalho. Isso fornece algumas informações contextuais sobre por que isso foi alterado, e não apenas o que foi alterado. O TFS possui um sistema de rastreamento de itens de trabalho bastante decente, portanto, isso é bastante trivial no momento do check-in.

(além de revisar as diferenças das minhas alterações)

mpeterson
fonte
2
Isso pode ser definido como uma política de check-in, para que nenhum código possa ser verificado sem se associar a um item de trabalho.
John Saunders
Bom ponto, John. Na verdade, espero fazer isso muito em breve onde trabalho.
mpeterson
Impor coisas é geralmente contraproducente. Certifique-se de que seu pessoal entenda que é bom para eles.
Robert Jeppesen
3

Uma coisa pequena que faço é não fazer check-in de arquivos que realmente não foram alterados. Esses arquivos podem ter sido modificados inadvertidamente, ou podem estar envolvidos em refatorações que foram revertidas ou que foram discutidas.

Dessa forma, seu conjunto de alterações (associado a um item de trabalho) contém exatamente os arquivos necessários para satisfazer o item de trabalho.

John Saunders
fonte
3

Para combinar todas as respostas aqui e fornecer uma lista de verificação completa

  1. [check-in / check-out] você não deve fazer check-in diretamente no fluxo em que outras pessoas estão trabalhando. Você deve ter uma estratégia de fluxo: por exemplo, por desenvolvedor, um fluxo no qual você possa fazer check-in e check-out independentemente sem incomodar os outros: seu trabalho será esteja seguro, mas em seu próprio fluxo de desenvolvimento, portanto [somente em seu próprio fluxo de desenvolvimento]. A cada verificação, você o associa a um registro de alterações, para que suas alterações sejam atômicas em relação àquelas chamadas de conjunto de alterações (para que você possa distribuir rfc / bugs individuais etc ... sem precisar entregar 'tudo').

  2. [depois rebase com o fluxo da sua equipe] significa que você recebe as alterações de outras pessoas no seu próprio fluxo. Durante essa operação, você pode ver na caixa de diálogo de mesclagem todos os "diffs" e passar por eles ou ... se houver milhares e / ou você não estiver usando código, mas também, por exemplo, modelos de dados / projetos siebel etc. mesclagens não triviais, mesclas trivial-automáticas e triviais, a última categoria contém as difíceis. Lembre-se de que você ainda está trabalhando em seu próprio fluxo.

  3. [rebase completo] Se estiver tudo bem, verifique todas as alterações que você acabou de receber do fluxo da equipe: seu próprio fluxo está atualizado

  4. [entregar] agora entregue seu trabalho ao fluxo da equipe. Se você não deseja entregar tudo, também pode selecionar, por exemplo, 1 RFC específico com as versões específicas dos arquivos ou um conjunto de RFCs / defeitos resolvidos.

  5. [entrega de teste] deve funcionar bem, mas como existe a chance de que alguém entregue alterações também: você pode testar se seu trabalho funciona com as alterações mais recentes no fluxo da equipe. Com as mesmas caixas de diálogo de mesclagem mostrando diferenças.

  6. [entrega completa] conclua sua entrega e seu trabalho agora está no fluxo da equipe.

Para torná-lo mais complexo: Como ainda existe a chance de o trabalho que você entregou = ok, mas você já está trabalhando em uma versão adicional, você deve baseline sempre após a entrega e indicar qual baseline é a preferida para outros usuários. . Isso garante que outros desenvolvedores obtenham uma versão recomendada e não a versão mais recente no fluxo (se você estiver trabalhando nesse cenário). Essa também é uma verificação tripla, para que, mesmo que as versões mais recentes do fluxo da equipe sejam "ruins", elas ainda não sejam as que outras pessoas refazem ou visualizam, e seu gerente de configuração pode mesclar a versão anterior à próxima versão para desfazer sua entrega.

  • a resposta da história acontece 2 vezes: nos passos 2 e 6
  • a resposta de Oded na dança do check-in: idem, mas uma camada extra de entrega e rebase no check-in / check-out para garantir que você trabalhe isolado e os erros sempre possam ser facilmente eliminados, mesmo em estágios posteriores
  • a resposta da guildsbounty respondida: o mais recente é a etapa 2. Para a compilação: realmente depende se você tem uma compilação ... no meu mundo, você tem entradas de modelos de dados, documentos do word, folhas de requisitos, dados de configuração da informatica, siebel, etc .., e sim também código java, código .net etc ... que todos devem se misturar. Portanto, não existe realmente "uma compilação" aqui, mas mais uma integração superior, dependendo se essa única, por exemplo, compilação a partir do seu "código" se integra com todo o restante, já que você não sabe ao certo se é uma integração e depende de nos ambientes de teste, pode ser necessário compilar coisas ou, em entregas mais altas, outra compilação, porque precisa de algo de outra equipe.
  • a resposta da guildsbounty sobre comentários e requerida: acho que todos os ambientes nos quais você não possui integração de VERSÕES e alterações nos conjuntos de alterações (e tipo: defeitos, RFC, hotfi) não estão maduros. Eu acho que é um caos se você não puder, por exemplo, automatizar as notas de versão com a quantidade de bugs e rfcs enviados que podem ser clicados nas versões exatas que foram tocadas (uma vez que, por exemplo, a versão 1 e a versão 3 do hello.c podem muito bem ser entregues, mas a versão 2 não deveria ter sido entregue, porque esse material seria parte de uma versão posterior, mas alguns noob já o colocaram) (isso significa uma decisão manual SE você também quiser tirar a versão 3 do hello. c MAS tirar a versão 3 significa que você também precisa remover todas as outras versões tocadas por esse RFC / defeito, para que você possa ser capaz com facilidade e rapidez com uma ferramenta para remover a coisa completa) (mesmo que vários desenvolvedores trabalhem em partes de mesma RFC), mas pelo menos você precisa de coisas para decidir sobre isso etc ...). Documentação extra é sempre útil, mas ao associar conjuntos de alterações, você obtém o círculo completo: uma versão <- um conjunto de alterações <- itens de trabalho <- um ticket / rfc / defeito <- um requisito. Significado: você sabe quais requisitos são entregues total ou completamente: um requisito possui vários RFCs ou bugs ou qualquer outra coisa. O RFC possui vários itens de trabalho para várias pessoas. esse item de trabalho corresponde a um conjunto de alterações que existe em um conjunto de versões (por exemplo, versões 1 e 3 do hello.c no fluxo de integração que, é claro, NÃO são as versões 1,
  • o comentário de luis.espinal: não quebre a compilação é verificado duas vezes em rebase e entrega ainda ... existem entregas mais altas para 'gerenciadores de lançamento e construtores' que devem ver conjuntos de alterações e linhas de base como informações. "Nunca trabalhe diretamente na ramificação principal" sim, a estrutura do fluxo pode ser grande ou simples, mas em essência: os desenvolvedores têm seu próprio fluxo, eles entregam para um fluxo de equipe que entrega para um fluxo de lançamento. -> para que as entregas de todas as equipes (por exemplo, equipe de documentação, equipe de requisitos, equipes de desenvolvimento,

No seu exemplo, você se esqueceu de comentar o código. Erros acontecem. O sistema de gerenciamento de configuração ao seu redor deve cuidar disso. Pode realmente ser que, por exemplo, milhares de mudanças ocorram e "compilações" e "integrações" ocorram em uma hierarquia de fluxos em diferentes servidores encadeados e processados ​​no tempo. Portanto, mesmo depois de cinco meses, seu código comentado é testado em um servidor de integração porque seu código precisa de integração com outros códigos e sistemas, ainda será possível executar atomicamente seu conjunto de alterações e continuar. Portanto, a melhor prática é mais ou menos em um nível superior. O design geral dos fluxos de gerenciamento de configuração deve cuidar disso. Para desenvolvedores individuais, a melhor prática é a validação / teste de unidade. Mas do quadro geral para "

edelwater
fonte
2

Algumas das opções a seguir se aplicam mais que outras (ou de formas diferentes), dependendo do seu SCM, então aqui estão elas:

  1. Não quebre a compilação - verifique apenas o código que é compilado.
  2. Comente seus check-ins (e possivelmente seus check-outs, se o seu SCM lhe der essa opção.)
  3. Não mantenha as coisas desmarcadas por longos períodos de tempo.
  4. Faça check-in com frequência (várias vezes ao dia, se possível).
  5. Rotular de forma significativa.
  6. Rotule regularmente.
  7. Nunca trabalhe diretamente na ramificação principal.
  8. Toda liberação para produção deve ter seu próprio rótulo (e uma ramificação somente leitura da ramificação principal, se possível). Quando possível, faça o mesmo nas versões de teste do UAT / Integração / Pré-produção.
  9. Você deve poder criar exatamente o que está em produção a partir do que está no seu SCM e de um rótulo.

NOTA : alguns dos itens acima parecem bastante óbvios, mas você não acreditaria em quantas pessoas realmente trabalham na ramificação principal ou faz alterações na produção primeiro e depois cria deltas manualmente para executar o controle de versão ... diretamente na ramificação principal. .. e com etiquetas. Doce como a bílis fermentada misturada com suco de axila não lavado ... sim, assim.

luis.espinal
fonte
2

Tenha uma lista de verificação pessoal. Comece vazio quando você estragar, em uma entrada. Quando se tornar uma segunda natureza, remova-o da lista.

Execute os testes. Se eles passarem, verifique. Se você errar e alguma coisa passar nos testes, escreva um teste.

ctrl-alt-delor
fonte
1

Fazemos o seguinte ...

  1. Teste - Queremos ter certeza de que funciona. No mínimo, queremos saber que isso não quebra nada.

  2. Revisão de código ou, pelo menos, uma verificação de amigos - Essa é uma ótima maneira de garantir que o conhecimento se espalhe e que as pessoas sejam atualizadas. Também ajuda a detectar bugs antes de fazer o check-in.

  3. Enviar um aviso prévio - Um aviso prévio é enviado ao grupo antes do check-in. O objetivo não é apenas permitir que outras pessoas saibam quais arquivos ou áreas estão sendo alteradas, mas também os avisa (eles devem optar por tomar conhecimento), caso se espere que essas mudanças os afetem.

  4. Algumas horas após o envio do aviso prévio, o check-in é realizado e o grupo é informado por e-mail. Todos no grupo podem saber quando o trabalho específico de um bug ou recurso é concluído.

  5. Uma cópia do aviso de check-in é colada no registro de correção associado ao bug ou recurso. Ao pesquisar os registros, achamos muito útil ter uma idéia do que a correção / recurso implicava.

Sparky
fonte
1

Execute seus testes de unidade em que você está trabalhando tão diligentemente. Verde é bom.

Naftuli Kay
fonte
1

Verifique se seu código está formatado corretamente (por exemplo, para Java: selecione seu código e pressione Ctrl-Shift-F no Eclipse). Mas tenha cuidado ao fazer o mesmo para um documento inteiro.

Rune Aamodt
fonte
1

Sempre, sempre, sempre , verifique se as alterações que você fez não quebram a compilação. Especialmente pequenas mudanças que podem parecer triviais.

Uma vez eu fiz uma alteração muito pequena que não achei que causaria nenhum problema antes de deixar o trabalho no fim de semana. Com certeza, essa pequena alteração quebrou a compilação e nenhuma execução noturna de teste foi executada para o nosso projeto. O chefe de perguntas e respostas não ficou muito feliz com isso, e com razão.

gablin
fonte
1

Procure por partes de suas alterações que possam ser inseridas como unidades independentes.

Muitas vezes, quando tenho uma correção ou aprimoramento funcional no código, há algumas alterações. Alguns deles são específicos para a mudança de comportamento que estou buscando; outros são refatorações que fiz para tornar essa mudança mais limpa.

Eu prefiro verificar cada refatoração separadamente, com sua própria descrição de alteração, assim:

REFACTORING: Renomeie X para Y

X fazia sentido antes porque ... mas agora deve ser Y. Isso está relacionado ao trabalho para a edição # 9.

Então, uma vez que cada boa refatoração é registrada, a mudança final de comportamento geralmente é trivial.

Além disso, algumas alterações afetam muitas linhas de código, mas não são muito interessantes, enquanto outras são muito localizadas, mas têm um impacto importante. Se essas alterações forem verificadas juntas, pode ser difícil ler as diferenças. Então, eu os mantenho separados.

Mais tarde, quando alguém está lendo o histórico de mudanças, é óbvio como as coisas chegaram ao estado atual das coisas e por que elas são assim. Também é trivial desfazer minha mudança de comportamento porque ela não está envolvida com muitas outras edições.

Jay Bazuzi
fonte
0

Faça o que faria ao devolver algo emprestado de alguém. Verifique se está limpo e em boa forma. Se você fez uma bagunça, limpe antes de devolver o código ao proprietário (na maioria dos casos, ao seu empregador).

Jason
fonte
O git ajuda você a limpar sua bagunça antes de se comprometer publicamente. Infelizmente, VCSs centralizados não.
Alex Budovski
0

Eu mantenho um repositório local de hg para o meu trabalho.

  • Sempre que faço o check-in, olho o diff e certifico-me de que todas as alterações sejam aceitáveis.
  • Eu tento observar o principal recurso do check-in.
  • Eu tento manter cada tamanho de confirmação em um recurso principal.

Não reivindico que sejam os melhores, mas eles funcionam para mim.

Paul Nathan
fonte
0

Quando escrevo um código que sei que não deve ser registrado, adiciono uma linha antes dele contendo "// TEMP:" e depois com "// END TEMP". Isso, juntamente com o diff antes do check-in, promete que eu não irei verificar esse código por engano.

user17815
fonte
0

Teste completamente tudo o que você adicionou ou alterou. Tente todos os casos possíveis em que você possa pensar. Não deixe o teste para o controle de qualidade. Se eu tivesse um sanduíche para cada vez que fiz algumas pequenas alterações e tentei alguns casos de teste apenas para estar do lado seguro, e imediatamente vi problemas, eu teria muitos sanduíches. Costumo dizer em voz alta para mim mesma: "Estou muito feliz por ter tentado isso ..."

Você diz que a interface do usuário ficou estranha após a alteração. Se você tivesse executado o programa e analisado a interface do usuário antes de fazer o check-in, teria notado o problema?

Ken
fonte