Rilascio di un progetto open source senza imbarazzo [chiuso]

Ho lavorato da solo su un progetto open source abbastanza grande per un bel po 'e si sta avvicinando al punto in cui mi piacerebbe rilasciarlo. Tuttavia, sono autodidatta e non conosco davvero nessuno in grado di rivedere adeguatamente il mio progetto.

Alcuni anni fa, avevo rilasciato un po 'di codice che praticamente era stato strappato (in senso critico) sul forum in cui l'avevo rilasciato. Anche se il codice ha funzionato, la critica è stata accurata ma brutale. Mi ha spinto a iniziare a cercare le migliori pratiche per tutto e alla fine sento che mi ha reso uno sviluppatore molto migliore. Ho ripassato tutto nel mio progetto così tante volte cercando di renderlo perfetto da aver perso il conto.

Credo nel mio progetto e penso che abbia il potenziale per aiutare molte persone e mi sento come se avessi fatto cose interessanti in modi interessanti. Tuttavia, poiché sono autodidatta, non posso fare a meno di chiedermi quali siano le lacune nella mia autoeducazione. Il modo in cui il mio codice è stato fatto a pezzi l'ultima volta non è qualcosa che vorrei ripetere. Penso che le mie due più grandi paure nel rilasciare il mio progetto in cui ho riversato innumerevoli ore siano assolutamente imbarazzate perché mi sono perse alcune cose palesemente ovvie a causa della mia auto-educazione o, peggio ancora, nel rilasciarlo al suono dei grilli.

C'è qualcuno che si è trovato in una situazione simile? Non ho paura delle critiche costruttive, fintanto che sono costruttive e non solo una sfuriata su come ho fatto un casino. So che esiste un sito di revisione del codice su StackExchange, ma in realtà non è impostato per progetti di grandi dimensioni e non pensavo che la community fosse abbastanza grande da ricevere un buon feedback se avessi pubblicato parti del mio progetto frammentariamente (I provato con un file). Cosa posso fare per dare al mio progetto almeno un po 'di successo senza essere imbarazzato o deviato nel processo?

A meno che il progetto non sia rivolto agli sviluppatori (ad es. Un framework di sviluppo, nel qual caso VUOI che lo critichino se ti fa imparare ancora di più), non dovresti preoccuparti. Ma anche allora, ci sono molti progetti open source rivolti agli sviluppatori che sono una schifezza, eppure le persone li adorano perché vanno al punto (pensa a Codeigniter, che è molto scarsamente progettato, e tuttavia è il framework php più popolare)

Se si tratta di un'applicazione per umani normali, probabilmente si preoccuperanno solo dei risultati.

Il tuo codice ha problemi. Anche il mio. Qualcun altro ha risposto a questa domanda? Anche il loro codice ha problemi.

A meno che non sia, diciamo, 10 righe o meno, è difettoso. Forse tragicamente così.

Essere uno sviluppatore significa CONSTANTAMENTE schiacciarti contro i limiti delle tue capacità e comprensione. Potrebbe non essere così per TUTTI gli sviluppatori, ma per me e per quelli che conosco, lavoriamo quasi sempre al limite della nostra competenza. E lo affronti ancora e ancora e ancora, poi passa un bel fine settimana, poi torna lunedì e fallo ancora e ancora e ancora e ancora.

Avendo lavorato quella vita per 15 anni, la cosa su cui ho deciso è questo fatto: non sei il tuo codice . Scrivi il codice. Sentenza del codice NON è il giudizio di voi . Il tuo codice ha problemi, alcuni che conosci, altri no. Avere quello che ti ha portato alla tua attenzione ti aiuta , a meno che tutto ciò che puoi fare al riguardo sia stare male. Sentirsi male non migliora il tuo codice, ti fa solo sentire male.

Scrivi il tuo codice e lo scrivi come sai. Forse domani saprai più di quello che hai fatto oggi, ma oggi lo hai fatto come sapevi. Il mio consiglio è: scrivere il codice di oggi oggi e il codice di domani domani. Quindi passa un buon fine settimana e torna lunedì a scrivere il codice di lunedì.

Come regola generale, i programmi open source hanno tre gruppi di persone che guardano il codice sorgente.

