Hva er det?

XY problemet er spør om din forsøkte løsning i stedet for faktiske problemet.

Det vil si at du prøver å løse problemet X , og du tror at løsningen Y ville fungere, men i stedet for å spørre om X når du får problemer, spør du om Y.

Problemet

Dette kan føre til frustrasjon fra folk som prøver å hjelpe deg med å løse problemet, fordi løsningen du trenger hjelp med kanskje ikke har noen åpenbare sammenhenger når du spør om det. til problemet du prøver å løse.

Hvordan unngå det

For å unngå å falle i denne fellen, inkluder alltid informasjon om et bredere bilde sammen med enhver forsøkt løsning. Hvis noen ber om mer informasjon, eller spesielt et mer spesifikt spørsmål, må du oppgi detaljer. Hvis det er andre løsninger som du tror vil bli foreslått og som du allerede har utelukket, så prøv ikke å unngå å gå over dem igjen – i stedet oppgi hvorfor du har utelukket dem, da dette gir mer informasjon om dine krav og hjelper andre med å gi bedre svar.

Et eksempel

En nylig IRC-samtale for illustrasjon:

Q: Er det en funksjon for å returnere en streng mellom to avgrensere?

B: Jeg forstår ikke hva du mener, men jeg tviler på at det allerede er en funksjon

C: Del og del opp

D: Partisjon også

Q: Jeg prøvde partisjon
Q: Jeg prøvde å bruke innebygde moduler for å få nummeret mellom noe slikt i en streng » attributt1: 50.223, attributt2: 442.1 »

D: Hvorfor ikke bare analysere strengen?

Q: Jeg trodde det kan ha vært noen innebygde parsing ting

D: par = [x.strip () for x i s.split («, «)]; attribs = {k: v for x i par for k, v i [x.split («: «)]}
D: Det er noen få biblioteker, men enkle formater er enkle nok – hvis du ikke bryr deg om feil håndtering
D: Endring av kilden til å bruke et velkjent format, f.eks. json eller yaml, foretrekkes når det er mulig

Q: Denne koden kommer faktisk fra HTML
Spørsmål: Men jeg vet ikke hvordan jeg skal analysere Javascript med HTMLParser eller hva det enn heter

D: Er det bare innebygd i HTML, eller en manglende versjon av HTML?

Q: Det er innebygd i HTML-en

D: Hvis det er JavaScript (og det vil si bortsett fra manglende ytre seler), kan JSON sannsynligvis analysere det

Q: Takk

D: Jeg sa det ikke eksplisitt: JSON analyserer bare datastrukturer, ikke JS-kode

Q: Det «alt jeg trenger å analysere er en datastruktur

Problemet handler egentlig om hvordan man analyserer JavaScript-datastrukturer, ikke finner » en streng mellom to avgrensere «, men det tar ganske mye tid og intuisjon å komme til det virkelige problemet.

Dette er lettere å gjøre i en fullt interaktiv chat (uansett hvilken modus), men på et SE-nettsted , der du polerer et innlegg litt, legger ut det og deretter har 5-30 minutter eller lenger før tilbakemelding, hjelper det virkelig å gå i riktig retning fra starten.

Kommentarer

