Ongelman yhteenveto:

Pitkä tarina, perin koodikannan ja kehitystiimin, jota en saa korvata, ja God Objectsin käyttö on iso asia. Jatkossa haluan saada meidät uudelleenarvioimaan asioita, mutta saan takaiskun joukkueilta, jotka haluavat tehdä kaiken God Objectsin kanssa ”, koska se on helpompaa”, mikä tarkoittaa, että minua ei sallita uudelleen. Työnsin takaisin vetoamalla vuosien kehityskokemukseeni, että olen uusi pomo, joka palkattiin tietämään nämä asiat, jne., Ja niin tekivät myös kolmannen osapuolen offshore-yhtiöt myyntiedustajana, ja tämä on nyt johtotasolla ja kokouksessani on huomenna ja haluan mennä sisään runsaalla teknisellä ampumatarvikkeella edistämään parhaita käytäntöjä, koska mielestäni se on halvempaa pitkällä aikavälillä (ja minusta henkilökohtaisesti tuntuu, että kolmas osapuoli on huolestunut) yritykselle.

Minun kysymykseni on tekniseltä tasolta, tiedän sen hyvän pitkän aikavälin, mutta minulla on vaikeuksia erittäin lyhyen ja 6 kuukauden ajanjakson kanssa, ja vaikka jotain, mistä ”tiedän”, en voi todistaa sitä viittaukset ja siteeratut resurssit yhden henkilön ulkopuolella (Robert C.Martin, alias setä Bob), koska se on mitä minua pyydetään tekemään, koska minulle on kerrottu, että minulla on tietoja yhdeltä henkilöltä ja vain yksi henkilö (Robert C Martin) ei ole tarpeeksi hyvä argumentti.

Kysymys:

Mitä som Resursseja voin lainata suoraan (otsikko, julkaistu vuosi, sivunumero, lainaus) alan tunnettujen asiantuntijoiden mukaan, jotka sanovat nimenomaisesti, että ”Jumalan” esineiden / luokkien / järjestelmien käyttö on huono (tai hyvä, koska etsimme teknisesti pätevin ratkaisu)?

Olen jo tehnyt tutkimusta:

  1. Minulla on täällä useita kirjoja, ja olen hakenut niiden hakemistosta sanojen ”jumalankohde” ja ”jumalaluokka” käyttöä. Huomasin, että omituisella tavalla sitä ei ole melkein koskaan käytetty ja esimerkiksi minun omistama GoF-kirjan kopio ei koskaan käytä sitä (ainakaan edessäni olevan hakemiston mukaan), mutta olen löytänyt sen kahdesta alla olevasta kirjasta, mutta haluan lisää Voin käyttää.
  2. Tarkistin Wikipedia-sivulta ”Jumala-esine” ja sen tällä hetkellä tynkä, jossa on vähän viittauslinkkejä, joten vaikka itse olen samaa mieltä siitä, että siinä sanotaan, sillä ei ole paljon mitä voin käyttää ympäristössä, jossa henkilökohtaista kokemusta ei pidetä pätevänä. Lainattua kirjaa pidetään liian vanhana, jotta ihmiset, joiden kanssa keskustelen näistä teknisistä näkökohdista, ovat perusteluina heidän mukaansa ”sen ajateltiin kerran olevan huono, mutta kukaan ei voinut todistaa sitä, ja nyt nykyaikainen ohjelmisto sanoo” jumala ”esineitä on hyvä käyttää”. Uskon henkilökohtaisesti, että tämä lausunto on väärä, mutta haluan todistaa totuuden mitä se onkin.
  3. Robert C Martinin ”Agile Principles, Patterns, and Practices in C #” (ISBN: 0-13-185725-8, kovakantinen) whe uudelleen sivulla 266 siinä sanotaan ”Kaikki tietävät, että jumalaluokat ovat huono idea. Emme halua keskittää koko järjestelmän älykkyyttä yhdeksi objektiksi tai yksittäiseksi toiminnoksi. Yksi OOD: n tavoitteista on käyttäytymisen jakaminen ja jakaminen moniin luokkiin ja moniin toimintoihin. ” – Ja sitten sanotaan joskus, että joskus on parempi käyttää jumalaluokat joskus (mainitaan esimerkkinä mikro-ohjaimet).
  4. Robert C Martinin ”Clean Code: Handbook of Agile Software Craftsmanship” ”sivu 136 (ja vain tämä sivu) puhuu” jumalaluokasta ”ja kutsuu sitä erinomaisena esimerkkinä” luokkien pitäisi olla pieniä ”-säännön rikkomisesta, jota hän käyttää yhden vastuun periaatteen edistämiseen” alkaen sivulta 138 .

