Taverna /dev/All

Conceitos de programação até quando podemos negligenciar?

Ultimamente venho acompanhando algumas lives de programação(coisa que não era comum eu fazer até a quarentena) e notei que só se falam em duas coisas, framework ou nova versão de linguagem. E a quantidade desses assuntos é tão grande que no meu entender se torna repetitivo, mas o que me incomoda mesmo é que pouquíssima pessoas(não vou colocar valor porque isso é baseado em achismo meu) falam sobre conceitos básicos tais como (estrutura de dados, SOLID, D.I, I.o.C, etc…);

Mas isso só me fez pensar em uma coisa, até que ponto podemos negligenciar os conceitos, lembro por ter passado por algumas empresas com projetos críticos para grandes clientes que não seguiam boas práticas, algumas era mais procedural que Orientação a Objetos, outros ignorava os problemas relacionado a base, padrão de arquitetura quase inexistente, porém apesar disso tudo, funcionava, e todos que já estavam ou entrava nos projetos iriam continuar aquele ciclo vicioso e por mais que você reclamasse por fazer alguma demanda naquele projeto a pessoa fazia, entregava e estava feito.

Dado esse contexto gostaria de questionar vocês algumas coisas:

  • Um software bom é um software que funciona ou é um software bem escrito
  • Os conceitos estão sendo perdidos por causas dos frameworks (ex: Spring fazendo D.I e IoC)
1 Curtida

Software que funcione sem aplicar conceitos que sejam desnecessários.

Procedural, estruturado e funcional muitas vezes sao mais práticos do que OO, principalmente pra lidar com dados. OOP é muito bom pra requisitos nao funcionais. As melhores linguagens sao multiparadigmas, mas muitos ainda enxergam OOP como bala de prata.

Os frameworks estão evoluindo/escondendo complicações justamente pra isso, pra forcarmos mais no resultado pro Negócio, que é o mais importante pra empresa.

1 Curtida

Acho que isto tem muito a ver com o tempo de vida esperado do sistema: explico.

Há sempre dois caminhos: você está escrevendo algo que irá durar anos e consegue ver que haverá a necessidade futura de manutenção e evolução daquele sistema? Se sim, os princípios não devem ser levados em consideração, eles OBRIGATORIAMENTE devem ser aplicados.

Se não, se é um sistema que irá ter curta duração, coisa de semanas, já é possível haver um relaxamento aí.

A coisa poderia parar aí, mas acho que dá pra complicar um pouco mais. Ok, é possível você ter um relaxamento na aplicação destes princípios, mas até que ponto? O que chamamos de “software funcionando” de fato? Até que ponto vai a responsabilidade do desenvolvedor? Explico: ok, o software vai durar pouco tempo, mas e se ele colocar em risco seus usuários?

A grande questão é: qual seria o mínimo necessário no caso de um sistema que terá vida curta? Indo um pouco além: como saber se este sistema terá vida curta?

Trago mais dúvidas que respostas, huh? :slight_smile:

2 Curtidas

interessante questionamento.

desde o ano passado uma das perguntas que tenho praticado me fazer é: “essa solução vai durar quanto tempo?”, e tenho tentado dar uma data p/ saber o quanto precisa ser refinada a solução.

eu fiz uma graduação bem sólida na parte de algoritmos e estrutura de dados por gosto pessoal e outra coisas relacionadas a SO, Redes e afins que fazem parte do nosso dia de desenvolvimento.

na prática sinto que usa-se mto pouco da teoria pelas abstrações criadas como vc diz de frameworks e afins mas os principios vejo em vários lugares. Com isso, sabendo os principios acho q consigo escolher as melhores implementações da abstrações deles.

em um podcast recente q participei eu falei sobre algo que me foi dito na graduação por um professor: “não venha aqui querendo aprender ferramenta, estou aqui p/ te ensinar os principios e disso vc aprender as ferramentas”, e eu levo isso comigo, pq ferramenta muda mas os principios dificilmente mudam.

