Escrever software é mais fácil do que ler e entendê-lo do zero? [fechadas]

Eu e um amigo meu discutimos ontem sobre as diferenças entre escrever um grande software C ++ e entendê-lo como um novo recruta.

É possível que, como um software é executado uma linha de cada vez e esse processo se assemelhe à forma como nós (humanos) aprendemos as coisas e construímos uma sobre a outra, escrever um software grande é realmente mais fácil do que lê-lo e entender o que ele faz (percorrer o código ajuda, mas você precisa se lembrar de várias classes / arquivos de origem juntos, nem sabe para que eles foram escritos; o código multithread adiciona pontos malus)?

Isso parece estranho no começo, mas depois que pensamos um pouco, parecia razoável

Com base na minha experiência, eu classificaria as atividades a seguir, da mais fácil à mais difícil.

1. Lendo código bom
2. Escrevendo código incorreto
3. Escrevendo um bom código
4. Lendo código incorreto

A classificação acima leva a 2 conclusões

1. Embora seja mais fácil escrever código do que ler código incorreto, é mais fácil ler código bom do que escrever seu próprio código
2. Escrever código incorreto é mais fácil do que escrever código bom, mas escrever código incorreto o configura para a leitura de código incorreto, que é a coisa mais difícil de todas. Especialmente porque o código incorreto é lido mais do que está escrito.

Obviamente, código bom e código ruim são generalizações amplas. Eu recomendo o Código Completo e o Código Limpo para obter mais detalhes sobre o bom código.

Esta pergunta apela a um falso consenso. http://en.wikipedia.org/wiki/False-consensus_effect

Pessoas diferentes aprendem e absorvem as informações de maneira diferente. É semelhante aos alunos auditivos, visuais e cinestéticos. Para alguns, ler código é mais fácil; para outros, criar código é mais fácil. Para mim, é o último. Para outros da minha equipe, é o primeiro. Não acredito que seja útil encontrar algum tipo de consenso ou maioria. É melhor entender como seu cérebro absorve e aprende informações e usa esse conhecimento para melhorar a si mesmo e aprender a aceitar outros que são diferentes.

diferenças entre escrever um grande software C ++ e entendê-lo como um novo recruta

Não é a mesma coisa que a diferença entre software de leitura e gravação. Quando você é iniciante em um projeto (e especialmente quando é iniciante em uma empresa), tem muito mais a aprender do que apenas o que o código faz. Entender por que o código faz o que faz muitas vezes requer uma compreensão de como os negócios funcionam e como o projeto se relaciona com o restante da organização. Em suma, ler código sem o benefício do conhecimento de segundo plano é uma tarefa mais lenta e mais difícil do que ler código quando você entende completamente o contexto em que o código funciona.

Não é uma diferença entre escrever um novo código da marca em um projeto greenfield e ler e modificar o código existente, mas eu não diria que é necessariamente mais fácil do que o outro, apenas diferente. Ao criar algo novo, você não precisa se preocupar em como fazer com que seu código funcione com o que já existe, mas você precisa tornar seu projeto suficientemente extensível e adaptável para que ele permaneça útil no futuro . Quando você está trabalhando em um projeto existente, geralmente pode usar o que já existe como guia, mas primeiro deve entender o que está lá.

Como um "novo recruta", geralmente é melhor trabalhar em um projeto existente especificamente porque ajuda você a aprender tudo o que não sabe: como a empresa funciona, como os vários projetos funcionam juntos, normas e práticas de codificação e até (especialmente) o que poderia ser melhorado.

É uma pergunta interessante, mas eu tenderia a me inclinar para o lado, sendo mais fácil de ler e entender do que criá-lo.

Se você é um programador veterano e experiente, é provável que leia o código e diga "Sim, boa escolha, verifique, oh, eu poderia ter feito o X em vez de Y" etc. Você pode modificar ou ajustar, mas isso economize imenso tempo escrevendo do zero (a menos que haja razões para fazê-lo).

Se você é um programador mais novo, então "você não sabe o que não sabe" e, portanto, terá que inventar / aprender todas as pequenas coisas e, muito provavelmente, terá ineficiências no código. Você provavelmente desenvolverá uma maior compreensão do idioma, no entanto.

Mas em ambos os casos, será mais fácil ler o código e partir daí do que escrevê-lo completamente do zero.

A maioria dos programadores acha mais fácil entender o código que eles mesmos escreveram em comparação com o código que outras pessoas escreveram. Isso se deve tanto ao aprendizado linha a linha que você mencionou, quanto a uma questão de estilo e talento individual. É por isso que tanta reinvenção das rodas acontece.

No entanto, essa é a visão das árvores. A visão da floresta é que é muito mais fácil ler o código do que escrevê-lo do zero. Por exemplo, é mais fácil escrever um novo processador de texto a partir do zero ou aprender uma base de código existente o suficiente para fazer melhorias?

Ao começar a ler o código, você pode pensar em várias maneiras de facilitar a leitura do código. Você passa o primeiro tempo apenas rastreando o código, tentando descobrir a configuração do terreno, às vezes em uma arquitetura completamente anátema de como você gostaria de fazê-lo. Mas mesmo em grandes bases de código, você passará talvez 40-80 horas girando suas rodas, em comparação com as centenas de milhares de horas-homem já investidas na criação desse aplicativo.

A pessoa que está escrevendo o software quase sempre terá a melhor compreensão do programa, simplesmente conhecendo a lógica e seu processo de pensamento enquanto o escreve.

Não acho que escrever código possa ser comparado à leitura de código em termos de facilidade de entendimento. Por um lado, simplesmente escrever software fornece uma melhor compreensão desse software específico, devido ao conhecimento do contexto associado a cada seção de código, biblioteca usada etc. No entanto, a leitura de código que outras pessoas escreveram pode ser difícil de entender em termos de o software real, mas em termos de compreensão da linguagem, ele pode fornecer informações sobre novas maneiras de fazer as coisas ou os usos de uma biblioteca que você talvez não tenha considerado usar, o que pode levar a tornar sua vida mais fácil para escrever códigos.

Em termos de construção de conhecimento, acho que a leitura e a escrita de códigos são muito conectadas e, de várias maneiras, construídas umas sobre as outras. A experiência de escrever código facilita a compreensão do código de outras pessoas, e a leitura do código permite que você tenha um tempo mais fácil de escrever código (por meio de novos conceitos lógicos, uso da biblioteca etc.).

Isso é algo que eu pessoalmente considero evidente, mas nunca tive certeza de que isso se aplica à população de programação como um todo. Por exemplo, eu conheci alguns codificadores muito talentosos que, em vez de lerem a documentação, podem escolher o código de outras pessoas e compreendê-lo como se fosse o seu.

Isso leva à pergunta: isso importa?

Se você estiver lendo o código, é provável que esteja fazendo uma alteração em vez de reescrevê-lo. Mesmo que você esteja reescrevendo, é provável que você esteja escrevendo isso em um novo idioma / versão e, portanto, pode não necessariamente criar o código da mesma maneira. O que estou dizendo é que nem sempre é necessário entender todo o código o tempo todo.

Tudo isso sendo verdade, as novas metodologias de desenvolvimento, por exemplo, o BDD , reconhecem que é importante que a lógica de negócios seja clara a partir do código, em vez de o código ser apenas um meio de conduzir a máquina. É claro que isso não é novidade - o conceito existe desde o trabalho seminal de Donald Knuth: Programação alfabetizada .

Estou na resposta do StMotorSpark, apenas adicionando:
depende de muitos fatores que não podem ser uma pergunta de sim ou não, por exemplo:

• O código existente está bem documentado e bem escrito ou parece um espaguete sem nenhum sentido ou comentário?
• É um aplicativo minúsculo com situações muito raras que custa um tempo sem fim para descobrir como solucionar ou um aplicativo maior, porém simples?
• etc.