Minulla on ongelma, että kaikki viittaukseni ja viittaukseni tulevat samalta henkilöltä (Robert C. Martin) ja olen yhdeltä ainoalta henkilöltä / lähteestä. Minulle kerrotaan, että koska hän on vain yksi näkemys, halu olla käyttämättä ”jumalaluokat” on pätemätön eikä sitä hyväksytä ohjelmistoteollisuuden vakiokäytännöksi. Onko tämä totta? Teinkö asioita teknisesti väärin yrittäen pysyä Bob-setän opetuksessa?

Jumala-objektit ja objekti-suuntautunut ohjelmointi ja suunnittelu:

Mitä enemmän ajattelen tätä, sitä enemmän luulen, että tämä on enemmän jotain, mitä opit opiskellessasi OOP: ta, eikä sitä ole koskaan nimenomaisesti kutsuttu; se on implisiittinen hyvään muotoilu on ajatteluni (korjaa minua vapaasti, kiitos, koska haluan oppia), ongelmana on, että ”tiedän” tämän, mutta en kaikki tiedä, joten tässä tapauksessa sitä ei pidetä pätevänä argumenttina, koska soitan tehokkaasti se yleisenä totuutena, vaikka itse asiassa useimmat ihmiset ovat tilastollisesti tietämättömiä siitä, koska tilastollisesti suurin osa ihmisistä ei ole ohjelmoijia.

Päätelmä:

Olen hämmentynyt siitä, mitä etsiä saadakseni parhaat lisätulokset, koska he tekevät teknisen vaatimuksen ja haluan tietää totuuden ja pystyä todistamaan sen viittauksilla kuin todellinen insinööri / tiedemies, vaikka olenkin puolueellinen jumalankohteita vastaan henkilökohtaisen kokemus koodista, joka käytti niitä. Kaikenlainen avunanto tai sitaatit ovat erittäin arvostettuja.

Kommentit

  • Pyydä heiltä dokumentaatio Jumalan esineistä hyväksi käytännöksi.
  • Juokse pois! Et halua ’ halua työskennellä siellä.
  • Määritä ymmärtämyksesi ” Jumalan objektista ” ja miten se liittyy kysymykseesi. Vietät 4 kappaletta sanomalla, että jumalaluokka ei ole kirjallisuudessa vakiotermi ’. Miksi sitten käytät sitä? Jos käytät alan standarditermejä ja pystyt osoittamaan, kuinka nämä käsitteet soveltuvat nykyiseen projektiisi, saatat vakuuttaa jotkut ihmiset mielipiteesi. Valmistettujen sanojen käyttäminen yrityskokouksessa vain heikentää argumenttiasi. Teollisuuden vakiotermejä on olemassa – et ole ’ et ensimmäinen henkilö, joka koskaan näkee kaiken globaalin tai yhden objektin painajaisen tai mitä yrität kuvata.
  • ’ puuttuu termi ” antipattern ”. Google-haun tekeminen ” jumala-objektin antipattern ” palauttaa tonnia sivuja syistä, miksi he ’ on huono.
  • Sinun ei pitäisi ’ hyökätä jumalakohteeseen, mutta sen aiheuttamiin ongelmiin. Kuten: meillä on erittäin tiukka kytkentä kaiken välillä ja muutos A: ssa edellyttää myös muutoksia B: ssä, C: ssä ja D: ssä. Joten auttaaksemme sitä, että ’ aiotaan purkaa luokkia. Tai: haluamme koodin olevan testauskehyksessä, emmekä voi ’ tehdä sitä, mitä aiomme tehdä? Yritä myös välttää termin ” Jumala ” käyttöä. Ihmiset, jotka eivät ole vastaanottavia, ajattelevat sinua ’ Hyperbolojen käyttäminen uudelleen.

