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

Estou trabalhando sozinho em um projeto de código aberto bastante grande há um bom tempo e está chegando ao ponto em que gostaria de lançá-lo. No entanto, sou autodidata e não conheço ninguém que possa revisar adequadamente meu projeto.

Alguns anos atrás, eu havia lançado um pequeno pedaço de código que praticamente foi rasgado (em um sentido crítico) no fórum em que o liberei. Embora o código tenha funcionado, as críticas foram precisas, mas brutais. Isso me levou a começar a procurar as melhores práticas para tudo e, no final, acho que isso me tornou um desenvolvedor muito melhor. Eu revi tudo no meu projeto tantas vezes tentando torná-lo perfeito que perdi a conta.

Acredito no meu projeto e acho que ele tem potencial para ajudar muitas pessoas e sinto que fiz algumas coisas legais de maneiras interessantes com ele. Ainda assim, como sou autodidata, não posso deixar de me perguntar quais são as lacunas existentes na minha auto-educação. A maneira como meu código foi dividido da última vez não é algo que eu gostaria de repetir. Eu acho que meus dois maiores medos em lançar meu projeto em que dediquei inúmeras horas estão sendo absolutamente embaraçados porque perdi algumas coisas óbvias por causa da minha auto-educação ou, pior, liberá-lo ao som de grilos.

Existe alguém que esteve em uma situação semelhante? Não tenho medo de críticas construtivas, desde que sejam construtivas e não apenas um discurso retórico sobre como eu estraguei tudo. Eu sei que existe um site de revisão de código no StackExchange, mas ele não está realmente configurado para grandes projetos e eu não sentia que a comunidade ainda fosse grande o suficiente para obter um bom feedback se eu publicasse partes do meu projeto aos poucos (eu tentei com um arquivo). O que posso fazer para dar ao meu projeto pelo menos alguma medida de sucesso sem ficar constrangido ou desestimulado no processo?

A menos que o projeto seja direcionado aos desenvolvedores (por exemplo: uma estrutura de desenvolvimento, nesse caso, você QUER que eles a critiquem, se isso faz você aprender 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 um aplicativo para seres humanos comuns, eles provavelmente se importarão apenas com os resultados.

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

A menos que seja, digamos, 10 linhas ou menos, é falha. Talvez tragicamente.

Ser desenvolvedor é CONSTANTEMENTE se misturar contra os limites de suas habilidades e compreensão. Pode não ser assim para TODOS os desenvolvedores, mas para mim e para os que conheço, trabalhamos sempre na ponta da nossa competência o tempo todo. E você enfrenta isso repetidas vezes, depois tem um bom fim de semana, depois volta segunda-feira e faz isso repetidamente.

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

Você escreve seu código e também sabe como. Talvez amanhã você saiba mais do que sabia hoje, mas hoje você fez isso tão bem quanto sabia. Meu conselho é: escreva o código de hoje hoje e o de amanhã amanhã. Então, tenha um bom 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 elas, para portá-lo para uma plataforma diferente ou como um ponto de partida para seus próprios programas. Se eles não gostam do código, normalmente não usam o código e você nunca os ouvirá.
2. Alunos, tentando aprender a codificar no idioma que você usou. Eles quase nunca entrarão em contato com você, mas, ocasionalmente, você receberá um e-mail perguntando por que fez algo de uma maneira ou de outra. (Para ser justo, eu não recebo um desses emails há muitos anos. Acho que sites como o StackExchange podem ter substituído essa interação)
3. Pesquisadores de segurança, como o pessoal do OpenBSD, tentando decidir se sua ferramenta é segura o suficiente para ser incluída em sua distribuição. Se não estiver, mas eles ainda quiserem incluir o seu programa, entrarão em contato para descobrir uma maneira de protegê-lo. (E se o seu programa se tornar popular, imagino que provavelmente também atraia pesquisadores de chapéu preto, que não entrarão em contato com você, não importa o que encontrem.)

No mundo real, as pessoas realmente não leem o seu código-fonte por nenhum outro motivo além disso, porque simplesmente não precisam. Você só recebeu esse volume de comentários antes porque publicou o código em um fórum, o que implicava que queria receber comentários 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 as que desejam adicionar recursos ou corrigir bugs, que já navegaram na 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 a ser feita seria "o que eu tenho a perder ao lançar este software"

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

Mesmo que o código seja péssimo e alguém dedique algum tempo para escrever um e-mail para você, adivinhe, ele provavelmente usou o software o suficiente para querer fazer algumas alterações e torná-lo melhor.

Você deveria estar feliz com isso! Aceite as críticas e melhore o seu código, peça ao cara com raiva que teve tempo para escrever para você. Ele se importa!

Depois de um tempo, os e-mails cessarão, 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á.

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

Se você realmente não está confortável em liberar o software com seu nome, solte-o com um apelido. Se for bem-sucedido, reivindique-o como seu, caso contrário altere seu apelido :)

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

