Trabalhando como desenvolvedor único: examinando o código

Não tenho escolha a não ser trabalhar por conta própria e não consigo encontrar uma solução adequada para examinar meu trabalho, verificar a sanidade, ter alguém com quem debater idéias, discutir boas práticas e assim por diante.

Pensei em obter uma resposta no artigo de Jeff Atwood: Em Programação, Um é o número mais solitário , o melhor que pude encontrar sobre o assunto, mas acabou reiterando minha pergunta.

Eu sei que sites do Stack Exchange como este e Code Review são uma resposta potencial óbvia, mas, como muitos gostariam, é MUITO longe do ideal:

Embora eu não possa listar todas as armadilhas, em geral, formular uma pergunta e colocá-la em um problema autônomo geralmente exige tanto trabalho que, no momento em que você a preparou o suficiente, você respondeu sua própria pergunta com mais tempo do que seria necessário. Além disso, ocultar detalhes para fazer uma pergunta bem definida elimina a possibilidade de alguém detectar problemas nos quais você não tinha pensado. Além disso, embora eu não consiga entender, a capacidade de resposta da conversa gratuita não pode ser comparada a qualquer forma de discussão textual da Internet em que eu possa pensar. Por último, mas não menos importante, não quero postar todo o meu projeto para o mundo ver pelo resto da eternidade, por razões óbvias.

Há outras respostas além de pagar a um consultor para examinar meu código?

Eu estive no seu lugar e não acho que exista uma solução fácil. Pagar a um consultor para examinar seu código não é uma boa maneira de gastar dinheiro. Se o seu problema é que você se sente sozinho e não tem ninguém com quem conversar sobre programação, não posso ajudá-lo, mas se você está realmente interessado em melhorar a qualidade do seu código, a melhor coisa a fazer é defini-lo de lado e volte a ele daqui a uma semana. Se o código for realmente ruim, será óbvio, porque você não poderá entendê-lo e poderá refatorá-lo para fazer sentido. Após algumas iterações desse processo, você começará a observar os padrões de código que facilitam o entendimento do código e a qualidade do seu código melhorará.

Há outras respostas além de pagar a um consultor para examinar meu código?

Não.

Meu conselho é ingressar em um grupo local de desenvolvedores \ usuários e discutir suas idéias com outras pessoas. Fale sobre o seu design. Pergunte a outros como eles abordaram certos problemas.

Se eles verificarem seu design, mesmo sem examinar seu código, isso deve ser bom o suficiente.

Existem técnicas de autoavaliação, como desenvolvimento orientado a testes, que podem ajudar a fornecer feedback. Quando se torna difícil você sabe que sua arquitetura provavelmente está fora de sintonia.

formular uma pergunta e colocá-la em um problema autônomo geralmente exige tanto trabalho que, quando você a prepara suficientemente, já responde à sua própria pergunta em mais tempo do que seria necessário.

Problema resolvido. Você não precisa de feedback externo sobre cada linha de código para melhorar, apenas uma boa amostra nos principais garfos da estrada e verificações cuidadosas nos pontos intermediários.

Você precisa superar a ideia de que pode manter o mesmo nível de qualidade trabalhando sozinho, na mesma quantidade de tempo que alguém que trabalha em equipe. Há uma razão pela qual as pessoas trabalham em equipe. A boa notícia é que você não tem conflitos sobre decisões de design. A má notícia é que você não tem conflitos sobre decisões de design. Esperamos que o tempo extra que você gaste mantendo a qualidade seja compensado pelas vantagens de trabalhar sozinho.

Eu recomendaria fazer o máximo de networking possível em conferências e grupos de usuários locais. Conheço muitos desenvolvedores que gravam trechos de códigos higiênicos por e-mail ou im o tempo todo, apenas para manter a nitidez e analisar os algoritmos juntos. Não, não é uma conversa cara a cara, e sim, às vezes é difícil desanimar códigos, mas uma revisão de código de mensagens instantâneas de 20 em alguns momentos pode ser bastante útil, especialmente quando você está desesperado por um segundo par de olhos.