Vastaus

Mahdolliset muutokset käytännössä tehdään tunnistamalla kipupisteet luoma nykyinen muotoilu. Erityisesti sinun on tunnistettava, mikä on nykyisen suunnittelun takia vaikeampi kuin sen pitäisi olla, mikä on hauras, mikä rikkoo nyt, mitä käyttäytymismalleja ei voida toteuttaa yksinkertaisella tavalla suorana (tai jopa jonkin verran epäsuorana) seurauksena nykyinen toteutus, tai joissakin tapauksissa, kuinka suorituskyky kärsii, kuinka paljon aikaa kuluu uuden tiimin jäsenen saamiseksi vauhtiin jne.

Toiseksi, toimiva koodi tuo kaikki argumentit teoriasta tai hyvästä suunnittelusta Tämä pätee valitettavasti myös huonoon koodiin. Joten joudut tarjoamaan paremman vaihtoehdon, mikä tarkoittaa, että sinun, parempien mallien ja käytäntöjen puolustajana, täytyy olla refactor kiusata parempaa suunnittelua. Löydä kapea, jäljitys-luodin tyyppinen taso nykyisen suunnittelun kautta ja toteuta ratkaisu, joka ehkä iteroinnille pitää jumalan objektin toteutuksen toimivana, mutta lykkää varsinaisen toteutuksen uudelle suunnittelulle. Kirjoita sitten koodi, joka hyödyntää tätä uutta muotoilua, ja näytä mitä voitat tämän muutoksen takia, olipa kyseessä sitten suorituskyky, ylläpidettävyys, ominaisuudet, virheiden tai kilpailuolosuhteiden korjaus tai kehittäjän kognitiivisen kuormituksen vähentäminen. / p>

Usein haasteena on löytää riittävän pieni pinta-ala hyökätä huonosti suunnitelluissa järjestelmissä, se voi viedä kauemmin kuin haluat antaa jonkin verran alkuarvoa, ja alkuperäinen voitto ei ehkä ole niin vaikuttava kaikille, mutta voit myös etsiä joitain uuden lähestymistavan puolestapuhujia, jos paritat sen ainakin tiukasti sympaattisten tiimin jäsenten kanssa.

Jumalaobjektin valitus toimii vain, kun saarnat uudelleen kuoro. Se on työkalu ongelman nimeämiseen ja toimii vain sen ratkaisemiseen, kun sinulla on vastaanottavainen yleisö, joka on vanhempi ja riittävän motivoitunut tekemään jotain asialle. Argumentin voittaa Jumalan objektin korjaaminen.

Koska välitön huolenaiheenne näyttää olevan johtajuuden osto, mielestäni on parasta tehdä tapaus, jonka mukaan tämän koodin korvaamisen on oltava strateginen tavoite ja sidottava ne liiketoiminnan tavoitteisiin, joista olet vastuussa. voi tehdä tapauksen, jossa voit antaa jonkin teknisen ohjauksen tekemällä ensin teknisen piikin siitä, mitä mielestäsi pitäisi tehdä sen korvaamiseksi, mieluiten ottamalla mukaan resursseja yhdeltä tai kahdelta tekniseltä henkilöltä, joilla on varauksia nykyiseen suunnitteluun.

Luulen, että olet löytänyt tarpeeksi resursseja argumenttisi perustelemiseksi; ihmiset tällaisissa kokouksissa kiinnittävät huomiota vain yhteenvetoon tutkimuksestasi, ja he lopettavat kuuntelun, kun mainitset kaksi tai kolme vahvistavaa lähdettä.Ensinnäkin sinun tulisi keskittyä ostamaan näkemäsi ongelma, ei välttämättä todistamaan jonkun toisen olevan väärässä tai itsessäsi oikeassa. Tämä on sosiaalinen ongelma, ei looginen.