Quanto mais tempo estou neste jogo, mais percebo que a única medida de qualidade do 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. Uma estrutura? Os adotantes disso. Um autônomo? A pessoa ou daemon que inicia o programa.

O código legal tem sua virtude, não me interpretem mal, mas quando é dito e feito, a única medida é "Funciona?" Eu já vi muitos códigos limpos, que são uma bagunça de buggy, e muitos códigos satanicamente perturbados, que são completamente confiáveis ​​(além de boas imagens limpas e ruins também :))

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 (teste de dados!) Que você procura melhorar seu programa. Aguente firme, evite a população de trolls da Internet e divirta-se no seu projeto!

Eu concordo plenamente com o que outros pôsteres disseram: Mesmo que seu código seja ruim e não seja de alta qualidade - a maioria das pessoas simplesmente não se importa. Todo mundo que mergulhou no código OpenSource uma vez ou outra pode ter pensado "WTF aconteceu aqui".

Mas eu não conheço ninguém por aí com a motivação de 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 sabemos que qualquer código que estamos escrevendo agora parecerá muito ruim para nós em apenas algumas semanas (o meu definitivamente será).

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

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

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

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

Algumas palavras sábias de Reid Hoffman, cofundador do LinkedIn:

"Se você não está envergonhado com o seu primeiro lançamento do produto, você o lançou tarde demais."

"Conseguir o envolvimento com os membros e ver o que é realmente importante é completamente essencial ... Então você obtém o produto mínimo viável o mais rápido possível."

Eu acho que isso se aplica especialmente a projetos de código aberto, onde ter uma ótima idéia com um início promissor incentiva as pessoas a contribuir e participar. Algo que é tão polido que faz você colocar seus óculos de sol pode não evocar tais sentimentos. Mas a coisa mais importante sobre a liberação antecipada é quebrar todos os seus preconceitos sobre o que deve ser feito e começar a avançar 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ê é quem vai se candidatar ao emprego e teme que o empregador possa ler essas críticas e pensa que você é um mau programador? O que estou perguntando é por que você tem medo de críticas sobre como estraga tudo. Você decide quais são os comentários genuínos e quais são os delitos. Pegue os bons como defeitos e corrija-os na próxima versão. Só estou sentindo que você está se preocupando desnecessariamente com as críticas. Você está ajudando a comunidade de código aberto, que por si só é uma causa muito boa. Por favor, mantenha o bom trabalho.

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

Quando / se você receber críticas públicas, isso resultará em melhorias no código e o ajudará a crescer como desenvolvedor. Isso é uma coisa boa.

Acho que, para meus projetos, a maioria das críticas / sugestões construtivas é enviada em particular, e não transmitida publicamente, e mesmo assim é improvável que você receba uma enxurrada de comentários. Portanto, eu recomendo apenas ir em frente!

Boa sorte.

Não há nada errado com o auto-estudo por si só. Você não pode ser isolado e as revisões de código por pares podem ajudar nisso.

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

O objetivo 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 disponível também é estelar. Às vezes, você recebe requisitos ruins, às vezes não tem tempo para fazer o que é certo. Às vezes, os desenvolvedores querem parecer um gênio, fazendo os outros parecerem ruins.

Não acredito que você possa aprender sem cometer alguns erros, principalmente se for algo que requer disciplina e esforço reais. Se fosse fácil, todos estariam fazendo isso. Apenas tente limitar os erros aos menores, usando as melhores práticas estabelecidas. Sei 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 em primeiro lugar. Dito isto, minha primeira crítica ao código é: tente considerá-lo objetivamente e aprenda com ele.