Rilascio di un progetto open source senza imbarazzo [chiuso]

A meno che il progetto non sia rivolto agli sviluppatori (ad esempio: un framework di sviluppo, nel qual caso vuoi che vengano criticati se ti fanno imparare ancora di più), non dovresti preoccuparti. Ma anche allora, ci sono molti progetti open source rivolti agli sviluppatori che fanno schifo, eppure la gente li adora perché vanno al punto (pensa a Codeigniter, che è molto poco architettato, eppure è 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 risponde a questa domanda? Anche il loro codice ha problemi.

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

Essere uno sviluppatore è COSTANTEMENTE schiacciare te stesso contro i limiti delle tue abilità e comprensione. Potrebbe non essere così per TUTTI gli sviluppatori, ma per me e per quelli che conosco, lavoriamo praticamente ai margini della nostra competenza in ogni momento. E lo affronti ancora e ancora, poi passa un bel fine settimana, poi torna lunedì e fallo più e più volte.

Avendo lavorato per quella vita per 15 anni, la cosa su cui mi sono basato è questo fatto: Non sei il tuo codice . SCRIVI il codice. Il giudizio del codice NON è il giudizio di tu . Il tuo codice ha problemi, alcuni conosci, altri no. Avendo attirato l'attenzione sulla tua attenzione ti aiuta , a meno che tutto ciò che puoi fare non sia male. Sentirsi male non migliora il tuo codice, ti fa solo stare male.

Scrivi il tuo codice e lo scrivi così come sai come. Forse domani ne saprai più di quello che hai fatto oggi, ma oggi lo hai fatto come sapevi. Il mio consiglio è: scrivi il codice di oggi e domani il codice di domani. Poi passa un bel fine settimana e torna lunedì per 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 considerando 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 a loro non piace il codice, in genere non useranno il codice e non ne sentirai mai.
2. Studenti, cercando di imparare come codificare nella lingua che hai usato. Questi non ti contatteranno quasi mai, ma potresti occasionalmente ricevere una e-mail chiedendo perché hai fatto qualcosa in un modo o in un altro. (Per essere onesti, in realtà non ho avuto uno di questi messaggi di posta elettronica in molti anni. Penso che siti web come StackExchange potrebbero aver sostituito questa interazione)
3. Ricercatori di sicurezza, come i ragazzi di OpenBSD, che cercano di decidere se il tuo strumento è abbastanza sicuro da essere incluso nella loro distribuzione. Se non lo è, ma vogliono comunque includere il tuo programma, saranno contattati per capire come proteggerlo. (E se il tuo programma diventa popolare, immagino che probabilmente attirerà anche i ricercatori black hat, che non ti contatteranno a prescindere da quello che troveranno.)

Nel mondo reale, le persone non leggeranno il tuo codice sorgente per nessun altro motivo oltre a questo, 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 un 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à navigato attraverso il codebase e non hanno eseguito urlando per le colline. ;)

Davvero non capisco la psicologia dietro a 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 è orribile e qualcuno si prende il tempo di scrivere una lettera di fuoco per te, indovina, probabilmente ha usato il tuo software abbastanza per voler apportare alcune modifiche e renderlo migliore.

Dovresti essere felice di questo! Accetta le critiche e migliora il tuo codice, chiedi al ragazzo arrabbiato che ha avuto il tempo di scriverti. A lui interessa!

Dopo un po 'le lettere di fuoco si fermeranno, le persone continueranno a usare il tuo software, avrai imparato dai tuoi errori e le lacune che non sapevi esistessero nella tua educazione non ci saranno più.

Preferisco 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 davvero a tuo agio nel rilasciare il software sotto il tuo nome, rilascialo sotto un soprannome. Se riesce a rivendicarlo come tuo, se non cambia il tuo nickname:)

Sono un convinto sostenitore non solo nell'open source, ma nello open development , dove le persone possono vedere l'evoluzione completa del tuo codice. Dal prototipo di capelli corti al codice di lavoro ... non dovresti mai essere imbarazzato. Ti stai mettendo là fuori - che ti prende coraggio. Possedilo ed esserne fiero. 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 di esso. Un standalone? La persona o il demone che avvia il programma.

Un buon 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 caos buggy, e un sacco di codice satanically squilibrato che è completamente affidabile (oltre a una buona pulizia e brutto brutto :))

Quindi, se i critici dicono che il tuo codice è brutto, a chi importa. Se dicono che non funziona, questa è la critica utile (test dei dati!) Che cerchi di migliorare il tuo programma. Aspetta lì, evita la popolazione di troll di internet e divertiti nel tuo progetto!

Sono assolutamente d'accordo con quello che hanno detto gli altri utenti: anche se il tuo codice è scadente e non di alta qualità, la maggior parte delle persone semplicemente non gli interessa. Tutti coloro che si sono tuffati nel codice OpenSource in un momento o nell'altro potrebbero aver pensato a se stessi "WTF è successo qui".

Ma non conosco nessuno là fuori con la motivazione di 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 noioso in solo pochi feek (il mio sicuramente lo farà).

Quindi non ti preoccupare più di tanto - le persone semplicemente hanno molto meglio da fare nel loro tempo libero rispetto al pignolo sul codice dei progetti OpenSource.

Il codice reale è sempre in decomposizione e sporco, schiaffeggiato e mantenuto in modo approssimativo ad hoc. La pulizia è limitata alla documentazione di casi speciali e costanti speciali. C'è un disadattamento di impedenza tra codice pulito e 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 una riscrittura minore, è un buon codice.

Alcune parole sagge di Reid Hoffman, co-fondatore di 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.”

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

Chi sei? Sei una persona che le persone conoscono come programmatore di Dio e si preoccupa che la tua reputazione scenda? Sei tu quello che farà domanda per il posto di lavoro e si preoccupa che il datore di lavoro possa leggere queste critiche, e pensi di essere un cattivo programmatore? Quello che ti sto chiedendo è perché hai paura delle critiche su come fai a sbagliare. Si arriva a decidere quali sono commenti genuini e quali sono sproloqui. Prendi quelli buoni come difetti e risolvili nella prossima versione. Sto solo sentendo che ti stai preoccupando inutilmente delle critiche. Stai aiutando la comunità open source, che è di per sé una buona causa. Per favore continuate così.

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

Quando / Se ricevi critiche pubbliche, questo 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 piuttosto che trasmessi pubblicamente, e anche in questo caso è improbabile che ricevano un'inondazione di commenti. Pertanto, ti consiglio di provarlo!

Buona fortuna.

Non c'è niente di sbagliato nello studio autonomo in sé e per sé. Non puoi essere isolato e le recensioni dei peer code possono aiutarti.

Devi anche concentrarti su quello che stai facendo. Perché ti importa se ottieni un feedback negativo sul tuo lavoro? Se è perché stai facendo l'ipotesi che se ottieni critiche è perché il codice è cattivo o non sei bravo a programmare, potrebbe essere vero o no.

Lo scopo dello sforzo è quello di assicurarsi che il codice funzioni e di ottenere il miglior codice possibile, ma dall'esperienza pratica, non tutto il codice commerciale è stellare. A volte hai cattive esigenze, a volte non hai il tempo di farlo bene. A volte gli sviluppatori vogliono incontrarsi come un genio facendo sembrare gli altri cattivi.

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

Se mi preoccupassi di quello che gli altri pensavano di me come programmatore, non sarei entrato in campo in primo luogo. Detto questo, il mio primo approccio alla critica del codice è cercare di prenderlo in modo obiettivo e imparare da esso.