Um bom código é impossível no desenvolvimento de software moderno? [fechadas]

19

Parece que mesmo que as ferramentas do desenvolvedor tenham se tornado mais sólidas e robustas, escrever um bom código se tornou um desafio. Mesmo que as ferramentas sejam mais poderosas, a qualidade do código não melhorou. Eu venho com dois fatores importantes, há menos tempo e os projetos são mais complexos. Como as ferramentas que usamos hoje são mais poderosas, é mais fácil escrever código mais complexo, mas não ter tempo para planejar e sem olhar para trás diminui a qualidade do código e aumenta os bugs e a manutenção. Não é que não tenhamos escrito código complexo antes. É que escrevemos código mais complexo.

Minha pergunta é a seguinte: Considerando que temos uma linguagem e ferramentas mais poderosas.

  • Por que escrever código bom é mais difícil?
  • Fatores, tempo e complexidade contribuem para isso?
  • As metodologias não são praticadas corretamente?

O tipo de projeto que considero é um aplicativo corporativo com grande complexidade e lógica de negócios. A definição de "bom código" é individual, por favor, não fique preso na interpretação de "bom código".

Amir Rezaei
fonte

Respostas:

34

Como foi declarado por DeMarco e Lister na Peopleware há cerca de 20 anos, a grande maioria dos projetos de software com falha falha não devido a desafios técnicos, mas a problemas sociológicos . Isso não mudou nas últimas décadas, não importa o quanto nossas ferramentas tenham melhorado.

Má gestão, expectativas irreais, não conseguir as pessoas certas para o trabalho e / ou não deixá-las fazer o seu trabalho, consequentemente, não conseguir mantê-las; locais de trabalho e ferramentas que não são adequadas para o trabalho de desenvolvimento de SW; conflitos pessoais não tratados; política ; esses são apenas alguns dos problemas típicos que podem tornar um projeto condenado desde o início.

Por que escrever código bom é mais difícil?

Não estou totalmente convencido de que é realmente mais difícil escrever um bom código agora do que há décadas atrás. De fato, comparado ao código ou montagem da máquina, tudo o que temos agora no mainstream é muito mais fácil de manusear. Apenas podemos precisar produzir mais.

É apenas por causa dos fatores mencionados, tempo e complexidade?

Sim, a complexidade alcançável certamente aumentou (e continua a aumentar) à medida que o poder de nossas ferramentas aumenta. Em outras palavras, continuamos forçando os limites. O que para mim se traduz, de modo que é igualmente difícil solucionar os maiores desafios de hoje, como há 30 anos, resolver os maiores desafios daquele dia.

