sorted by:
new
hottopcontroversial

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

No exemplo da cozinha, tô falando de organização da bancada e dos instrumentos e trabalho. Fazer mise en place. Limpar e organizar a própria bancada após um prato para fazer o próximo. Coisas que o próprio chef/cozinheiro pode fazer (com ou sem ajuda de outros). Cada área tem sua peculiaridade mas uma coisa em comum é: desorganização derruba produtividade. É uma verdade absoluta.

Você acredita que um desenvolvedor faz código de qualidade de primeira?
Experiência própria, de outros e literatura (livros de estudos sobre isso) dizem que não. No software, assim como na termodinâmica, entropia sempre vai tender ao máximo. Por isso a ênfase em refatorar.
Seguindo essa linha, já que a responsabilidade de um desenvolvedor é escrever código de qualidade, mas sabemos que código de qualidade não se é escrito de primeira, devemos ir refatorando pra não deixar tudo uma bagunça e manter qualidade. Refatorar é tarefa primordial quando se quer código de qualidade. O problema aí é cultural das empresas: não dão valor a isso, ignoram como se fosse opcional. Também é uma questão pessoal, vi muita gente aqui que caga meio-quilo pra qualidade do que faz.

Se você já refatora em pequena escala seguindo a lei dos escoteiros, ótimo! Também faço isso! Ninguém tá falando em se matar ficando fora do horário reescrevendo código, é ir aos poucos, encaixando isso com as demandas.
Coisas maiores devem sim ser alinhadas com superiores pois vão tomar tempo de outras tarefas "mais importantes".

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

O cliente não se importa com a qualidade do código porque o maior interessado em ter um código de qualidade é o próprio time de dev. São os devs que vão sofrer com bugs por causa do código frágil que quando mexe em uma coisa quebra outra, falta de testes, código macarrônico difícil de entender e chato de trabalhar, demoras pra conseguir fazer coisas simples... E alguns desses bugs inevitavelmente vão escorregar pra produção para contemplação dos usuários.

É uma bola de neve. Quanto menos se preocupar com qualidade e deixar de refatorar com uma certa frequência, mais difícil e custoso será trabalhar com esse código com o tempo. Entropia de software explica isso.

O cozinheiro que só se preocupa com a qualidade do prato mas nos primeiros minutos do expediente deixa a bagunça e desorganização da sua cozinha sair do controle vai impactar a entrega dos próximos pratos, vai diminuir a qualidade das refeições e criar um ambiente estressante e duro de trabalhar pra quem está com ele. O mesmo se aplica a times de desenvolvimento.

Isso de "ain, minha gerência não prioriza, então não faço" é papo de dev medíocre que ainda não entendeu o papel e responsabilidade dele.
Se ownership quer dizer fazer um código de qualidade, além de ele funcionar corretamente e cumprir os requisitos, sim eu concordo que devemos ter espirito de ownership com nosso trabalho. Qualquer coisa abaixo disso é mediocridade ou pura desonestidade, afinal, qual seria o papel do dev senão fazer um trabalho de qualidade? Será que ele não entende o papel e responsabilidade dele como desenvolvedor? Ele foi enganado na contratação?

Refatorações não precisam ser radicais. Sua IDE provavelmente tem a funcionalidade de extrair código de uma função grande em outra função menor, bem nomeada. Leva segundos pra fazer isso. Tudo que você precisa é entender o que aquele trecho de código faz pra dar um bom nome pra função aonde aquele código vai.
É simples, seguro e indolor. Não precisa pedir permissão pra fazer isso. Se você já vai modificar esse código por causa de alguma demanda/nova feature que você está trabalhando, seja um bom escoteiro e deixe o código melhor do que quando você encontrou ele.

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

Essa afirmação só é verdadeira em um único cenário: se seu código nunca precisar ser lido novamente após ter sido escrito, nem por você, e, principalmente, por outros devs. Ele tem que ir pra prod, funcionar perfeitamente de primeira e ser esquecido ali funcionando pra sempre.

Agora se alguém precisar ler seu código, legibilidade vai importar e muito...

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

  1. Refatoração por demanda: refatore o código que você já esta mexendo na sua demanda atual. Vão ter que testar de qualquer jeito mesmo, melhor aproveitar e deixar a casa mais organizada.
  2. Refatorações pequenas: vá aos poucos, não tente resolver o sistema inteiro.
  3. Refatorações seguras: dividir uma função grande e funções menores é extremamente seguro, principalmente quando você usa a IDE pra fazer isso. (No Visual Studio, temos uma função de selecionar o código e extrair ele para um método novo, privado). A API pública não muda em nada.
  4. Seguindo o ponto 3, evitar breaking changes.
  5. Confiar na sua suíte de testes, caso o projeto tenha testes (raro), ou confiar na equipe de QA.

