Több szakmai gyakorlat és az első munkahelyem során ugyanaz a probléma merült fel 3 különböző vállalatban. Tehát igen, ez meglehetősen gyakori.

Amit megtudhat, hogy megtanulja, hogyan működik minden, írja meg word vagy akár txt dokumentumokban, így rendelkezésére áll egy alapvető dokumentáció, amelyre mindig hivatkozhat, vagy ha valaki új megérkezik a társaságba, amit odaadhat neki, és kiegészíti azzal, amit szerinte hiányzik.

Ez segíthet az első dokumentáció elkészítésében ...

Úgy tűnik, hogy a többi válasz azon a véleményen van, hogy a "mélyen specifikus, dokumentálatlan keretrendszer" 1) problémás, 2) változtatni kell és 3) tenni kell valamit. Azt javaslom, hogy először azonosítsa, van-e egyáltalán probléma, és ha igen, mi ez a probléma.

Saját egyedi keretet írtak egyedi típusokkal, struktúrákkal és modellekkel.

Ennek oka lehet, hogy ez a keretrendszer lehetővé teszi a vállalat fejlesztőinek, hogy hatékonyan és eredményesen valósítsák meg a vállalat termékeit / megoldásait. Vagy előfordulhat, hogy nem itt találták ki.

Nem adott meg információt arról, hogy ezek közül melyik a valóság.

Kevés a dokumentáció hiánya.

Arra számítok, hogy a legtöbb szoftver, amelyet más fejlesztők nem használnak, beleértve a vállalati szoftverek túlnyomó részét, nem rendelkezik dokumentációval. Tehát önmagában ez egyáltalán nem meglepő.

A szoftvercsapat alapvetően 3 olyan fejlesztő, akik 10+ éve vannak itt, akik többnyire fejből ismerik a keretrendszert.

Működő szoftvereket és megoldásokat gyártanak? Ennyire hatékonyan csinálják?

Junior alkalmazott vagyok, 1-3 éves tapasztalattal. Állítólag felgyorsulok ezzel a keretrendszerrel.

Egyetértek azzal, hogy ez kihívást jelenthet.

A keret hatalmas, és eddig ez szinte lehetetlen bármit is fejleszteni, függetlenül a kisebb dolgoktól.

A "hatalmas" és a "nem önállóan" nem feltétlenül jár együtt. Egy olyan keretrendszert, amely sok kölcsönös függőséggel rendelkezik, gyakran nehéz kialakítani egy újonnan érkező számára, mert meg kell értenie az egészet, hogy ne törjön meg valami. Egy olyan projekten, amely jól szervezett olyan alapvető CS elvekkel, mint az egyedi felelősség, a kapszulázás, a meghatározott interfészhatárok, teljesen "függetlenül" lehet dolgozni, csak egy adott alrendszerben fog működni.

Találkoztam az egyik fejlesztővel, hogy megpróbáljak tanulni tőlük, de ez nem megy olyan gyorsan, mint gondolnám.

Lehet, hogy módosítania kell az elvárásait. Nagy rendszerekben hónapok vagy évek be telik a teljes fedélzeti felvétel. Ha megszokta a kis projekteket vagy az induló vállalatokat, akkor egészen más tapasztalat, ha mondjuk 6 hónapig dolgoztam egy nagyvállalatnál, és még mindig úgy érzi, hogy nem tud ennyit. Ez a nagyvállalatoknál normális.

Tehát ahelyett, hogy elgondolkodna azon, hogy milyen gyorsan kellene felpörögnie, kérdezze meg a főnökét (vagy még az egyik olyan fejlesztő is, akivel a legbarátságosabb vagy, mennyire gondolják, hogy felveszed a rendszert).

Ne feledje: saját bevallása szerint 10 évbe telt, amíg eljutottak a jelenlegi állapotukba.

Felvetettem a dokumentáció kérdését a menedzsernél, és bár ő egyetért vele, a keretet dokumentálni tudó 3 ember mindig olyan projektekkel van elfoglalva, amelyek pénzt hoznak be.

Ez is normális. Nem valószínű, hogy sikerül dokumentálnia a rendszert. Sikerülhet nek megtanulnia, vagy azt tapasztalhatja, hogy az agya nem az adott nyelv / architektúra / kódolási stílusban működik. Én például általában nem szívesen nézem meg a Java kódot, még akkor is, ha a kérdéses könyvtár / program kisebb, mint egy nagy Ruby keretrendszer, amellyel nincs gondom.

