na CargoBR - Membro do GruPy-SP - Aspirante a Mestre em Ciências da Computação - Viciado em World of Warcraft (for the horde!) - Palestrante/instrutor nas horas que sobram Eu
burras pra trabalhar comigo! 2. Se eu trabalhasse sozinho seria muito mais rápido! 3. Nenhum design pattern pode ser aplicado ao meu problema pois ele é único! 4. Fico motivado quando meu código faz truques e magias! 5. Fico entediado quando o assunto é respeitar regras, boa arquitetura, documentação testes e disciplina! 6. O código das outras pessoas é sempre ruim, mas o meu não o meu é perfeito! 7. Por ser perfeito eu nem preciso testar direito, eu já rodei tudo aqui na minha cabeça! 8. Por ser perfeito se ele quebrar por receber input no formato errado é culpa do usuário! 9. Não preciso mais ler coisa sobre programação e nem ler código de outras pessoas! 10. Na minha máquina funciona!
Existe algo modificado manualmente em um servidor de produção • Possivelmente na sua máquina esta modificação não estará com o mesmo estado que no sistema operacional de produção/homologação/sandbox/staging, cuidado com isso!
Na sua máquina e nos seus testes você usa SQLite e em produção é usado PostgreSQL • Os ORMs por abstraírem a complexidade das bases de dados pode acontecer de “por baixo dos panos” rolar uma incompatibilidade e você demorar muito pra descobrir isso
• Cenário muito comum: Celery na sua máquina está em uma versão e o Celery em produção está em outra versão • Você erroneamente poderá implementar coisas no seu código que não rodam em produção pois a versão do sistema que está em produção é diferente da sua rodando localmente
muito comum: Existe algum pacote muito importante nos seus requisitos que não tem versão específica ao instalar/atualizar alguma coisa em produção instala uma versão mais recente e QUEBRA TUDO! • Cuidado com a versão das bibliotecas!
para realizar homologar/testes/builds etc • Se estes servidores não estiverem “idênticos” ao seu ambiente de produção essa aplicação poderá ser testada e retestada e nada vai adiantar, pois cada ambiente tem uma característica e provavelmente quando o software for para produção você terá problemas
responsável pelos ambientes de produção o que realmente está rodando em produção: ◦ Versões de bibliotecas ◦ Versões de sistemas ◦ Customizações do Sistema operacional ◦ Banco de dados • E pelo menos TENTE que seus ambientes de teste sejam o mais similar a infra de produção
Thread 2 {conta_1: 20, conta_2: 0} tempo X {conta_1: 20, conta_2: 0} tempo X {conta_1: 0, conta_2: 20} tempo Y {conta_1: -20, conta_2: 40} tempo Y Transferi mais dinheiro do que eu precisava e deixei a conta_1 negativa ao término da Thread 2!
seguros? • Se for para produção o código desse jeito é fácil fazer rollback? • Qual a cobertura de testes do meu código? • Qual a qualidade do meu código? • Qual o tamanho da merda se isso parar de funcionar? • O tempo de resposta está adequado? • Será que isso vai demorar mais para responder em produção?