Fornire codice alle persone che ti aiutano a eseguire il debug?

Nonostante i problemi di licenza e copyright, di solito ottieni le migliori risposte per frammenti di codice veramente brevi: 5 linee sono ideali, 50 linee sono fattibili, 500 linee richiedono troppo. Se pubblichi un breve snippet, dimostri di aver fatto uno sforzo per ridurre il problema, che sei disposto a fare i compiti (traduci la breve soluzione proof-of-concept in qualcosa che funziona nel tuo prodotto) e che tu considera il tempo di coloro che ti stanno aiutando come il tuo.

Onestamente, non riesco a pensare a un problema che richiederebbe l'invio di grandi quantità di codice; tali problemi dovrebbero sempre rientrare in una delle seguenti categorie:

• "Per favore, fai il mio lavoro per me, perché sono pigro": il tuo problema può essere risolto o ridotto usando tecniche di debug standard, ma piuttosto che provarlo tu stesso e cercare aiuto con i risultati, preferisci che qualcun altro lavori per te.
• "Non capisco questo codice, è troppo complicato": si potrebbe obiettare che se il codice è così complicato da non poterlo capire, è un codice errato e deve essere riscritto o riscritto. È anche possibile che tu non capisca completamente il problema che stai cercando di risolvere, nel qual caso il tuo tentativo di codifica è condannato sin dall'inizio; e la soluzione è ovvia (anche se non comoda): ri-analizzare il problema, rifattorizzare, ridisegnare, riscrivere, fino a quando la struttura non è chiara. Ora dovresti essere in grado di estrarre un breve frammento che mostri il problema.
• Il disordine di qualcun altro. La maggior parte di noi si trova in una situazione in cui si eredita una pila di spaghetti di 10 anni, con dipendenze incrociate dappertutto, piena di metodi misteriosi senza uno scopo apparente, nomi identificativi fuorvianti, commenti inutili, uso liberale di caratteristiche linguistiche oscure e casi limite, roba inutilmente complicata, ridondante o completamente errata, in breve, il tuo incubo medio. La triste notizia è: sei in questo casino da solo, a nessuno piace occuparsene. Man up e fai domande sulle strategie adatte (in effetti, p.se è pieno di ottime domande e risposte su questo argomento), ma non aspettarti che qualcuno faccia il tuo lavoro per te (vedi ancora un modello?)
• Problemi di progettazione su larga scala. Questi problemi giocano su scala macroscopica, ma se riesci a esprimerli bene, non è necessario inserire alcun codice, o forse solo alcuni stub che illustrano il tuo design.

Ogni volta che ho uno scenario del genere quando devo condividere il mio codice per scopi di debug su Stack Overflow. Faccio molte modifiche. Rimuovo il pacchetto della mia organizzazione dai file Java. Rinominare i nomi delle API. E un sacco di cose. In modo da poter rispettare la politica della mia azienda di non fornire codice online. Ma con le modifiche, sarà sicuro ricevere aiuto dalle persone.

Le persone possono aiutarti rapidamente con gli snippet di codice breve. Condivido sempre il mio senso e approccio che sto usando e chiedo alle persone. E ho sempre indicazioni molto utili.

Ricorda che il codice pubblicato sui siti Stack Exchange diventerà licenza CC-wiki, quindi potresti non voler licenziare il tuo codice quindi pubblicandolo in quel contesto.

Più in generale, vuoi dimostrare abbastanza codice che il problema o il bug che stai cercando di risolvere sia riproducibile. Ma a prescindere dalle considerazioni sulla proprietà intellettuale, dare all'altra parte più codice di quanto sia necessario rende più difficile per loro determinare dove si trova il problema: ricorda che hai problemi a trovare il bug e conosci il tuo codice meglio di loro. Il "progetto di buggy minimale" aiuta il tuo lettore a vedere cosa stai cercando di fare, e in effetti puoi anche ottenere una migliore comprensione del problema identificando gli estratti rilevanti del codice.