Teknologiajohtajan roolissa sinun on sidottava kaikki aloitteet liiketoiminnan tavoitteisiin, joten tärkein asia tapauksen tekemisessä esimiehille on se, mitä työtä näiden tavoitteiden saavuttamiseksi. Koska sinua pidetään myös ”uudena kaverina”, et voi vain odottaa ihmisten heittävän pois työnsä tai odottavan nopeasti putoavan jonoon; sinun täytyy rakentaa luottamusta osoittamalla, että pystyt tuottamaan. Pitkän aikavälin huolenaiheena johtajaroolissa sinun on myös opittava keskittymään tuloksiin, mutta ei välttämättä ole kiinnittynyt lopputulokseen. Olet nyt antamassa strategista ohjausta, poistamalla taktiset esteet tiimisi etenemisestä ja tarjoamalla joukkueellesi mentorointia, etkä voita uskottavuuden taisteluja omien tiimisi jäsenten kanssa.

Ylhäältä alaspäin tekeminen tekee ole harvoin uskottava, ellei sinulla ole ihoa pelissä; jos olet samanlaisessa tilanteessa uudestaan, sinun tulisi keskittyä enemmän konsensuksen rakentamiseen organisaatiossasi pikemminkin kuin kärjistyäsi, kun tunnet tilanteen hallitsevan.

Mutta ottaen huomioon missä olet nyt, sanoisin, että paras veto on väittää, että lähestymistapasi tuo mitattavia pitkäaikaisia etuja kokemuksesi perusteella ja että se on sopusoinnussa tunnettujen ammattilaisten, kuten setä Bob ja hänen kanssaan, ja että haluat viettää muutaman päivän / viikon viemällä esimerkkiä kapean uudelleenrakentamisen korkeimmalle bang-for-buck -ominaisuudelle osoittaaksesi miltä näkemyksesi hyvän suunnittelun pitäisi näyttää. Sinun on kuitenkin sovitettava tapauksesi mukaan tiettyihin liiketoiminnan tavoitteisiin, jotka ylittävät henkilökohtaiset mieltymykset.

Kommentit

  • Hyvä asia siitä, että se on sosiaalinen ongelma. On oltava, miksi siellä on niin paljon huonoa kirjoitettua koodia ja huonosti suunniteltuja sovelluksia.
  • +1 sen sitomiseksi ’ business speak ’ sinänsä; pyri tekemään siitä mahdollisimman osuva yleisöllesi. Jos ’ puhut uudelleen avainhenkilöiden kanssa, tee puhu siitä, kuinka koodistandardilla on suora yhteys ylläpitoon ja suorituskykyyn, ja keskustele siitä, miten tämä liittyy projektin yleiseen talouteen, pitkän aikavälin vakauteen ja niin edelleen. Kuulostaa sinulta ’ on palkattu tietosi takia; muista tämä. (Älä vain tule ’ ei tule nykimättömäksi johtajaksi, joka ajattelee hän tietää aina parhaiten – mutta tässä tapauksessa ’ olet 100% oikea.)
  • +1 ” -käyttökoodille antaa kaikki argumentit teoriasta tai hyvästä suunnittelusta. ” Jotain, jonka usein unohdamme tehtävässämme täydellisen koodin saamiseksi.
  • Loistava vastaus, paljon viisautta hakeville joukkuejohtajille.

Vastaa

