A probléma összefoglalása:

Hosszú történet, örököltem egy kódbázist és egy fejlesztőcsapatot, amelyet nem szabad cserélnem, és az Isten objektumok használata nagy kérdés. Továbbra is szeretném, ha újrateremtenénk a dolgokat, de visszaszorulok azoktól a csapatoktól, akik mindent meg akarnak csinálni az Isten Objektumokkal “, mert ez könnyebb”, és ez azt jelenti, hogy nem engedhetnék át faktort. Éveken át tartó fejlesztési tapasztalatomra hivatkozva visszaszorítottam, hogy én vagyok az új főnök, akit felkértek, hogy ismerje ezeket a dolgokat, stb., És ezt tette a harmadik fél offshore cégeinek is az értékesítési képviselője, és ez most az ügyvezetői szinten van holnap van, és rengeteg technikai lőszerrel szeretnék bemenni a bevált gyakorlatok támogatására, mert úgy érzem, hogy hosszú távon olcsóbb lesz (és személy szerint úgy érzem, hogy ez a harmadik fél aggódik) a vállalat számára.

A kérdésem technikai szintről származik, tudom, hogy jó hosszú távon, de az ultra rövid távú és a 6 hónapos futamidővel vannak problémáim, és bár valami olyasmi, amit “tudok” nem tudok bizonyítani egy személyen kívüli hivatkozások és idézett források (Robert C. Martin, más néven Bob bácsi), mivel ezt kérik tőlem, mivel azt mondták, hogy egy személytől rendelkezem adatokkal, és csak egy személy (Robert C Martin) Elég jó érv.

Kérdés:

Mik azok Azok a források, amelyeket közvetlenül idézhetek (cím, közzétett év, oldalszám, idézet) a szakterület jól ismert szakértői részéről, akik kifejezetten azt mondják, hogy az “Isten” tárgyak / osztályok / rendszerek használata rossz (vagy jó, mivel a technikailag legmegfelelőbb megoldás)?

Már elvégzett kutatás:

  1. Számos könyvem van itt, és keresgéltem az indexeikben az “isten tárgy” és az “isten osztály” szavak használatát. Megállapítottam, hogy furcsa módon szinte soha nem használták, és például a GoF könyv példánya soha nem használja (legalábbis az előttem lévő index szerint), de az alábbi két könyvben megtaláltam, de többet akarok Használhatom.
  2. Megnéztem a Wikipedia oldalon az “Isten objektumot” , és jelenleg csonkja van, kevés hivatkozási linkkel, így bár én személy szerint egyetértek azzal, hogy azt mondja, nem sokat használhatok olyan környezetben, ahol a személyes tapasztalat nem tekinthető érvényesnek. Az idézett könyvet szintén túl réginek tartják, hogy érvényesnek tartsák azok az emberek, akikkel érvként vitatom ezeket a technikai pontokat. azt állítják, hogy “valaha azt gondolták, hogy rossz, de senki sem tudta bizonyítani, és most a modern szoftver azt mondja, hogy az” isten “tárgyakat jó használni.” Én személy szerint úgy vélem, hogy ez az állítás helytelen, de igazolni akarom bármi is legyen.
  3. Robert C Martin “Agile Principles, Patterns and Practices in C #” című könyvében (ISBN: 0-13-185725-8, keménytáblás) whe A 266. oldalon olvasható “Mindenki tudja, hogy az istenórák rossz ötlet. Nem akarjuk a rendszer összes intelligenciáját egyetlen objektumba vagy egyetlen funkcióba összpontosítani. Az OOD egyik célja a viselkedés felosztása és elosztása számos osztályba és sok funkcióba. ” – Aztán folytatja, hogy néha jobb, ha néha az Isten osztályait használjuk (a mikrovezérlőket említjük példaként).
  4. Robert C Martin “Clean Code: A kézikönyv az agilis szoftverek kivitelezéséhez” című cikkében. “136. oldal (és csak ez az oldal) az” Isten osztályáról “beszél, és kiemelkedő példaként hívja fel az” Egy osztálynak legyen kicsi “szabály megsértését, amelyet az Egységes Felelősség Elvének népszerűsítésére használ”, a 138. oldalon kezdve. .