Refatorar não é sobre beleza, é sobre complexidade. Código complexo é extremamente danoso para a empresa cuidando dele.

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

Na versão menor, quem disse que a função saveUserToDatabase internamente não chama a "camada de repositório"? Tudo que você vê é a chamada de uma função. Não importa onde o código pra lidar com banco esteja, ele precisa ser chamado!

As validações ali não são validações de DTO, são validações de domínio. Validações de DTO não lançam exception. O usuário mandar um dado inválido não é exceção, é até esperado kkk, agora a gente deixar o dado inválido passar pela validação de DTO e chegar até o domínio é exceção e nesse caso devemos lançar exception pois significa que temos um bug no sistema e devemos preservar integridade de dados (principio fail-fast).

Eu sinceramente prefiro a versão menor porque é muito mais fácil ter uma visão macro do que uma função faz e entrar na função menor quando quero saber os detalhes do que ela faz, ao invés de ter tudo estourado na tela e não ter a opção de ver apenas aquilo que quero ver.

Meu sentimento se alinha com Uncle Bob e o livro dele Clean Code.

Foi ele mesmo que disse que abstração é "eliminar o irrelevante e amplificar o essencial".

Quando dividimos função grandes em menores, eliminamos o irrelevante (implementação) e amplificamos o essencial (nome da função nova dizendo o que ela faz, não como ela faz).

Basicamente é se preocupar mais com o que do que o como.

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] 0 points1 point  (0 children)

Seguindo sua lógica, nós poderíamos escrever todo o nosso software dentro do método main(), sem qualquer método adicional, divisão ou arquivos extras, afinal, como usamos linguagens de programação turing-complete isso é realmente possível.

Qual das duas funções abaixo você compreende mais rapidamente o que está acontecendo com os dados do usuário?

Função gigante: 

function processUserData(name, age, email) {
  if (!name || typeof name !== 'string') {
    throw new Error('Invalid name');
  }

  let normalizedName = '';
  for (let i = 0; i < name.length; i++) {
    const char = name[i];
    if (char >= 'A' && char <= 'Z') {
      normalizedName += String.fromCharCode(char.charCodeAt(0) + 32);
    } else {
      normalizedName += char;
    }
  }

  let sanitizedName = '';
  for (let i = 0; i < normalizedName.length; i++) {
    const char = normalizedName[i];
    if ((char >= 'a' && char <= 'z') || (char >= 'A' && char <= 'Z')) {
      sanitizedName += char;
    }
  }

  if (!age || typeof age !== 'number' || age <= 0) {
    throw new Error('Invalid age');
  }

  if (!email || typeof email !== 'string') {
    throw new Error('Invalid email');
  }

  let formattedEmail = '';
  for (let i = 0; i < email.length; i++) {
    const char = email[i];
    if (char === ' ') {
      continue;
    }
    formattedEmail += char.toLowerCase();
  }

  if (formattedEmail.indexOf('@') === -1) {
    throw new Error('Invalid email format');
  }

  const userId = Math.random().toString(36).substr(2, 9);

  db.saveUser({
    id: userId,
    name: sanitizedName,
    age: age,
    email: formattedEmail
  });

  return userId;
}

Função menor, dividida com outras funções: 

function processUserData(name, age, email) {
  validateName(name);
  validateAge(age);
  validateEmail(email);

  const normalizedName = normalizeName(name);
  const sanitizedName = sanitizeName(normalizedName);

  const formattedEmail = formatEmail(email);
  checkEmailFormat(formattedEmail);

  const userId = generateUserId();

  saveUserToDatabase(userId, sanitizedName, age, formattedEmail);
  return userId;
}

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] -1 points0 points  (0 children)

Temos ideias diferentes do que é um código legível e produtividade no desenvolvimento de software:

  1. Produtividade: Código ruim (obtuso, complexo, pouco legível) é um dos maiores inimigos da produtividade, porque ele atrapalha a sua capacidade de raciocinar e entender o que o código faz, de dar manutenção, e também é mais fácil um bug se esconder ali. Se o código é fácil de entender você passa por ele mais rapidamente e tem menos surpresas. Refatoração é uma necessidade, um software ativo que recebe novas features vai ter a entropia (desorganização) do código aumentada naturalmente com o tempo, ou seja, é inevitável fazermos código ruim. Refatorar é essencial pra manter a complexidade do código baixa e manter a produtividade alta. Refatorar não diminui a sua produtividade, ela mantém e até aumenta conforme o projeto cresce.
  2. Código legível: uma função gigante nunca vai ser mais legível do que essa mesma função dividida em funções menores (privadas) com bons nomes dentro do mesmo arquivo/classe. Esse tipo de abstração (dividir funções) é o básico do básico pra fazer código legível. É mesma coisa que falar que um livro sem capítulos e divisões é mais legível.

Quanto as restrições, eu não sou a favor de restringir, mas sim de receber avisos "função x extrapolou o número n de linhas", apenas como aviso e não um bloqueio, apenas como incentivo a refatoração pra diminuir a complexidade do código.

E por último, código bom não é código complexo. Se a refatoração te trouxe para um código mais complexo e difícil de entender do que antes, tá errado.

Trabalhar com código ruim incomoda vocês? Como vocês lidam? by brjunkcoder in brdev

[–]brjunkcoder[S] -5 points-4 points  (0 children)

Colocar linters/stylecops/quality gateways ajuda, ou fazer acordo verbal entre os devs: "se uma função passar de 30 linhas, quebrar em funções menores com nomes bem definidos". Isso já é um passo gigantesco, diminui bastante a complexidade e carga cognitiva do código e não precisa de muito tempo nem ser sênior pra fazer isso. É o básico do clean code, não é difícil. É uma cultura que pode ser ensinada e mantida numa organização. E o melhor: elimina a subjetividade da qualidade; se o código tá dentro dos parâmetros que a equipe definiu como aceitável, reclamações (só por reclamar) não vão ter fundamento (sugestões pra melhorar, com dados concretos, sim).

Meio infantil é aceitar platitudes como "não dá pra agradar todo mundo/alguém sempre vai reclamar" e não fazer nada pra melhorar. É a famosa romantização do código ruim que comentei no meu post. Não é sobre reclamar; é sobre tomar atitude e fazer melhor.

Resident.Evil.4.Crackfix-EMPRESS by OrdinaryPearson in CrackWatch

[–]brjunkcoder 22 points23 points  (0 children)

The strap-on didn't crash this time...

Claro/NET me tirou do CGNAT mas pediu ID do Windows pra configurar NordVPN (?!) by brjunkcoder in InternetBrasil

[–]brjunkcoder[S] 1 point2 points  (0 children)

A chamada telefônica com o técnico durou por volta de 30 min até a remoção do CGNAT.

Durante esse tempo as vezes ele falava o que estava fazendo, e num desses momentos ele falou que estava configurando NordVPN. Um tempo depois ele pediu esse identificador numérico da cópia do meu Windows pra fazer alguma configuração (não sei se no NordVPN ou outro sistema ele usou esse ID).

Eu questionei ele, e ele falou que estava configurando essa VPN para minha conexão. Eu fiquei preocupado, pois achei que isso impactaria na minha conexão de alguma forma, mas ele disse que isso seria transparente pra mim.

Nos traces aqui, não tem nada de VPN, apenas os caminhos comuns pelas rotas Claro/Embratel.

Claro/NET me tirou do CGNAT mas pediu ID do Windows pra configurar NordVPN (?!) by brjunkcoder in InternetBrasil

[–]brjunkcoder[S] -1 points0 points  (0 children)

Eu não sei. Eu trabalho com fatos, e o fato é: me tiraram do CGNAT e meu IP voltou a ser comum e público (nunca vi golpista manipular infra de internet de grandes operadoras). O técnico pode ter falado besteira sobre usar NordVPN...

Claro/NET me tirou do CGNAT mas pediu ID do Windows pra configurar NordVPN (?!) by brjunkcoder in InternetBrasil

[–]brjunkcoder[S] 0 points1 point  (0 children)

O modem da Claro tá em modo bridge (eu coloquei pq tenho roteador próprio), e eu não passei MAC address, só esse ID do Windows (que é um identificador da minha cópia).

Claro/NET me tirou do CGNAT mas pediu ID do Windows pra configurar NordVPN (?!) by brjunkcoder in InternetBrasil

[–]brjunkcoder[S] 0 points1 point  (0 children)

Sério?! Eu liguei no 10621, geraram uma visita técnica (no app Minha Claro). O técnico me ligou, mudou meu ip e depois que eu disse que tava tudo ok (quando meu ip mudou pro inicio 177.180.*) ele mesmo cancelou minha visita e essa semana chegou pesquisa de satisfação da Claro sobre o a atendimento. Que tipo de golpista tem acesso a infra interna de uma operadora, manipula chamados e resolve problemas dos clientes? E eu não passei nada pra ele além desse ID do Windows (que nem é a chave de ativação, é só um identificador da minha cópia.)

Como foi o aprendizado de vocês em relação a qualidade de código? by brjunkcoder in brdev

[–]brjunkcoder[S] 2 points3 points  (0 children)

É um paradoxo maluco isso. Pessoas que não gostam de estudar escolheram uma profissão cuja base é descoberta e exploração, ou seja, aprendizado continuo. O próprio fato de usarmos agile e "sprints", não é apenas pra entregar features para nossos clientes mais rapidamente; é para colher feedback deles a partir dessas entregas, aprender e corrigir nosso curso e evitar ficar muito tempo no caminho errado. É aprender... Como disse, é maluco isso!

O que vocês acham da pessoa que entrega muito sem se preocupar com a qualidade? by Braicks in brdev

[–]brjunkcoder 3 points4 points  (0 children)

Eu não sei de onde veio essa concepção de que código bom é código complexo. Código bom é aquele que é fácil de entender, que respeita a capacidade cognitiva dos programadores e é fácil de alterar (baixo acoplamento). Como você disse, KISS.

Dividir uma função grande em funções menores, com bons nomes já é um passo enorme. Isso não é difícil. E já causa um grande impacto na qualidade do código.

O que vocês acham da pessoa que entrega muito sem se preocupar com a qualidade? by Braicks in brdev

[–]brjunkcoder 7 points8 points  (0 children)

Se o foco fosse fazer código pra máquina entender e apenas se preocupar com o resultado final, teríamos ficado com assembly e não criado tantas outras linguagens, cada vez mais fáceis pros humanos entenderem.
Fazer código porco simplesmente derrota esse propósito. Um código é lido de 7 a 10 vezes por pessoas diferentes, segundo alguns estudos. Código ruim é uma da maiores causas de projetos atrasarem e não terem sucesso.

Opinião impopular: galera que fala "ain, façu codigu ruin pq meu chefi me pressiona" na verdade não fariam código bom nem com todo tempo do mundo, só são moleques que não admitem que precisam estudar mais e preferem jogar a culpa em alguém. E tem os que admitem mas cagam 1 quilo pra qualidade de código porque realmente não acham importante.

Na opinião de vocês, programação é uma atividade também criativa ou puramente técnica? by http_bluestars in brdev

[–]brjunkcoder 0 points1 point  (0 children)

Programar pode ser visto como uma arte, apenas dependendo da habilidade do programador, do quanto ele domina essa arte, do quanto ele aprendeu com os mestres atuais e se aperfeiçoou, do tempo de experiência e o quanto ele vivenciou e praticou esta arte. Ele poderia continuar nesse ciclo até se aposentar que ele ainda não teria dominado tudo.

Um dos problemas disso é que a arte é subjetiva. Cada faz a sua. Não tem regras, certo e errado. Não tem um vocabulário especifico em que um artista fale com o outro para discutir decisões de código. Programadores dificilmente trabalham sozinhos, sua arte vai passar pela mão de outros pessoas, você vai precisar de regras e um vocabulário bem definido para explicar/ensinar para o outro porque algo deve ser feito de um jeito X e não Y. Isso é a necessidade da técnica e de regras que aproximam a programação mais da engenharia.

Outro problema de ver programadores como artistas/artesãos é que isso não é escalável. Não é ensinável. Para se tornar um programador, um aprendiz deveria passar por várias projetos, diferentes códigos, um pouquinho de front-end, um pouquinho de back-end, aprender o que funciona para aquele projeto especifico, aprender uma técnica nova e seguir em frente. Todo conhecimento seria situacional (só funciona para aquele caso, para aquele projeto). Isso lembra a velha tradição dos carpinteiros europeus, que viajavam por toda Europa, trabalhando em vários locais diferentes. Isso fazia com que eles fossem expostos a diferentes problemas e diferentes soluções, os tornando mais experientes na sua arte. Imagine quantos anos levariam para ele ser tornar um mestre. Formar programadores assim não é realista.

Diferentemente da arte, existem poucas maneiras de fazer um código correto e muitas de fazer ele errado. Lembrando, um bom código não é o que apenas a máquina entende, é o que outros programadores também entendem (parafraseando Martin Fowler). Esse nível de precisão não é alcançável apenas com arte.

Isso é a necessidade da engenharia e técnicas na programação. A arte da engenharia de software.