• IMO XY-problemer er noen ganger nyttige fordi svarene kan hjelpe spørgeren til å forstå hvorfor løsningen deres ikke ville ‘ t fungere, og bedre forstå originalen problemet i prosessen.
• Den enkleste måten å komme til det virkelige problemet er å spørre hvorfor fem ganger.
• Selv om du begynner med Y i stedet for X, kan det hende du har å spørre hvorfor 10 ganger (eller mer, bruk de 5 hvorfor på alle nivåer?). 🙂
• Hvorfor Y – at ‘ er spørsmålet å stille
• For å være rettferdig, stiller spørsmålstegnere mange ganger spørsmål om X, og svaret er » at ‘ er for mye, bryt det ned til et lite eksempel » og så isolerer plakaten deres forsøkte løsning Y, og alle mister det opprinnelige problemet av syne.
• Sometmes sitter du fast med Y. I min første jobb måtte jeg endre en nettbutikk. Kodebasen var en råtten blanding av html PHP og js. Det var to måter å løse problemer på: Gjør om hele greia (avvist av sjefen) legg til mer tape. SÅ hjalp meg ikke egentlig der. » Hvordan y? » » Hvorfor ville du gjøre det? » » Fordi jeg må » » Y / Ikke gjør dette / hvorfor bruker du {antipattern}? » » Fordi jeg må »
• @OliverA. Så blir en del av spørsmålet en forklaring på hvorfor du trenger å gjøre Y. » Jeg trenger å gjøre Y fordi arv / boss / gammelt rammeverk » så blir spørsmålet lettere å svare, og mer verdifullt for alle.
• @LegoStormtroopr Med unntak av at mange mennesker ikke ‘ t forstår det. De forstår ‘ t at du noen ganger ikke ‘ ikke har den luksusen å velge riktig tilnærming og bare har for å plaster eksisterende kode, og spørsmålet er lukket som for smalt eller noe …
• Jeg gjorde solide forsøk på å koke alle spørsmålene mine ned til så mye av et » Y » som mulig. Jeg har ingen interesse i å stave ut hele omfanget av problemet mitt (spesielt når jeg jobber med proprietær programvare med lukket kilde på jobben min), og jeg har lyst til (unntatt å håndtere de som insisterer på å krysse kjeden med » hvorfor? hvorfor? hvorfor? «) Jeg kan få svar raskere ved å kapsle inn spørsmålene mine fra alle sammenhenger.
• Det kommer an på på askeren ‘ s samlede kunnskap om problemområdet.Jeg er enig med n00n, for de som er mer erfarne med alternativene, har de kanskje allerede utelukket alle mulige X ‘ s, og nå er X en konstant, og de vil bare løse for Y. Det forringer spørsmålet å måtte gå over alle mulige X ‘ s som du ‘ allerede har utelukket, og fordype deg i kontorpolitikk eller eksisterende systemarkitektur. Noen mindre erfarne kan ha nytte av å ha andre ‘ s gjennomgang av alternativ X ‘ og foreslå at de vurderer denne forutsetningen på nytt.
• Moteksemplet: Meg: Er det noen måte å endre gjeldende katalog i Java? Annet: I java trenger du ikke ‘ ikke å gjøre det. Hva vil du gjøre? Meg: (sukk) OK, jeg har en kjørbar krukke for et program som lytter til en port og utveksler meldinger. Krukken sitter normalt i x / bin og konfigurasjonen sitter i x / conf. Så, programmet leser konfigurasjonen fra ../conf. Nå vil jeg kjøre det i en tomcat-server ved å kalle programmet ‘ s hovedmetode selv. Men jeg har ingen kontroll på serveren ‘ s hjemmekatalog og » ../conf» er ikke et akseptabelt sted.
• (forts.) Så jeg lurer på om det er noen måte å endre hjemmekatalogen for en tråd. Annet: Å, skjønner jeg. Vel, du kan ‘ ikke gjøre det i Java. Meg: Hvorfor kunne du ikke ‘ ikke fortelle meg det tidligere? – I så fall stilte jeg spørsmål X og jeg ble besvart på spørsmål Y (hvordan du bruker filer i Java).
• Vanligvis vil jeg ikke at folk skal løse problemet mitt, bare svar på spørsmålet mitt. Det kan være ganske irriterende når folk prøver å hjelpe med førstnevnte i stedet for sistnevnte.
• @NoctisSkytower Men det meste av tiden er hvert svar kontekstavhengig … Spørsmål: » Hvordan kan jeg gjøre X i C? » A: » Det er 20 forskjellige måter, hver med sine egne fallgruver og bruk, du kan studere dem selv og gjøre alle feil andre har gjort, eller du kan fortelle oss hvilket problem du vil løse med dette, og vi kan gi deg den beste tilnærmingen ! » Q: » Jeg vil ikke ‘ jeg vil ikke et foredrag bare gi meg noe svar, jeg bryr meg ikke ‘! » – A: » -.- bye. »
• Ikke-programmerende SE-nettsteder lenker til dette svaret for å forklare XY Problem-konseptet. Et mer universelt (ikke-programmerings) eksempel vil være enda mer nyttig.