1. Le persone che stanno pensando di modificare il codice per far funzionare il programma in modo leggermente diverso per loro, per portarlo su una piattaforma diversa o come punto di partenza per i propri programmi. Se non gli piace il codice, in genere non lo useranno e non ne sentirai mai parlare.
2. Studenti, cercando di imparare a programmare nella lingua che hai usato. Questi non ti contatteranno quasi mai, ma potresti occasionalmente ricevere un'e-mail che ti chiede perché hai fatto qualcosa in un modo o in un altro. (Per essere onesti, non ho avuto una di queste e-mail da molti anni. Penso che siti come StackExchange possano aver sostituito questa interazione)
3. Ricercatori di sicurezza, come i ragazzi di OpenBSD, cercano di decidere se il tuo strumento è abbastanza sicuro da essere incluso nella loro distribuzione. Se non lo è, ma vogliono ancora includere il tuo programma, si metteranno in contatto per trovare un modo per proteggerlo. (E se il tuo programma diventa popolare, immagino che probabilmente attirerà anche i ricercatori di black hat, che non ti contatteranno, qualunque cosa trovino.)

Nel mondo reale, le persone non leggeranno davvero il tuo codice sorgente per nessun altro motivo diverso da questi, perché semplicemente non ne hanno bisogno. Hai ricevuto un tale volume di feedback solo perché hai pubblicato il codice su un forum, il che implicava che volevi ricevere feedback sul codice.

Non penso che tu debba davvero preoccuparti di un torrente di abusi; le uniche persone che potrebbero contattarti sono persone che vogliono aggiungere funzionalità o correggere bug, che hanno già sfogliato la base di codici e non hanno corso a urlare per le colline. ;)

Davvero non capisco la psicologia dietro questa domanda ... una domanda migliore da porsi sarebbe "cosa devo perdere rilasciando questo software"

Anche se il tuo progetto è pieno di odori di codice, devi perdere qualcosa?

Anche se il codice è terribile e qualcuno si prende il tempo di scriverti una mail di fiamma, indovina un po ', probabilmente ha usato il tuo software abbastanza da voler apportare alcune modifiche e migliorarlo.

Dovresti esserne felice! Accetta le critiche e migliora il tuo codice, chiedi al ragazzo arrabbiato che si è preso il tempo di scriverti. Ci tiene!

Dopo un po 'le mail di fiamma si fermeranno, le persone continueranno a usare il tuo software, avrai imparato dai tuoi errori e le lacune che non sapevi esistessero nella tua istruzione non saranno più lì.

Preferirei di gran lunga lavorare con qualcuno che è disposto a fare qualcosa, ammettere i propri errori, correggerli e andare avanti rispetto a qualcuno che non è disposto a fare nulla.

Se non ti senti a tuo agio nel rilasciare il software con il tuo nome, rilascialo sotto un nickname. Se riesce rivendicalo come tuo, altrimenti cambia il tuo nickname :)

Sono fermamente convinto non solo dell'open source, ma dello sviluppo aperto , in cui le persone possono vedere l'evoluzione completa del tuo codice. Dal prototipo dal cervello al codice di lavoro ... non dovresti mai essere imbarazzato. Ti stai mettendo là fuori - questo richiede coraggio. Possederlo ed esserne orgoglioso. Nessuno è perfetto.

Più sono stato in questo gioco, più mi sono reso conto che l'unica misura della qualità del codice è l'esperienza del cliente. Se stai scrivendo una funzione, è il chiamante di quella funzione. Una biblioteca? Gli sviluppatori che scrivono per quella libreria. Un quadro? Gli adottanti. Uno standalone? La persona o il demone che avvia il programma.

Il bel codice ha la sua virtù, non fraintendetemi, ma quando viene detto e fatto l'unica misura è "Funziona?" Ho visto un sacco di codice pulito che è un casino e un sacco di codice satanicamente squilibrato che è completamente affidabile (oltre a un buon pulito e un brutto brutto :))

Quindi, se i critici dicono che il tuo codice è brutto, chi se ne frega. Se dicono che non funziona, questa è la critica utile (test dei dati!) Che cerchi di migliorare il tuo programma. Resisti, evita la popolazione di troll di Internet e divertiti con il tuo progetto!

Sono pienamente d'accordo con quanto affermato da altri poster: anche se il tuo codice è scadente e non di alta qualità, alla maggior parte delle persone semplicemente non importa. Chiunque si sia immerso nel codice OpenSource prima o poi potrebbe aver pensato "WTF è successo qui".

