Cum dovedesc sau resping “ obiectele lui Dumnezeu ” sunt greșite?

Cazul pentru orice schimbare de practică se face identificând punctele de durere creat de designul existent. Mai exact, trebuie să identificați ceea ce este mai greu decât ar trebui să fie din cauza designului existent, a ceea ce este fragil, a ceea ce se rupe acum, ce comportamente nu pot fi implementate într-o manieră simplă ca rezultat direct (sau chiar oarecum indirect) al implementarea actuală sau, în unele cazuri, modul în care suferă performanța, cât timp este necesar pentru a aduce un nou membru al echipei la viteză etc.

În al doilea rând, codul de lucru depășește orice argument cu privire la teorie sau la un design bun Din păcate, acest lucru este valabil chiar și pentru codurile necorespunzătoare. Deci, va trebui să oferiți o alternativă mai bună, ceea ce înseamnă că dvs., în calitate de avocat pentru modele și practici mai bune, va trebui să refactorați pentru a elimina un design mai bun. Găsiți un plan îngust, stil trasor-glonț prin designul existent și implementați o soluție care, probabil, pentru o iterație, menține implementarea obiectului zeu funcțional, dar diferă implementarea efectivă la noul design. Apoi scrieți un cod care profită de acest nou design și arătați ce câștigați datorită acestei modificări, fie că este vorba despre performanța, mentenabilitatea, caracteristicile, corectarea erorilor sau condițiile de rasă sau reducerea încărcării cognitive pentru dezvoltator.

Este adesea o provocare să găsești o suprafață suficient de mică pentru a ataca în sisteme slab arhitecturate, poate dura mai mult decât ți-ar plăcea să oferi o valoare inițială, iar plata inițială poate să nu fie atât de impresionantă pentru toată lumea, dar puteți lucra și la găsirea unor susținători ai noii dvs. abordări dacă vă asociați cu membrii echipei care sunt cel puțin ușor simpatici.

Lamenting the God Object funcționează numai atunci când predicați către Corul. „Este un instrument pentru denumirea unei probleme și funcționează doar pentru rezolvarea acesteia atunci când aveți un public receptiv suficient de motivat și de senior pentru a face ceva în acest sens. Fixarea obiectului Dumnezeu câștigă argumentul.

Întrucât îngrijorarea ta imediată pare să fie un buy-in executiv, cred că cel mai bine este să faci un argument că înlocuirea acestui cod trebuie să fie un obiectiv strategic și să le asociezi la obiectivele de afaceri pentru care ești responsabil. Cred că poate susține că puteți oferi o anumită direcție tehnică lucrând mai întâi la o creștere tehnică a ceea ce credeți că ar trebui făcut pentru a o înlocui, de preferință implicând resurse de la una sau două persoane tehnice care au rezerve cu privire la designul actual.

Cred că ați găsit suficiente resurse pentru a vă justifica argumentul; oamenii care participă la astfel de întâlniri vor fi atenți doar la rezumatul cercetărilor dvs. și vor înceta să asculte după ce menționați două sau trei surse coroborate.Concentrarea dvs. ar trebui să fie inițial să obțineți răscumpărarea pentru a rezolva problema pe care o vedeți, nu dovedind neapărat că altcineva greșește sau că aveți dreptate. Aceasta este o problemă socială, nu una logică.

Într-un rol de conducere în domeniul tehnologiei, trebuie să legați oricare dintre inițiativele dvs. de obiectivele de afaceri, deci cel mai important lucru pentru a vă prezenta cazul către directori este ceea ce se va lucra pentru aceste obiective. Deoarece ești considerat și „tipul nou”, nu te poți aștepta doar ca oamenii să-și arunce munca sau să se aștepte să cadă rapid în linie; trebuie să construiți o anumită încredere dovedind că puteți livra. Ca o preocupare pe termen lung, într-un rol de conducere, trebuie să învățați să vă concentrați asupra rezultatelor, dar să nu fiți neapărat atașat la specificul rezultatului. Acum sunteți acolo pentru a oferi direcție strategică, pentru a elimina obstacolele tactice din progresul echipei dvs. și pentru a oferi consiliere echipei dvs., nu pentru a câștiga bătălii de credibilitate cu membrii propriei echipe.