XY-problemet, som det noen ganger kalles, er en mental blokk som fører til enorme mengder bortkastet tid og energi, både fra folk som ber om hjelp og fra de som gir hjelp. Det går ofte noe sånt som dette

• Brukeren vil gjøre X.
• Brukeren vet ikke hvordan de skal gjøre X, men tror de kan fumle seg frem til en løsning hvis de klarer bare å gjøre Y.
• Brukeren vet ikke hvordan man gjør Y heller.
• Bruker ber om hjelp med Y.
• Andre prøver å hjelpe brukeren med Y, men er forvirret fordi Y virker som et merkelig problem å ville løse.
• Etter mye samhandling og bortkastet tid blir det endelig klart at brukeren virkelig ønsker hjelp med X, og at Y var ikke engang en passende løsning for X.

Problemet oppstår når folk får tankegangen sitt fast på en tilnærming og blir ute av stand til å ta et skritt tilbake. Forblir åpen for å ha en ny se på det større bildet, disse menneskene kan finne tilbake til X og fortsette å søke etter alternative løsninger.

Se « XyProblem » for mer informasjon.

Kommentarer

• Jeg synes også dette svaret er nødvendig tillegg til forklaringen. Jeg leste over, prøvde å tenke på det nåværende problemet mitt (om det er et X- eller Y-spørsmål), og når jeg leste videre til denne kommentaren, fikk jeg » aha » forståelsesøyeblikk at hvis jeg hadde postet spørsmålet mitt, ville jeg ha forhørt meg om Y og ikke X. Gjentakelsen av min situasjon kan være en mental blokk som er fokusert på hvordan jeg løser problem i stedet for å tydelig angi problemet jeg vil løse er veldig nyttig.
• Jeg tror det er brukernes ‘ ansvar. Jeg ‘ har møtt mange ganger problemet, at jeg ønsket å løse problemet X, og alle foreslo Y og Z. Men hvis jeg hadde ønsket en løsning for Y eller Z, er dette det jeg hadde spurt. Jeg synes dette er litt pinlig, ikke bare fordi svarene jeg får ikke hører til spørsmålet mitt, men også fordi jeg føler meg undervurdert.Siden jeg savner bevisst alle detaljer som kan villede svarerne mine på denne dårlige måten.
• Dette spesielle svaret minner meg om Maslow ‘ s Hammer
• Jeg er uenig i svaret. Hvis du har problem X og angir Y som din løsning og ber om hjelp til Y, er det du ‘ gjør å etablere din (sannsynligvis feil) forståelse av problemet. Når jeg vil hjelpe noen, vil jeg ikke bare vite X-spørsmålet deres, men hvordan det er at de for øyeblikket tenker (Y). Noen ganger er det ‘ viktigere å lære hvordan å tenke enn å lære hva å tenke. Og XY-problemet gir meg viktige ledetråder til hvordan jeg skal nærme meg å gjøre nettopp det.
• Faktisk er å advare XY-problemer spesielt ikke vennlig. Og (å velge, åh, en): stackoverflow har vært fryktelig i denne forbindelse de siste årene. Jeg ‘ holder fast at de andre programmeringssentrerte SE-nettstedene ikke ‘ t så uopprettelig skru opp som de gjorde. > @ tgm1024 Jeg forstår ikke ‘ t helt kommentarene dine; XY-problemet er ikke når en bruker inkluderer tankeprosessen ved å gi både X og Y i spørsmålet, det ‘ s når brukeren ikke ‘ t inkluderer tankeprosessen og gir bare Y fordi spesielt i så fall er det ‘ vanskelig å lære dem å tenke .
• @JiK, Du identifiserer det enten som et XY-problem, eller du gjør ikke ‘ t. Hvis du gjør det, er du ‘ klar over X. Hvis du ikke ‘ t, så ‘ bør ikke anta hva X er, fordi den presenterte Y kan være et gyldig dannet spørsmål .
• Brukeren ‘ vet ikke hvordan man gjør X, men tror de kan fumle seg frem til en løsning hvis de bare klarer å gjøre Y. Høres ut som hvordan alle problemer blir løst for meg: P. Alt i det ytterste bør alle starte spørsmålet med » Jeg vil forbedre livet mitt / verden på en eller annen måte. Jeg ble født i 19 … »
• Noen ganger er det ‘ ganske riktig. For mange år siden, etter at Oracle DBA vendte seg mot meg (hans sysadmin) og sa trøtt » På en eller annen måte, noe, har noe gått galt » Jeg laget meg en t-skjorte med den på. Det er på mange måter en perfekt feilrapport fordi den ikke ‘ t kommer med noen antagelser som jeg da må avkrefte: det starter med hans problem og lar meg gå gjennom hans observasjoner og hans forventninger for å se hvor misforholdet med virkeligheten kan være.
• @ tgm1024 Det ‘ handler om å unngå å kaste bort mye tid for både spørgeren og svarerne. Hvis du er klar over forbeholdene om en mulig gyldig Y, bør du ta med informasjonen i spørsmålet ditt. Ytterligere be om X vil unngås. Hvis du ikke ‘ ikke vet at advarslene som ber om X, sannsynligvis er akkurat det du trenger fordi en løsning for Y ikke vil hjelpe deg veldig mye. Det ville være uvennlig å ikke peke dem mot riktig løsning og i stedet la dem ha en dårlig løsning.
• @trixn, jeg ‘ Jeg er ikke sikker på hvor vi være uenig. Imidlertid — > Hvis du har problem X og oppgir Y som din løsning og ber om hjelp til Y, hva du ‘ å gjøre er å etablere din (sannsynligvis feil) forståelse av problemet. Når jeg vil hjelpe noen, vil jeg ikke bare vite X-spørsmålet deres, , men hvordan det er at de tenker for øyeblikket (Y). Noen ganger er det ‘ viktigere å lære hvordan man tenker enn å lære hva man skal tenke. Og deres passende og verdifulle XY-problem gir meg viktige ledetråder til hvordan jeg skal nærme meg å gjøre nettopp det.
• @ tgm1024 Det er bokstavelig talt det du allerede har sagt før. Poenget mitt handlet om din uttalelse om at formaning av XY-problemer er spesielt uvennlig. Selvfølgelig er det ‘ også et spørsmål om hvordan du uttrykker din mistanke om at et spørsmål kan være et XY-problem. Men generelt sett er jeg ikke ‘ ikke enig i at å peke på det er ikke uvennlig, da det faktisk kan være det han / hun faktisk trenger. Derfor ‘ hvorfor jeg vanligvis ber om mer informasjon om brukssaken. Hvis Y er et lett å svare på spørsmål, svarer jeg vanligvis på det uansett med en merknad om at det kanskje ikke er ønsket løsning uansett.
• @trixn, selvfølgelig kan du peke noen i riktig retning, og selvfølgelig du kan veilede noen mot en ny måte å se på noe på.Å begynne med forestillingen om at spørsmålsdannelsen seg selv på en eller annen måte er feil, er det jeg ‘ er på sterk odds med. Se for eksempel på det hyperbolske sitatet i det 71 oppstemte svaret av Jonathan Benn: » Spesifikt for Q & A, pernisiasiteten til en XY-problemet kommer av det faktum at det er frustrerende for alle involverte. » Det er rett og slett tull. XY-spørsmålet er verdifullt. Det ‘ er bare frustrerende for folk som ønsker det.
• Flott forklaring. RE: » og at Y ikke var ‘ t enda en passende løsning for X «, Jeg tror at Y noen ganger kan være en løsning for X. Men det er ikke en naturlig eller praktisk løsning.
• Imo dette er den som skal være på toppen. Ingen krenkelse på det øverste svaret, men jeg først leste det og det fikk meg til å klø meg i hodet og så kom jeg ned for å se dette og svaret ble krystallklart for meg.

Et XY-problem ser ut til å være en delmengde av Einstellung-effekten , der en problemløser sitter fast på en bestemt løsning og ikke klarer å gå tilbake mentalt for å se potensielt overlegne løsninger. Dette psykologiske fenomenet påvirker alle, både nybegynnere og eksperter.

« Hvorfor din første idé kan blinde deg til en bedre » forklarer et eksempel fra sjakk hvor en person vinner med en 5-trekk kvalt kompis i ett parti. Det neste spillet, den samme spilleren klarer ikke å se en raskere tre-trekk-kompis fordi de sitter fast på ideen om en 5-trekk-kompis.

Spesifikt for Q & A, skadeligheten ved et XY-problem kommer av at det er frustrerende for alle involverte:

1. Personen som stiller spørsmålet, stiller feil spørsmål (som er relatert til deres forsøkte løsning i stedet for det opprinnelige problemet), og finner det da vanskelig å avklare spørsmålet fordi de sitter fast på sin egen løsning. De foreslåtte svarene er utilfredsstillende fordi de ikke adresserer hvordan man implementerer forfatterens løsning.
2. Folk som svarer på spørsmålet, synes det er frustrerende fordi den foreslåtte løsningen ikke gir mening for dem siden de nærmer seg problem fra en ny vinkel og påvirkes (antagelig ikke) av Einstellung-effekten, og de synes det er vanskelig å få originalplakaten til å avklare spørsmålet.