Ensinnäkin sinun on esitettävä, että kaikkien mitattavissa olevien organisaatioiden on omaksuttava alan parhaat käytännöt. Sanomalla, että ”se toimii vain meille!” ei voida mitata ajassa tai resurssissa, koska se on yksinkertaisesti arvaamatonta. Ohjelmistotuotanto on tiedettä yhtä paljon kuin muita tieteenaloja, ja näitä käsitteitä on tutkittu, tutkittu, testattu ja dokumentoitu.

  1. Jumalan objekti on anti-malli , joka sanoo, että

    Ohjelmistotuotannossa anti-malli (tai anti-malli) on yhteiskunnallisessa tai liiketoiminnassa tai ohjelmistotuotannossa käytetty malli, jota voidaan käyttää yleisesti, mutta joka on tehotonta ja / tai käytännössä haitallista.

  2. Google IO -konferenssissa 2009 tämä aihe selitettiin osittain, kun MVP kuvio selitettiin. Sillä ei ehkä ole merkitystä Jumalan objektille, mutta se voi antaa sinulle jonkin verran ammuksia.

  3. Tämän anti-mallin käyttäminen rikkoo myös yksittäisen vastuun periaate objektisuuntautuneissa malleissa, joissa todetaan, että:

    kaikilla luokilla tulisi olla yksi vastuu, ja tämän vastuun tulisi olla luokan on oltava kokonaan kapseloitu. Kaikkien sen palveluiden tulee olla kapeasti yhdenmukaisia tämän vastuun kanssa.

  4. Decaying Code -blogissa puhutaan myös tästä ja sen ratkaisusta.

  5. Emme voi puhua yhden vastuun periaatteesta puhumatta objektista kytkentä .

    […] kytkentä tai riippuvuus on aste, johon kukin ohjelmamoduuli luottaa kumpaankin yksi muista moduuleista.

    Missä tiukasti kytketty järjestelmä voi aiheuttaa assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. Kohteen korkeampi taso tarkoittaa vähemmän yhteenkuuluvuutta ja päinvastoin. Jumalan esineet ovat hyvä esimerkki tiukasta kytkemisestä, koska he tietävät enemmän kuin pitäisi, joten ylikuormitetaan heitä vastuulla, mikä rajoittaa suuresti koodin uudelleenkäytettävyyttä.

  6. Suunnitellessasi monimutkaista sovellusta yksinkertaisuus täytyy tulla mieleen. Suuret ongelmat on hajotettava pienemmiksi, joita on helpompi hallita, testata ja dokumentoida. Tämä pätee erityisesti olio-suuntautuneessa paradigmassa.

    Tällä argumentilla palataan takaisin anti-pattern-argumenttiin, mutta tämä paradigma on kyse malleista, reaalimaailman esineiden esittämisestä ja viime kädessä tiedoista kapselointi.

  7. Olet oikeassa, kun sanot, että näitä ”hyviä käytäntöjä” on enemmän luokkahuoneissa. Minulla on kuitenkin opetuskokemuksia korkeakoulussa (ja joissakin yliopistoissa), ja näin näiden periaatteiden opettamisen vain yliopistoissa, erityisesti insinööritieteellisissä tiedekunnissa. Mikä on surullista. Mutta kuten mikä tahansa hyvä käytäntö, ne, jotka pyrkivät parantamaan itseään, yleensä oppivat joitain perustavanlaatuisia suunnittelumalleja ja lopulta ymmärtävät, kuinka viidakko kytkeytymisen ja yhteenkuuluvuuden välillä.

    Opetan yleensä opiskelijoille sen, että se saattaa tuntua vaativan enemmän ponnisteluja hyvien ohjelmointistandardien omaksumiseksi, mutta se maksaa aina pitkällä aikavälillä. Hyvä esimerkki olisi joku, joka pyytää ohjelmoijaa kirjoittamaan lajittelutoiminnon. Ohjelmoijalla on kaksi vaihtoehtoa; 1) kirjoita nopea kuplalajittelutoiminto (alle 5 minuuttia), joka ei ole kestävä elementtiluettelon kasvaessa, tai 2) kirjoita monimutkaisempi (alias optimoitu) lajittelualgoritmi (pikalajittelu jne.), Joka skaalautuu paremmin suuremmilla listoilla.

Kommentit

  • Objektikeskeiset ohjelmointikielet vaativat usein, että jos vastuussa on kaksi itsenäistä lähdekokoonpanoa objektin käyttäytymisen eri näkökohtien ’ käyttäytymisen kannalta on luotava itsenäisiä objektin instansseja kapseloimaan nämä käyttäytymismuodot. Valitettavasti, vaikka monissa tapauksissa toiminnallisuuden loogisimmat alajaot koodikokoonpanojen välillä eivät ole ’ t yhtäpitäviä toiminnallisuuden loogisimman alijaon kanssa objekti-ilmentymien välillä, olen I >