OTOH, uma vez que o campo cresceu tão enormemente, há muito mais problemas "pequenos" ou "conhecidos" agora do que há 30 anos atrás. Esses problemas tecnicamente não devem mais ser um desafio, mas ... aqui entra a máxima acima :-(

Além disso, o número de programadores cresceu enormemente. E pelo menos minha percepção pessoal é de que o nível médio de experiência e conhecimento diminuiu, simplesmente porque há muito mais juniores chegando continuamente ao campo do que idosos que poderiam educá-los.

As metodologias não são praticadas corretamente?

IMHO certamente não. DeMarco e Lister têm algumas palavras duras sobre metodologias big-M. Eles dizem que nenhuma metodologia pode fazer com que um projeto seja bem-sucedido - somente as pessoas da equipe podem. OTOH as metodologias de pequeno m que elogiam estão bem próximas do que agora conhecemos como "ágil", que está se espalhando amplamente (IMHO por um bom motivo). Sem mencionar boas práticas como testes de unidade e refatoração, que apenas 10 anos atrás não eram amplamente conhecidas e hoje em dia muitos graduados as conhecem.

Péter Török
fonte
2
Não ser uma gramática nazista ou algo além de 'irrealista' (no segundo parágrafo) não é uma palavra. Eu acho que você quer dizer 'irrealista'.
Só posso apoiar a questão "Junior". Eu sou um deles e certamente gostaria de ter um mentor para me ajudar. É grato que Internet é lá hoje, e Amazon e assim ajudar, mas ainda assim ...
Matthieu M.
1
+1: Além disso, devido à rápida mudança e crescimento de ferramentas / tecnologias / metodologias, em certa medida somos todos juniores pelo menos duas vezes por ano. A experiência permite apenas que alguns veterinários aceleram mais rapidamente do que alguns jrs.
Steven Evers
Recuso-me a levar essa questão a sério, a menos que não tenhamos regras formais para separar código bonito de código feio.
shabunc
17

Questões relacionadas à codificação sob prazos irrealistas e ao lidar com dívidas técnicas são conhecidas desde Weinberg '71 e também Brooks '72. A literatura fica difícil de pesquisar online antes disso, mas tenho quase certeza de que existem relatórios antigos do CDC, da IBM e da NASA dizendo a mesma coisa.

Paul Nathan
fonte
1
+ Para "dívida técnica" e referências.
Amir Rezaei 27/01
10

Eu acho que todos nós temos nossas próprias idéias e limites para "Good Code". No entanto, existem vários problemas que contribuem:

  • A aplicação incorreta de "faça funcionar e melhore" significa que deixamos o código morto e 10 variantes diferentes do mesmo método em que cada um é usado apenas uma vez na base de código. Esse material nunca parece estar limpo.
  • Falta de tempo e orçamento. O cliente deseja 100 novos recursos em três meses, alguns deles não triviais, e não querem gastar dinheiro com coisas que não podem ver diretamente.
  • Falta de carinho. Vamos ser sinceros, alguns desenvolvedores se preocupam com a aparência e o comportamento do código, mais do que outros. Veja o primeiro marcador para um exemplo.
  • Realmente não sabemos como criar "bom código". Meu conceito de bom código está em constante evolução. O que eu achava bom uma década atrás não é mais tão bom.
  • "Bom código" é um julgamento de valor. Além de "funciona", e não há bugs conhecidos, qualquer outro critério para um bom código é essencialmente uma questão de opinião.

No final, acho que é melhor buscar melhor do que buscar "bom" ou "melhor". Se víssemos o melhor código existente, o reconheceríamos como tal?

Berin Loritsch
fonte
1
+1 bom ponto. Por "código bom", não me referi ao código perfeito. Código perfeito não existe. "Código bom" é um código que não lhe causa dor de cabeça; por exemplo, é bem pensado.
Amir Rezaei 27/01
1
Excelente argumento sobre "bom código" ser um alvo em movimento. No entanto, não concordo que seja apenas um julgamento de valor. Acredito que o código limpo é mais fácil de testar, estender e manter a unidade do que o código confuso; portanto, é mensurávelmente mais barato a longo prazo. Obviamente, como normalmente não realizamos testes duplo-cego com grupos de controle em projetos reais de SW ;-), há apenas evidências anedóticas disso, nenhuma prova científica.
Péter Török
Parece que nossas definições atuais de "bom código" estão de acordo. No entanto, já vi alguns exemplos estelares de bom design de API que facilitaram muito minha vida - mas a biblioteca não tinha testes de unidade. Isso não significa que não foi testado, apenas não havia nada para automatizar o teste. Estou deixando espaço para isso.
Berin Loritsch
8

Por que escrever código bom é mais difícil?

Porque o software está cada vez mais sendo construído sobre camadas de abstração. Cada nova tecnologia que alega tornar o desenvolvimento mais fácil e rápido apenas adiciona mais um nível de complexidade que um desenvolvedor precisa entender. Agora, essas abstrações podem ter um enorme benefício para a produtividade, mas se você não entender o que elas estão tentando ocultar, isso tornará o software mais suscetível a erros e baixa qualidade.

Pemdas
fonte
+1 Muito bom, novas ferramentas aumentam a produtividade, o que pode levar a mais complexidade.
Amir Rezaei
1
+1. Também conhecida como "Lei das abstrações com vazamentos". :)
Bobby Tables
6

Um bom código é impossível no desenvolvimento de software moderno?