Mit tehetek ez ellen ?

Első és legfontosabb:

Beszéljen a főnökével arról, hogy mit várnak el tőle, és megfelel-e az elvárásoknak. Ha a főnöke érzékeny, kitalálhatja hogy szüksége van néhány biztató szóra, és adja meg ezeket, feltéve, hogy valójában megfelel az elvárásoknak.

Ezután fogalmazza meg a problémát. Nem vagy elégedett a fedélzeti sebesség kel? Nem tetszik a rendszer architektúrája ? Úgy érzi, nem kap elegendő támogatást ?

Attól függően, hogy mi a probléma észlelése, változik a cselekvés menete.

Utolsó megjegyzés :

Azt állítja, hogy a többi fejlesztő bevételt termel a vállalat számára. Ez azt jelenti, hogy minden nap el kell dönteniük, hogy bevételt termelnek-e vagy képeznek. A vállalat prioritásaitól függően előfordulhat, hogy a jövedelemtermelést helyezik előtérbe, és nem sok időt szánnak a fedélzetre.

Ezt figyelembe vehetik a főnöke elvárásai is.

Ettől függetlenül , ez nem a legjobb hely, mert a vállalatnak az alkalmazottaira van szüksége a bevételhez. Ennek kijavításához javaslom a kezdeményezést , de ne a dokumentumok igénylésével, hanem annak kidolgozásával, amelyről úgy gondolja, hogy a vállalat bevételhez jut . Próbáljon meg előállni egy módszerrel, amellyel olyat tehet, ami lefordított dollárt jelent. Ezt úgy kell megfogalmaznia, hogy az a leglényegesebb szempontból egyértelműen előnyös legyen a vállalat számára (a $$$ többet keresett, mint a $$$ a segítségére fordított összeg). Ez ösztönzi a főnököt és rajtuk keresztül a többi fejlesztőt, hogy több időt szánjanak rád.

Sajnos ez meglehetősen gyakori. Van néhány dolog, amellyel segíthet.

Először azt javaslom, hogy tartson naplót a felmerülő kérdésekről. Gyakran csak a kérdések kiírása segít Önnek megtalálni a válaszokat, de ha nem, akkor felvetheti azokat a kapcsolattartójával.

Amint megismeri a keretrendszert, írjon hozzá saját dokumentációt. Nem kell túl formálisnak lennie. Ha dokumentált egy szakaszt, megkérheti kollégáit, hogy nézzék át azt, hogy helyesek-e, és végül a vállalatnak lesz dokumentációja ehhez a látszólag fontos szoftverhez.

Használnak valamilyen fajtát a dokumentáció-generáló rendszerről, ahol a dokumentációt magába a kódba írják? Ha igen, annak javítása és a javítások / húzási kérelmek benyújtása nagyszerű módja a megismerkedésnek, ellenőrizze megértését és járuljon hozzá valami hasznoshoz.

Győződjön meg róla, hogy főnöke tisztában van azzal, hogy meredek tanulási görbe van, de Ön erőfeszítéseket tesz, hogy felgyorsuljon, miközben produktívak.

Ez sajnos gyakoribb, mint szeretné.

Tapasztaltam több olyan társaságot, amelyek hasonló környezettel rendelkeztek. A legfőbb ok mindig az volt, hogy a menedzsment (akik nem fejlesztők) mikroszinten kezelte fejlesztőinek munkaterhelését, és nem törődött azzal, hogy időt fordítson az olyan számlázatlan számlákra, mint az újrafeldolgozás vagy a dokumentáció (akár azért, mert elutasították annak fontosságát, akár fejlesztőik hiányozták a jót gyakorlati tapasztalat vagy gerinc, hogy időt kérjek rá)

A dokumentációs problémát felvetettem a menedzsernél, és bár ő egyetért, a keretet dokumentálni tudó 3 ember mindig elfoglalt projektek, amelyek pénzt hoznak be.

"Egyszer megtesszük, amikor lesz időnk", gyakrabban mondják, mint csinálják. Mindegyik esetben, amit láttam, ugyanazok az emberek soha nem szántak időt, és ha volt rá idő, akkor is találtak más módokat a kitöltésére. Ne higgyen egy üres ígéretnek, főleg, ha többször is megtörtént valódi intézkedés nélkül.

