Ciocan de aur

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 4 aprilie 2022; verificările necesită 4 modificări .

Ciocanul de aur ( ing.  Ciocanul de aur ) este un anti- model de proiectare, care constă în folosirea aceleiași soluții peste tot, inclusiv prin ajustarea artificială a condițiilor, cerințelor, constrângerilor problemei la o soluție dată [1] .

Cunoscut și ca : Legea  instrumentului , ciocanul lui Maslow , Ciocalul .  Poate apărea atât la nivel managerial [2] , cât și la nivel de dezvoltatori [3] , esența acesteia nu se schimbă.  

Esența antipatternului

Ciocanul de aur - încredere în universalitatea completă a oricărei soluții și aplicarea acestei soluții (de exemplu, unul dintre modelele de proiectare în programare) la orice sarcină. Înclinația de a folosi „ciocanul de aur” nu depinde de experiența specialistului.

Factorii care contribuie la apariția „ciocanului de aur” [4] :

• echipa de dezvoltare tinde să folosească tehnologie familiară;
• echipa de dezvoltare nu este familiarizată cu alte tehnologii de dezvoltare;
• trecerea la o altă tehnologie este asociată cu un anumit risc;
• tehnologia familiară simplifică planificarea și evaluarea dezvoltării;
• motive politice, în special, investiții mari care vizează deja promovarea unui produs sau tehnologie [3] ;
• încredere în caracteristicile propriului produs, care nu sunt disponibile de la alte produse din industrie [3] .

Consecințele sunt:

• soluție suboptimală (chiar dacă din exterior arată „drăguț”);
• complicație inutilă sau simplificare inacceptabilă a sistemului.

Semne și consecințe ale apariției ciocanului de aur [3] :

• instrumente și tehnologii identice sunt utilizate pentru un număr mare de produse diverse din punct de vedere conceptual;
• soluțiile au performanțe slabe, scalabilitate etc. în comparație cu alte soluții din industrie;
• arhitectura sistemului este cel mai bine descrisă de un anumit produs, pachet de aplicație sau set de instrumente pentru furnizor;
• Dezvoltatorii, în discutarea cerințelor cu analiștii și utilizatorii finali, pledează pentru cerințe care pot fi adaptate cu anumite instrumente sau îndepărtate din domeniile în care nu se aplică.
• dezvoltatorii devin izolați de industrie. Ei demonstrează o lipsă de cunoștințe și experiență cu abordări alternative;
• produsele existente dictează designul și arhitectura sistemului;
• toate noile dezvoltări se bazează în mare măsură pe produsul sau tehnologia unui anumit furnizor.

Exemplu: Unele companii web continuă să utilizeze și să mențină sisteme de cache dezvoltate în mod automat, în ciuda disponibilității alternativelor open source [4] .

Modalități de a face față ciocanului de aur

Modalități de prevenire:

• Analiza disponibilității soluțiilor alternative, căutarea și compararea altor modalități de rezolvare a problemei. De exemplu, dezvoltatorii de software trebuie să țină pasul cu tendințele tehnologice actuale. Acest lucru se aplică atât direct dezvoltatorilor de software, cât și managementului. O modalitate bună de a menține schimbul de cunoștințe despre inovațiile tehnice este practica organizării unor întâlniri de discuții în care se vor discuta noile tehnologii (modeluri, standarde emergente, produse noi) [3] .
• Prototiparea , compararea diferitelor moduri de a rezolva o anumită problemă, prin crearea de prototipuri.

Metode de identificare - lipsa managerului de o colecție de soluții pentru diverse sarcini și apariția dificultăților atunci când apar noi situații problematice, indică apariția unui „ciocan de aur” la nivel managerial [5] . Pentru a identifica un ciocan la nivel de dezvoltator, ar trebui să utilizați revizuirea codului ( ing.  Revizuirea codului ) - monitorizarea codului în cursul îndeplinirii sarcinii și identificarea soluțiilor neoptimale sau repetate frecvent, analizând și comparând alternativele acestora.

Remedii - refactorizarea vă va permite să optimizați codul alegând soluții mai potrivite și reparându-le pe cele existente.

Istoria termenului

Prima mențiune este datată 1964 și îi aparține lui Abraham Kaplan[6] :