Na verdade, não é possível. Mas não por nenhum dos motivos que você já ouviu.

O escopo da grande maioria dos projetos está muito além da capacidade de um cérebro humano. É por isso que as pessoas têm a ideia de abstração , ou seja, continuam escondendo detalhes e escalam mais alto a árvore de abstração até que a densidade dos ramos (quantidade de informações a serem manipuladas) diminua para uma taxa aceitável.

Fizemos isso, resolvemos o problema da complexidade, mas isso não removeu o problema maior que tínhamos antes.

Ainda é muito complexo para nós lidarmos.

Para criar uma solução de alta qualidade, precisamos ser capazes de ver e entender simultaneamente tudo ao mesmo tempo, ou seja, todos os módulos em um grande e todos os pequenos detalhes de implementação. De repente, para ver discrepâncias, veja cada parte do código no contexto de todos os cenários possíveis e otimize toda a base de códigos ao mesmo tempo.

Nós nunca seremos capazes de fazer isso.

E se não pudermos, nunca produziremos código de qualidade.

Os gerentes verão o conhecimento dos módulos, mas não conhecerão questões e limitações internas por módulo.

Os programadores de módulos conhecerão as limitações locais, mas não poderão otimizá-lo no contexto de uma imagem maior.

Não há como comunicar entendimento entre gerentes e programadores (e mesmo entre programadores). E mesmo que houvesse, a capacidade do cérebro humano não poderia lidar com isso.

Há pouco que podemos fazer, exceto continuar tentando (um exercício fútil). Vamos manter o código mais ou menos operacional e aproveitar a vida.


fonte
Eu gosto desta resposta, se não fosse escrita em um tom fatal e pessimista ...
Timwi
1
@ Timwi: Não é realmente pessimista. Era para lhe trazer um alívio do fardo. :)
4

Eu nego a premissa de sua pergunta. É mais fácil do que nunca escrever um bom código e, por isso, estamos enfrentando problemas muito mais difíceis do que antes.

Não quero escolher nenhum fornecedor em particular, mas comparar o Windows 1.0 ao Windows 7. O último contém milhares de vezes mais código, mas o tempo médio entre falhas aumentou cem vezes. Deveríamos poder incorporar uma planilha do Excel em um documento do Word desde o Windows 3.1, mas hoje em dia funciona mais ou menos.

Sem querer cair no sentimentalismo "Vocês, hoje em dia, com digitação de pato e VM", sugiro que você não tenha idéia de como foi difícil escrever um bom código nos anos 80: modelos de memória TINY, SMALL e ENORME, sobreposições , chamadas de SO não rentáveis ​​(estremecimento). Boa viagem para tudo isso.

Charles E. Grant
fonte
Odeio ficar fora do tópico, mas pessoalmente eu diria que o Windows 1.0 a 3.11 era realmente muito estável, devido provavelmente à sua falta de complexidade. As versões mais travadas do Windows foram 95, 98 e ME. Obviamente, quais versões eram “boas” de outras maneiras é uma questão diferente.
Timwi
E a codificação em minicomputadores ou mainframes em vez de sistemas de baixa potência? As questões que fazem referência estão relacionados com o modelo Intel 8086 ...
Paul Nathan
@Paul, os problemas do 8086 foram os que mais me envolveram, então eles se assemelham à minha cabeça. No entanto, as ferramentas para escrever software, mesmo em mainframes, eram incrivelmente cruas para os padrões modernos. Os editores geralmente estavam mais próximos do edlin do que do emacs. Em 1982, eu estava usando o NUROS (Sistema Operacional Remoto da Universidade de Nebraska) no hardware IBM. Os trabalhos foram programados e executados usando cartões perfurados 'virtuais'. E não esqueçamos os bugs do Y2K, principalmente engendrados em ferro grande pelas restrições percebidas no armazenamento.
Charles E. Grant
2

As aplicações modernas são mais complexas do que eram há 20 a 30 anos, porque seu ambiente é mais rico e versátil.