A problémám az, hogy az összes hivatkozásom és idézetem ugyanattól a személytől származik (Robert C. Martin), és ugyanazon egyedülálló személytől / forrásból származik. Azt mondják nekem, hogy mivel ő csak egy nézet, a vágyam, hogy ne használjam az “Isten osztályait”, érvénytelen, és nem fogadom el a szoftveripar bevált gyakorlatának. Igaz ez? Műszakilag rosszul csinálom a dolgokat azzal, hogy megpróbálok betartani Bob bácsi tanítását?

Isten objektumok és tárgyorientált programozás és tervezés:

Minél jobban gondolkodom ezen, annál inkább azt gondolom, hogy ez inkább olyan dolog, amit megtanulsz, amikor OOP-t tanulsz, és soha nem hívják ki kifejezetten; implicit jó a tervezés az én gondolkodásom (bátran javítson ki, kérem, kérem, mivel szeretnék megtanulni), a probléma az, hogy ezt “tudom”, de nem mindenki tudja, ezért ebben az esetben ez nem tekinthető érvényes érvnek, mert tényleg felhívom egyetemes igazságként, bár valójában a legtöbb ember statisztikailag nem tud róla, mivel statisztikailag a legtöbb ember nem programozó.

Következtetés:

Tanácstalan vagyok a keresésre hogy a lehető legjobb kiegészítő eredményeket idézzem, mivel technikai igényt támasztanak, és szeretném megismerni az igazságot, és idézetekkel igazolni tudnám, mint egy igazi mérnök / tudós, még akkor is, ha az én személyes adataim miatt elfogult vagyok az isten tárgyai ellen. tapasztalat az őket használó kóddal kapcsolatban. Bármilyen segítséget vagy idézetet nagyon értékelnénk.

Megjegyzések

  • Kérje tőlük az Isten tárgyainak helyes gyakorlatként történő dokumentálását.
  • Elfutni! Nem akarsz ‘ ott dolgozni.
  • Kérjük, adja meg az ” Isten objektum ” és hogyan kapcsolódik a kérdéséhez. 4 bekezdést töltesz azzal, hogy az Isten osztálya nem ‘ t az irodalomban szokásos kifejezés. Akkor miért használja? Ha iparági szabványos kifejezéseket használ, és megmutatja, hogy ezek a fogalmak hogyan vonatkoznak a jelenlegi projektjére, akkor meggyőzhet néhány embert a véleményéről. Kitalált szavak használata üzleti megbeszélésen csak aláássa az érvelését. Iparági szabványok léteznek – nem ‘ nem az első ember, aki valaha látott egy mindent globális vagy egy tárgyú rémálmat, vagy bármit, amit le akarsz írni.
  • ‘ hiányzik a ” antipattern ” kifejezés. Ha Google-keresést végez a ” istenobjektum antipattern ” tonna oldalról ad vissza olyan okokat, amelyek miatt ‘ rossz.
  • Nem ‘ nem az istenobjektumot kell támadnia, hanem az általa létrehozott problémákat. Tetszik: nagyon szoros összekapcsolódás van mindenünk között, és az A változásához B, C és D változásokra is szükség van. Tehát, hogy ez ellen segítsünk, ‘ osztályokat fogunk kibontani. Vagy: azt akarjuk, hogy a kód egy tesztelési keretrendszerben legyen, és ‘ nem tehetjük meg, mit fogunk csinálni? Ne felejtse el használni az ” Isten ” kifejezést is, mert a nem fogékony emberek azt gondolják, hogy ‘ hiperbolusok használata.

Válasz

A gyakorlat bármilyen változásának oka a fájdalompontok azonosítása. a meglévő kialakítás hozta létre. Pontosabban meg kell határoznia, hogy mi a létező kialakítás miatt nehezebb, mint kellene, mi a törékeny, mi törik most, milyen magatartásformák nem valósíthatók meg egyszerű módon a (vagy akár kissé közvetett) eredményeként. a jelenlegi megvalósítás, vagy bizonyos esetekben hogyan szenved a teljesítmény, mennyi időbe telik az új csapattag felgyorsítása stb.

