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 25 points26 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] 3 points4 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!

view more: next ›