et ole nähnyt paljon keskustelua kahden tyyppisen jaon erottamisesta.

  • Uskon, että tämä on hieman aiheen ulkopuolella tässä kysymyksessä. ’ emme puhu tässä jumalankohteen anti-mallista, vaan koodikytkennästä ja yhteenkuuluvuudesta, joka on paljon laaja aihe ja erittäin subjektiivinen.

    • vastaus

    Voi tässä menen, erittelemme toisen vanhan kysymyksen, mutta aion arvata, ettet voittanut tätä argumenttia ja tässä miksi.

    Se kuulostaa kulttuuri-ongelmalta

    Sinä olet heidän johtaja, mutta et voi korvata heitä, ja sinun on mentävä esimiehesi luokse saadaksesi heidät tekemään sitä, mitä uskot heidän tekevän, mikä tässä tapauksessa on mielestäni ainakin pudottaa se pois jumalankohteiden liikkuessa eteenpäin. Minusta se kuulostaa klassiselta kooditapaukselta, joka heijastaa kulttuuria, jossa se syntyi. Toisin sanoen jumala on kohde, jolla tämä yritys toimii. Haluatko tehdä minkäänlaisen mielekkään muutoksen? Oletko menossa aina samaan paikkaan sen puolesta viime kädessä, koska kaikki päätökset on ilmeisesti poistettava ylhäältä.

    Olen ollut s kilpailu useisiin epäonnistuneisiin yrityksiin perinnöllisistä koodinpuhdistuksista ja koodikäytäntömuutoksista Olen nyt sitä mieltä, että et voi taistella kulttuuria vastaan, joka mahdollisti koodin, kun kyseinen kulttuuri on edelleen tiukasti vakiintunut tai ainakin taistelukulttuuri on erittäin kova ylämäkeen aiheuttama iskulause, että on epätodennäköistä, että kukaan voisi koskaan maksaa minulle tarpeeksi tai antaa minulle tarpeeksi voimaa tuntea, että se oli kannattava pyrkimys, joka todennäköisesti onnistuisi koskaan uudelleen.

    Ennen kuin muutosta voi tapahtua, heidän täytyy olla motivoituneita vaihtamaan, ja valitettavasti ohjelmoijina, jotka antavat tarpeeksi pirun lukemaan Stackia toisinaan, on vaikea ymmärtää, että kaikkia ei motivoi samat asiat. Olen voittanut paljon järkeviä argumentteja kokemuksissani, mutta päivän päätteeksi yritys kärsii älyllisesti laiskasta kehitystä syystä.

    Ehkä liiketoiminnalliset huolenaiheet ovat motivoituneet ajattelemaan vain huomenna eikä ensi viikolla tai viiden vuoden kuluttua (erityisen turhauttava skenaario, kun ”olet maahanmuuttajien lapsi maasta, joka rakensi arktisen alueen siemenholvin maailmanlopun sattuessa). Ehkä he pelkäävät muutosta.Ehkä he arvostavat ikäaikaa liian paljon siihen pisteeseen asti, että komentoketju on merkityksetön, vaikka heidän on palkattava ulkopuolelta tuomaan kehitystiimin johtaja tai johtaja, koska he tunnistavat, ettei kukaan heidän koko eliniänsä tiimissään ole kasvanut riittävän aikanaan siellä (tai koska mainitut elinaikana olevat henkilöt eivät halua vastuuseen liittyvää riskiä). Tai, ja ”olen nähnyt tämän, ehkä se on todella todellinen ja masentava ilmiö, että keskinkertaisuus puolustaa itseään, koska se tietää sisimmässään, että voi” Älä kilpaile laadun kanssa ja kun on tarpeeksi lapsilukua sen kiertämiseen, on mahdotonta selvittää, kuka syyttää, kun kaikki menee säännöllisesti palasiksi.

    Kuinka taistelet asioita, jotka juurtuvat viime kädessä pelkoon tai rikkinäiset mittarit menestykseen? Sanon tämän, se vie paljon enemmän kuin edes sitoutunut laadukas kehitystiimi, ja sinulla oli paljon vähemmän kuin sen äänen, joka kuului tämän Q: n julkaisuhetkellä.

    Tapahtumassa, joka ei ole mahdoton, että se ei ole ratkomaton kulttuuriongelma …

    Oletetaan nyt, että ihmiset ovat huipulla ovat erittäin alttiita muutoksille, ja he ovat todella halukkaita luottamaan sinuun, jotta saavutat sen, sinun tarvitsee vain erottaa kaikki argumenttisi rahalla ja menetetyillä mahdollisuuksilla.

    Joka kerta, kun jonkun kouluttaminen kestää kauemmin Uutta tässä naurettavassa koodikannassa, joka kerta, kun uuden ominaisuuden muokkaaminen tai lisääminen kestää kauemmin, joka kerta on äärettömän vaikeaa paljastaa päätepisteitä toiselle järjestelmälle yritykseltä, jonka kanssa haluat olla kumppanina, se maksaa rahaa. Paljon Tärkeintä on, että se jättää ikkunan auki pienemmälle ketterämmälle kilpailijalle hyppäämään, asettamaan sinut tilanteeseen, jossa voit tehdä vain reagoida niihin liian slo siepata kaikki lopulta itseltäsi.

    Huomaa vain, että erityisen itsepäinen ja tyhmä kulttuuri ylläpitää vallitsevaa tilaa hinnalla millä hyvänsä, vaikka yrityksen todellinen fyysinen katto olisikin tulessa, koska

    Kommentit

    • Poistuin yrityksestä pian sen jälkeen. he yrittivät palkata minut kokopäiväisesti ja saada minut muuttamaan New Yorkiin Seattlesta hyväksymään tarjouksen; Sanoin heille periaatteessa ” Ei, en aio ’ aio muuttaa NY: hen, kun johtamani joukkue on Bellevue, WA ” ja siinä vaiheessa kävelin periaatteessa kadun toisella puolella ja sain työpaikan MSFT: ssä, kunnes löysin jotain parempaa.
    • @honestduane Joo, tuo joukko odotuksia yksin puhuu paljon. Hyvä sinulle GTFO: ssa.

    Vastaa

    Voisit mainita joitain OOP: n perusperiaatteita, kuten löysä kytkentä ja korkea koheesio. ”Jumala-esine” kuulostaa siltä, että se yhdistää etuyhteydettömät luokat ja jolla on heikko yhteenkuuluvuus.

    Vastaa

    Voit aina kysyä Bob-setältä itseltään .

    Asia on, että se on niin itsestään selvää ihmisille, että kun se on kirjoitettu, monien kirjoittajien ei tarvitse viitata siihen uudelleen. Tarvitaan vain yksi lähde.

    Muita termejä, joista kannattaa aloittaa lähteitä etsittäessä, ovat:

    • SOLID
    • Demeterin laki
    • Iso mutapallo

    Kaikki nämä ilmaisevat toisiinsa liittyviä käsitteitä, jotka saattavat tuottaa elinkelpoisia viitelähteitä, vaikka niitä ei itse asiassa nimetä sellaisiksi.

    Viime kädessä tosin olet pomo. Syy tehdä se johtuu siitä, että sanot niin, ja vaikka sinua pidettäisiin hyvänä johtajana, sinun pitäisi todella olla valmis perustelemaan päätöksesi; olet tehnyt niin, ja jos vielä on vastarintaa, oikea toimintatapa on tiimisi tehtävä niin kuin heille sanotaan.

    Kommentit

    • ” jos vastarintaa on edelleen, tiimisi on toimittava oikein, kuten he ’ kertovat ” Ehkä oikea toimintatapa on lopettaa pikemminkin kuin tehdä joukkueestasi kurja ..?
    • Johtaja ’ s päätös on ollut riittävän perusteltu, ja jos joukkue ei ole ’ samaa mieltä, ongelma on tiimissä. Operaattori palkattiin hänen asiantuntemuksestaan eikä hänelle annettu lupaa käyttää sitä yrityksen hyödyksi, koska kollegat eivät voittaneet ’ t käyttäytyvän kohtuullisesti ei ’ t hyväksyttävä. Anna ’ s kääntää väitteesi päähän – miksi ’ ei vastustuskykyisten tiimin jäsenten pitäisi lopettaa, jos heidän näkemyksensä työstä ei ole yhteensopiva yrityksen asia?
    • Kohtuullinen asia. Se riippuu siitä, miten haluat johtaa joukkuetta. Mutta kokemukseni mukaan ihmisten pakottaminen tekemään asioita vastoin tahtoaan johtaa vain kurjuuteen. Haluaisin mieluummin nähdä Jumalan objektit koko koodipohjassa kuin kurja kehitystiimi. Ehkä vastaus on lähettää heidät kurssille. Kaikki rakastavat koulutusta. Win-win.
    • Johtavan kehittäjän / esimiehen / minkä tahansa tulee ehdottomasti toteuttaa kaikki kohtuulliset toimenpiteet varmistaakseen, että tiimillä on hyvät työsuhteet keskenään. Jos lisäkoulutuksesta on apua, pidä sitä kaikin keinoin vaihtoehtona – mutta tämä näyttää olevan tahallisen tietämättömyyden tapaus ja kertoa jollekin, että heidät on koulutettava ymmärtämään ideasi, kun heidän mielestään ’ olet tehnyt, on eri mieltä kuin ei ymmärrä, se voi palata. Minulla on vaikea kuvitella tapoja käsitellä ihmisiä, jotka eivät halua ’ halua oppia.

    Vastaa

    Kuinka voin todistaa tai kumota ”jumala” -objektit ovat väärässä?

    Et voi.

    Tällainen oletus ei sovellu matemaattiseen todistukseen, ja matemaattinen todiste on ainoa todiste, joka on hyvä.

    Vaikka yrität korvata tunnesanan ”väärä” kvantitatiivisesti mitattavilla jumalankohteiden käytön vaikutuksilla huomaat, että:

    1. käytettävissä olevat mittayksiköt ovat raakoja,
    2. on olemassa muutamia uskottavia tutkimuksia, joissa nämä mitat on määritetty ammattimaisten ohjelmoijien tuottamalle koodille
    3. on olemassa vain vähän, joskaan uskottavia tutkimuksia, joissa kielirakenteet tai suunnittelu (anti) mallit on sidottu näihin toimenpiteisiin.

    Ja että jättää huomiotta kysymyksen siitä, milloin tietty esine on ”jumala” -objekti.

    Parhaimmillaan tällaiset tutkimukset voisivat osoittaa vain empiirisen korrelaation. Ei aito todiste.

    Se, mitä todella teet, on keskustelu jumala-esineiden eduista ja haitoista muiden ihmisten mielipiteiden muuttamiseksi. … ja sitten organisaatiosi harjoittelu.

    Älä käytä sanoja, kuten ”todiste”, tai ihmiset, joiden kanssa keskustelet, voivat nauraa kasvoillesi.

    vastaus

    Saatat haluta nähdä viikon gurun # 84 . Kaikki koskee jumalankohteita (monoliitteja) ja kuinka ne ovat huonoja.

    Ote:

    (majuri) Se eristää mahdollisesti itsenäinen toiminnallisuus luokan sisällä […] (vähäinen) Se voi estää luokan laajentamisen uusilla toiminnoilla […]

    Vastaa

    En ole varma, onko tiimisi todella kiinnostunut akateemisesta näytöstä, jonka mukaan ”Jumala vastustaa väärää”.

    Psykologisesta näkökulmasta refraktoiva häpeäsi voidaan ymmärtää väärin hyökkäämällä joukkueen osaamiseen a la: ”joukkue on tehnyt huonoa työtä”, vaikka ohjelma toimii odotetulla tavalla.

    Mitä todella haluat tehdä, on selviytyä ”spagettikoodin” ja ”Jumalan esineiden” kielteisistä sivuvaikutuksista: räjähtävät kustannukset uusien ominaisuuksien lisäämiseksi sivuvaikutusten aiheuttamien vikojen lisääntymisen vuoksi.

    Beeing very erityiset kysymykset ja kysymysten esittäminen vastausten antamisen sijaan voivat olla hyödyllisiä: 

    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

    Vastaa

    Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *