Sim, nesse caso não tem muito o que fazer. Ainda mais se o cara é o dono do negócio ou muito peixe do dono.
Eu falo com base em minhas experiências. Em geral, todos já possuem uma fórmula mágica (ou nem tanto assim).
Eu tive experiências em pequenas, médias e grandes empresas, com todo tipo de gestor.
Poucos foram os casos em que tive liberdade para chegar para o gestor e dizer que ele estava indo para um caminho incorreto. Mesmo com todas as provas de que a metodologia X era melhor que Y ou que modificar o processo nos pontos A, B e C daria resultados melhores.
Por fim, você acaba entendendo que o que manda é você estar em paz consigo mesmo.
Aliás, o sabor do “eu avisei” é o melhor que você vai conseguir desfrutar.
Pra você vê como a gente não pode cravar nada apenas com base em nossas próprias observações… Eu, pelo contrário vivi os 2 mundos. Tive chefe e tive líderes.
Consegui em muitos lugares expor minhas ideias e ser ouvido e já teve lugar que não precisei ser ouvido porque a equipe era absurdamente mais experiente que eu e aprendi muito com todos.
Porém recentemente eu tenho caído muito em lugares onde eu sou ouvido.
Sim, é bom, mas se parar pra pensar, quando engole, o sabor fica um pouco amargo no final, pois é muito melhor você ser ouvido e ter seu ambiente melhorado, pois se chegou ao ponto de você dizer eu avisei, é porque deu ruim…
Massageia o ego, concordo, mas eu pelo menos não desfruto tanto assim e tenho cada vez menos dito essa frase.
Cara, eu vivi os dois mundos. Mas, eu entendo que, no fim, o trabalho é só um meio para pagar minhas contas e me dar o conforto que eu quero, para mim e minha família.
Se você pretende fazer algo realmente inovador, DIY - faça você mesmo.
Abre uma empresa, mostre como se faz.
Sim, não se discutiu isso aqui ou se tirou o mérito de seu trabalho ser a forma que você usa pra pagar suas contas e não a razão da sua vida. Inclusive, exatamente por concordar com isso que hoje eu me esforço ao máximo para que esse ambiente seja o mais saudável possível. Luto para implantar as melhores práticas para que depois problemas em produção não venham tomar o meu tempo com as minhas filhas ou dos meu hobbies.
A menos que você diga que quando seu trabalho ou o trabalho da sua equipe quebra algo em produção você não está nem aí já que não está no horário de trabalho e que só vai olhar pra isso no outro dia ou na segunda-feira quando chegar na empresa. Aí ok. Eu já não consigo fazer isso. Querer que o meu trabalho não gere prejuízos para o estabelecimento que paga o salário que paga as minhas contas é muito meu. Por isso minha insistência com uso de testes automatizados, pois quanto menor a chance de colocar bugs em produção, mais tempo eu tenho pra minha família.
E exatamente por não conflitar com o que discutimos, quero que meu trabalho seja o mais fluido possível e insisto pra manter meu ambiente saudável, afinal esse papo de separar vida pessoal de profissional está cada vez mais caindo por terra, já que é muito difícil para o ser humano conseguir ser tão robotizado assim.
Abrir uma empresa é MUITO mais do que parece man… Sim, eu tenho atualmente 2 empresas em 2 modelos diferentes, sendo apenas um com CNPJ e atualmente voltei para o mercado CLT por Ns motivos.
Abrir uma empresa envolve muito mais do que apenas método de trabalho e para a maioria das pessoas pode realmente ser inviável alcançar isso e aí por essa filosofia, essas pessoas não teriam como inovar nunca. Porém não é bem assim, é muito comum pessoas empreenderem e inovarem em suas empregadoras. Pessoas brilhantes que se destacam, conseguem expressar e embasar suas opiniões e uma hora ou outra são ouvidas. Acontece muitas vezes dessas apanharem por isso, mas também é comum que algumas vezes essas pessoas se dêem bem e cresçam profissionalmente.
Sim, o mercado é uma merda e a chance de você ser martelado por se expor é grande, mas eu nunca conheci nenhum profissional que se destacou e foi contratado pelas maiores sem se expor.
O tema é bem complexo e tinha que ser resolvido na mesa de um bar, eu realmente entendo o seu ponto, mas hoje eu vejo as minhas opções muito mais complexa do que 0 ou 1, mesmo podendo viver de forma binária assim…
Abraços e valeu pela boa conversa 
A questão de abrir uma empresa, no meu modo de ver e ignorando todas as burocracias existentes, é para que você faça do jeito que quer fazer, entendeu?
Defina os objetivos, a visão, missão e valores e vai atrás.
Sei que é muito mais que isso, ams, aí você pode determinar o que quer que tua empresa seja ou represente.
Sim, entendi sim
É uma das formas possíveis, mas longe de ser a única. Perceba que no post lá em cima o amigo pergunta sobre a nossa opinião em fazer testes unitários ser uma responsabilidade dele e ele ainda ter que corrigir os bugs encontrados durante o teste de outros desenvolvedores.
Como eu não concordo com isso, eu:
-
Saio da empresa e abro minha própria empresa onde os devs serão obrigados a fazer os testes automatizados? Ou
-
Mostro para o meu time a possibilidade de mudança e tento aplicar o que eu acredito que pode melhorar nossas entregas
Na opção 1 eu tenho o risco de ser empreendedor no Brasil, que é alto e caro, além de ter um propósito que logo logo pode se comprovar errado quando um dos meus funcionários me mostrar que podemos ir para outro caminho.
Na opção 2, testo uma alteração e vejo se encaixa para o meu time e descubro o quanto antes se podemos melhorar o processo ou abandoná-lo porque não se encaixa no nosso cenário. O que você acha que é mais simples?
Sempre tem a opção 3, que discutimos exaustivamente no post, do meu patrão não aceitar as mudanças e dizer “aqui quem manda sou eu”, que permite que você desligue seu modo proativo e vá ao mercado buscar novas oportunidades, nesse caso, você fica naquele lugar, trabalhando da forma que o dono quer, entregando seu trabalho com responsabilidade (enquanto recarrega suas energias para quando encontrar o próximo desafio) e vida que segue.
Isso aí é a vida, para nossa sorte, em TI temos muitas oportunidades fervendo pra tudo que é lado e temos essa possibilidade ainda, temos que aproveitá-la de forma saudável.
Por isso é cada vez mais comuns que candidatos em nossa área também comecem a entrevistar as empresas, afinal temos um pouco de poder em nossas mãos também, então antes de entrar na próxima empresa que vai me pagar 500 contos a mais que a anterior, eu sempre entrevisto meu entrevistador para saber até onde eu posso atuar dentro de onde estou me metendo e vejo, de acordo com a resposta dele, se eu embarco no projeto ou não.
Pelos casos que passei isso foi verdade, um esforço que não vale a pena. Imagina fazer teste unitário até de js. De nada adianta testar a parte do back se uma linha de js der pau.
Concordo que é útil pra quem desenvolve frameworks, mas testes funcionais são bem mais efetivos para sistemas de informação, testando regras diretamente no resultado real da aplicação, cobrindo todas as camadas de uma vez. O que chamam de integração também é útil em alguns casos.
Todos da equipe de qualidade. Se só tem você complica mesmo. Mas pra quem desenvolve funcionalidade o ideal é focar em resultados para produção, nao perder tempo programando teste.
Bom, vou te dar uma visão do que já vi acontecer ao aplicar testes unitários.
Você começa a se preocupar com a separação de responsabilidades e clareza do seus métodos/funções, facilitando e muito para depois conseguir separar em serviços pequenos e isolados.
Normalmente quando você me diz que testes unitários não agregam valor a um determinado projeto, eu só consigo enxergar um projeto de acoplamento fortíssimo, totalmente colado na cama dos dados e a uma arquitetura engessada que só evolui “jogando tudo fora e refazendo”.
Testes de integração são necessários para testar todas as partes juntas e numa arquitetura desacoplada normalmente são caros, porque é custoso unir todas as partes em testes únicos e simular os ambientes dos dados. Testes unitários garantem validação em partes granulares do seu código.
Claro que sempre aparecem os aloprados que testam métodos de retorno simples, mas aí é a extrapolação da técnica.
E no fim como já vi que agrega à evolução de arquiteturas meu conselho é que sempre o dono dos testes automatizados (pelo menos os unitários) sejam os próprios desenvolvedores, já que a ideia de evoluir a arquitetura depois parte dos mesmos.
Mas… Todavia… Entretanto… Se você está em uma empresa mais engessada e corporativa, tudo que falei acima é uma evolução em pequenos passos e é muito melhor ter uma equipe construindo testes do que teste nenhum. Cenário esse que eu já vi muito e tive que implantar 1 vez.
Bom expor essa experiência. Aqui nao dependemos do esforço de programar testes unitários pra ter separação de responsabilidades, clareza, etc.
Não é questão de dependência, mas de garantia. Depender de esforço humano para validar pedaços de software escritos por terceiros pode não ser uma boa.
Se sua equipe consegue, perfeito, você que deveria expor pra nós como funciona sem gerar conflitos de interesses, afinal é um case bem legal.
Normalmente deixar isso nas mãos de terceiros gera desencontro de informações e confusão de fluxo por quem não entende do código. Se você tem pessoas que não escrevem os códigos mas escrevem todos os testes e isso funciona redondinho, realmente vocês que deveriam virar case, pois são muito exceção da regra…
Compartilha aí o lugar onde trabalha também, deve ser um lugar foda de trabalhar onde tudo funciona perfeitamente bem
Teste unitário também nao garante nada, se a equipe for ruim podem fazer um produto ruim de manter mesmo com testes unitários.
De que esforço humano está falando?
- Código bonito e bem escrito também não.
- Usar a melhor tecnologia/framework pra resolver um problema também não.
- Atualizar Sistemas em tecnologias e versões mais novas também não.
- Pagar qualificações e certificações para seu time também não.
- etc… também não.
Nada que você faz pra melhorar seu ambiente garante nada… Você pode ter tudo isso e ainda fazer a solução errada. Porém você ainda faz pra tentar dirimir os riscos e não é certeza de acertar 100%.
é, acho que me expressei bem mal aí. Quis dizer mais no sentido de depender de uma pessoa entrando manualmente no sistema tendo que clicar em todas as combinações possíveis de inputs para testar seu software manualmente, ou seja, o que chamamos de teste caixa preta.
Concordo, acho que ninguém aqui está defendendo testes manuais. Só coloquei minha opinião que testes funcionais sao mais efetivos para sistemas de informacao. Já tive essa experiência com testes unitários, mas com os funcionais jogamos fora os unitários.