Trattare con un difetto di progettazione fondamentale quando si è nuovi al progetto [chiuso]

Anche se sei abbastanza sicuro che questo è 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 inserito lì per quello che era un buon motivo al momento e ora è ancora in giro per ragioni storiche.

Invece di "fare saltare questo sulla mailing list", prova a fare una domanda. Qualcosa come:

"Hey, I just ran into X, and it doesn't make any sense to me. It seems like the right way to implement this would be Y, but then again I know I'm new here and I don't want to jump to any conclusions. Is this a mistake in the design, or is there something I'm missing? Can someone fill me in? Thanks."

L'ingegneria è uno dei pochi luoghi al mondo in cui l'umiltà è ancora considerata un'autentica virtù e fare domande su "problemi ovvi" in questo modo è un ottimo modo per ottenere buone risposte e imparare nuove cose.

Una delle 48 leggi del potere :

Win through your Actions, Never through Argument

Any momentary triumph you think gained through argument is really a Pyrrhic victory: The resentment and ill will you stir up is stronger and lasts longer than any momentary change of opinion. It is much more powerful to get others to agree with you through your actions, without saying a word. Demonstrate, do not explicate.

Questo è quello che ho imparato a mie spese dopo molti argomenti inutili.

In questo caso specifico, consiglierei di creare una parte di codice molto semplice e specifica che dovrebbe funzionare, ma non 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 membro del gruppo . Anche se ti sei unito alla compagnia, le persone non ti percepiscono ancora come un membro del gruppo. Quindi, potrebbe essere meglio andare insieme al gruppo stabilito fino a quando non impareranno a percepirti come uno di loro.

Potresti chiederti perché è stato utilizzato un particolare design? In questo modo si può ottenere più del retroscena in quanto potrebbero esserci dei buoni motivi per cui è stato scelto qualcosa che non si conosce. Vorrei andare con l'idea che non sei proprio l'esperto che può scegliere il design, ma indagare potrebbe essere un modo per imparare di più così che alla fine potresti chiedere di quel difetto che hai trovato in modo che il messaggio non venga visto come esca o trolling.

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

I'm working on fixing some of the bugs as a way to get into the "loop" and become a regular committer to the project. The problem is I think I've uncovered a fundamental design flaw that's causing one of the bugs I'm working on.

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

Ciò che potresti aver scoperto è un design leggermente migliore, per il problema che stai riscontrando. Probabilmente dovresti testarlo a fondo, però - dal momento che sei nuovo nel progetto, c'è una possibilità persino migliore che tu non abbia idea di cosa stai parlando.

But I feel like if I blast this on the mailing list I'm going to come off as arrogant

Definirlo un "difetto fondamentale del design" sarà sicuramente arrogante. Del resto, anche segnalare che potrebbe essere un bug non è la migliore idea. Se non sai per certo (e puoi eseguirne il backup) che si tratta di un problema, devi fare domande e ricerche umilmente finché non lo capisci completamente . Meglio di chiunque tu stia cercando di convincere.

...and some of the discussions I've had about the issue are butting heads with some of the people. How should I go about this?

Stop. Questo non è un problema morale, e non sta uccidendo nessuno (presumo). Se intendi essere un membro a lungo termine del progetto, devi prima guadagnare la fiducia prima di interrogarli. Risolvi i bug, esegui un ottimo lavoro (con qualsiasi metrica il gruppo valori), disegna alcune caratteristiche e guadagna un posto al tavolo.

Quindi, senza puntare le dita o chiamare qualcosa di rotto, fai apparire umilmente un suggerimento per migliorare il design del gruppo. E faresti meglio a pensare a tutte le conseguenze e alle soluzioni, o verrai abbattuto per essere "ingenuo". Sii pronto per una discussione sul perché il tuo design è migliore. Preparati a perdere e perdere con grazia.

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

...

Se sei capace, l'alternativa è semplicemente codificare quella maledetta cosa in modo così sanguinante che tremano per lo stupore per la tua prodezza di codifica e non hanno altra scelta che accettare l'elegante semplicità e la verità eterna del tuo progetto. Gli sviluppatori fanno rispettano le competenze, ma bisogna stare attenti - la punizione per incompetenza (o arroganza ingiustificata) è piuttosto severa. Dal momento che stai facendo questa domanda, però, suppongo che la brillante e impudica strada dell'arroganza non sia davvero un'opzione. ;)

"Hi thanks for welcoming me into your home. As I walk through the door, I want to let everyone in the family know that their baby is ugly and somebody dressed him funny."

Un bug è un bug, ed è giusto chiamarlo così. Dire che è causato da un "difetto di progettazione" è puntare il dito contro il ragazzo davanti a te (quasi come il "papà") e dirgli che è un idiota.

Inutile e controproducente. Suggerisco:

"In regards to issue #blah, I think I can fix it by doing X Y and Z but I'm not sure how that will impact the rest of the project. Would this be ok?"

Dove X Y e Z correggono il problema. Lascia che ti dica che era un difetto di progettazione; potrebbe esserci una soluzione alternativa. Oppure le supposizioni dietro il 'difetto' possono essere così profonde in tutto il progetto che cambiandolo risolverà il bug ma spezzerà il resto!