mas é aquilo, vc pode ter uma carreira inteira sem precisar saber disso, basta escolher um caminho q não tenha essas pedras e não vejo problema nenhum nisso.

2 Curtidas

Como desenvolvedor, entendo que diante de tantas forças conflitantes num projeto, cabe a nós defender que a qualidade do código seja a melhor possível. É até mesmo uma questão ética e moral. É muito fácil clientes e gerentes optarem pelo relaxamento da qualidade em prol de tempo, dinheiro, etc. Porém, minha posição como desenvolvedor é defender a qualidade. Caso contrário, iremos ver cada vez mais projetos inviáveis e desenvolvedores de baixa qualidade atrapalhando o trabalho dos de boa qualidade. Saber dizer não é fundamental.

2 Curtidas

Não seria obrigatoriedade, e sim opções de acordo com a necessidade. Trabalhei em vários projetos críticos de longa data que nunca sairam de producao sem levar isso como obrigação. Natural negligenciar quando alguém tenta obrigar algo que complique o dia a dia da equipe para entrega de resultados que atendam o cliente.

1 Curtida

Você tem razão: há este aspecto humano que realmente precisa ser levado em consideração

1 Curtida

Bom questionamento.

Acho que tem alguns pontos para explicar esse comportamento, primeiro que vídeos sobre conceitos dão mais trabalho e menos visualização, atualmente as pessoas procuram consumir conteúdo de forma rápida e diversa, falar sobre conceitos básicos requer uma didática mais elaborada e com exemplos acessíveis (caso queira atingir um público maior),

Outra questão é que a maior parte das empresas criou a cultura de cobrar ferramentas/frameworks como requisitos nos processos, vejo que está mudando mas ainda tem muito o que percorrer.

Com relação a qualidade do código, como foi citado, contexto tem que ser levado em conta. Acho ótimo livros ou artigos (geralmente de autores estrangeiros) que falam sobre defesa da qualidade do código, de como negociar prazos, o que é ser profissional etc, trazem uma perspectiva e uma experiência sobre o contexto do autor e sempre se tem como acrescentar no próprio dia a dia, mas fazendo um ponderamento, não há como trazer 100% para a prática.

Acho fundamental saber e entender os conceitos (até hoje estudo para isso), mas pra mim o principal é saber quando usá-los e isso leva um bom tempo. Indo para o ponto de vista humano é preciso dar tranquilidade ou trabalhar o emocional das pessoas para chegar ao estado ótimo da programação.

Por ser uma atividade ligada a criatividade e a lógica, o mercado de trabalho, contexto social e até político pode influenciar em uma construção de código. Trabalho com um sistema antigo (e a muito tempo) e vejo nele um reflexo tanto dos períodos conturbados quanto dos bons períodos das pessoas que passaram pelo mesmo. Com os anos aprendi a não julgar e a perceber que em primeiro lugar vem o código funcionando e que em minha realidade o software é o meio e não o fim.

Já vi funcionalidades perderem o timing do negócio devido a equipes estarem discutindo qual é a melhor forma de integrar 2 sistemas e outra empresa pegar o contrato por fazer um webcrawling que lia a página de um e passava para o outro (na força bruta mesmo). Com isso pessoas foram desligadas depois de um tempo e outras acumularam funções, quem fica geralmente tem um trabalho de resiliência enorme.

Não sou a favor da falta de qualidade, muito pelo contrário, testes unitários já salvaram minha qualidade de vida, padrões me pouparam raciocínio em vários momentos e utilizar um inspetor de código hoje pra mim é fundamental, mas somos seres moldados e influenciados pelo meio em que vivemos e acho que as ferramentas e conceitos tem que ser para as pessoas e não o contrário.

Desculpem se escrevi demais, acho que o isolamento e o trabalho remoto está me influenciando.

Um abraço a todos.

2 Curtidas