Hacsak nem tudja megingatni a megfelelő embereket (a menedzsment, vagy a fejlesztők kellő többsége, aki viszont képes kényszerítse a menedzsmentet hallgatni), nem sok mindent tud majd megtenni ebben a környezetben anélkül, hogy egyedül vállalná a herkulesi feladatot.

Amit innen teszel, rajtad múlik.

• Egyszerűen beeshet a sorba, és úgy végezheti a munkát, ahogyan megteheti. Ha ehhez állandó segítségre van szükség a szakértőktől, akkor legyen. A vállalat felelőssége, hogy erőforrásokat biztosítson, így Ön dolgozhat a keretrendszerével. Dokumentáció vagy egyértelmű kód hiányában ez azt jelenti, hogy szakértőkhöz kell hozzáférni, akiknek kérdéseket lehet feltenni. Ha ezek sem állnak rendelkezésre (vagy panaszkodnak a kérdéseire), akkor hívja fel a figyelmet arra, hogy addig nem tudja ellátni feladatait, amíg a problémákat nem oldják meg.
• A lehető leghamarabb átugorhatja a hajót, ha nem tetszik ez a környezet, és inkább másik céget keres. Vigyázzon, hogy mindig van esély arra, hogy hasonló helyzetbe kerüljön, és ezt általában nem az interjú során deríti ki (hacsak nem egyértelműen kifejtik gyakorlataikat).
• Ezt úgy tekintheti, mint egy lehetőséget, hogy betöltsön egy nagyon szükséges szerepet a vállalatban. Dokumentálja a folyamatot, javítsa a bevált gyakorlatot, vállalja a jobb gyakorlati környezet kialakítását. Ha jól csinálják, ez jelentősen javíthatja pozícióját a fejlesztői csapatban. De ez egy felfelé irányuló csata, amikor a csapat többi tagja nincs a fedélzeten.
• Megpróbálhatja meggyőzni a döntéshozókat, hogy ismerjék fel a fejlesztési folyamat hibáit. Akár vitával, akár szilárd bizonyítékokkal meggyőzheti az embereket arról, hogy javíthatják termelékenységüket, ha javítják folyamatukat. De vigyázzon azokra, akiknek nem érdeke, hogy másképp csinálják a dolgokat ("de a dolgok így zajlanak itt").

Tapasztalataim szerint mindegyik projektet 3-6 hónapig adtam a fejlesztési folyamat javítására irányuló erőfeszítések és kérések. Egy esetben sikerült megfordítanom. Más esetekben végül konfliktusba került a vezetőséggel, amely akkor sem volt hajlandó hallgatni az észre, amikor több független vállalkozó is ugyanazokra a kérdésekre hívta fel a figyelmet, ahelyett, hogy ezeket az embereket hibáztatta volna képzetlenségükért. Mérgező környezetek léteznek, és némelyik megöl, mielőtt megtisztítaná őket.

Az a döntés, hogy meg akarsz-e vívni ezt a felfelé tartó csatát vagy sem.

Nos, ez attól függ, hogyan akarsz hozzáállni a helyzethez, és mennyi a menedzsment támogatásod, és mennyire könnyű / nehéz átállni egy szabványos keretrendszerre, amit csinálsz.

I azt jelenti, hogy a legalapvetőbbnél 3 lehetőséged van:

• távozz.
• ismerd meg az új keretrendszert.
• győzd meg a főnököt, hogy lehetővé tegye kezdje el rendszeresen szabványosítani az új fejlesztéseket.

Hogy őszinte legyek, a 3. lehetőséget választanám. És kell kezelői támogatás. Ha ez segít, hozza fel a lényegét: mi történik, amikor az a 3 haver elmegy? Ha a házi készítésű rendszere kicsi és könnyen megtanulható, az egy dolog lehet. De a fene egy ideig mást csinál, mint csak apró változtatásokat. Ha megmaradna a '3 haver', fennmaradna-e a vállalata?

A legfontosabb, amit szem előtt kell tartani: előbbre kell vezetnie az utat. A menedzsment nem akarja hallani: "Mi csináljuk az XYZ-t, és ez elpusztít minket!"

Azt akarják hallani: "Nos, mi csináljuk az XYZ-t, de ez nem fog sokáig működni Tehát ehelyett azonnal el kell indítanunk a Small Change A-t, majd B-t kell végeznünk minden felmerülő új projektnél, majd C-t. " Más szóval, a lehető legkevesebb fájdalommal járó terv.

Mint sok más válaszadó, én is pontosan ugyanabban a helyzetben voltam, ezért jól értem ennek hátrányait. Valójában azonban megpróbálom hangsúlyozni ennek a helyzetnek néhány hátrányát - főként a tanulás égisze alatt.

Tegyük fel, hogy karrierje elején vagy, tehát valószínű, hogy te vagy. " d túl sokáig kell munkahelyet váltani, függetlenül attól, hogy ez az oka vagy mások egész sora. Azt tanácsolom, hogy alakítsd át ezt a nézőpontodat a távozás okával, egy lehetőséggel, amellyel tanulhatsz, amíg még ott vagy.

Úgy gondolom, hogy a legjobban megismerhetem a tanulási lehetőségeket, ha egy szokással dolgozunk. házon belüli keretben vissza kell lépnünk arra, hogy mi a keret az . Alapvetően absztrakció az alkalmazás felépítésének sok gyakori problémáján keresztül, amelynek segítségével energiáját nagyobb mértékben az alkalmazás azon részeire összpontosíthatja, amelyek az Ön termékét / vállalkozását különlegessé teszik, és kevésbé az árura. darabok, amelyeket a legtöbb terméknek / vállalkozásnak meg kell valósítania.

A legtöbb vállalat természetesen ezért használja a polcon kívüli kereteket. Az esetek 99% -ában valóban ezekre az árucikkekre van szükség. Az első dolog, amit meg kell próbálni megtanulni, amikor a vállalata egyéni keretet választ, a miért . Elég könnyű ezt inkompetenciának integetni, és talán néha bizonyos mértékig így is van, de valószínűleg gyakrabban az az igazi ok, hogy a népszerű keretrendszerek által biztosított árucikkek (legalábbis az alkalmazás első írásakor) eltűntek ' nem megfelelő az alkalmazáshoz és az általa megoldott üzleti problémához.

Melyik részek és miért egy igazán érdekes kérdés, amelyből sokat meg fog tanulni - akár igazuk volt, akár tévedtek a döntéseik során! (Tudja meg, mit kell tennie, biztos, de azt is, hogy mit ne tegyen). A nap végén ez a lényege a szoftvermérnök munkájának - az üzleti problémák megfelelő technikai megoldásainak kidolgozása, vagy legalábbis feltérképezése. Annak mértéke, hogy nagyjából jó mérnök vagy-e, az, hogy mennyire tudsz ilyen jól teljesíteni, és annak megismerése, hogy a vállalat más tapasztaltabb mérnökei hogyan és miért döntöttek úgy, hogy egyedi megoldásokkal oldják meg a vállalat sajátos üzleti problémáit. teljesen nyitottak az Ön számára (mint ahogy szó, szó szerint Ön előtt van a kód) egy aranyos tanulási lehetőség, amely csak most érhető el, ebben a munkában. Vigye el.

Az üzleti problémamegoldás perspektíváján kívül pusztán technikai szempontból itt is arany tanulási lehetőség rejlik. Vagyis olyan helyzetbe kényszerül, ahol mélyen meg kell értenie, és egyes esetekben meg kell változtatnia a szokásos alkalmazás-fejlesztési problémák egyedi megoldásait, amelyeket más, széles körben elterjedt, népszerű keretrendszerekben csak az Ön számára megoldanak és átadnak te egy tányéron.

A mérnöki munkában a legtöbb tanulást a szükség irányítja. Mélyen el kell gondolkodnia és meg kell értenie a problémákat és a megoldásokat, mert muszáj. Amikor neked megoldják őket, érdeklődésből esetleg megvizsgálhatja, hogyan működnek a motorháztető alatt, de általában nem megy bele annyi mélységbe, és nem tölt el annyi időt rajta, mint egyébként ha valóban el kellett végeznie a munkát.

Ha önállóan kell megvalósítania egy keretrendszert, vagy meg kell fordítania valaki más próbálkozását, mint az Ön esetében, ez egy újabb aranyos lehetőség arra, hogy valóban megértsem a megoldandó problémák részleteit, amelyek valóban hasznosak lesznek a karrier hátralévő részében. Különösen nagyszerű, hogy fiatal mérnökként ezt megcsinálja. Ismét, igen, ez talán nem a legélvezetesebb dolog, és néha egyenesen frusztráló lehet, értem, de éljen ezzel a lehetőséggel, amíg van rá lehetősége!

Ön a karrierje elején jár, és normális, hogy még nem tapasztalt nagy projekteket, ezért nem tudja, mire számíthat, ha régi kóddal dolgozik. Ön kifejezetten dokumentációt keres, mivel így dolgozhatna egy nagy népszerű nyílt forráskódú keretrendszerrel (például Qt a C ++ nyelven, vagy válasszon példát az alapnyelvéből).

A dolgok nem így működnek belső örökölt kódban, és megkönnyíti a jövőbeni szakmai életedet, ha megtanulod, hogyan kell eligazodni egy nagy, dokumentálatlan kódbázison, hogyan lehet segítséget kérni belső szakértőktől anélkül, hogy elidegenítenék őket, és hogyan lehet öndokumentáló kódot írni minimális szükséglet mellett a duplikált erőfeszítéseket a dokumentációban.

A következő javaslatom lenne:

• Állítsa vissza az elvárásait. Ne számítson arra, hogy a dokumentumok elolvasása lesz az elsődleges módja a régi kód elsajátításának.
• Fedezzen fel más módszereket egy meglévő projekt megtanulásához. Van néhány erőforrás a neten erre. Kezdheti ezzel a kérdéssel. Mint sok minden, ez a gyakorlással jobb lesz. Nekem személy szerint a kód újrafrakcionálása ad a legtöbb tanulást kódolási percenként, még akkor is, ha később ezt a refaktort eldobnám.
• Gyakran találhat választ arra, hogy "hogyan kell ezt csinálni" néhány létező kódban. használja ezt a funkciót. Ne szégyenlősen kezdje másolásával.

Összességében sok jó ok van arra, hogy elmeneküljön egy projekt vagy egy vállalat elől. A nagy belső keretrendszer önmagában nem elégséges dokumentációval nem tűnik számomra erős oknak a távozásra.

Azt hiszem, sok mindent elmondtak már, de szeretnék tapasztalatokból adni néhány idõtartamot, hogy minél jobb ötleted legyen, mire számíthatsz;

internáltam a vállalatnál i Most dolgozzon, közvetlenül az iskolán kívül. A felvételi folyamat során szó szerint mérföldköveket adtak nekem (kissé humoros módon, bár mind a valóságon alapultak):

• 1 nappal távozás előtt , a legrövidebb ideig valaki dolgozott és távozott
• 2 héttel a távozás előtt, ahogyan ez a leggyakoribb
• 4 hónap volt, mivel ez leginkább akkor történt, amikor az alkalmazottak öregségig álltak a cégnél.
• 4 hónap mind a juniorok, mind az idősek számára, hogy megtanulják és megértsék a szoftvert

Szakosodtam a műszaki szoftvermérnöki szakra (C / C ++, beágyazott rendszerek stb.), és át akartam lépni szoftvertervezés (C #, web, asztali alkalmazások stb.), így alig tudtam olyan alapvető konstrukciókat, mint az OOP, vagy azokat a nyelveket, amelyekkel dolgoztam.

Fél évbe telt, mire úgy éreztem, hogy legalább valamivel hozzájárulok, és egy teljes igen r végre elég kompetensnek érezte magát a szoftverrel való munkához. További fél évbe telt, mire technikai szinten úgy éreztem magam, mint a kollégáim, és mielőtt kompetensnek éreztem magam ahhoz, hogy megérinthessem a szoftverek minden sorát.

Az egész helyzet ugyanaz volt, nincs dokumentáció (bár magát a kódot elég jól karbantartották), és senki sem fogta meg a kezem - és nem is ismertem a tech stacket.

Itt az a lényeg, hogy időbe telik, és hogy nem szabad aggódnia az eljövendő idő. Nyugi - rendben jöttem ki, és te is.

Néhány más tipp, amit útközben vettem fel:

• Ne félj a dolgok lebontásától. A félelem sokáig visszatartott, és élni tanulni kell.
• Amikor végül megtöred a dolgokat - győződj meg róla, hogy megfelelő okod van rá, és ezt hangoztasd.