Affrontare un difetto di progettazione fondamentale quando sei nuovo nel progetto [chiuso]


13

Ho appena iniziato a lavorare su un progetto open source con circa 30 sviluppatori. Sto lavorando per correggere alcuni dei bug come un modo per entrare nel "loop" e diventare un committer regolare del progetto. Il problema è che penso di aver scoperto un difetto di progettazione fondamentale che sta causando uno dei bug a cui sto lavorando. Ma mi sento come se lo facessi saltare sulla mailing list, diventerò arrogante, e alcune delle discussioni che ho avuto sul problema stanno facendo impazzire alcune persone. Come devo procedere?

Risposte:


20

Anche se sei abbastanza sicuro che si tratti di un "difetto di progettazione fondamentale", ricorda che sei un estraneo. Potrebbe essere lì per una buona ragione. Oppure, a seconda di quanti anni ha il progetto, avrebbe potuto essere messo lì per quella che era una buona ragione all'epoca e ora è ancora in circolazione per ragioni storiche.

Invece di "lanciarlo nella mailing list", prova a porre una domanda. Qualcosa di simile a:

"Ehi, mi sono appena imbattuto in X, e per me non ha alcun senso. Sembra che il modo giusto di implementare questo sarebbe Y, ma poi so di essere nuovo qui e non voglio saltare alle conclusioni. È un errore nel progetto o c'è qualcosa che mi manca? Qualcuno può riempirmi? Grazie. "

L'ingegneria è uno dei pochi posti al mondo in cui l'umiltà è ancora considerata una vera virtù e porre domande su "ovvi problemi" in questo modo è davvero un buon modo per ottenere buone risposte e imparare nuove cose.


2
Questo è decisamente nella giusta direzione. Voglio solo farlo in un modo che non verrà fuori come "So che hai torto e ho ragione" e ne ricavo ancora qualcosa.
Matt Phillips,

@Matt: Quindi pronuncialo come "Non so di avere ragione", e fai del tuo meglio per evitare di farlo sembrare sarcastico o accusatorio.
Mason Wheeler,

Userei qualcosa del tipo "Non capisco perché sia ​​fatto in questo modo. Non sarebbe meglio / più facile / più freddo farlo in un altro modo? Penso che aiuterebbe anche con il bug XX"
Javier

2
Penso che potresti voler giocare un po 'con la formulazione invece di dire direttamente "il modo giusto per implementare questo sarebbe Y". Trasformandolo in una pura domanda "c'è qualche motivo per cui Y non viene usato" ottiene lo stesso punto senza mettere il piede in giù. Chiunque avrà un ego un po 'fragile quando viene interrogato sul proprio codice e facendo appello alla propria esperienza (perché hai scelto X invece di Y) invece di sfidarlo (Y è / sembra / si sente meglio / più freddo / più facile di X) può suscitare una risposta più favorevole.
Steven,

6

Una delle 48 leggi del potere :

Vinci attraverso le tue azioni, mai attraverso l'argomento

Qualsiasi trionfo momentaneo che pensi sia stato ottenuto attraverso l'argomentazione è in realtà una vittoria di Pirro: il risentimento e la cattiva volontà che susciti sono più forti e durano più a lungo di qualsiasi momentaneo cambio di opinione. È molto più potente convincere gli altri a concordare con te attraverso le tue azioni, senza dire una parola. Dimostrare, non esplicitare.

Questo è quello che ho imparato a mie spese dopo molte discussioni inutili.

In questo caso particolare, consiglierei di inventare un codice molto semplice e specifico che dovrebbe funzionare ma che non funzionerà a causa di questo difetto di progettazione. Come dice il vecchio proverbio, "Non puoi discutere con il compilatore / interprete".

L'altra cosa è che per avere influenza su un gruppo, devi essere percepito come un membro del gruppo . Anche se sei entrato a far parte dell'azienda, le persone non ti percepiscono ancora come membro del gruppo. Pertanto, potrebbe essere meglio andare con il gruppo stabilito fino a quando non imparano a percepirti come uno di loro.


5

Potresti chiedere perché è stato utilizzato un particolare design? In questo modo potresti ottenere più informazioni sulla storia precedente in quanto potrebbero esserci alcuni buoni motivi per cui è stato scelto qualcosa che non conosci. Vorrei pensare che non sei un esperto in grado di distinguere il design, ma indagare potrebbe essere un modo per imparare di più in modo che alla fine potresti chiedere su quel difetto che hai trovato in modo che il messaggio non venga visualizzato come esca di fiamma o traina.