Era comum um programa DOS ficar em um loop apertado, aguardando a próxima pressão de tecla do usuário, e depois chamar o código correspondente, e voltar a aguardar a próxima pressão de tecla.

Qualquer aplicação moderna em que você não possa usar o mouse para nada tem um sério problema de explicação. E as coisas podem acontecer em qualquer ordem, pois é perfeitamente possível que o usuário digite, clique com o mouse e continue digitando enquanto os feeds RSS estão sendo atualizados no aplicativo, mostrando as entradas mais recentes para o usuário enquanto ele digita.

Todas essas tarefas multitarefas são intrinsecamente muito mais complexas do que quando você só pensava nas chaves do usuário. Isso torna mais difícil escrever um código realmente bom.

Felizmente, quando os pesquisadores descobrirem como podemos tornar os programas multitarefas mais utilizáveis, vistos do ponto de vista dos desenvolvedores, isso pode facilitar, mas por enquanto estamos presos a todos que tentam fazer o bem, mas não sabem como fazê-lo. isto.


fonte
+1 "Aplicações modernas são mais complexas do que eram há 20 a 30 anos"
Amir Rezaei
2

Parece-me que o software foi expandido para preencher a velocidade do processador, memória, disco e tempo do programador disponíveis. Pode-se afirmar que isso ocorre porque o software realiza muito mais. Bem, tenho certeza de que realiza muito mais, mas não o suficiente para justificar o inchaço.

Eu acho que há uma antiga lei da ciência que vale a pena lembrar:

A natureza abomina o vácuo.

François Rabelas (monge e satirista francês 1494-1553)

Mike Dunlavey
fonte
1

Na verdade, acho que ficou mais fácil escrever um bom código, ou seja, programas que funcionam como esperado e são mantidos durante a última década. As ferramentas disponíveis estão melhores agora, as bibliotecas são mais maduras e abrangentes, o hardware se tornou muito mais rápido, portanto não precisamos usar truques de otimização.

Então, por que nós não?

Na OMI, o principal motivo é que procuramos constantemente maneiras e desculpas para abusar das coisas. Em vez de seguir o caminho antiquado, fácil e provavelmente chato, como criar um executável do Windows, aumentamos os limites do possível e procuramos maneiras de, por exemplo, recriar algo como o PhotoShop como aplicativo da Web. Por quê? Porque nós podemos. Ou pelo menos achamos que sim.

user281377
fonte
1
Discordo da implicação de que a inovação deve ser evitada e as tecnologias ou métodos antiquados nunca devem ser obsoletos. Poderia muito bem parar de escrever qualquer programa e apenas usar o que temos ...
Timwi
Timwi: Não estou argumentando contra a inovação. É apenas o motivo pelo qual parece tão difícil escrever um bom código.
precisa saber é o seguinte
1

Quando foi a última vez que alguém não escreveu uma exploração ou estudou para fazê-lo brincar com a montagem (sem contar os hackers do kernel e os caras do ASIC)? Quantos bugs foram descobertos nas bibliotecas principais do C? Quase nenhum e alguns. Tudo o que estou dizendo é que as pessoas são capazes de um excelente código. Melhores ferramentas e linguagens apenas o tornam menos 'obrigatório' e mais 'opcional'. Não que eu ache que devemos escrever códigos realmente terríveis, mas quando penso em construções lógicas complicadas ... ninguém teria sonhado em escrever algo com matrizes de hash na montagem. Tinha que haver uma maneira 'melhor' de lidar com a lógica em vez de usar uma construção complicada. Mesmo que o código seja bonito, às vezes a abordagem não é tão elegante. Eu acho que isso resolve o problema que você mencionou. Um bom código nem sempre é apenas organizado,

RobotHumans
fonte
Os funcionários do sistema incorporado escrevem uma quantidade decente de montagem.
Paul Nathan
@Paul Nathan True
RobotHumans
0

Acho que é porque ferramentas melhores e computadores mais rápidos e responsivos significam que esperamos obter muito mais tempo de duração da complexidade do produto final do que há alguns anos (ou poucas décadas). Portanto, a complexidade dos aplicativos continua aumentando e nossas suposições sobre o nível razoável de produtividade continuam aumentando.