Másodszor, a működő kód megdönti az érveket az elméletről vagy a jó tervezésről. Ez sajnos még a rossz kódokra is igaz. Tehát jobb alternatívát kell nyújtania, ami azt jelenti, hogy Önnek, mint a jobb minták és gyakorlatok szószólójának, refrakternek kell lennie, hogy jobb dizájnt ugrasson. Keressen egy keskeny, nyomjelző stílusú síkot a meglévő kialakításon keresztül, és valósítson meg egy olyan megoldást, amely talán az iterációhoz megtartja az istenobjektum megvalósítását, de a tényleges megvalósítást elhalasztja az új tervnél. Ezután írjon egy kódot, amely kihasználja ezt az új dizájnt, és mutassa meg, mit nyer a változás miatt, legyen szó teljesítményről, karbantarthatóságról, funkciókról, hibák vagy versenyfeltételek javításáról, vagy a fejlesztő kognitív terhelésének csökkentéséről.

Gyakran kihívást jelent egy elég kicsi felület megtalálása a támadásokhoz rosszul felépített rendszerekben, több időbe telhet, mint amennyit Ön valamilyen kezdeti értéket szeretne elérni, és a kezdeti kifizetés nem biztos, hogy olyan lenyűgöző mindenkinek, de azon is dolgozhat, hogy megtalálja új megközelítésének híveit, ha párosul vele legalább enyhén szimpatikus csapattagokkal.

Az Isten objektum siránkozása csak akkor működik, ha újra prédikál a kórus. Ez egy probléma megnevezésére szolgáló eszköz, és csak akkor működik, ha megoldást talál, ha van egy befogadó közönsége, amely idősebb és elég motivált ahhoz, hogy tegyen valamit. Az Isten objektum javítása megnyeri az érvet.

Mivel úgy tűnik, hogy azonnali aggodalmad a vezetői felvásárlás miatt van, úgy gondolom, hogy az a legjobb, ha azt állítja, hogy a kód cseréjének stratégiai célnak kell lennie, és azokat az üzleti célokhoz kell kötnie, amelyekért Ön felelős. olyan esetet hozhat létre, amely valamilyen technikai irányt adhat, ha először kidolgoz egy technikai csúcsot azon, hogy mit gondol, mit kell tennie annak pótlására, lehetőleg egy vagy két olyan szakember erőforrásait bevonva, akiknek fenntartása van a jelenlegi kialakítással kapcsolatban.

Úgy gondolom, hogy elegendő forrást talált az érvelés igazolására; az ilyen találkozókon résztvevők csak a kutatás összefoglalására figyelnek, és nem hallgatnak meg, miután megemlít két vagy három megerősítő forrást.Kezdetben arra kell összpontosítania, hogy megvásárolja a problémát, amelyet lát, és nem feltétlenül bizonyítja, hogy valaki más téved, vagy Önnek igaza van. Ez társadalmi probléma, nem logikus.

A technológiai vezetői szerepkörben bármelyik kezdeményezését üzleti célokhoz kell kötnie, ezért az a legfontosabb, hogy ügyét a vezetőkhöz tegye. a célok érdekében végzett munka. Mivel Ön “új srácnak” is számít, nem várhatja el, hogy az emberek eldobják a munkájukat, vagy arra számíthatnak, hogy gyorsan sorba esnek; bizonyos bizalmat kell kiépítenie annak bizonyításával, hogy képes teljesíteni. Hosszú távon aggodalomra ad okot, hogy vezetői szerepkörben meg kell tanulnia arra is, hogy az eredményekre koncentráljon, de nem feltétlenül ragaszkodik az eredmény sajátosságaihoz. Most stratégiai iránymutatást nyújt, eltávolítja a taktikai akadályokat a csapat előrehaladásától, és mentort kínál a csapatnak, és nem nyer hitelességi csatákat saját csapattagjaival.

Felülről lefelé történő döntés meghozatala ritkán legyél hiteles, kivéve, ha van némi bőröd a játékban; ha újra hasonló helyzetben vagy, akkor inkább a konszenzus kialakítására kell koncentrálnod a szervezeteden, nem pedig fokozódnod, ha úgy érzed, hogy a helyzet nincs kontroll alatt.

De ha figyelembe vesszük, hogy hol tart most, azt mondanám, hogy a legjobb megoldás az, ha azt állítja, hogy megközelítése mérhető hosszú távú előnyöket hoz a tapasztalatai alapján, és hogy ez összhangban áll olyan ismert szakemberek munkájával, mint például Bob bácsi és társai, és hogy néhány napot / hetet szeretne eltölteni példamutatással a legmagasabb bumm-for-buck szempont szűk refaktorálásával, hogy bemutassa, hogyan kell kinéznie a jó design véleményének. Bármely esetét is össze kell hangolnia a személyes preferenciáin túlmutató konkrét üzleti célokkal.