Kommentarer

• Interessant hvordan Einstellung effect beskrivelsen er basert på en åpenbar feil. Luchin eksperimenterte med hvordan folk ville trekke problemet fra hans ufullstendige og tvetydige beskrivelse (var han ber om optimalisering for latens eller optimalisering for gjennomstrømning?). Men han gjorde seg villfarende for at han angivelig fortsatt eksperimenterte med » hvordan folk kommer til løsninger «. Det er kanskje en referanse ting. Luchin var så fokusert på sin interesse, at han ikke klarte å legge merke til da han viderekoblet seg til et helt annet problem.
• Min kilde var Scientific American, hvis du protesterer kan du ta det opp med dem;)
• Jeg synes det er bedre eksempel fra sjakk vil være omtrent som en spiller som er fokusert på å prøve å oppnå en komplisert sjakkematte med utilstrekkelig materiale, mens man ser bort fra det faktum at de har en bonde som kan dronning.

Manglende firkantet puslespill er en god illustrasjon. Det illustrerer en enkel og universell problem / spørsmål / løsningsprosess, der «litt illusjon» forårsaker komplikasjoner.

Det er et selvinnlysende problem — 1 × 1 hull i det som oppstår på den andre figuren —, men løsningen er tydelig først etter at vi vet (som et egg fra Columbus) … Alle mennesker, eksperter og ikke-eksperter, er enig i at det er et problem.

• normal bruker : mener at «det er to ekvivalente figurer, de» totale trekanter «i et perfekt 13 × 5 rutenett .. . «, følgende med spørsmålet:

  • problem Y : «Hvorfor har den andre ekvivalente trekanten et hull i den?» .

• ekspertbruker : tenk noe som «oops , de er like , men ikke «helt likeverdige» figurer «, som følger med spørsmålet:

  • problem X : «Hvordan viser jeg at de ikke er perfekte ekvivalenter?» .

Den smarte geometrieksperten tenker i form av «lignende geometrier som ikke er perfekte ekvivalenter».

Den vanlige brukeren mener feilaktig når det gjelder nøyaktig kongruens . Så, bruken av feil hypotese , produser syke Y spørsmål.

» XY-problemet «som en spesialisering av» feil hypoteseadferd «