Estou em uma situação semelhante e confio bastante no Stack Overflow para obter feedback sobre perguntas cruéis. Também acho que, na verdade, preciso escrever uma descrição do problema que a resposta geralmente se torna óbvia. Em termos de práticas recomendadas, sou desenvolvedor de .Net e uso o ReSharper, que oferece sugestões de alternativas de boas práticas para o código que estou escrevendo (que às vezes eu simplesmente ignoro - pode ser um pouco pedante). E outra ferramenta útil é o FxCop, que fará uma análise estática do código e destacará qualquer problema que não corresponda ao seu conjunto de regras.

Caso contrário, é sua responsabilidade ler e manter-se atualizado sobre as práticas atuais. Gosto do Morning Dew de Alvin Ashcraft para obter links para o que há de novo e melhorado no mundo .Net.

Eu sugeriria tentar criar (ou encontrar) um pequeno grupo de usuários. Disponibilize seu código e peça a todos que se comprometam em fazê-lo funcionar - meia hora ou mais por dia.

Um feedback construtivo da minha experiência é que, durante os anos iniciais do seu desenvolvimento, seria muito importante, embora não obrigatório, que um desenvolvedor experiente revise seu código para estabelecer as bases. Quando tiver experiência, você pode seguir a abordagem sugerida por @ davidk01, isto é, revisar seu próprio código periodicamente para melhorar a qualidade do código.

Não conheço detalhes da sua situação, mas onde estou agora há muitas pessoas com fome de estudantes experientes que são mais do que felizes em trabalhar como estagiário e aprender alguma coisa.

Pode parecer um trabalho extra para você lidar com eles e ensiná-los isso e aquilo, mas estávamos todos lá quando começamos e acho que é a nossa vez de pagar.

Eles não são especialistas e podem até enganá-lo às vezes, mas geralmente desafiam tudo e estão cheios de idéias e são ótimos para uma discussão em que você precisa defender todos os detalhes do seu código.

Embora eu não possa listar todas as armadilhas, em geral, formular uma pergunta e colocá-la em um problema autônomo geralmente exige tanto trabalho que, no momento em que você a preparou o suficiente, você respondeu sua própria pergunta com mais tempo do que seria necessário.

Eu experimento o mesmo em> 75% das perguntas que eu postar.

No entanto, esse não é um argumento para não se incomodar em fazê-lo. Esta é efetivamente a depuração de pato de borracha. Você está encontrando respostas para as perguntas que acha podem surgir em resposta à sua pergunta; o que significa que você está pensando sobre o problema do ponto de vista de diferentes pessoas; o que significa que você está pensando no problema de todas as direções possíveis; qual é a melhor maneira de encontrar a falha.

Na melhor das hipóteses, você provou conclusivamente que claramente não consegue pensar na resposta aqui. No "pior", você acaba respondendo sua própria pergunta. Cuidado com as citações, porque isso não é ruim. Talvez tenha sido um pouco ineficiente, mas resolver o problema lentamente é melhor do que decidir rapidamente não resolver o problema . Você será mais rápido em resolver o problema eventualmente.

Caso em questão:

Quando eu era um desenvolvedor iniciante, lidei com a página de erros do ASP.Net várias vezes. Eu precisava procurar no Google a mensagem para descobrir o que havia de errado. pode demorar várias horas até que eu tenha a solução certa. Basicamente, cometi todos os erros do livro e, posteriormente, tive que lidar com as consequências de ter que depurar os problemas.

Agora, quando um erro aparece, eu já conheço os "suspeitos do costume" do que pode estar causando o problema. Minha lista mental de "suspeitos do costume" é efetivamente baseada nos problemas com os quais tive mais problemas durante minha carreira. Sem primeiro ter feito o trabalho de pernas ineficiente em termos de horas no Google, eu nunca teria feito essa lista mental . Mas agora que tenho essa lista mental, sou consideravelmente mais rápido na solução de problemas.

Além disso, embora eu não consiga entender, a capacidade de resposta da conversa gratuita não pode ser comparada a qualquer forma de discussão textual da Internet em que eu possa pensar.

Eu discordo um pouco aqui. Você está certo que a comunicação na Internet é menos responsiva, mas você (na minha opinião) está errado que isso faz mal a você.

Como desenvolvedor solitário, você dependerá da depuração de patos de borracha. O ingrediente chave para fazer o RDD funcionar é que você antecipa perguntas que o pato de borracha possa ter para você. Você obviamente não pode confiar no que o pato de borracha realmente diz.

Ao lidar com sistemas de mensagens lentos (postando no StackOverflow ou se comunicando escrevendo cartas), você é inerentemente incentivado a garantir que esteja certo da primeira vez. Porque precisar corrigir um erro será um processo lento e árduo.
Por comparação, considere que sistemas de mensagens rápidas (conversação, mensagens instantâneas), você pode corrigir imediatamente algo. A capacidade de corrigir rapidamente algo torna as pessoas menos incentivadas a garantir que ele esteja correto.

Quatro casos em questão:

• Quando estou fazendo minha própria análise pessoal / lista de tarefas como desenvolvedor, ainda uso caneta e papel. Percebi que falo sobre suposições e falsidades ao digitar minhas anotações, porque minha mente pensa que "posso consertar isso mais tarde". No entanto, ter que corrigir algo que você escreveu no papel é irritante, você precisa riscar as coisas e escrever nas entrelinhas, e o documento fica muito pior quando há rabiscos. Escrever em papel me faz checar os fatos antes de me comprometer a escrevê-lo. Isso pega muitos mal-entendidos cedo, antes mesmo de escrever um código que produzisse bugs.
• Minha avó era secretária (era da máquina de escrever). Fazer um erro de digitação em um documento formal significava ter que digitar a página inteira novamente. Minha tia é secretária (idade do processador de texto). Ela pode confiar em um verificador ortográfico automático, e os erros podem ser corrigidos facilmente e com o mínimo de esforço. Sem surpresa, minha avó comete menos erros de digitação e ortografia em comparação com minha tia.
• Os videogames costumavam ser impressos em cartuchos. Corrigir um bug após o lançamento era quase impossível. Você precisaria reimprimir todos os cartuchos, distribuí-los a todos os fornecedores e torcer para que os fornecedores entrassem em contato com os clientes que já compraram o jogo. Custaria toneladas de dinheiro (o dobro do custo de produção física) e ainda não alcançaria alguns clientes. Agora, na era das correções na Internet, os desenvolvedores de jogos mostraram ser consideravelmente menos investidos em testar seus jogos para evitar erros de lançamento, porque é muito mais fácil simplesmente corrigir uma correção diretamente para cada cliente. O impacto de cometer um erro é minimizado a um ponto em que é melhor corrigir alguns problemas após o fato, em comparação com a necessidade de testar todos os possíveis erros que podem ocorrer.
• Eu morava em um apartamento do terceiro andar, sem elevador, e precisava estacionar uma ou duas ruas do meu prédio. Eu quase nunca esqueci de tirar algo do meu carro. Agora, moro em uma casa com meu carro ao meu lado na garagem. Eu esqueço de tirar coisas do meu carro o tempo todo .

A idéia subjacente aqui é que um sistema de intercâmbio difícil incentiva as pessoas a fazer trocas corretas e verificadas . A severidade da punição (= processo de correção difícil) ensina você a não cometer erros.

Além disso, ocultar detalhes para fazer uma pergunta bem definida elimina a possibilidade de alguém detectar problemas nos quais você não tinha pensado.

Ao criar um MCVE , você não deve apenas criá-lo e publicá-lo na pergunta. Você deve primeiro fazer isso por conta própria , para poder isolar o problema. E então, quando você acha que o problema não pode mais ser reduzido e ainda não vê a causa; então você tem uma pergunta válida para o StackOverflow.

Caso em questão:

Eu sempre tenho um segundo Visual Studio em execução com um aplicativo de console simples chamado Sandbox. Sempre que encontro um problema técnico, copio o código incorreto na sandbox e começo a brincar com ele.

• O que acontece quando eu mudo essa configuração?
• Posso reproduzir o problema se diminuir o código?
• Quais configurações tornam possível / impossível reproduzir o problema?

Em 90% dos casos, encontro a causa do problema porque o sandbox me ajudou a analisar o código incorreto sem ser distraído pelo contexto circundante (ou, por exemplo, por qualquer incerteza sobre valores que ocorrem em diferentes partes do código.

Nos outros 10% dos casos, fiquei com o código mínimo para reproduzir o problema, que serve como um exemplo de snippet perfeito para postar no StackOverflow.

Por último, mas não menos importante, não quero postar todo o meu projeto para o mundo ver pelo resto da eternidade, por razões óbvias.

Quando você já possui seu MCVE, não deve ter muita informação pessoal (ou da empresa). Se o fizer, como o código é mínimo, é fácil renomear as coisas para um exemplo mais básico de foo / bar / baz.