Onde trabalho, os desenvolvedores estão sempre com pressa (porque sempre há mais coisas que os clientes gostariam que tivessem tempo). Portanto, muitos blocos de código são copiados com edição mínima e sem o esforço para realmente entendê-los. E é claro que erros são cometidos. Acabei de ver um bug ser corrigido, em que um desenvolvedor copiava algum código que eu havia otimizado, sem perceber que as suposições que tornavam a otimização válida não eram verdadeiras onde ele a colocava.

Tudo isso se resume a expectativas, tanto internas (nossas próprias expectativas) quanto de nossas organizações. Tentamos fazer o máximo possível no menor tempo possível. E inevitavelmente resultam erros.

A capacidade de resposta do computador também incentiva uma edição rápida e rápida, depois uma compilação e execução de teste. Nos velhos tempos (como 35 anos atrás), a rotação era tão lenta que eu imprimia o código (a fonte era perfurada na época) e fazia uma explicação manual do código antes de enviar meu baralho. Agora, simplesmente editamos a compilação e a execução. Portanto, muitos bugs que teríamos detectado, através de instruções metódicas de código, agora contamos com o compilador e / ou o conjunto de testes de unidade para detectar.

Omega Centauri
fonte
Soa como uma empresa jovem, que ainda não aprendeu que o mais barato é fazer certo da primeira vez ...
Thorbjorn: Surpreendentemente, existe há quase três décadas. E está realmente indo muito bem. É claro que existem modelos de negócios que respondem muito bem às solicitações dos clientes (nós) e alguns que são muito orientados à qualidade. É realmente difícil ser os dois.
Omega Centauri
0

Como as pessoas pioraram na produção de um bom código?

Se você pegar o .NET e uma linguagem como C #, por exemplo (e eu percebo que não é a única plataforma / linguagem), eu argumentaria que a codificação é bem tornou-se muito, muito mais fácil devido à automação de muitas coisas dentro do Visual Studio meio Ambiente.

De qualquer forma, o simples fato de agora termos IDEs muito sofisticados, capazes de nos guiar pelo processo de codificação e desenvolvimento, está facilitando o alcance do "bom código".

Agora, os programadores podem se concentrar na produção de uma boa estrutura, em vez de gastar tanto tempo digitando colchetes e chaves e novas linhas e lembrando chamadas de métodos e nomes de classes.

Meus dois centavos.

Nick Bedford
fonte
-2

qualidade do código não melhorou

por favor, não fique preso na interpretação de "bom código"

Ótima tautologia lógica.

O código não melhora porque as pessoas continuam mudando a definição de "bom".

Se você pode 'discutir "bom código", não pode comparar e realmente não pode decidir se é "um desafio" ou não.

S.Lott
fonte
Para mim, "código bom" é tal que diminui o número de bugs. Agora isso pode ser realizado de várias maneiras.
Amir Rezaei 27/01
@Amir Rezaei: "A definição de" bom código "é individual". "'código bom' é tal que diminui o número de erros" Escolha apenas uma definição e atualize sua pergunta para incluir apenas uma definição.
S.Lott 27/01
Bem, "'bom código' é tal que diminui o número de erros" é a minha ideia pessoal de "bom código". Acho que todo mundo sabe quando o projeto precisa ser limpo ou não .
Amir Rezaei 27/01
@Amir Rezaei: Este é o meu ponto. Se você não pode (ou não quer) definir "bom" na pergunta, não podemos comparar. Você pode afirmar que o número de bugs é o mesmo. Outra pessoa pode afirmar que o custo dos bugs diminui. Outro pode afirmar que o risco comercial devido ao planejamento de bugs aumenta. Sem uma única definição de "bom", todos podemos conversar sobre coisas diferentes. Por favor, atualize a questão.
S.Lott 27/01
Código Bom: compilou, passou nos testes, recebeu a aprovação do usuário e foi colocado em produção. Só espero que ninguém queira mudar isso.
Jeffo