Bom fiz esse questionamento e não esperava ter tanta interação aqui(primeira vez postando algo sério). Concordo com os pontos abordados aqui e acho que no final tudo vai depender do quanto você é profissional, eu fiz esse questionamento realmente para entender até que ponto eu posso e devo me preocupar. Já comecei código do zero e perdi timing assumo isso por simplesmente querer fazer o mais perfeito possível e o que eu precisava fazer era o mais simples. Hoje estou desenvolvendo uma solução do zero mas fazendo apenas o máximo de esforço necessário já ganhei alguma experiência e sei o que vai dá problema lá pra frente. Só o que eu vejo é geralmente discutimos um indivíduo, mas trabalhamos em grande parte em equipes, uma pessoa fazer um software funcionar é diferente de uma equipe fazer um software funcionar, sabemos que existes diversas pessoas com experiências diferentes da sua porém digamos que toda uma equipe está viciada em uma forma de codar e você entra nessa equipe ver que aquilo na frente pode dar problema, você tenta convencer e não aceitam, você vai negligenciar os seus conhecimentos ?

Não quero dizer aqui onde eu passei era o melhor e tal só estou levantando a bola para entender até que ponto isso é saudável para a sua carreira e todos os cenários que eu falei são hipotéticos claro que grande maiorias são resolvidos com conversas, mas sabemos que por mais que a tecnologia seja boa, ainda são feito por pessoas.

1 Curtida

Olha: eu tenho uma técnica que é infalível pra este tipo de situação.

É simples e composta por uma única pergunta de duas palavras: “Por quê?”

Se você não ouvir uma resposta bem fundamentada, tá topando com um “Momento diva” e mero capricho. O ofício de desenvolvimento deve ser baseado em boas técnicas, mas ao mesmo tempo é muito importante que a gente também evite cair no capricho alheio (ou próprio).

1 Curtida

É verdade. Há um certo canto da sereia em querer usar coisas novas, ou o forçar a barra nos projetos pra encher o currículo de nominhos da moda, e muitas vezes as decisões por fazer assim ou assado são pautadas pela vaidade. Se bobear o cabra já começa o projeto pensando na palestra lacradora que vai dar no evento técnico da comunidade dizendo que usou XPTO. Dureza… E um perigo! Como você disse outro dia no twitter @kicolobo, o cliente te paga prq confia na sua expertise e vc usa ele de cobaia para testar novas tecnologias sem ele saber (pode dar certo, mas se der errado a responsabilidade e é toda sua…).

Muita gente com facilidade para programação transforma a profissão numa espécie de puzzle, um vício em desafiar o cérebro a explorar o desconhecido, viver o momento da confusão, construir o conhecimento novo, dominar novos stacks e se sentir vitorioso, recorrentemente. E isso é gostoso mesmo, e é oq me nos mantém amantes desse afazer. Mas tem que ter juízo para não subverter o profissional para saciar esse vício.

Ao mesmo tempo que reconheço o fator vaidade e prazer na complexidade vencida, que pode levar a escolhas técnicas não justificadas, eu tbem alerto para o efeito colateral do banner todo-mundo-pode-programar, em que espera-se que tudo seja resolvido só com if/else/while. Há um certo medo de complexidade, de qualquer coisa que exija análise e estudo. As pessoas param lá na aula de AED 1, ATP 1, Introdução à Programação, ou equivalente. Ficam estagnadas naquele tipo de problema “faça um programa que receba X e imprima Y”, ao passo que projetos complexos existem de fato e podem demandar soluções complexas.

Outra coisa gozada é que todo mundo adora usar um framework ou biblioteca com aquela API confortável e intuitiva, flexível, e quase sempre eles conseguem ser assim prq foram desenvolvidos e mantidos com conceitos avançados de programação, além de bem documentados, com exemplos e tutoriais além do doc de cada pedaço do código. Mas quando se trata do próprio projeto em que vc trabalha na empresa, que pode precisar também se beneficiar de reuso e boa manutenção, poucos patrocinam essa mesma qualidade para componentes internos…

Tem mto oq falar em torno desse tema. Vou para por aqui. Ficam aí meus centavos para a discussão.

1 Curtida

itexto