Megjegyzések

  • Jó pont, hogy ez társadalmi probléma. Biztos ezért van olyan sok rossz írott kód és rosszul megtervezett alkalmazás.
  • +1, ha összekapcsolja a ‘ business speak ‘ mint olyan; törekedjen arra, hogy minél relevánsabb legyen a közönsége számára. Ha ‘ beszél a vezetőkkel, akkor tegye beszéljen arról, hogy a kód szabványának közvetlen kapcsolata van-e a karbantartással és a teljesítménnyel, és beszélje meg, hogyan kapcsolódik ez a projekt általános pénzügyeihez, hosszú távú stabilitásához és így tovább. Úgy hangzik, mint te ‘ vettek fel a tudásod miatt; ne feledd ezt. (Csak ne ‘ ne legyél kijutó menedzser, aki úgy gondolja mindig ő tudja a legjobban – de ebben az esetben Ön ‘ 100% -ban helytálló.)
  • +1 a ” működő kódhoz minden érvet felvet az elméletről vagy a jó tervezésről. ” Valami, amit gyakran elfelejtünk küldetésünk során a tökéletes kódért.
  • Remek válasz, sok bölcsesség benne a törekvő csapatvezetők számára.

Válasz

Először be kell mutatnia, hogy minden mérhető szervezetnek alkalmaznia kell az iparág legjobb gyakorlatait. Mondván, hogy “ez csak nekünk működik!” nem mérhető sem időben, sem erőforrásban, mivel egyszerűen kiszámíthatatlan. A szoftvertervezés ugyanúgy tudomány, mint bármely más tudományterület, és ezeket a fogalmakat tanulmányozták, kutatták, tesztelték és dokumentálták.

  1. a Isten objektum egy anti-minta , amely kijelenti, hogy

    A szoftverfejlesztésben az anti-minta (vagy anti-minta) a társadalmi vagy üzleti műveletekben vagy szoftverfejlesztésben használt minta, amelyet gyakran használnak, de a gyakorlatban hatástalan és / vagy kontraproduktív.

  2. A Google IO 2009. évi konferenciáján ezt a témát részben megmagyarázták, amikor az MVP mintát magyarázták. Lehet, hogy nem releváns az Isten objektum szempontjából, de adhat némi lőszert.

  3. Ezen anti-minta használata megsérti a egyetlen felelősség elve objektum-orientált tervezésnél, amely kimondja, hogy:

    minden osztálynak egyetlen felelősséggel kell rendelkeznie, és ezt a felelősséget teljesen be kell zárnia az osztályba. Minden szolgáltatásának szűken illeszkednie kell ehhez a felelősséghez.

  4. A A Decaying Code blog erről és annak megoldásáról is beszél.

  5. Nem beszélhetünk az egyetlen felelősség elvéről anélkül, hogy objektumról beszélnénk csatolás .

    […] csatolás vagy függőség az a mérték, amelyen az egyes programmodulok mindegyikre támaszkodnak az egyik másik modul.

    Ahol szorosan összekapcsolt rendszer okozhat assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency. A magasabb szintű objektumkupolás kevesebb kohéziót jelent, és oda-vissza. Isten objektumai jó példa a szoros összekapcsolásra, mivel többet tudnak, mint kellene, ezáltal túlterhelik őket felelősséggel, és ezáltal nagymértékben korlátozzák a kód újrafelhasználhatóságát.

  6. Egy komplex alkalmazás megtervezésekor egyszerűségnek eszébe kell jutnia. A nagy problémákat kisebbekre kell bontani, amelyeket könnyebb kezelni, tesztelni és dokumentálni. Ez különösen igaz egy objektumorientált paradigmában.

    Ezzel az érveléssel visszavezetünk az anti-pattern érvre, de ez a paradigma a mintákról, a valós objektum-ábrázolásról és végső soron az adatokról szól. beágyazás.

  7. Önnek igaza van, amikor azt mondja, hogy ezek a “jó gyakorlatok” inkább az osztálytermekben vannak. Ugyanakkor van tanítási tapasztalatom az egyetemen (és néhány egyetemen), és ezeket az elveket csak az egyetemeken láttam tanítani, különösen a mérnöki karokon. Ami szomorú. De mint minden bevált gyakorlat, azok is, akik maguk igyekeznek jobbak lenni, általában megtanulnak néhány alap tervezési mintát , és végül megértik, hogy miként lehet átjutni a kapcsolás és a kohézió között.

    Amit általában tanítok a hallgatóknak, úgy tűnik, hogy úgy tűnik, hogy több erőfeszítést igényel a jó programozási szabványok elfogadása, de hosszú távon mindig megtérül. Jó példa arra, ha valaki programozót kér fel egy rendezési függvény megírására. A programozónak két választási lehetősége van; 1) írjon egy gyors buborék rendezési funkciót (kevesebb, mint 5 perc), amely nem lesz fenntartható az elemek listájának növekedésével, vagy 2) írjon egy összetettebb (más néven optimalizált) rendezési algoritmust (gyors rendezés stb.), Amely jobban méretezhető nagyobb listákkal.

