Ajudar alguém que não é e nunca será um programador profissional a escrever um código mais legível e utilizável para usar e interpretar [fechado]

Eu sou Elvis, tentando muito aprender a ser Einstein. Eu trabalho para o Mort.

De que diabos esse idiota louco está falando!?!? (Você só precisa ler os primeiros parágrafos)

Se você não gosta de ler esse link, basicamente, sou um programador profissional e meu chefe é (isso é assustadoramente preciso):

o programador profissional de linha de negócios que não possui formação em ciência da computação, mas que possui muita familiaridade com o Office e o VBA, e que normalmente escreve aplicativos de produtividade compartilhados entre seus colegas de trabalho

Tudo isso dito, grande parte do meu trabalho é pegar seu código de paralelepípedo e torná-lo pronto para produção. No entanto, o estilo muito pobre e o cultismo de carga tornam isso difícil. Isso é agravado pelo fato de ele não querer ler livros de programação ou me permitir ajudá-lo a refatorar seu código.

Existem outras estratégias para ajudar alguém que não é um programador profissional e nunca será um programador profissional a escrever código daqui para frente que seja mais legível e utilizável para eu usar e interpretar?

Ao analisar suas respostas em vários comentários, não sei se você percebe que o que está experimentando é bastante comum, principalmente quando trabalha em áreas especializadas onde são necessários especialistas em domínio (vamos chamá-los de cientista) para descobrir como incorporar e adaptar algoritmos para problemas em questão.

Em vez de reclamar do cientista e esperar que ele mude, apenas perceba que você não deve esperar que o cientista se importe muito com a "qualidade do código". Freqüentemente é difícil fazer com que outros desenvolvedores de software se preocupem com a "qualidade do código" e muito menos com alguém cujos principais interesses estejam no domínio e não na programação.

Para onde você vai daqui depende em grande parte o grau de confiança que o "cientista" tem em sua capacidade de entender o trabalho deles. Se eles confiam que você pode entender o código deles e não o estragar quando você modifica as coisas, geralmente não há problema. Eles contarão com sua experiência.

No entanto, se o cientista não quiser que você altere o código deles, é muito provável que você ainda não "tenha conquistado" a confiança deles. Se for esse o caso, em vez de se concentrar em consertar o cientista, você deve se concentrar em "consertar" a si mesmo. O que quero dizer com isso é tomar medidas para ganhar sua confiança. Provavelmente, a maneira mais fácil de fazer isso é a seguinte:

Como parte do seu processo de teste:

1. Comece a transformar os algoritmos em algo mais fácil de entender (por exemplo, diagramas, PDL, notação matemática)
2. Aprenda a entender os algoritmos.
3. Certifique-se de identificar os casos extremos.
4. Pergunte ao cientista se sua representação "alternativa" simplificada está correta
5. E, MAIS IMPORTANTE, identifique os problemas que você encontrou; E, sem soar "acusatório", diga algo como "Eu estava olhando para o algoritmo e notei que XYZ deveria fazer isso ou deveria fazer isso?". Nada ganhará sua confiança melhor do que esta bala.

Quando você começa a encontrar bugs E demonstra interesse na área de interesse, as chances se tornam muito maiores que pelo menos elas permitem que você comece a modificar o código para torná-lo mais "profissional". Freqüentemente, eles nem sentem mais a necessidade de codificar um protótipo. Eles escreverão algo em uma dessas anotações "alternativas" que você ensinou (sem que eles percebam) e terão confiança de que você saberá o que eles significam.

De qualquer maneira, minha primeira tentativa seria oferecer algumas sugestões sobre como o cientista poderia ajudar a "se comunicar" melhor para ajudá-lo; mas parece que você já tentou isso. Portanto, o único passo que você tem controle é o que você faz. Ganhe sua confiança e quase sempre o especialista em domínio ficará aliviado em passar a codificação para outra pessoa e não precisará se preocupar com todos os pequenos detalhes necessários para escrever o código. Eles preferem se concentrar em melhorar os algoritmos.

Às vezes, tudo o que você pode fazer é oferecer uma sugestão e deixar para lá depois. Você não impressionará seu chefe ou um veterano se continuar insistindo em algo que ele já rejeitou ou decidiu que não quer fazer, mesmo se você estiver 100% correto. De fato, isso prejudicará um relacionamento, seja você o sugerente ou o sugerido. Apenas se concentre no que você pode fazer para facilitar seu trabalho.

Quando ele é realmente "alguém que não é um programador profissional, nunca será um programador profissional", como você diz, e quando grande parte do seu trabalho é realmente "pegando o código de paralelepípedos e preparando a produção", parece que você A equipe de dois homens seria mais produtiva quando deixaria a programação para você e se concentraria na parte gerencial do projeto.

No entanto, isso pressupõe que você esteja certo. Nós programadores sempre tendemos a desconsiderar o código escrito por outras pessoas muito pior que o nosso. Esse preconceito é realmente difícil de derrotar e nos leva a subestimar nossos colegas. O que você considera "programação de cultos de carga" pode ser "melhores práticas comprovadas" da perspectiva dele, e o que você considera "aplicação elegante de padrões orientados a objetos" pode ser "uma engenharia desnecessária" para ele. Difícil dizer para mim, porque eu só conheço o seu lado da história.

O desprezo pelo código de outras pessoas se torna mais forte, quanto mais diferentes são nossos estilos de programação. Nesse caso, é um instinto positivo, porque a mistura de diferentes estilos de programação em um projeto dificulta a manutenção.

Quando vocês dois não conseguem imitar o estilo do outro, podem definir responsabilidades claras. Responsabilize uma pessoa por uma parte do aplicativo e a outra pessoa pela outra. Defina interfaces claras entre os dois módulos juntos, mas deixe a implementação interna para o responsável. Para torná-lo mais ciente dos erros em seu código, você pode escrever testes de unidade para ele e apontar quando o código dele obviamente não se comporta de acordo com o contrato de interface que você especificou juntos.

Ao estabelecer uma propriedade clara do código, você pode obter uma melhor coexistência de seus diferentes estilos. Além disso, quando vocês dois são responsáveis ​​por corrigir os erros em seu próprio código, não precisam navegar com frequência pelos códigos dos outros.

Você precisa se perguntar: qual é o seu objetivo final aqui? 1. para ajudar seu chefe? 2. para ajudar a empresa? 3. para ajudar a si mesmo? E antes de responder "todas as opções acima", reduza a velocidade. Sua primeira tarefa é definir claramente seu objetivo principal, porque a resposta depende disso.

Se seu objetivo é:

1. Ajudar seu chefe? Desistir. Ele não parece estar pedindo por isso. Você disse: "Ele sabe que seu código é ruim, mas faz o que ele precisa". Bem, então, final da discussão. A menos que e até que seu chefe esteja insatisfeito com a situação atual, ele não vai mudar e ressentirá seus esforços para ajudá-lo. Se, em algum momento no futuro, ele "sentir a dor" do status quo, espero que você tenha se estabelecido como um mentor confiável e ele saberá onde pedir ajuda.

2. Ajude sua empresa? A situação atual está ameaçando os resultados? Os prazos estão em risco? A alta gerência está aumentando seu calor? Caso contrário, desista. (Esse é essencialmente o argumento que Jimmy Hoffa fez em seu comentário à sua postagem original.) Se, no entanto, a situação atual representar de fato um risco inaceitável para o seu departamento / empresa, uma mudança de processo será necessária. Nesse caso, eu sugeriria que você se sentasse e descrevesse outradivisão de trabalho. A chave aqui é explicar que o tempo que você gasta refatorando o código do seu chefe seria melhor gasto escrevendo um novo código. Você diz que não tem tempo escrevendo tudo sozinho, mas não é isso que estou sugerindo. Você precisa descobrir como maximizar seus respectivos pontos fortes. Pare de pensar nele como um Mort e pense nele como um desenvolvedor júnior com conhecimento de domínio superior. Esse é um acordo de trabalho muito comum no setor, e você deveria aprender a prosperar nele. Por exemplo, verifique se ele sabe que você sabe o quão essencial é o conhecimento dele (repita essa etapa com frequência) e, em seguida,humildemente, sugira a seguinte estratégia (ou algo semelhante) como um caminho mais rápido para levar seu conhecimento ao mercado: (a) divida o trabalho em sprints "ágeis", (b) colabore fortemente na frente (em cada sprint) definindo o excesso todos os requisitos e arquitetura. (c) Deixe-o sair e construir o protótipo para elaborar todas as decisões algorítmicas, enquanto você constrói a infraestrutura com a qual concordou na etapa anterior. (d) Implemente seus algoritmos em sua estrutura enquanto ele cria testes para verificá-lo. (e) Conduza seu V&V juntos em um ambiente de programação por pares. (por exemplo, "Este teste falhou; por quê? erro de lógica algorítmica ou erro de codificação?"; itere aqui).

3. Fique a vontade? Seja honesto aqui. Se tudo o que você está fazendo é reclamar que não gosta do seu trabalho, sugiro que você gaste mais tempo pensando no item 2 acima. Se você não se importa com a empresa E não gosta do seu trabalho, comece a distribuir seu currículo. Se você se preocupa com a sua empresa, mas não gosta do seu trabalho, o foco no número 2 deve ajudar em ambas as contas. Mas, nesse caso, é um "ganha-ganha" somente se for claro para todos que sua paixão deriva genuinamente de um desejo de ajudar a equipe, e não apenas de uma frustração egocêntrica em sua tarefa.

Não tenho certeza se acrescentarei algo a esta discussão, mas tendo trabalhado em cenários semelhantes em que uma violação do Access está atingindo uma linha com ShowMessage('Hello');ou similar, apenas para descobrir que a mesma linha tem mais código, fora da tela para o direita,

Eu acredito que você tem duas opções básicas:

1. Deixe o código executar . Se o código estiver funcionando e fazendo o que deve fazer, a menos que seu chefe esteja pedindo especificamente que você corrija o código, deixe como está. Isso também pode levá-lo a entender que seu código parece mais agradável e deixar o trabalho para você (como também apontado por Dunk em sua resposta).
2. Se você está muito determinado a tornar o código profissional, crie uma biblioteca / estrutura que ele possa usar. Se houver um padrão nos erros / estratégias que você corrige normalmente, você poderá agrupá-los em alguns arquivos da biblioteca e fornecer a ele como uma "biblioteca base da empresa" , que você também pode usar como um interface comum.