Luând o decizie de sus rareori fiți credibili, cu excepția cazului în care aveți ceva în joc; dacă vă aflați din nou într-o situație similară, ar trebui să vă concentrați mai mult pe crearea consensului în cadrul organizației dvs., decât pe escaladarea odată ce simțiți că situația este scăpată de sub control.

Dar, ținând cont de locul în care vă aflați acum, aș spune că cel mai bun pariu este să susțineți că abordarea dvs. va aduce beneficii măsurabile pe termen lung pe baza experienței dvs. și că este în concordanță cu munca unor practicanți cunoscuți, cum ar fi unchiul Bob și colab., și că ți-ar plăcea să petreci câteva zile / săptămâni conducând cu exemplul pe o refacere îngustă a celui mai înalt aspect bang-for-buck, pentru a demonstra cum ar trebui să arate viziunea ta despre un design bun. Cu toate acestea, va trebui să vă aliniați la obiectivele specifice ale afacerii dvs. dincolo de preferințele dvs. personale.

Comentarii

• Un punct bun despre faptul că este un problemă socială. Trebuie să fie motivul pentru care există atât de mult cod scris rău și aplicații slab concepute acolo.
• +1 pentru legarea acestuia cu ‘ business speak ‘ ca atare; intenționați să îl faceți cât mai relevant pentru publicul dvs. Dacă ‘ discutați cu directorii, faceți vorbiți despre cum standardul de cod are o legătură directă cu întreținerea și performanța și discutați despre legătura dintre acestea și finanțele generale ale proiectului, stabilitatea pe termen lung și așa mai departe. Sună ca dvs. a fost angajat din cauza cunoștințelor dvs.; amintiți-vă acest lucru. (Doar nu ‘ nu deveniți un manager jerk-off care crede el știe întotdeauna cel mai bine – dar în acest caz ‘ ești 100% corect.)
• +1 pentru codul de lucru ” depășește orice argument cu privire la teorie sau la un design bun. ” Ceva pe care îl uităm adesea în căutarea noastră pentru un cod perfect.
• Răspuns excelent, multă înțelepciune acolo pentru aspiranții la echipă.

Mai întâi, trebuie să prezentați că orice organizație măsurabilă trebuie să adopte cele mai bune practici din industrie. Spunând că „doar funcționează pentru noi!” nu poate fi măsurat, nici în timp, nici în resurse, deoarece este pur și simplu imprevizibil. Ingineria software este o știință la fel de mult ca orice alte domenii ale științei, iar aceste concepte au fost studiate, cercetate, testate și documentate.

1. God Object este un anti-model care afirmă că

   În ingineria software, un anti-model (sau antipattern) este un model utilizat în operațiuni sociale sau de afaceri sau inginerie software care poate fi utilizat în mod obișnuit, dar este ineficient și / sau contraproductiv în practică.

2. În conferința Google IO din 2009 , acest subiect a fost parțial explicat atunci când MVP modelul a fost explicat. Este posibil să nu fie relevant pentru Obiectul lui Dumnezeu, dar vă poate oferi niște muniție.

3. De asemenea, utilizarea acestui anti-model încalcă principiul responsabilității unice în proiectele orientate pe obiecte, care afirmă că:

   fiecare clasă ar trebui să aibă o singură responsabilitate și această responsabilitate ar trebui să fie în întregime încapsulat de clasă. Toate serviciile sale ar trebui aliniate în mod restrâns cu respectiva responsabilitate.

4. Blogul Decaying Code vorbește și despre acest lucru și despre soluția acestuia.