Du vil løse det virkelige spørsmålet- X, og du tenker i form av en Y -kontekst, og prøv å bruke spørsmål- Y. I stedet for å spørre om kontekst X, spør du om kontekst Y.
(som @Gnome la merke til ovenfor , men bruker andre ord)

Så, «XY Problem» er bare et annet (mer spesialisert) begrep for å si «Bruk av feil arbeidshypotese » .

Kommentarer

• Gjennomgå nedstemningen din, jeg redigerte for å skille personlig mening fra denne mer generiske og kanskje interessante formen å forklare » hva er «.
• Jeg får mening fra svaret ditt og du ‘ er den som svarer på spørsmålet med animert illustrasjon. Hvis mitt rykte (i dette metafellesskapet) tillater meg å stemme opp, vil jeg stemme opp dette.
• Dette svaret illustrerer en typisk use case , når » tenkende imperativ programmerer » stiller et spørsmål om funksjonelt språk … Den foreslåtte løsningen : spør på toppnivå.
• beklager, hvorfor den andre ekvivalente trekanten har et hull i den?
• Hei @KorayTugay, spørsmålet ditt er utenfor omfanget (det er et klassisk problem, slik at du kan bruke klassiske forklaringer, se Wikipedia-lenken min!). PS: Jeg liker å se hullet som forskjellen , fordi trekantene er like og har nesten samme område, men ikke akkurat det samme området, slik at du kan konstruere hullet fra den lille stripen til den geometriske forskjellen.
• @koraytugay se på punktet der de røde og blå trekanter berører når animasjonen tilbakestilles .. det blir klart at den blå trekanten er » brattere » enn den røde, så når den blå trekanten er i bunnen er hypotenusen » konveks » og når det er øverst » konkav «. Denne » bøying » av hypotenusen gir opphav til en firkant ‘ s forskjell i området

Unngå XY-problemet

Jeg hevder at du ikke kan unngå det. Ikke uten å bare kaste programkravene dine på SO og be dem om å gjøre designet ditt for deg ( anbefales ikke) .

Jeg hevder dette fordi designprosessen for all programvare er basert på et startsett med krav «A». Derfra sier du «Jeg kan oppnå A hvis jeg gjør B og C «. Derfra sier du» Jeg kan oppnå B hvis jeg gjør D og E og jeg kan oppnå C hvis jeg gjør F og G «. Og det fortsetter til det punktet vi sier at» Jeg kan oppnå X hvis jeg gjør Y «. Vi gjør dette vanligvis så fort at vi ikke en gang tenker på prosessen.

Så det største problemet med XY-problemet er at Y ikke er mulig, men du vet ikke hvor mye av din design for å slappe av for å g et tilbake til X som er mulig. Du vet vanligvis ikke engang at Y er umulig uten å spørre. Du vet ikke hva du ikke vet. Derfor er det uunngåelig

Still spørsmål der du risikerer å falle inn i XY

Det beste du kan gjøre med XY-problemet er å beskytte mot det når du stiller spørsmål. Still fortsatt det samme spørsmålet, men gi så mye relevant informasjon som mulig:

• Oppgi problemet ditt
• Oppgi hva du prøver å oppnå
• Oppgi hvordan det passer inn i ditt bredere design

Dette vil hjelpe folk å identifisere at det er XY og hjelpe deg mye raskere.

VIKTIG: Gi svar på XY-problemer

Etter min mening er det største problemet med XY-spørsmål er (ofte) uhjelpelige svarene de provoserer på. Vi vil aldri stoppe folk å stille disse spørsmålene, så det beste er å forstå hvordan vi kan svare på dem raskt og effektivt.

Ironisk nok blir mange av disse dårlige svarene og svarene gitt av de som vil være mest nyttige og kan gis av noen av de mest anerkjente menneskene på forumet / SO.

Jeg har oppdaget en metode for å svare på disse spørsmålene som ser ut til å bidra til å komme rundt psykologien assosiert med XY-problemer og lede OP for et spørsmål til en fungerende løsning. Metoden tar litt lengre tid å svare på første gang, men lukker Q / A-løkken mye raskere.

Jeg foreslår at du svarer på spørsmålet i tre deler og gir dem i følgende rekkefølge.

1. Svar på OPs spørsmål . Selv om OP sannsynligvis trenger noe annet, må du aldri forsømme å svare på spørsmålet de faktisk har stilt først og ikke på spørsmålet du tror de vil ha svar på. I noen tilfeller kan svaret være «Y er ikke mulig» . For ofte ser jeg svar (kommentarer) som spør «hvorfor trenger du det?» . Dette gir OP ingenting. Hvis du sier «Det blir veldig vanskelig. Forklar hvorfor du trenger det, vi kan kanskje hjelpe « så vil en OP i mange tilfeller ganske enkelt ta » Y er veldig vanskelig « og gå tilbake til tegnebrettet .. . Det er greit fordi du har svart på spørsmålet deres, og de kan godt komme tilbake med spørsmål X selv.

2. Diskuter OPs forsøkte løsning . Denne biten er vanskelig og tar litt tanke. Men jeg kan ikke understreke hvor viktig den er. Hvis OP har bedt om Y og du tror de vil ha X, fortsetter du med å snakke om Y (IKKE X) etter å ha svart på spørsmålet deres (1). Hva skal Y brukes til? Hvordan er det ikke aktuelt for X? Det avgjørende er å fortsette å snakke om spørsmålet, men gå fra å svare på det til å gi nyttig informasjon. For når alt kommer til alt det du mener OP trenger. Nyttig informasjon og ikke svaret på deres spørsmål.

3. Løs X Dette har du kløet å gjøre, og er tross alt poenget med svaret ditt. Du har møtt OP på deres vilkår og besvart spørsmålet deres. Du har hjulpet dem med å forstå svikt i spørsmålet deres og hvorfor det ikke er å løse Y … så nå er du helt berettiget til å forklare en løsning til X.

De fleste er her for å lære så del 1 og 2 av dette svaret er like viktig som del 3. Men for ofte blir del 3 gitt på det «s eier og det er ekstremt frustrerende og nedlatende for OP å ikke nevne mange OP vil ikke akseptere svaret.

Å gi dette svaret unngår også forlegenhet når du tror OP har et XY problem når de faktisk don «t. Alt du har gjort er å gi litt ekstra informasjon. Bare å gi del 3 risikoer som ser ut til å ikke ha lest spørsmålet.

Forresten. Les spørsmålet igjen og les dette svaret … legg merke til de tre delene?

Kommentarer

• Som » XY Problem » er en slags » Bruk av feil hypotese » , må Stackoverflow-fellesskapet hjelpe til å vise riktig hypotese … Dette er fokuset i » Gi svar på XY-problemer «?
• @PeterKrauss På en måte. Det er mer en antagelse (jeg er enig i at samfunnet burde) . Jeg antar at noen som svarer på spørsmålet vil gi del 3 – riktig hypotese. Problemet med XY-problemet ligger i bortkastet tid. Så fokuset på dette svaret er å markere at det å bruke tid på å gi del 1 og 2 foran ikke er bortkastet tid, men faktisk sparer tid i det lange løp. Du har rett i at dette svaret er generalisert til Bruk av feil hypotese .
• Altfor ofte tar OP svaret til Y og løper, uten å lese videre eller innse at Y var den feil løsning på X. På grunn av dette ville jeg ‘ heller ikke gi dem et svar som vil bli misbrukt. Jeg ‘ risikerer heller å krenke dem for å komme til riktig løsning enn å bidra til både dårlig kode og feil logikk.
• @Tom At ‘ det er greit, i så fall er » du ber om noe som er veldig vanskelig » eller » du bør ikke ‘ t gjøre dette, det ‘ er en virkelig dårlig idé » type del (1) er helt passende.
• Jeg lo høyt etter at jeg var ferdig med å lese dette og sjekket tilbake. Utmerket svar, gode observasjoner, utmerket lederskap-ved-eksempel.
• Jeg vil legge til at formålet med dette nettstedet ikke bare er å hjelpe personen som opprinnelig stilte spørsmålet, men også å opprette et lager for alle andre som finner spørsmålet senere. Selv om Y ikke er den rette måten å gjøre X på, kan det fortsatt være nyttig i seg selv i andre sammenhenger, så svar på Y kan også være verdifullt.
• Dette svarer faktisk på det faktiske spørsmålet riktig mens andre bare rett og slett uttalte fakta

(atskilt fra det andre svaret mitt fordi dette har mer mening enn forklaring)

Hvis du er enig i at «XY-problemet» bare er et annet (mer spesialisert) begrep for «Bruk av feil arbeidshypotese», som illustrert og forklart her , og ligner på «Einstellung-effekten» forklart her av @Jonathan Benn …

Vi kan tenke på noen hovedsituasjoner:

• Rush situasjon: feil hypotese er bare et språk eller forenklet bivirkning, som kan korrigeres av brukeren med litt mer oppmerksomhet, og investering mer tid på å redigere spørsmålet.

• Normal situasjon: som i illustrert Missi ng Square puzzle, du vet ikke at hypotesen din er feil. Dette er hovedsituasjonen å diskutere her (!).

Så la oss sette fokus på normal situasjonen.

LØSNINGER / ATTENUATORER

«XY-problemet» er et gyldig problem!

Stack Exchange-spørsmålet er å vise et problem. Hvis spørsmålet mitt hjelper til å vise at reelt problem er min feil hypotese , det er OK! Det er et første skritt , og kanskje trenger jeg ingen andre spørsmål etter å ha fått riktig hypotese (og prøver å løse meg selv).

Eksempel. Se « XPath for xml: lang? Testing av attributtets egenakse mislykkes «; det virkelige problemet er at @attribute::self ikke eksisterer, så det var en feil hypotese om tittelen på spørsmålet.

help/mcve løsningen har begrensninger

Stack Overflow «s help/mcve begrunnelse : «Hvordan lage en M inimal, C omplete og V erifiserbar E xample «, kan brukes til å unngå XY-problemet.

Men redigeringskostnad (tid og oppmerksomhet dyrt), og oppfatningen om at det er en slags forurensning i teksten din (en «dårlig markedsføring» for spørsmålet) er ulemper.

Det er riktig å forenkle problemet og forklar med mer fokus på poenget.

Beste praksis

Tren brukere av Stack Overflow for å sjekke om forenkling er fornuftig. Algoritme for et godt spørsmål:

1. Prøv å opprette en MCVE.

2. Hvis en MCVE ikke er pr aktuelt, prøv i det minste å forenkle.

   2.1. Test, se etter inkonsekvenser, simuler leseren … og gjennomgå. Produserer forenklingen din noe rart, endrer konteksten? Gjennomgå for å unngå feil.

3. Lytt til til kommentarene om spørsmålet ditt , og prøv å avklare, prøv å arbeid rediger spørsmålet om nødvendig: hvis det er noen som kommenterer, er det en legg merke til at du kan investere mer tid i spørsmålet ditt.

Feil hypotese er ikke selvinnlysende, men når vi forenkler, forsterker vi de gale effektene, og det blir mer tydelig.

PS: Når vi derimot forklarer og viser alle detaljene, all sammenheng, og sjekker det virkelige poenget, samlingen av problemet (som når vi bruker mcve), inkonsekvensene viser også mer bevis.

Kommentarer

• Det ‘ er min erfaring at den MCVE skaper flere XY-problemer, ikke mindre. Det gjør en mer ren abstraksjon ved å fjerne konteksten til det originale spørsmålet. Det er X som kan være inneholdt i sammenheng med det opprinnelige spørsmålet, men MCVE vil kun være konstruert for å uttrykke Y.
• Takk @couling (!). Ja, som metodikk er MCVE kanskje ikke en » beste praksis «, men er en måte å håndheve » … forklar og vis alle detaljene … «. Hjernen vår fungerer bedre etter den slags egenanmeldelse … Du kan redigere og rette teksten, det er en Wiki.