Megjegyzések

  • Az objektumorientált programozási nyelvek gyakran megkövetelik, hogy ha két független forráscsoport felelős Az objektum ‘ viselkedésének különböző aspektusaihoz független objektum-példányokat kell létrehozni, hogy beilleszkedjenek ezekbe a viselkedésekbe. Sajnos, annak ellenére, hogy sok esetben a funkcionalitás leglogikusabb felosztása a kódegyüttesek között nem esik egybe a funkcionalitás leglogikusabb felosztásával az objektumpéldányok között, I ‘ még nem láttam sok vitát a kétféle felosztás megkülönböztetéséről.
  • Úgy gondolom, hogy ez egy kicsit nem témakör ehhez a kérdéshez. ‘ itt nem az Isten objektum anti-mintázatáról beszélünk, hanem a kód-összekapcsolásról és a kohézióról, ami sokkal tágabb téma és nagyon szubjektív.

Válasz

Ó, tessék, elidézek egy másik régi kérdést, de azt hiszem, nem fogtad megnyerni ezt az érvet, és itt miért.

Kultúrproblémának hangzik

Önnek van menedzser, de nem tudja őket helyettesíteni, és a menedzsereihez kell mennie ahhoz, hogy rávegye őket arra, amit ön szerint meg kellene tenniük, ami ebben az esetben feltételezem, hogy legalább leüt az isten tárgyakkal, amelyek előre haladnak. Nekem úgy hangzik, mint egy klasszikus kódeset, amely tükrözi azt a kultúrát, amelyben született. Más szavakkal, az isten célja, hogy hogyan működik ez a társaság. Szeretne bármilyen értelmes változtatást végrehajtani? Mindig ugyanoda megy, ezért végső soron mivel minden döntést nyilvánvalóan felül kell tisztázni.

Miután p A régi kódtisztítások és a kódpolitika megváltoztatásának több sikertelen kísérlete miatt most azon a véleményen vagyok, hogy nem lehet harcolni a kultúrával, amely a kódot lehetővé tette, amikor ez a kultúra még mindig szilárdan be van építve, vagy legalábbis a harci kultúra nagyon nehéz felfelé irányuló szlogen, hogy valószínűtlen, hogy bárki is tudna nekem valaha fizetni elegendő mennyiséget vagy elegendő erőt ahhoz, hogy úgy érezzem, ez egy olyan erőfeszítés, amely valószínűleg mindig is sikeres lesz.

Mielőtt változások történhetnek, motiválni kell őket a változásra, és sajnos olyan programozókként, akik elég rohadtul adják a Stack alkalmi elolvasását, nehéz megértenünk, hogy nem mindenkit ugyanazok a dolgok motiválnak. Rengeteg racionális érvet nyertem tapasztalataim során, de a nap végén a vállalat okkal intellektuálisan lusta dev-okat szenved.

Talán az üzleti aggályokat arra ösztönözték, hogy inkább csak a holnapra gondoljanak, mintsem a következő héten vagy öt éven belül (különösen frusztráló forgatókönyv, amikor “egy olyan országból érkező bevándorlók gyermeke vagy, amely apokalipszis esetén magboltot épített az Északi-sarkvidéken). Talán félnek a változástól.Talán túlságosan nagyra értékelik az időskort annyiban, hogy a parancsnoki lánc értelmetlen, még akkor is, ha kívülről kell bérelniük egy dev-csapat vezetőjének vagy menedzserének behozatalát, mert felismerik, hogy senki az egész életében élő csapatukban nem nőtt eleget az idejében vagy (mert az említett életfogytiglanok nem akarják a felelősséggel járó kockázatot). Vagy, és láttam ezt, talán ez a valóságos és nyomasztó jelenség, amikor a középszerűség harcolja önmagát, mert belülről tudja, hogy képes ” Nem versenyezhet a minõséggel, és ha van elegendõ szûkösség a megkerülésére, lehetetlen kitalálni, hogy ki a hibás, amikor minden rendszeresen darabokra megy.

