Vlw

O SonarLint é muito bom. Mas come uma memória da zorra. rsrsrs Procurei algumas alternativas mas não achei nada pra Python tão bom quanto o SonarLint

Você troca de empresa, ta maluco ficar ai kkkkkk.

Por incrível que pareça, eu refatorei meu código assim.

Muito obrigado Rafael! Você está coberto de razão. Todos os devs em todos os níveis geram smells! Nós mesmos quando estamos com algo ultra urgente apelamos também para as soluções mais rápidas, mas sempre sabendo que precisaremos voltar lá para refatorar. Assumir os smells não desmerece ninguém. Ir lá refatorá-los é que faz um dev um profissional melhor. Grande abraço!

@@codigofontetv Seria legal também se vocês abordassem uma situação (bem polêmica rs) que é muito recorrente no dia a dia dos devs que é a "obsessão por padrões de projeto" que acaba gerando diversos problemas na manutenção do sistema tornando a arquitetura mais complexa do que deveria, muitos se esquecem da importância de manter uma arquitetura manutenível e bem estruturada (por mais que exista complexidade). Sendo que o objetivo deveria ser "resolver problemas complexos com soluções simples" e bem padronizadas hahaha.

É um exercício de humildade e empatia o desenvolvedor olhar um código 1 ou 2 anos depois de ele ter colocado a mão. Faz a gente olhar as coisas com outras perspectiva e ver que o smell não tá só no outro xD

Acho que o segredo do "refatorar sem medo" são os Testes Automatizados: fazê-los sempre que possível, e antes até de começar a mexer no código, traz segurança e confiança ao manter um sistema, além de proporcionar comunicação mais eficiente entre profissionais. E o vídeo de hoje foi muito bom, parabéns ao pessoal do Código Fonte TV!

Isso mesmo Jerson! :D Espalhe o smell desse vídeo por aí... kkkk

Exatamente, todo push feito nas sextas já deveriam ser considerados smells! kkkkk

@@codigofontetv Sou vitima disso, o pepino fica pra quem vai trabalhar nos finais de semana (plantão), os "Engenheiros" fazem essas obras de arte e depois a Operação é quem segura o tranco!! hehehehe Abs!

Tem razão, numa sexta-feira às 17:59 está liberado qualquer coisa que rode (mas que deve ser refatorado na segunda)! kkkkk Muito obrigado por nos acompanhar.

Muito obrigado pela correção Daniel!!!

Com certeza Ozeias! Ruby já está na nossa lista.

Uncle Bob é um cara um tanto quanto radical pra levar o que ele fala ao pé da letra xD

@@GutoCmtt alguma coisa errada em passar um objeto como parâmetro ao invés de 15 variáveis?

​@@cebolaloco O que vcs falam é em 3, obviamente 15 variáveis não é devem ser usadas como parametro, qualquer erro na ordem já quebra o programa. Quanto ao que ele dá a entender no livro, nem sempre vai ser possível fazer com um objeto. O que ele fala é em passar entidades, ou seja, teria um grau maior de complexidade sendo criado para algo que muitas vezes seria um terceiro argumento, ou um array associativo ao invés das variáveis. O que se vê bastante são argumentos sendo passados como um array associativo, onde fica fácil de entender e de aplicar, e nesse caso eu concordo, mais do que 3 (ele fala em mais do que 2, mas aí já é exagero) argumentos começa a ficar complicado... E quanto ao Uncle Sam, sim, tem muito mérito no que ele fala e os livros trazem bastante reflexões necessárias. Mas o que ele fala não dá pra levar sempre ao pé da letra pq ele é bastante radical nas posições dele, isso já é praticamente um consenso.

@@GutoCmtt ​ @GutoCmtt Entendi. Mas acho que você tá "overengineering". Abaixo eu coloquei duas maneiras de passar argumentos. Considere que, enquanto na primeira opção você precisa se preocupar com a ordem dos argumentos, na segunda você pode facilmente acessá-los com "." ou "´[ ]", além de ser mais fácil ler o código. Qual das duas maneiras abaixo você acha mais fácil passar/ler argumentos? ---------- function renderUser(userFirstName, userLastName userId, userAge, userStreet, userCity, userNacionality, userPhone, userPicture) { // código... } renderUser(userName, userId, userAge, userStreet, userCity, userNacionality, userPhone, userPicture); ---------- const user = { firstName: "Bob", lastName: "Silva", id: 1, age: 20, contact: { address: { street: "foo foo foo", city: "ace ace", }, phone: "99999999999" }, nacionality: "brasileiro", picture: "..." }; function renderUser(user) { // código... } renderUser(user); ---------- kzfaq.info/get/bejne/baudldJ8tq6cnIE.html 1:10:40 em diante. "if you have a function and you want to pass six things into it, and those six things are so cohesive that they can be passed into a function together, why aren't they already an object?" "I don't want to see a long, comma separated list of arguments." "create the number of arguments down to two or three. Create objects if you have to."

​@@cebolaloco Então, eu já acho que a idéia dele é que é overengineering. Eu acho legal e concordo com criar um array associativo, onde vc pode acessar todos argumentos dentro e passar como $arg['rua'], $arg['cep'] ou algo assim. Mas criar um novo tipo de objeto, uma classe só pra tentar encaixar os argumentos, como se sempre fizesse sentido, acho que é demais. Fora que nem sempre vai dar, e ele fala como se os argumentos de função sempre fizessem sentido em um objeto, apenas por fazerem sentido como argumentos.

es engenheiro estrututal?

@@engecivila Engenheiro naval de formação e trabalho com fluidodinamica computacional. Mas tenho experiência em usar códigos comerciais pra cálculo estrutural.

@@danieldebatin2385 bacana. Fiz o comentario pq sei que normalmente usam fortran em eng estrutural em agumas universidades

Não existe isso cara, Js é Js Html é Html

q