O que acontece com os programadores com mais frequência ao ler o código de outras pessoas? [fechadas]

Ao ler o código de outros, você geralmente tem problemas para entendê-lo, ou é mais comum que você questione o código de outros sobre o fato de ele estar errado / não eficiente / com formato incorreto (etc)?

Alguém lendo o que você codificou em seu primeiro emprego

readability

— snoopy
fonte

Você se torna assimilado. Você se torna parte do Um.

— Thomas Eding

Devo dizer que, em um ambiente profissional, você geralmente conserta as partes quebradas, que tendem a ser as piores partes do código. Minha experiência é que quase sempre é como seu desenho animado. Se você tiver a sorte de trabalhar em algum lugar em que a qualidade do software é fundamental para o sucesso dos negócios - e a empresa aprecia isso -, sua experiência será muito melhor. Mas corrigir bugs e estender as coisas inevitavelmente leva você às piores partes de qualquer base de código.

— precisa saber é o seguinte

Respostas:

Hoje em dia não tenho muitos problemas para ler o código de outras pessoas. Já vi tantos códigos ruins que posso até diagnosticar que tipo de evolução levou a qualquer um que encontrei.

Na maioria das vezes, o código profissionalmente ruim é o código que começou bem, mas as melhores práticas, requisitos ou conjuntos de habilidades foram removidos por baixo dele. Às vezes, é apenas alguém que é ruim ou novo no idioma, mas isso também é bastante aparente (e incomum em um ambiente profissional). Quanto mais eu entendo por que o código apodrece, menos questiono a competência de outros programadores.

— Telastyn
fonte

+100 para "quanto menos eu questionar a competência de outros programadores". Eu acho que a atitude às vezes presente "claramente um idiota escreveu isso" cria um ambiente em que os novatos têm medo de fazer perguntas (ou "não-idiotas" não questionam suas próprias práticas o suficiente), o que, por sua vez, leva a códigos ruins.

— Timothy Jones

@ TimothyJones Você percebe que é realmente possível premiar +100, por meio do mecanismo de recompensa?

— Dawood ibn Kareem

@DavidWallace eu tinha esquecido, obrigado. No entanto, não poderei comentar mais. Talvez eu volte e faça isso quando não for todo o meu representante.

— Timothy Jones

O pior é quando você diz: "Claramente, um idiota escreveu isso" pouco antes de perceber que está analisando seu próprio código!

— precisa saber é o seguinte

@GlenPeterson, Não, eu diria que o pior é quando a pessoa que escreveu isso está bem perto de você ...

— Svish

Isso pode ser o resultado desse processo de desenvolvimento .

Nos últimos 2 anos, tenho trabalhado com código de outras pessoas. Eu depurei, corrigi bugs e fiz melhorias. Na minha experiência, geralmente penso que o código é ruim, cheio de bugs, lento, consome muito mais memória do que o necessário, utilizava conceitos de programação inadequadamente, muito mal formatados (isso é difícil de conviver), não comentado e o fluxo lógico é um bagunça. E se eu disser que encontrei uma função com 5 mil linhas de código?

Então, na minha experiência, eu normalmente questiono a qualidade do código. Se algo é difícil de entender, porque é complexo, faz sentido depois que você o entende. Mas se é apenas ruim, sempre será ruim.

— Joqus
fonte

Resposta curta: Principalmente não gostamos ou somos muito críticos sobre o motivo pelo qual a codificação é feita dessa maneira, e não o contrário. No entanto, quanto mais você lê o código incorreto dos outros, mais rápido aprecia o código bem escrito :)

Embora possa parecer óbvio, mas a melhor maneira de melhorar a leitura do código das pessoas é: lendo o código das pessoas . O problema é que, quando as pessoas tipicamente leem o código de outras pessoas, elas não tentam " entendê- lo " , ou seja, familiarizam-se intimamente com ele; eles fazem o equivalente à leitura rápida de poesia.

Para inserir o código de outra pessoa, tente o seguinte:

Refatorando o código.
Escolher um recurso a ser adicionado que requer aprofundamento no código.
Escrevendo testes de unidade abrangentes para o código.

Todas essas etapas forçarão você a ler o código em maior profundidade.

Existem também algumas dicas de como maximizar o entendimento de uma base de código que você apresentou para manutenção e suporte:

Depois de ter uma idéia básica do que está acontecendo, você pode dar uma boa olhada no armazenamento de dados (a camada de persistência). Essa é outra ótima maneira de entender o que está acontecendo, mas verifique se as coisas que você está estudando estão realmente em uso. Lembro-me de algumas vezes que realmente cheguei ao fundo de algumas classes com essa abordagem, pensando que entendi o sistema - e depois percebendo mais tarde que as classes não eram usadas.

Pode parecer uma tarefa assustadora - leva tempo e nenhuma ferramenta sofisticada pode remover a necessidade de inteligência - mas também pode ser muito gratificante. À medida que avança, você provavelmente encontrará muitos bugs nos casos de canto / borda e verá maneiras de melhorar o código. Um conselho - não exagere na refatoração / alteração até entender bem o código. Freqüentemente, o que parece um erro ou simplesmente um código incorreto quando você o vê pela primeira vez, acaba sendo um gênio sutil no trabalho de uma investigação posterior e esclarecida. Além disso, a remoção de código não utilizado é muito satisfatória e excelente para futuros mantenedores. É claro, com a suposição de que toda a base de código é controlada por versão.

— Yusubov
fonte