4

Probabilmente non ti piacerà questo ... ma, ecco qui ...

Sto lavorando per correggere alcuni dei bug come un modo per entrare nel "loop" e diventare un committer regolare del progetto. Il problema è che penso di aver scoperto un difetto di progettazione fondamentale che sta causando uno dei bug a cui sto lavorando.

No, no non l'hai fatto. Se lo facessi, non ne saresti così esitante. Il fatto che tu stesso non sia sicuro del "difetto di progettazione fondamentale" significa che non ne hai scoperto uno. Quando provi a segnalare l'errore di qualcun altro, non ti compra alcun amico per usare superlativi (come "fondamentale").

Quello che potresti aver scoperto è un design leggermente migliore, per il problema che stai riscontrando. Probabilmente dovresti testarlo a fondo, tuttavia, poiché sei nuovo nel progetto, c'è una possibilità persino migliore di non avere idea di cosa stai parlando.

Ma mi sento come se lo facessi saltare nella mailing list, diventerò arrogante

Definirlo un "difetto di progettazione fondamentale" si rivelerà sicuramente arrogante. Del resto, anche sottolineare che potrebbe essere un bug non è la migliore idea. Se non sai per certo (e puoi supportarlo) che si tratta di un problema, allora devi fare umilmente domande e ricerche fino a quando non lo capisci completamente . Meglio di chiunque tu stia cercando di convincere.

... e alcune delle discussioni che ho avuto in merito al problema sono quelle di alcune persone. Come devo procedere?

Fermare. Questo non è un problema morale e non sta uccidendo nessuno (presumo). Se intendi diventare un membro a lungo termine del progetto, devi prima guadagnare la fiducia prima di metterli in discussione. Risolvi i bug, fai un ottimo lavoro (con qualsiasi metrica valuti i valori del gruppo), progetta alcune funzionalità e guadagna un posto al tavolo.

Quindi, senza puntare le dita o chiamare qualcosa di rotto, invoca umilmente un suggerimento per migliorare il design del gruppo. E è meglio che tu abbia riflettuto su tutte le conseguenze e le soluzioni, o verrai abbattuto per essere "ingenuo". Preparati per una discussione sul perché il tuo design è migliore. Preparati a perdere e perdere con grazia.

Se la tua idea è davvero migliore, o alla fine verrà accettata dal gruppo (anche se forse non dal designer originale), al gruppo non importa o al gruppo è stupido. In uno di questi ultimi casi, perché vorresti far parte del gruppo, comunque?

...

Se sei in grado, l'alternativa è semplicemente codificare la maledetta cosa in modo così sanguinosamente brillante che tremeranno di stupore per la tua abilità di programmazione e non avranno altra scelta che accettare l'elegante semplicità e l'eterna verità del tuo design. Gli sviluppatori fare competenza rispetto, ma bisogna stare attenti - la punizione per incompetenza (o l'arroganza ingiustificata) è piuttosto grave. Dal momento che stai ponendo questa domanda, però, immagino che la brillante e spudorata via dell'arroganza non sia davvero un'opzione. ;)


2
"Ciao, grazie per avermi dato il benvenuto nella tua casa. Mentre varco la porta, voglio far sapere a tutti i membri della famiglia che il loro bambino è brutto e qualcuno lo ha vestito in modo divertente."

Un bug è un bug ed è ok chiamarlo così. Dire che è causato da un "difetto di progettazione" significa puntare un dito sul ragazzo davanti a te (molto simile al "papà") e dirgli che è un idiota.

Non necessario e controproducente. Suggerisco:

"Per quanto riguarda il problema #blah, penso di poterlo risolvere facendo XY e Z ma non sono sicuro di come questo avrà un impatto sul resto del progetto. Andrebbe bene?"

Dove XY e Z risolvono il problema. Lascia che ti diano che è stato un difetto di progettazione; potrebbe esserci una soluzione alternativa. Oppure le ipotesi alla base del "difetto" potrebbero essere così profonde in tutto il progetto che modificarlo risolverà il bug ma romperà tutto il resto!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.