Ma non conosco nessuno là fuori con la motivazione a criticare la base di codice di un progetto solo per il gusto di dire "amico, il tuo codice sembra orribile!". Siamo stati tutti lì e sappiamo tutti che qualsiasi codice che stiamo scrivendo in questo momento sembrerà piuttosto zoppo per noi stessi in poche occhiate (il mio sicuramente lo farà).

Quindi non ti preoccupare così tanto: le persone hanno semplicemente molto meglio da fare nel tempo libero che puntare sul codice dei progetti OpenSource.

Il vero codice è sempre in putrefazione e sporco, schiaffeggiato e mantenuto in modo approssimativamente ad hoc. La pulizia è limitata alla documentazione di casi speciali e costanti speciali. C'è un'incongruenza di impedenza tra il codice pulito e il mondo reale.

Ho anche notato che qualsiasi ingegnere competente può fare a pezzi il codice di qualcun altro.

Se (1) supera i test e ottiene lo scopo senza fallire AND (2) puoi apportare piccole modifiche con solo una piccola riscrittura, è un buon codice.

Alcune sagge parole di Reid Hoffman, co-fondatore di LinkedIn:

"Se non sei imbarazzato dalla tua prima versione del prodotto, hai rilasciato troppo tardi."

"Ottenere il coinvolgimento con i membri e vedere ciò che è realmente importante è completamente fondamentale ... Quindi puoi ottenere il minimo prodotto possibile il prima possibile."

Penso che ciò si applichi in particolare ai progetti open source in cui avere una grande idea con un inizio promettente incoraggia le persone a contribuire e partecipare. Qualcosa di così lucido da farti indossare gli occhiali da sole potrebbe non suscitare simili sentimenti. Ma la cosa più importante del rilascio anticipato è infrangere tutti i tuoi preconcetti su ciò che dovrebbe essere fatto e iniziare a muoverti nella giusta direzione.

Tu chi sei? Sei qualcuno che la gente conosce come programmatore di Dio e teme che la tua reputazione scenderà? Sei tu quello che farà domanda per il lavoro e le preoccupazioni che il datore di lavoro possa leggere queste critiche e pensi di essere un cattivo programmatore? Quello che sto chiedendo è perché hai paura delle critiche su come rovini. Puoi decidere quali sono i commenti autentici e quali sono gli sfoghi. Prendi quelli buoni come difetti e correggili nella prossima versione. Sento solo che ti stai preoccupando inutilmente delle critiche. Stai aiutando la comunità open source, questa è di per sé un'ottima causa. Per favore continuate così.

Se sei veramente preoccupato, usa semplicemente uno pseudonimo online quando rilasci il software. Quindi non vi sarà alcun impatto sulla tua reputazione nella vita reale.

Quando / Se ricevi critiche pubbliche, ciò porterà a miglioramenti nel codice e ti aiuterà a crescere come sviluppatore. Questa è una buona cosa

Trovo che per i miei progetti le critiche / i suggerimenti più costruttivi vengano inviati privatamente anziché trasmessi pubblicamente, e anche in questo caso è improbabile che tu riceva un'inondazione di commenti. Pertanto, consiglio di provarlo!

In bocca al lupo.

Non c'è nulla di sbagliato nello studio di sé in sé e per sé. Non puoi essere isolato e le revisioni del codice dei pari possono aiutarti.

Devi anche concentrarti su ciò che stai facendo. Perché ti importa se ricevi feedback negativi sul tuo lavoro? Se è perché stai assumendo che se ricevi critiche è perché il codice è cattivo o non sei bravo a programmare, questo potrebbe essere o meno vero.

Lo scopo dello sforzo è di assicurarsi che il codice funzioni e di ottenere il miglior codice possibile, ma per esperienza pratica, non tutto il codice commerciale là fuori è stellare. A volte si ottengono cattivi requisiti, a volte non si ha il tempo di farlo nel modo giusto. A volte gli sviluppatori vogliono presentarsi come un genio facendo sembrare gli altri cattivi.

Non credo che tu possa imparare senza fare alcuni errori, specialmente se è qualcosa che richiede vera disciplina e impegno. Se fosse facile, lo farebbero tutti. Cerca di limitare gli errori a quelli minori, usando le migliori pratiche stabilite. Mi rendo conto che non è sempre possibile!

Se mi preoccupassi di ciò che gli altri pensavano di me come programmatore, non sarei andato in campo in primo luogo. Detto questo, la mia prima opinione sulla critica del codice è: provare a prenderlo in modo obiettivo e imparare da esso.