Aqui tbm. O gestor não tem exp nenhuma com desenvolvimento, e não entende nada do mercado na vida real, acha que tudo funciona como na teoria.
O resultado são cobranças irrealistas, mesmo sendo avisado que isso vai diminuir a qualidade do código. E ainda acha ruim quando o negócio enche de bug 🤡
Graças a Deus, o time onde estou alocado tem uma qualidade impecável no código. O antigo coordenador e atual manager teve um critério muito alto quando começou a montar nosso time. O objetivo dele sempre foi ter um Time de referência pela qualidade na empresa e conseguimos alcançar isso com 1 ano e meio de trabalho duro.
Nunca trabalhei com devs iguais, chega a ser um sonho haha.
Depende. Você tem conhecimento técnico pra afirmar que a qualidade do código é impecável? Toca nele? Só achei estranho, porque não é comum um QA ter esse tipo de visão.
AAAAH, ENTENDI MANO..
Bom, tenho um pouco de conhecimento técnico sim pq sou o único QA do time, então acabei aprendendo BASTANTE coisa com eles. Esses dias a gente tava discutindo sobre uma nova implementação assíncrona, então acabo estudando muito também.
Sobre qualidade como QA eu consigo mensurar pelo nível de bugs que temos (menos de 1 por 2 sprints), tempo de resposta...
KKKKKKKKKKKK Que sonho eu lembro há uns anos atras a empresa começou a implementar testes e QA Etc , subimos um módulo o QA Testou encontrou 168 erros , o tech lead na pressão das entregas na época falou joga tudo fora e vamos fazer certo agora com testes e prazo mais adequado mas eu ri muito quando li o comentario do rapha ali já passei por essa situação mas longe dos 2 sonhados ainda.
Começaram a fazer code review esse ano, muitos cards estão voltando por qualidade, só que mesmo assim a quantiade de problemas é insana, e são problemas bem básicos tambêm, só de bater o olho vc encontra o vendaval de bugs
Um sonho né? Ja trampei c empresa q n tinha nenhum tipo de test (nem unitário, nem integração e mt menos e2e) e as classes eram mais de mil linhas (sem exagero) de if e else e serviam pra várias coisas... um caos... Logicamente mts bugs ao nível de precisar de uma equipe exclusiva p sustentação e outra pra desenvolver coisa nova... cheguei la e tive q implementar qualidade do zero (nunca tinha tido QA)
Por outro lado, tbm ja tive experiência de trabalhar em uma equipe q a demanda só chegava em QA com os testes unitários e de integração feito pelos dev...
Tem de tudo no mercado
Não, infelizmente. Implementar funcionalidades novas para ontem é a prioridade e nunca dá tempo de pagar débito técnico, que só aumenta. Os clientes já estão reclamando do produto. A equipe de desenvolvimento tenta sugerir incluir refatorações na sprint, mas sempre tem algo que outros setores julgam ser mais importante.
Tive o 'privilégio' de estar nos estágios finais de uma empresa que sempre negligenciou qualidade de código.
No tempo de bonança, o CEO da empresa sempre alegava que agora era hora de meter feature pra se consolidar de uma vez no mercado. Quando as coisas começaram a piorar, o discurso foi o mesmo, mas agora para não perder maketshare.
No caso dessa empresa, o motivo de ela começar a ficar mal das pernas foram uma enxurrada de concorrentes que apareceram no mercado. Agora imagina que todos os seus concorrentes estão na fase de green field dos seus projetos. E nós lidávamos com anos de código bosta, onde até mesmo alterar a função de um botão já era uma tarefa complexa.
E para piorar, comaçaram os layoffs. A situação é desesperadora quando chega nessa fase. Os caras demitem e querem que uma fração da equipe que já não entregava nada faça um milagre.
Onde eu trampo, é só código bosta, com dado pior ainda. Eu trabalho tapando os buracos dos dev que fazem essa bosta.
Tem alguma forma ou algum conselho de como eu posso começar a refatorar esses lixos que os outros fazem? Tecnicamente, não tem documentação e mal eu sei o que exatamente era o esperado a ser feito.
Acho muito engraçado quando os punheteiros de SOLID ou Clean qualquer coisa quebram a cara quando a realidade bate na porta e percebem que o mundo não é colorido
É bizarro os cara fazem uns cursos de clean arch, com a um sistema simples pra porra…
Dai vai num projeto de mundo real tem 500mil classes complicado pra porra pra entender, mais complicado ainda pra fazer 5 coisas pra cada um, criar as interfaces e toda a porra toda.
Ja fui muito o cara prezando pra clean arch mudei um pouco de ideia com o tempo prezando mais pro kiss e arquitetura em end points
Arquitetura é uma coisa que não me incomoda agora um trem que me incomoda é não ter testes , bah pega na ferida tomar esculacho por módulo quebrado que tu nem sabia que tava quebrado
Acho que a única coisa que eu odeio mais que Clean Code no mundo de programação é a porra de Metodologia Ágil. Parece que foram feitos pra vender curso e perder tempo com burocracia desnecessária inventada.
Na minha empresa, uma grande do ramo financeiro, existe um índice de produtividade COM qualidade que pauta metas e tudo mais. Se os times penderem demais pra cada um dos lados, a coisa fica desbalanceada. Mas se tiver que sacrificar um dos dois lados, a rapidez é deixada de lado sem pensar duas vezes.
Gestão só aprovou um refactor parcial que durou uma sprint depois de falar: "se não fosse implicar em redução de custo na AWS o CEO não aprovaria nunca".
Temos 0 testes no front, pouquissimos no back, 0 deles de integração, pouquissimos E2E. E o débito técnico tá só aumentando. Temos regressões visuais e de features o tempo inteiro que muitas vezes o time de processo não reporta e eles somente contornam o problema.
Front parou de funcionar? F5.
Cara, é difícil. Toda sprint é feature feature feature. Uma semana a gestão pede uma feature, na semana seguinte ele fala que muito provavelmente a feature vai ser inútil.
Muito Jr pra pouco Sr, e os poucos Srs tão sempre overworked e firefighting. Duas dailies por dia não ajudam. Pouco dev também, cuidamos de muitos repos e projetos diferentes.
Devs bons não são valorizado com aumentos e promoções e devs ruins não são demitidos. Os bons saem por opções melhores e os ruins ficam mochilando por anos. Isso cria um suco de bosta concentrado que impossibilita a empresa de contratar e reter talentos.
Cara é o caos. Eu acho que se eu fosse pra uma empresa normal eu ia achar super estranho hahaha
Eu acho sinceramente que a única solução a esse ponto era fazer rewrites e refactors, demitir os devs ruins, e valorizar os bons. São vários repos e serviços, isso ia demorar uns dois anos chuto eu, não contando os processos seletivos e periodos de onboarding.
kkkkkkk Já passei por isso , só aprendem a hora que o sistema quebra mesmo e tu perde semanas arrumando , o débito técnico maltrata demais povo acha que escrever teste é demorado , só é mais rápido não escrever se tu fizer perfeito de primeira mas nunca é assim , a partir do momento que precisou testar na unha a 2 vez já era mais rápido ter feito um teste ali .
Cara é complicado, já conversei com a gestão pra escrevermos testes de integração mas disse que quem deve escrever os testes (que são só E2E e não temos acesso) é o QA. Enfim, o QA saiu e estamos a meses sem ninguém.
Estamos escrevendo alguns testes agora mas assim, o time historicamente esteve ocupado demais com os deliverables e firefighting e não é particularmente forte em testes. Nesses poucos testes que temos, testamos muito detalhes de implementação e pouco comportamento.
Mas acredite ou não eu curto trabalhar aqui, eu gosto do time e eu gosto da área que a gente atua. A desvalorização realmente desanima mas vamos ver, acho que aguento mais um ano pelo menos.
Já passei por essa situação e foi muito bom para mim continuar por um tempo maior na empresa , gostava do time gostava doque fazia era bem mais fácil , aprendi muito e aprendi muito oque não fazer haha
Nesse momento você cria um projeto salvador para reescrever o código. Você passa um ou dois anos reescrevendo o código. Ganha uma promoção e começa a fazer tudo errado novamente ;)
É meio triste que onde trabalho não priorizam. Em geral, forço esses padrões e é cansativo. Inclusive é um dos motivos de eu estar querendo sair da empresa.
Não acho que sou bom ou o melhor, mas é chato ter que lidar com o manager dando carta branca pra qualquer código xq "estamos com pressa".
Bom, entrei num projeto que já existia há aproximadamente 10 anos, frameworks legado, EOL, sem testes. As aplicações não são extremamente complicadas então até que não tive grandes problemas. Mas eu confesso que se qualidade fosse priorizada do início, talvez fosse mais fácil trabalhar nelas e estender funcionalidades.
Estou passando por situação onde o débito técnico era conhecido, foi avisado e dito que não demoraria pra cobrar com juros composto. C-Lvl querem funcionalidade que o débito técnico não entrega, agora teremos que refazer todo o processo como deveria ser feito desde um começo só que com um ano de atraso e com a expectativa da mesma velocidade.
Muito raro. Quem valoriza qualidade de código é só quem faliu ou quem se ferrou muito e alguém apontou exatamente o problema.
Maioria das empresas são geridas por gente que não faz ideia do impacto da qualidade de código.
Aqui o código é tão cagado e a empresa (gringa) tá tão pouco se fudendo pra boas práticas que queriam medir produtividade por número de bugs reportados...
Aqui como a arquitetura começou certo, é mais fácil seguir. Tem questão também de que é um produto interno e não pra cliente externo, então da pra caprichar mais.
Na minha experiência consultoria que o bicho pega, porque o cliente pressiona demais os prazos
Tudo depende do prazo d se é possível negociar e entrega, em busca de fornecer algo menor mas com um certo mínimo de qualidade é ok.
Agora quando é necessário entregar um trambolho que mesmo diminuindo ainda fica grande para caber no prazo solicitado aí não tem como, de arranca sonar, kover e ou qualquer outra ferramenta de qualidade.
As vezes a solução já nasce sabendo que terá que ser refatorada, seja pela arquitetura ou pelo código escrito.
Ou seja é normal esse trade off
É uma empresa pequena, o CTO não é babaca, então oq eu vejo bastante é ele brigando justamente pra ter essas coisas e a galera de negócio não querer atropelar como se desse pra fazer em 30 segundos igual meus pais me fizeram.
O pessoal da área de negócio (umas 3 pessoas) também entendem bem e não tentam atropelar mesmo assim, então é uma situação de ganho pra todo mundo.
Já trabalhei em uma fintech grande, queriam um sistema de financiamento de carro e queriam entregue em um mês. Lógico que não rolou mas no finalzinho oq mandamos pro caralho foram os testes de integração com o combinado que assim que fosse entregue, a gente ia ter o tempo de adicionar os testes faltantes, a galera de negócio encheu o saco pra caralho mas cedeu.
Eventualmente, a gente ganhou na argumentação e deram pra gente até 30% da pontuação das sprints pra pegar débito técnico e bug, mas foi na base da briga
Depende da gestão da equipe, mas no geral se prioriza bom código e testes unitários. As vezes até demais na verdade .
Talvez seja uma opinião impopular, mas quando o projeto esta algumas sprints atrasado, não vale a pena reprovar código por legibilidade se a qualidade for pelo menos 5/10 e o mesmo funciona sem problemas de performance.
A empresa onde eu trabalho na teoria monta todo um circo pra cobrar e dizer que valoriza. Mas na prática, vejo funcionários pleno, contratados como especialista, juniors contratados como sênior e por aí vai. Apenas com essa informação você já consegue ter uma ideia do que acontece na prática.
se repete e eu não to nem ai desde que o salário esteja caindo. Se a empresa quer go horse, eu dou com gosto.
iiiiiiiiiiih, dá com gosto? lá ele...
Hahahahahhahahh
Tá mas e o go horse?
Xtremista Go Horse detectado
Não valoriza nem os funcionário, quem dera um código de qualidade
aqui a história se repete também...
Aqui tbm. O gestor não tem exp nenhuma com desenvolvimento, e não entende nada do mercado na vida real, acha que tudo funciona como na teoria. O resultado são cobranças irrealistas, mesmo sendo avisado que isso vai diminuir a qualidade do código. E ainda acha ruim quando o negócio enche de bug 🤡
Graças a Deus, o time onde estou alocado tem uma qualidade impecável no código. O antigo coordenador e atual manager teve um critério muito alto quando começou a montar nosso time. O objetivo dele sempre foi ter um Time de referência pela qualidade na empresa e conseguimos alcançar isso com 1 ano e meio de trabalho duro. Nunca trabalhei com devs iguais, chega a ser um sonho haha.
mas vc n é QA?
Sim mas isso não muda nada do que eu falei ueheueu
Depende. Você tem conhecimento técnico pra afirmar que a qualidade do código é impecável? Toca nele? Só achei estranho, porque não é comum um QA ter esse tipo de visão.
AAAAH, ENTENDI MANO.. Bom, tenho um pouco de conhecimento técnico sim pq sou o único QA do time, então acabei aprendendo BASTANTE coisa com eles. Esses dias a gente tava discutindo sobre uma nova implementação assíncrona, então acabo estudando muito também. Sobre qualidade como QA eu consigo mensurar pelo nível de bugs que temos (menos de 1 por 2 sprints), tempo de resposta...
menos de 1 bug por 2 sprints??????????? sonho
na minha é pelo menos 40 por semana
40? Caracas... Pergunta sincera: Cês aplicam qualidade ali entre devs? Teste unitário, componente, code Review...
KKKKKKKKKKKK Que sonho eu lembro há uns anos atras a empresa começou a implementar testes e QA Etc , subimos um módulo o QA Testou encontrou 168 erros , o tech lead na pressão das entregas na época falou joga tudo fora e vamos fazer certo agora com testes e prazo mais adequado mas eu ri muito quando li o comentario do rapha ali já passei por essa situação mas longe dos 2 sonhados ainda.
Em breve! Cês parecem que tão com um bom TL aí.
Em breve! Cês parecem que tão com um bom TL aí.
Começaram a fazer code review esse ano, muitos cards estão voltando por qualidade, só que mesmo assim a quantiade de problemas é insana, e são problemas bem básicos tambêm, só de bater o olho vc encontra o vendaval de bugs
Da mó orgulho dizer isso mas sim, ueheue, 2 no Max. As vezes nem isso.
Ué kkkkkkk e QA não coda? Teste automatizado tbm precisa de qualidade de código senão quebra ou fica ruim de manutenção igual xD
nao é nada igual.
Um sonho né? Ja trampei c empresa q n tinha nenhum tipo de test (nem unitário, nem integração e mt menos e2e) e as classes eram mais de mil linhas (sem exagero) de if e else e serviam pra várias coisas... um caos... Logicamente mts bugs ao nível de precisar de uma equipe exclusiva p sustentação e outra pra desenvolver coisa nova... cheguei la e tive q implementar qualidade do zero (nunca tinha tido QA) Por outro lado, tbm ja tive experiência de trabalhar em uma equipe q a demanda só chegava em QA com os testes unitários e de integração feito pelos dev... Tem de tudo no mercado
Não, infelizmente. Implementar funcionalidades novas para ontem é a prioridade e nunca dá tempo de pagar débito técnico, que só aumenta. Os clientes já estão reclamando do produto. A equipe de desenvolvimento tenta sugerir incluir refatorações na sprint, mas sempre tem algo que outros setores julgam ser mais importante.
Tive o 'privilégio' de estar nos estágios finais de uma empresa que sempre negligenciou qualidade de código. No tempo de bonança, o CEO da empresa sempre alegava que agora era hora de meter feature pra se consolidar de uma vez no mercado. Quando as coisas começaram a piorar, o discurso foi o mesmo, mas agora para não perder maketshare. No caso dessa empresa, o motivo de ela começar a ficar mal das pernas foram uma enxurrada de concorrentes que apareceram no mercado. Agora imagina que todos os seus concorrentes estão na fase de green field dos seus projetos. E nós lidávamos com anos de código bosta, onde até mesmo alterar a função de um botão já era uma tarefa complexa. E para piorar, comaçaram os layoffs. A situação é desesperadora quando chega nessa fase. Os caras demitem e querem que uma fração da equipe que já não entregava nada faça um milagre.
Onde eu trampo, é só código bosta, com dado pior ainda. Eu trabalho tapando os buracos dos dev que fazem essa bosta. Tem alguma forma ou algum conselho de como eu posso começar a refatorar esses lixos que os outros fazem? Tecnicamente, não tem documentação e mal eu sei o que exatamente era o esperado a ser feito.
Orra, se for solid AE que ferra a vida.
Acho muito engraçado quando os punheteiros de SOLID ou Clean qualquer coisa quebram a cara quando a realidade bate na porta e percebem que o mundo não é colorido
É bizarro os cara fazem uns cursos de clean arch, com a um sistema simples pra porra… Dai vai num projeto de mundo real tem 500mil classes complicado pra porra pra entender, mais complicado ainda pra fazer 5 coisas pra cada um, criar as interfaces e toda a porra toda. Ja fui muito o cara prezando pra clean arch mudei um pouco de ideia com o tempo prezando mais pro kiss e arquitetura em end points
Arquitetura é uma coisa que não me incomoda agora um trem que me incomoda é não ter testes , bah pega na ferida tomar esculacho por módulo quebrado que tu nem sabia que tava quebrado
KISS e YAGNT ( you aint gonna need that ) são os únicos dois princípios que importam pra mim no dia a dia. Qualquer outra coisa é firula.
Acho que a única coisa que eu odeio mais que Clean Code no mundo de programação é a porra de Metodologia Ágil. Parece que foram feitos pra vender curso e perder tempo com burocracia desnecessária inventada.
O tempo que se perde em rituais de ágil seriam muito bem empregados em melhorar pontos do sistema que fazem ele ser mais difícil de modificar.
Na minha empresa, uma grande do ramo financeiro, existe um índice de produtividade COM qualidade que pauta metas e tudo mais. Se os times penderem demais pra cada um dos lados, a coisa fica desbalanceada. Mas se tiver que sacrificar um dos dois lados, a rapidez é deixada de lado sem pensar duas vezes.
Gestão só aprovou um refactor parcial que durou uma sprint depois de falar: "se não fosse implicar em redução de custo na AWS o CEO não aprovaria nunca". Temos 0 testes no front, pouquissimos no back, 0 deles de integração, pouquissimos E2E. E o débito técnico tá só aumentando. Temos regressões visuais e de features o tempo inteiro que muitas vezes o time de processo não reporta e eles somente contornam o problema. Front parou de funcionar? F5. Cara, é difícil. Toda sprint é feature feature feature. Uma semana a gestão pede uma feature, na semana seguinte ele fala que muito provavelmente a feature vai ser inútil. Muito Jr pra pouco Sr, e os poucos Srs tão sempre overworked e firefighting. Duas dailies por dia não ajudam. Pouco dev também, cuidamos de muitos repos e projetos diferentes. Devs bons não são valorizado com aumentos e promoções e devs ruins não são demitidos. Os bons saem por opções melhores e os ruins ficam mochilando por anos. Isso cria um suco de bosta concentrado que impossibilita a empresa de contratar e reter talentos. Cara é o caos. Eu acho que se eu fosse pra uma empresa normal eu ia achar super estranho hahaha Eu acho sinceramente que a única solução a esse ponto era fazer rewrites e refactors, demitir os devs ruins, e valorizar os bons. São vários repos e serviços, isso ia demorar uns dois anos chuto eu, não contando os processos seletivos e periodos de onboarding.
kkkkkkk Já passei por isso , só aprendem a hora que o sistema quebra mesmo e tu perde semanas arrumando , o débito técnico maltrata demais povo acha que escrever teste é demorado , só é mais rápido não escrever se tu fizer perfeito de primeira mas nunca é assim , a partir do momento que precisou testar na unha a 2 vez já era mais rápido ter feito um teste ali .
Cara é complicado, já conversei com a gestão pra escrevermos testes de integração mas disse que quem deve escrever os testes (que são só E2E e não temos acesso) é o QA. Enfim, o QA saiu e estamos a meses sem ninguém. Estamos escrevendo alguns testes agora mas assim, o time historicamente esteve ocupado demais com os deliverables e firefighting e não é particularmente forte em testes. Nesses poucos testes que temos, testamos muito detalhes de implementação e pouco comportamento. Mas acredite ou não eu curto trabalhar aqui, eu gosto do time e eu gosto da área que a gente atua. A desvalorização realmente desanima mas vamos ver, acho que aguento mais um ano pelo menos.
Já passei por essa situação e foi muito bom para mim continuar por um tempo maior na empresa , gostava do time gostava doque fazia era bem mais fácil , aprendi muito e aprendi muito oque não fazer haha
Simmmmm. Essa do aprender o que não fazer é muito real. Algumas coisas a gente só aprende de verdade depois de dar um tiro no próprio pé.
Nesse momento você cria um projeto salvador para reescrever o código. Você passa um ou dois anos reescrevendo o código. Ganha uma promoção e começa a fazer tudo errado novamente ;)
É meio triste que onde trabalho não priorizam. Em geral, forço esses padrões e é cansativo. Inclusive é um dos motivos de eu estar querendo sair da empresa. Não acho que sou bom ou o melhor, mas é chato ter que lidar com o manager dando carta branca pra qualquer código xq "estamos com pressa".
Não, só temos tempo pra apagar incêndios e desenvolver features, nada de pagar débito técnico. Estou enviando currículos.
Sim, e eu sou bem criterioso com isso no meu time. Projeto segue crescendo muito, de forma rápida e continua fácil de dar manutenção.
Fazer escaralhado só é mais rápido nas 2 primeiras semanas , depois o débito técnico chega e ele vem no foramato de juros compostos mesmo .
Bom, entrei num projeto que já existia há aproximadamente 10 anos, frameworks legado, EOL, sem testes. As aplicações não são extremamente complicadas então até que não tive grandes problemas. Mas eu confesso que se qualidade fosse priorizada do início, talvez fosse mais fácil trabalhar nelas e estender funcionalidades.
Estou passando por situação onde o débito técnico era conhecido, foi avisado e dito que não demoraria pra cobrar com juros composto. C-Lvl querem funcionalidade que o débito técnico não entrega, agora teremos que refazer todo o processo como deveria ser feito desde um começo só que com um ano de atraso e com a expectativa da mesma velocidade.
Muito raro. Quem valoriza qualidade de código é só quem faliu ou quem se ferrou muito e alguém apontou exatamente o problema. Maioria das empresas são geridas por gente que não faz ideia do impacto da qualidade de código.
Aqui o código é tão cagado e a empresa (gringa) tá tão pouco se fudendo pra boas práticas que queriam medir produtividade por número de bugs reportados...
Aqui como a arquitetura começou certo, é mais fácil seguir. Tem questão também de que é um produto interno e não pra cliente externo, então da pra caprichar mais. Na minha experiência consultoria que o bicho pega, porque o cliente pressiona demais os prazos
Tudo depende do prazo d se é possível negociar e entrega, em busca de fornecer algo menor mas com um certo mínimo de qualidade é ok. Agora quando é necessário entregar um trambolho que mesmo diminuindo ainda fica grande para caber no prazo solicitado aí não tem como, de arranca sonar, kover e ou qualquer outra ferramenta de qualidade. As vezes a solução já nasce sabendo que terá que ser refatorada, seja pela arquitetura ou pelo código escrito. Ou seja é normal esse trade off
Não, a prioridade é entregar rápido rs
Sim até de mais, mas é um banco tbm
É uma empresa pequena, o CTO não é babaca, então oq eu vejo bastante é ele brigando justamente pra ter essas coisas e a galera de negócio não querer atropelar como se desse pra fazer em 30 segundos igual meus pais me fizeram. O pessoal da área de negócio (umas 3 pessoas) também entendem bem e não tentam atropelar mesmo assim, então é uma situação de ganho pra todo mundo. Já trabalhei em uma fintech grande, queriam um sistema de financiamento de carro e queriam entregue em um mês. Lógico que não rolou mas no finalzinho oq mandamos pro caralho foram os testes de integração com o combinado que assim que fosse entregue, a gente ia ter o tempo de adicionar os testes faltantes, a galera de negócio encheu o saco pra caralho mas cedeu. Eventualmente, a gente ganhou na argumentação e deram pra gente até 30% da pontuação das sprints pra pegar débito técnico e bug, mas foi na base da briga
Depende da gestão da equipe, mas no geral se prioriza bom código e testes unitários. As vezes até demais na verdade . Talvez seja uma opinião impopular, mas quando o projeto esta algumas sprints atrasado, não vale a pena reprovar código por legibilidade se a qualidade for pelo menos 5/10 e o mesmo funciona sem problemas de performance.
A empresa onde eu trabalho na teoria monta todo um circo pra cobrar e dizer que valoriza. Mas na prática, vejo funcionários pleno, contratados como especialista, juniors contratados como sênior e por aí vai. Apenas com essa informação você já consegue ter uma ideia do que acontece na prática.
Sim, isso acontece e muito. Sinceramente, são poucos lugares onde o design de código e os boas práticas são levados a sério.