Gyllene hammare

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 4 april 2022; kontroller kräver 4 redigeringar .

Guldhammare ( eng.  Golden hammer ) är ett antimönster av design, som består i att använda samma lösning överallt, inklusive genom att på konstgjord väg anpassa problemets villkor, krav, begränsningar till en given lösning [1] .

Även känd som : Instrumentets lag  , Maslows hammare , Gavel . Det kan dyka upp både på ledningsnivå [2] och på utvecklarenivå [3] , kärnan i detta förändras inte.   

Kärnan i antimönster

Guldhammare - förtroende för den fullständiga universaliteten av alla lösningar och tillämpningen av denna lösning (till exempel ett av designmönstren i programmering) för alla uppgifter. Benägenheten att använda "guldhammaren" beror inte på specialistens erfarenhet.

Faktorer som bidrar till utseendet på "guldhammaren" [4] :

• utvecklingsteamet tenderar att använda bekant teknik;
• utvecklingsteamet är inte bekant med annan utvecklingsteknik;
• byte till annan teknik är förenat med en viss risk;
• bekant teknik förenklar utvecklingsplanering och utvärdering;
• politiska skäl, särskilt stora investeringar som redan syftar till att främja en produkt eller teknik [3] ;
• förtroende för egenskaperna hos sin egen produkt, som inte är tillgängliga från andra produkter i branschen [3] .

Konsekvenserna är:

• suboptimal lösning (även om det ser "fint" ut från utsidan);
• onödig komplikation eller oacceptabel förenkling av systemet.

Tecken och konsekvenser av utseendet på den gyllene hammaren [3] :

• identiska verktyg och teknologier används för ett stort antal konceptuellt olika produkter;
• lösningar har dålig prestanda, skalbarhet etc. jämfört med andra lösningar i branschen;
• systemarkitekturen beskrivs bäst av en specifik produkt, applikationspaket eller leverantörsverktygslåda;
• Utvecklare, när de diskuterar krav med analytiker och slutanvändare, förespråkar krav som kan skräddarsys med vissa verktyg eller tas bort från områden där de inte gäller.
• utvecklare blir isolerade från branschen. De visar brist på kunskap och erfarenhet av alternativa tillvägagångssätt;
• befintliga produkter dikterar systemets design och arkitektur;
• all nyutveckling baseras till stor del på en viss leverantörs produkt eller teknologi.

Exempel: Vissa webbföretag fortsätter att använda och underhålla egenutvecklade cachningssystem trots att det finns alternativ med öppen källkod [4] .

Sätt att hantera den gyllene hammaren

Sätt att förebygga:

• Analys av tillgången på alternativa lösningar, sökning och jämförelse av andra sätt att lösa problemet. Till exempel måste mjukvaruutvecklare hänga med i aktuella tekniktrender. Detta gäller både direkt för mjukvaruutvecklare och ledning. Ett bra sätt att upprätthålla kunskapsutbytet om tekniska innovationer är praxis att organisera diskussionsmöten där ny teknik (mönster, framväxande standarder, nya produkter) kommer att diskuteras [3] .
• Prototyping , jämför olika sätt att lösa ett givet problem, genom att skapa prototyper.

Identifieringsmetoder - chefens brist på en samling lösningar för olika uppgifter och uppkomsten av svårigheter när nya problemsituationer uppstår, indikerar uppkomsten av en "guldhammare" på chefsnivå [5] . För att identifiera en hammare på utvecklarnivå bör du använda kodgranskning ( eng.  Code review ) - övervaka koden under arbetets gång och identifiera icke-optimala eller ofta upprepade lösningar, analysera och jämföra deras alternativ.

Åtgärder - refactoring gör att du kan optimera koden genom att välja lämpligare lösningar och fixa befintliga.

Termens historia

Det första omnämnandet är daterat 1964 och tillhör Abraham Kaplan[6] :

Jag kallar det instrumentets lag): Ge en liten pojke en hammare, så kommer han att upptäcka att allt omkring honom bara behöver slås.

Originaltext  (engelska)[ visaDölj] Jag kallar det instrumentets lag, och det kan formuleras så här: Ge en liten pojke en hammare, så kommer han att upptäcka att allt han möter behöver dunka. — Abraham Kaplan

Ett liknande koncept kallades "Maslow's Hammer" efter Abraham Harold Maslow , som skrev 1966:

Jag tror att om ditt enda verktyg är en hammare, då vill du se på något som liknar en spik [7] .

Originaltext  (engelska)[ visaDölj] Jag antar att det är frestande, om det enda verktyget du har är en hammare, att behandla allt som om det vore en spik.

Det engelska uttrycket "a Birmingham screwdriver" syftar på vanan att använda ett verktyg för alla ändamål, och går före Kaplan och Maslow [8] . Konceptet tillskrivs också Mark Twain , även om det inte finns någon bekräftelse i Twains publicerade arbete [9] .

Anmärkningsvärda undantag

Ibland fungerar guldhammarens antimönster:

• om produkten som definierar de arkitektoniska begränsningarna är ett avsett strategiskt beslut på lång sikt;
• om produkten är en del av en leverantörs paket, för de flesta programvarubehov .

Relation med andra mönster och antimönster

• Silver Bullet ( engelska  SilverBullet ) är en hypotetisk universell metod inom teknik eller ledningsteknik som ökar prestandan, tillförlitligheten och enkelheten för ett mjukvaruprojekt med en storleksordning [10] . Frederick Brooks visade att det inte finns någon silverkula : ingen teknisk eller organisatorisk innovation kan i grunden minska den inneboende komplexiteten i ett projekt (det vill säga komplexiteten på grund av komplexiteten i själva uppgiften och andra oundvikliga faktorer). "Silverkulan" och "guldhammaren" orsakar skada på olika sätt: om "hammaren" leder till negativa konsekvenser direkt, på grund av förskjutningen av mer framgångsrika lösningar av den, så riktar "kulan" vanligtvis inte, men indirekt skada genom att den söker och försöker ansöka som ett resultat, spenderas mer resurser än det gör det möjligt att spara.
• Leverantörslåsningsberoende .  _ _ _ Utvecklare söker aktivt leverantörsstöd för att tillämpa guldhammaren. Hela projektet förlitar sig på ett enda verktyg/teknikleverantörsmetod vid produktutveckling och implementering [11] .

Se även

• Panacea

Anteckningar

1. ↑ Bulajic A., 2011 .
2. ↑ Laplante, 2005 , sid. 71-73.
3. ↑ 1 2 3 4 5 Brown, 1998 , sid. 62-63.
4. ↑ 1 2 Freeman E., 2011 , sid. 622-623.
5. ↑ Laplante, 2005 , sid. 73.
6. ↑ Kaplan A., 1964 , s. 28.
7. ↑ Maslow AH, 1966 , s. femton.
8. ↑ Green J., 1985 .
9. ↑ McQuade, 2006 .
10. ↑ Brooks F., 1986 .
11. ↑ Brown, 1998 , sid. 64-65.

Litteratur

• Miroshnichenko E. A. Programmeringsteknik . - Förlag vid Tomsk Polytechnic University, 2008.
• Bulajic A. Design Patterns Past and Future // Proceedings of Informing Science & IT Education Conference  (  InSITE). — 2011.
• Smith CU, Williams LG Software Performance AntiPatterns  //  2nd International Workshop on Software and Performance. — 2000.
• Maslow A.H. Vetenskapens psykologi . - 1966. - ISBN 0-9760402-3-9 .
• Kaplan A. Utredningens uppförande: Metodik för beteendevetenskap . - San Francisco: Chandler Publishing Co, 1964. - ISBN 0-7658-0448-4 .
• Green, Jonathan. Ordbok för Slang. - Cassell, 1998. - ISBN 978-0304344352 .
• McQuade TJ Kognition och ekonomi. - Emerald Group Publishing, 2006. - 77 sid.
• Allen E. Typiska designfel. - Förlaget "Peter", 2003. - 224 sid. — ISBN 5-887827-304-6 .
• Brooks F. No Silver Bullet - Essence and Accidents of Software Engineering. . - TPU, 1986.
• Freeman E., Freeman Al. Design mönster. - Peter, 2011. - 646 sid.
• Brun WH, Malveau RC AntiPatterns. Refaktorering av programvara, arkitekturer och projekt i kris. . - Robert Ipsen, 1998. - 157 sid. — ISBN 0-471-19713-0 .
• Laplante PA, Neill CJ Antimönster: Identifiering, Refactoring och Management. . - Auerbach Publications, 2005. - 333 s. — ISBN 0-8493-2994-9 .  (inte tillgänglig länk)