Eu o numesc Legea instrumentului): Dă-i unui băiețel un ciocan și va descoperi că totul în jurul lui trebuie doar lovit.

Text original  (engleză)[ arataascunde] O numesc legea instrumentului și poate fi formulată după cum urmează: Dă-i unui băiețel un ciocan și va descoperi că tot ceea ce întâlnește trebuie lovit. — Abraham Kaplan

Un concept similar a fost numit „ciocanul lui Maslow” după Abraham Harold Maslow , care a scris în 1966:

Cred că dacă singurul tău instrument este un ciocan, atunci vrei să te uiți la orice ca un cui [7] .

Text original  (engleză)[ arataascunde] Presupun că este tentant, dacă singurul instrument pe care îl ai este un ciocan, să tratezi totul ca și cum ar fi un cui.

Expresia engleză „o șurubelniță Birmingham” se referă la obiceiul de a folosi un singur instrument pentru toate scopurile și precede Kaplan și Maslow [8] . Conceptul este atribuit și lui Mark Twain , deși nu există nicio confirmare în lucrarea publicată de Twain [9] .

Excepții notabile

Uneori, ciocanul de aur anti-model funcționează:

• dacă produsul care definește constrângerile arhitecturale este o decizie strategică intenționată pe termen lung;
• dacă produsul face parte din pachetul unui furnizor, pentru majoritatea nevoilor de software .

Relația cu alte modele și anti-tipare

• Silver Bullet ( în engleză  SilverBullet ) este o metodă universală ipotetică în tehnologie sau tehnică de management care crește performanța, fiabilitatea și simplitatea unui proiect software cu un ordin de mărime [10] . Frederick Brooks a arătat că nu există un glonț de argint : nicio inovație tehnologică sau organizațională nu poate reduce în mod fundamental complexitatea inerentă a unui proiect (adică complexitatea datorată complexității sarcinii în sine și altor factori inevitabili). „Glonțul de argint” și „ciocanul de aur” provoacă daune în moduri diferite: dacă „ciocanul” duce direct la consecințe negative, din cauza deplasării soluțiilor mai reușite de către acesta, atunci „glonțul” de obicei nu direcționează, dar prejudiciu indirect prin faptul că caută și încearcă să aplice ca urmare, sunt cheltuite mai multe resurse decât face posibilă economisirea.
• Dependența de blocare a furnizorului .  Dezvoltatorii caută în mod activ sprijinul furnizorilor în aplicarea ciocanului de aur. Întregul proiect se bazează pe o abordare unică de instrument/furnizor de tehnologie în dezvoltarea și implementarea produsului [11] .

Vezi și

• Panaceu

Note

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

Literatură

• Miroshnichenko E. A. Tehnologii de programare . - Editura Universității Politehnice din Tomsk, 2008.
• Bulajic A. Design Patterns Past and Future // Proceedings of Informing Science & IT Education Conference  (  InSITE). — 2011.
• Smith CU, Williams LG Software Performance AntiPatterns  //  Al 2-lea workshop internațional despre software și performanță. — 2000.
• Maslow A.H. Psihologia științei . - 1966. - ISBN 0-9760402-3-9 .
• Kaplan A. The Conduct of Inquiry: Methodology for Behavioral Science . - San Francisco: Chandler Publishing Co, 1964. - ISBN 0-7658-0448-4 .
• Verde, Jonathan. Dicţionar de argou. - Cassell, 1998. - ISBN 978-0304344352 .
• McQuade TJ Cogniție și economie. - Editura Emerald Group, 2006. - 77 p.
• Allen E. Erori tipice de proiectare. - Editura „Petru”, 2003. - 224 p. — ISBN 5-887827-304-6 .
• Brooks F. No Silver Bullet - Esența și accidentele ingineriei software. . - TPU, 1986.
• Freeman E., Freeman Al. Modele de design. - Petru, 2011. - 646 p.
• Brown WH, Malveau RC AntiPatterns. Refactorizare software, arhitecturi și proiecte în criză. . - Robert Ipsen, 1998. - 157 p. — ISBN 0-471-19713-0 .
• Laplante PA, Neill CJ Antipatterns: Identificare, refactorizare și management. . - Publicaţiile Auerbach, 2005. - 333 p. — ISBN 0-8493-2994-9 .  (link indisponibil)