Hogyan küzdesz meg olyan kérdésekkel, amelyek végeredményben félelemben vagy gyökerekben gyökereznek törött mutatók a sikerhez? Ezt elmondom neked, sokkal több kell, mint egy elkötelezett minőségi fejlesztő csapat, és ennél sokkal kevesebb volt a hangból, mint amilyennek ezt a Q-t közzétették.

A lehetetlen eseményben, hogy ez nem megoldhatatlan kulturális probléma …

Most az embereket feltételezem a tetején nagyon fogékonyak a változásokra, és valóban hajlandók bízni benned abban, hogy sikerüljön, akkor tényleg csak az összes érvedet kell pénzzel és elveszett lehetőségekkel szétválasztanod.

Minden alkalommal, amikor valakinek tovább tart a kiképzése Új a nevetséges kódbázisban, valahányszor hosszabb időre van szükség valamilyen új szolgáltatás módosításához vagy hozzáadásához, minden alkalommal, amikor túlzottan nehézzé válik a végpontok kitétele egy másik rendszer számára egy olyan társaságtól, amellyel partneri kapcsolatban akar lenni, pénzbe kerül. A legfontosabb, hogy nyitva hagy egy ablakot egy kisebb, mozgékonyabb versenytárs számára, hogy bepattanjon, és olyan helyzetbe hozza, ahol csak annyit tehet, hogy túl gyorsan reagál rájuk. wly, és végül ragadja el magától mindent.

Csak ismerje fel, hogy egy különösen makacs és ostoba kultúra mindenáron fenntartja a jelenlegi helyzetet, még akkor is, ha a vállalat tényleges fizikai teteje valóban lángokban áll, mert

Megjegyzések

  • Nem sokkal később elhagytam a céget. megpróbáltak teljes munkaidőben foglalkoztatni, és Seattle-ből New Yorkba költözni, hogy elfogadják az ajánlatot; Alapvetően azt mondtam nekik, hogy ” Dehogyis, én ‘ nem fogok NY-ba költözni, amikor az általam irányítandó csapat Bellevue-ban van, WA ” és ekkor alapvetően az utca túloldalán jártam, és az MSFT-nél kaptam munkát, amíg nem találtam valami jobbat.
  • @honestduane Igen, ez az elvárások összessége egyedül beszél sokat. Jó neked a GTFO-n.

Válasz

Idézhetsz néhány legalapvetőbb OOP-t, mint pl. laza csatlakozás és nagy kohézió. Egy “Isten objektum” úgy hangzik, mintha összekapcsolná egymástól független osztályokat, és alacsony az összetartása.

Válasz

Mindig megkérdezheti magát Bob bácsit .

Az a helyzet, hogy olyan érzékeny az emberek számára, hogy bármilyen érzékkel rendelkezzenek, hogy ha egyszer megfogalmazzák, akkor nem kell többször hivatkozniuk a szerzők sokaságára. egy forrás.

További források keresésével érdemes kezdeni:

  • SZILÁRD
  • Demeter törvénye
  • Nagy sárlabda

Mindezek olyan kapcsolódó fogalmakat fejeznek ki, amelyek életképes referenciaforrásokat eredményezhetnek, annak ellenére, hogy valójában nem is nevezik így.

Végső soron bár te vagy a főnök. Ennek az az oka, hogy ezt mondod, és bár jó menedzsernek tekinthető, valóban fel kell készülnie arra, hogy igazolja döntéseit; ezt megtette, és ha még mindig van ellenállás, a helyes cselekvés az, ha a csapatod úgy cselekszik, ahogyan mondták neki.

Megjegyzések

  • ” ha még mindig van ellenállás, akkor a helyes cselekvési mód a csapata számára az, ha ‘ azt mondja ” Lehet, hogy a helyes cselekvés az, ha kilépsz, nem pedig nyomorulttá teszed a csapatodat ..?
  • A menedzser ‘ s a döntést megfelelően indokolták, és ha a csapat nem ért egyet ‘, akkor a probléma a csapattal van. Az OP-t szakértelmére alkalmazták, és nem engedték meg, hogy ezt az üzlet hasznára használja, mert a kollégák nem fogják div div

