Liberando um projeto de código aberto sem ficar envergonhado [fechado]

A menos que o projeto seja destinado a desenvolvedores (por exemplo: uma estrutura de desenvolvimento, caso em que você QUER criticar se isso fizer com que você aprenda ainda mais), não se preocupe. Mas mesmo assim, existem muitos projetos de código aberto voltados para desenvolvedores que são uma porcaria, mas as pessoas os amam porque vão direto ao ponto (pense no Codeigniter, que é muito mal arquitetado, e ainda é o framework php mais popular)

Se for uma aplicação para humanos normais, eles provavelmente só se importarão com os resultados.

Seu código tem problemas. Também o meu. Alguém mais respondeu a esta pergunta? O código deles também tem problemas.

A menos que sejam, digamos, 10 linhas ou menos, é falho. Talvez de maneira trágica.

Ser um desenvolvedor é CONSTANTEMENTE se misturar com os limites de suas habilidades e compreensão. Pode não ser assim para TODOS os desenvolvedores, mas para mim e para os que eu conheço, trabalhamos no limite de nossa competência praticamente em todos os momentos. E você enfrenta isso de novo e de novo, depois tem um bom fim de semana, depois volta na segunda e faz de novo e de novo e de novo.

Tendo trabalhado essa vida por 15 anos, a coisa que resolvi é um fato: Você não é o seu código . Você escreve o código. O julgamento do código NÃO é um julgamento de você . Seu código tem problemas, alguns que você conhece, outros não. Ter isso trazido à sua atenção ajuda você , a menos que tudo que você possa fazer sobre isso seja sentir-se mal. Sentir-se mal não melhora o seu código, apenas faz você se sentir mal.

Você escreve seu código e escreve tão bem quanto você sabe. Talvez amanhã você saiba mais do que você fez hoje, mas hoje você fez isso tão bem quanto você sabia. Meu conselho é: escreva hoje o código de hoje e amanhã o código de amanhã. Então, tenha um ótimo final de semana e volte na segunda-feira para escrever o código de segunda-feira.

Como regra geral, os programas de código aberto têm três grupos de pessoas que analisam o código-fonte.

1. Pessoas que estão pensando em modificar o código para fazer com que o programa funcione de maneira um pouco diferente para eles, para transportá-lo para uma plataforma diferente ou como um ponto de partida para seus próprios programas. Se eles não gostarem do código, eles normalmente não usarão o código e você nunca ouvirá deles.
2. Alunos que tentam aprender a codificar no idioma que você usou. Estes quase nunca entrarão em contato com você, mas você pode ocasionalmente receber um e-mail perguntando por que você fez algo de um modo em relação ao outro. (Para ser justo, eu não recebi nenhum desses e-mails em muitos anos. Acho que sites como o StackExchange podem ter substituído essa interação)
3. Pesquisadores de segurança, como os caras do OpenBSD, tentando decidir se sua ferramenta é segura o suficiente para ser incluída em sua distribuição. Se não for, mas eles ainda querem incluir seu programa, eles entrarão em contato para descobrir uma maneira de protegê-lo. (E se o seu programa se tornar popular, imagino que ele provavelmente também atrairá pesquisadores de black hat, que não entrarão em contato com você, não importa o que encontrarem.)

No mundo real, as pessoas realmente não vão ler o seu código-fonte por qualquer outro motivo que não seja, porque elas simplesmente não precisam. Você só recebeu esse volume de comentários antes porque postou o código em um fórum, o que significa que você queria receber feedback sobre o código.

Eu não acho que você realmente precise se preocupar com uma torrente de abuso; as únicas pessoas que provavelmente entrarão em contato com você são pessoas que querem adicionar recursos ou corrigir bugs, que já navegaram pela base de código e não correram gritando pelas colinas. ;)

Eu realmente não entendo a psicologia por trás dessa pergunta ... uma pergunta melhor seria: "o que eu tenho a perder com o lançamento desse software"

Mesmo que seu projeto esteja cheio de códigos cheirosos, você precisa perder alguma coisa?

Mesmo que o código seja horrível e alguém dedique um tempo para escrever uma mensagem para você, adivinhe, ele provavelmente usou seu software o suficiente para fazer algumas alterações e torná-lo melhor.

Você deveria estar feliz com isso! Aceite as críticas e melhore seu código, pergunte ao cara irritado que reservou um tempo para escrever para você. Ele se importa!

Depois de um tempo as mensagens vão parar, as pessoas continuarão usando seu software, você aprenderá com seus erros e as lacunas que você não sabia que existiam em sua educação não estarão mais lá.

Eu prefiro trabalhar com alguém que esteja disposto a fazer algo, admitir seus erros, corrigi-los e continuar do que alguém que não esteja disposto a fazer nada.

Se você não se sentir confortável em liberar o software com o seu nome, solte-o sob um apelido. Se conseguir reivindicá-lo como seu, se não mudar seu apelido:)

Acredito firmemente não apenas no código aberto, mas no desenvolvimento aberto , onde as pessoas podem ver a evolução completa do seu código. Do protótipo do cérebro ao trabalho com o código de trabalho ... você nunca deve ficar envergonhado. Você está se colocando lá fora - isso requer coragem. Adquira e tenha orgulho disso. Ninguém é perfeito.

Quanto mais tempo eu estive nesse jogo, mais eu percebi que a única medida de qualidade de código é a experiência do cliente. Se você está escrevendo uma função, é o chamador dessa função. Uma biblioteca? Os desenvolvedores que escrevem para essa biblioteca. Um quadro? Os adotantes disso. Um autônomo? A pessoa ou daemon que inicia o programa.

O código legal tem sua virtude, não me leve a mal - mas quando é dito e feito, a única medida é "funciona?" Eu vi um monte de código limpo que é uma bagunça buggy, e um monte de código satanicamente enlouquecido que é completamente confiável (além de bem limpo e feio) :)

Então, se os críticos dizem que seu código é feio, quem se importa. Se eles disserem que não funciona - essa é a crítica útil (dados de teste!) Que você procura melhorar seu programa. Aguente firme, evite a população de trolls da Internet e divirta-se no seu projeto!

Concordo strongmente com o que outros posters disseram: Mesmo que o seu código seja de baixa qualidade e não de alta qualidade - a maioria das pessoas simplesmente não se importa. Todos que já mergulharam no código OpenSource de uma vez ou outra podem ter pensado para si mesmo "WTF aconteceu aqui".

Mas eu não conheço ninguém por aí com a motivação para criticar a base de código de um projeto apenas para dizer "cara, seu código parece horrível!". Todos nós já estivemos lá e todos nós sabemos que qualquer código que estamos escrevendo agora parecerá muito insatisfatório para nós mesmos em apenas alguns vislumbres (o meu definitivamente será).

Portanto, não se preocupe tanto - as pessoas simplesmente têm muito melhor para fazer no seu tempo livre do que deduzir o código dos projetos OpenSource.

O código real está sempre apodrecendo e sujo, colado e mantido de maneira aproximadamente ad hoc. A limpeza é limitada à documentação de casos especiais e constantes especiais. Existe uma incompatibilidade de impedância entre o código limpo e o mundo real.

Eu também notei que qualquer engenheiro competente pode separar o código de outra pessoa.

Se (1) passar nos testes e conseguir o propósito feito sem falhar E (2) você pode fazer pequenas alterações com apenas pequenas reescritas, é um bom código.

Algumas palavras sábias de Reid Hoffman, co-fundador do LinkedIn:

“If you’re not embarrassed by your first product release, you’ve released too late.”

“Getting engagement with members and seeing what is actually important is completely key… So you get out the minimum viable product as soon as you can.”

Eu acho que isso se aplica especialmente a projetos de código aberto, onde ter uma ótima ideia com um começo promissor incentiva as pessoas a contribuir e participar. Algo que é tão polido faz você colocar seus óculos de sol pode não evocar tais sentimentos. Mas a coisa mais importante sobre liberar cedo é quebrar todos os seus preconceitos sobre o que deve ser feito e começar a se mover na direção certa.

Quem é você? Você é alguém que as pessoas conhecem como programador de Deus e teme que sua reputação caia? Você é aquele que vai se candidatar ao cargo e se preocupa com o fato de o empregador poder ler essas críticas e achar que você é um mau programador? O que eu estou perguntando é por que você tem medo de críticas sobre como você estraga tudo. Você decide quais são os comentários genuínos e quais são rivais. Pegue os bons como defeitos e conserte-os na próxima versão. Estou apenas sentindo que você está se preocupando desnecessariamente com as críticas. Você está ajudando a comunidade de código aberto, que em si é uma causa muito boa. Por favor, mantenha o bom trabalho.

Se você estiver genuinamente preocupado, basta usar um pseudônimo online ao liberar o software. Então, não há como impactar sua reputação na vida real.

Quando / If receber críticas do público, isso levará a melhorias no código e ajudará você a crescer como desenvolvedor. Isso é bom.

Acho que para meus projetos as críticas / sugestões mais construtivas são enviadas em particular, em vez de transmitidas publicamente, e mesmo assim é improvável que você receba uma enxurrada de comentários. Portanto, eu recomendo apenas ir para ele!

Boa sorte.

Não há nada errado com o auto-estudo em si mesmo. Você não pode ser isolado e revisões de código de peer podem ajudar com isso.

Você também precisa se concentrar no que está fazendo. Por que você se importa se receber feedback negativo sobre o seu trabalho? Se é porque você está fazendo a suposição de que, se você receber críticas, é porque o código é ruim ou você não é bom em programação, isso pode ou não ser verdade.

O propósito do esforço é garantir que o código funcione e obter o melhor código possível, mas, por experiência prática, nem todo o código comercial lá fora é estelar. Às vezes você recebe requisitos ruins, às vezes você não tem tempo para fazer o certo. Às vezes, os desenvolvedores querem parecer geniais fazendo os outros parecerem ruins.

Eu não acredito que você possa aprender sem cometer alguns erros, especialmente se for algo que exige muita disciplina e esforço. Se fosse fácil, todo mundo estaria fazendo isso. Apenas tente limitar os erros aos menores, usando as melhores práticas estabelecidas. Eu percebo que nem sempre é possível!

Se eu me preocupasse com o que os outros pensavam de mim como programador, eu não teria entrado em campo antes de tudo. Dito isto, minha primeira crítica à crítica do código é tentar tomá-lo objetivamente e aprender com ele.