5. Nu putem vorbi despre principiul responsabilității unice fără a vorbi despre obiect coupling .

   […] cuplarea sau dependența este gradul în care fiecare modul de program se bazează pe fiecare unul dintre celelalte module.

   În cazul în care un sistem strâns cuplat poate cauza assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Un nivel mai ridicat de couping a obiectelor înseamnă o mai mică coeziune și viceversa. Obiectele lui Dumnezeu sunt un bun exemplu de cuplare strânsă, deoarece știu mai mult decât ar trebui, astfel le supraîncarcă cu responsabilitate, limitând astfel foarte mult reutilizarea codului.

6. Când proiectăm o aplicație complexă, simplitate trebuie să vă vină în minte. Problemele mari trebuie descompuse în altele mai mici, care sunt mai ușor de gestionat, testat și documentat. Acest lucru este valabil mai ales într-o paradigmă orientată pe obiecte.

   Cu acest argument, ne întoarcem la argumentul anti-model, dar această paradigmă se referă la tipare, la reprezentarea obiectelor din lumea reală și, în ultimă instanță, la date. încapsulare.

7. Ai dreptate când spui că aceste „bune practici” sunt mai existente în sălile de clasă. Cu toate acestea, am experiențe de predare în facultate (și în unele universități) și am văzut că aceste principii sunt predate doar în universități, în special în facultățile de inginerie. Ceea ce este trist. Dar, ca orice bună practică, cei care se străduiesc să se îmbunătățească singuri învață de obicei câteva modele de proiectare și, în cele din urmă, înțeleg cum să se unească între cuplare și coeziune.

   Ceea ce învăț de obicei studenților este că, poate pare să necesite mai multe eforturi pentru a adopta standarde bune de programare, dar întotdeauna dă roade pe termen lung. Un exemplu bun ar fi cineva care cere unui programator să scrie o funcție de sortare. Programatorul are două opțiuni; 1) scrieți o funcție de sortare rapidă cu bule (mai puțin de 5 minute) care nu va fi sustenabilă pe măsură ce lista de elemente crește sau 2) scrieți un algoritm de sortare mai complex (alias optimizat) (sortare rapidă etc.) care se va scala mai bine cu liste mai mari.

Comentarii

• Limbajele de programare orientate pe obiecte necesită adesea că dacă sunt responsabile două ansambluri sursă independente pentru diferite aspecte ale comportamentului unui obiect ‘, vor trebui create instanțe de obiect independente pentru a încapsula aceste comportamente. Din păcate, chiar dacă în multe cazuri cele mai logice subdiviziuni ale funcționalității dintre ansamblurile de coduri nu coincid cu cea mai logică subdiviziune a funcționalității dintre instanțele obiectelor, eu ‘ Nu am văzut prea multe discuții despre diferențierea celor două tipuri de subdiviziuni.
• Cred că este puțin subiect pentru această întrebare. ‘ nu vorbim despre anti-modelul Obiectului Dumnezeu, aici, ci cuplarea și coeziunea codului, care este un subiect mult mai larg și foarte subiectiv.

Oh, aici, merg, necrozând o altă întrebare veche, dar „cred că nu ai câștigat acest argument și aici” de ce.

Sună ca o problemă culturală

Tu ești manager, dar nu poți să-i înlocuiești și trebuie să mergi la managerii tăi pentru a-i determina să facă ceea ce crezi că ar trebui să facă, ceea ce presupun în acest caz este cel puțin să-l elimini cu obiectele zeului înaintând. Mi se pare un caz clasic de cod care reflectă cultura în care s-a născut. Cu alte cuvinte, obiectul lui Dumnezeu este modul în care funcționează această companie. Vrei să faci orice fel de schimbare semnificativă? Mergi mereu în același loc pentru asta în cele din urmă, deoarece toate deciziile aparent trebuie clarificate în partea de sus.

După ce a fost p rivalizează cu mai multe încercări nereușite de curățare a codului vechi și modificări ale politicii de cod. Acum sunt de părere că nu poți lupta împotriva culturii care a făcut posibil codul în primul rând, atunci când cultura respectivă este încă bine înrădăcinată sau, cel puțin, combaterea culturii este un slogan foarte dur în ascensiune că este puțin probabil ca cineva să-mi plătească vreodată suficient sau să-mi dea suficientă putere pentru a simți că a fost un efort demn care ar fi reușit să reușească vreodată.

Înainte de a putea exista schimbări, trebuie să fie motivați să se schimbe și, din păcate, în calitate de programatori care dau destul de naibii să citească Stack ocazional, ne este greu să înțelegem că nu toată lumea este motivată de aceleași lucruri. Am câștigat o mulțime de argumente raționale din experiențele mele, dar la sfârșitul zilei, compania suferă dezvoltatori leneși din punct de vedere intelectual dintr-un motiv.

Poate că preocupările de afaceri au fost motivate să se gândească doar la ziua de mâine, mai degrabă decât la săptămâna viitoare sau cinci ani afară (un scenariu deosebit de frustrant când „sunteți copilul imigranților dintr-o țară care a construit un seif de semințe în Arctica în caz de apocalipsă). Poate că le este frică de schimbare.Poate că apreciază prea mult vechimea până la punctul în care lanțul de comandă este lipsit de sens chiar și atunci când trebuie să angajeze din exterior pentru a aduce un conducător de echipă sau un manager de echipă pentru că recunosc că nimeni din echipa lor din viață nu a crescut suficient în timpul lor acolo (sau pentru că susținătorii nu doresc riscul asociat cu responsabilitatea). Sau, și „am văzut acest lucru, poate că este„ fenomenul foarte real și deprimant al mediocrității care se luptă pentru că știe adânc în interior că poate ” Nu concurați cu calitatea și atunci când există suficientă nebunie pentru a o înconjura, este imposibil să vă dați seama cui să dați vina atunci când totul merge în mod obișnuit.

Cum luptați împotriva problemelor care sunt în cele din urmă înrădăcinate în frică sau valori defecte pentru succes? Vă spun asta, este nevoie de mult mai mult decât chiar de o echipă de dev calitativă și ați avut mult mai puțin decât sunetul din momentul în care a fost postat acest Q.

În cazul imposibil de realizat că nu este o problemă de cultură care nu se poate atrage …

Presupunând acum oameni din partea de sus sunt foarte receptivi la schimbare și sunt de fapt dispuși să aibă încredere în voi pentru a reuși, într-adevăr trebuie doar să vă punctați toate argumentele cu bani și oportunități pierdute.

De fiecare dată când este nevoie de mai mult timp pentru a instrui pe cineva nou pe această bază de cod ridicolă, de fiecare dată când durează mai mult pentru a modifica sau adăuga o nouă caracteristică la ceva, de fiecare dată când devine dificil de expus punctele finale unui alt sistem de la o companie cu care doriți să faceți partener, costă bani. cel mai important, lasă o fereastră deschisă pentru ca un concurent mai mic și mai agil să se lase, te pune într-o poziție în care tot ce poți face este să reacționezi la ei mult prea slab și, în cele din urmă, smulge-ți totul de la tine.

Recunoaște doar că o cultură deosebit de încăpățânată și stupidă va menține statu quo-ul cu orice preț, chiar dacă acoperișul fizic real al companiei este de fapt în flăcări, deoarece din aceasta.

Comentarii

• Am părăsit compania la scurt timp după aceea. au încercat să mă angajeze cu normă întreagă și să mă facă să mă mut la NY din Seattle pentru a accepta oferta; Practic le-am spus ” În niciun caz, nu ‘ nu mă voi muta la NY când echipa pe care o voi gestiona este în Bellevue, WA ” și în acel moment am traversat practic strada și am primit un loc de muncă la MSFT până am găsit ceva mai bun.
• @honestduane Da, acel set de așteptări singur vorbește volum. Bine pentru dvs. pe GTFO.

Ați putea cita unele dintre cele mai elementare principii OOP, cum ar fi cuplare slabă și coeziune ridicată. Un „obiect al lui Dumnezeu” sună de parcă ar cupla clase fără legătură și are o coeziune redusă.

Ai putea să-l întrebi întotdeauna pe unchiul Bob însuși .

Lucrul este că „este atât de evident pentru persoanele cu orice sens că, odată ce este explicat, nu mai trebuie să fie referit de o multitudine de autori. Trebuie doar să existe o singură sursă.

Alți termeni cu care ați putea dori să începeți atunci când căutați surse sunt:

• SOLID
• Legea lui Demeter
• Big Ball of Mud

Toate aceste exprima concepte conexe care ar putea produce surse de referință viabile, chiar dacă nu o denumesc de fapt ca atare.

În cele din urmă totuși, tu ești șeful. Motivul pentru care o faci este că spui asta și, deși pentru a fi considerat un bun manager, ar trebui să fii pregătit să-ți justifici deciziile; ai făcut asta și dacă există încă rezistență, calea corectă de acțiune este ca echipa dvs. să facă ceea ce li s-a spus.

Comentarii

• ” dacă există încă rezistență, acțiunea corectă este ca echipa dvs. să facă așa cum au spus ‘ id = „1fdb1bfaab”>

Cum dovedesc sau resping obiectele „zeului” sunt greșite?

Nu puteți.

Acest tip de conjectură nu este supus dovezilor matematice, iar dovada matematică este singurul tip de dovadă care este solidă.

Chiar dacă încercați să înlocuiți cuvântul emotiv „greșit” cu măsuri cuantificabile ale efectelor utilizării obiectelor lui Dumnezeu, veți constata că:

1. măsurile disponibile sunt brute,
2. există puține studii credibile în care acele măsuri au fost cuantificate pentru codul produs de programatori profesioniști
3. există puține studii credibile în care construcțiile de limbă sau modelele (anti) de proiectare au fost legate de aceste măsuri.

Și că ignoră problema de a decide când un anumit obiect este un obiect „zeu”.

În cel mai bun caz, aceste tipuri de studii nu ar putea demonstra decât o corelație empirică. Nu este o dovadă autentică.

Ceea ce faceți este dezbate argumentele pro și contra obiectelor „zeului” în vederea schimbării opiniilor celorlalte popoare … și apoi practica organizației dvs.

Nu folosiți cuvinte precum „dovadă” sau persoanele cu care dezbateți sunt susceptibile să râdă în fața voastră.

Poate doriți să vedeți guru al săptămânii # 84 . Este vorba despre obiecte ale lui Dumnezeu (monoliti) și despre modul în care acestea sunt rele.

Extras:

(Major) Izolează funcționalitate potențial independentă în interiorul unei clase […] (Minor) Poate descuraja extinderea clasei cu funcționalități noi […]

Nu sunt sigur dacă echipa ta este cu adevărat interesată să demonstreze că „obiectele lui Dumnezeu sunt greșite”.

Din punct de vedere psihologic, abordarea refactorizării poate fi înțeleasă greșit ca atacând competența echipei: „echipa a făcut o treabă proastă”, deși programul funcționează așa cum era de așteptat.

Ceea ce doriți cu adevărat să faceți este să faceți față efectelor secundare negative ale „codului spagetti” și „obiectelor lui Dumnezeu”: explodarea costurilor pentru adăugarea de caracteristici noi din cauza bug-urilor în creștere cauzate de efectele secundare.

întrebările specifice și punerea în loc de a oferi răspunsuri pot fi mai utile:

manager > Why did implement the new tax-calculation schema took more than 4 weeks team > because {reason a} manager > And why was {reason a}? team > because {reason b} manager > And why was {reason b}? ... team > because {reason z} manager > what could we do to avoid {reason z} ? team > refactor code