t ‘ t elfogadható. Hagyja, hogy ‘ s fején állítsa állítását – miért ne kellene ‘ t abbahagyni az ellenálló csapattagoknak, ha állásuk véleménye összeférhetetlen hogy a vállalkozásé?

  • Igazságos pont. Attól függ, hogyan akarja irányítani a csapatot. De tapasztalatom szerint az emberek arra kényszerítése, hogy akaratuk ellenére tegyenek dolgokat, csak nyomorúsághoz vezet. Inkább Isten objektumokat látnék az egész kódbázisban, mint egy nyomorult fejlesztőcsapatot. Talán a válasz az, hogy kiképzésre küldik őket. Mindenki szereti a tanfolyamot. Win-win.
  • A vezető fejlesztőnek / vezetőnek / bárkinek minden ésszerű intézkedést meg kell tennie annak biztosítása érdekében, hogy a csapat jó munkakapcsolatot tartson fenn egymással. Ha a kiegészítő képzés hasznos, akkor mindenképpen fontolja meg ezt opciónak – de ez úgy tűnik, mintha a szándékos tudatlanság esete lenne, és azt mondanánk valakinek, hogy ki kell képezni őket arra, hogy megértse ötletét, amikor azt gondolja, hogy ‘ megtörtént, hogy nem értek egyet, ahelyett, hogy nem értenék, visszaüthet. Nehezen tudom elképzelni, hogyan lehetne olyan emberekkel bánni, akik nem akarnak ‘ tanulni.

    • Válasz

    Hogyan igazolhatom vagy cáfolhatom az „isten” objektumokat?

    Nem lehet.

    Ez a fajta sejtés nem alkalmazható matematikai bizonyításra, és csak a matematikai bizonyítás a hangos.

    Még akkor is, ha megpróbálja helyettesíteni az érzelmi “rossz” szót az istenobjektumok használatának hatásainak számszerűsíthető mértékeivel a következőket találja:

    1. a rendelkezésre álló mértékek nyersek,
    2. kevés hiteles tanulmány létezik, ahol ezeket az intézkedéseket számszerűsítették volna a professzionális programozók által előállított kódokhoz
    3. kevés olyan hiteles tanulmány létezik, ahol nyelvi konstrukciókat vagy tervezési (anti) mintákat kötöttek ezekhez az intézkedésekhez.

    És ez figyelmen kívül hagyja annak eldöntését, hogy egy adott objektum mikor „isten” objektum.

    Legjobb esetben ezek a fajta tanulmányok csak empirikus összefüggést tudnak bizonyítani. Nem valódi bizonyíték.

    Az, amit valójában csinálsz, vitatkozik az “isten” tárgyak előnyeivel és hátrányaival más népek véleményének megváltoztatása céljából. … majd a szervezete gyakorlata.

    Ne használjon olyan szavakat, mint „igazolás”, vagy azok az emberek, akikkel vitatkozik, hajlamosak az arcába nevetni.

    Válasz

    Esetleg meglátogathatja a (z) 84. hét heti gurut . Minden az istenobjektumokról (monolitok) és azok rossz állapotáról szól.

    Kivonat:

    (őrnagy) Elkülöníti potenciálisan független funkcionalitás egy osztályon belül […] (kisebb) Ez visszatarthatja az osztály új funkciókkal történő bővítését […]

    Válasz

    Nem vagyok biztos benne, hogy a csapatát valóban érdekli-e az akadémikus, bizonyítja, hogy “Isten téved.”

    Pszichológiai szempontból a visszafogott szemrehányásod félreérthető, mivel a csapat kompetenciájának megtámadása a la: “a csapat rossz munkát végzett”, bár a program a várakozásoknak megfelelően működik.

    Amit igazán szeretne csinálni, az az, hogy megbirkózzon a “spagetti kód” és az “Isten tiltakozik” negatív mellékhatásokkal: az új funkciók hozzáadásával járó költségek felrobbanása a mellékhatások okozta növekvő hibák miatt.

    Nagyon méhelés A válaszadás helyett a konkrét és a kérdések feltevése hasznosabb lehet: 

    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

    Vélemény, hozzászólás?

    Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük