Amikor egy új projekt beindításához, hogyan tervezzenek, vagy meddig tart?
Pszeudókód? Folyamatábrák?
Ne próbálja gondolni az összes osztály előre?
TBH, soha tervezni semmit. Azt, hogy egyenesen rá, és úgy gondolja, a megoldások problémák merülnek fel. Leginkább azért, mert a néhány alkalommal próbáltam tervez előre, én mindig elfelejtek valamit nagyobb, így a logika a tervezési lenne hibás.
Sokat kevesebb, mint kéne
Mindig merülni, hogy piszkos, majd rájönnek, hogy tettem egy káosz. Akkor menj vissza, és tervet, és csinálni.
de a rendetlen hibákat fázist ad nekem nagy ötlet, hogy nem lenne ellenére az egy formális tervezési folyamat.
Szerkesztése én elsősorban kap ilyen jellegű törni a billentyűzetet szórakozik, ha játszik nagyobb / összetett. Érdekes, hogy meddig dolgok, mielőtt rájönnek, hogy a „ez a fejemben ez így van rendben” design 100% hibás.
Attól függ. Most azért írom meglehetősen egyszerű, és egy nagyobb tervezési lesz lépésről lépésre építjük fel, és észreveszem, hogy mi még mindig hiányzik, és mi már befejeződött. Volt még néhány szőrös dolgok szükséges kiterjedt vonalvezetés és úgy gondolta, hogy jobb, bár már nem jött át számos építészeti problémákat, hogy a szükséges, így (még fiatal, meg ilyesmi). Leginkább ezek voltak trükkös számtani dolgokat.
Az én szakmai tavaly, a menedzserem kellemesen csalódtam szoktam ábrák a probléma. Azt hittem, hogy egy elveszett művészet a diákok ezekben a napokban. Nem voltam túl kellemesen meglepődtek, hogy tekinthető-én kelt.
Különben is, ez attól függ, hogy az idővonal a projekt számomra, határidők a legfontosabb dolog természetesen.
Valószínűleg nem a legjobb módszer ... de ... azt tervezem kód .
Sokszor felfedezni osztály / módszerek / stb. hogy szükségem van csak ennek révén ez így. Ezzel azt mondta, én mindig azt feltételezik, hogy az én tervezési kód nem lesz a végső megoldás.
Emellett én jegyzetelniük részletező „főbb jellemzői” és „kisebb / kívánság jellemzői”.
Ha figyelembe a probléma, bármilyen méretű, mindig tervezem írásban is legalább kétszer.
Minden attól függ, hogy mekkora a projekt is. Néha is hónapokig csak összegyűjteni a követelményeknek, és pontosan tudják, mit kell tennie.
Mikor jön le, hogy a kódoló része, minden attól függ, mennyire bonyolult ez. Ha ez rendkívül bonyolult, én úgy akarja kezdeni az egyszerűen ki mit akarok csinálni. Aztán majd írja ki az én pszeudo kódot megjegyzéseket. Aztán kódolni fogja körül ezeket a megjegyzéseket.
Azonban, ha ez egyszerű kódolás. Én általában csak annyit írj, hogy milyen a fejemben, és kipróbálni.
Mi egy nagyon agilis megközelítés, hogy működni fog a főbb részeit és persze a dolgok mindig jönnek felbukkan a követelményeknek. Tehát, hogy lehetővé azok számára, ahogy jönnek fel. Te soha nem fog teljesen pontosan tudja, mit akar létrehozni az elején a teremtés ciklust.
Ez a véleményem.
A legtöbb időt, azt legalább próbálja meg, hogy a teljes diagram (akár csak a fejemben), hogy milyen a modul / rendszer fog működni. Szeretem tudni, hogy mit fogok csinálni, mielőtt csinálni. Lehetővé teszi, hogy a programozási könnyebb és gyorsabb (mi általában szoros határidők, ahol dolgozom). Minden alkalommal, hogy én nem, én befut a problémákat, hogy általában arra késztet, hogy húzza ki kódot, és üzembe máshol van. Bevallom, én folyamatban jött át keserű tapasztalat és kaptam nagyon-nagyon jól használja regex a kódot és a globális keresés és csere.
Valaki hozott egy jó pont, néha van egy nagyon nagy rendszer, és hogy lesz nehéz. Megpróbálom, és lebontani darabokat. Fogok dolgozni valamin, és kap ez húsú ki, és dolgozni valami mást egy darabig, és hogyan hatnak egymásra. Még előre tervezni, hiányzik a dolgokat, és meg kell refactor kódot, de legalább én nem redoing mindent, mert én legalább volt valami a munkaterv.
Ez attól függ, hogy mennyire összetett a probléma akkor próbálják megoldani. Ha szed egy nagy programozó projekt, akkor szükség van egy bizonyos fokú tervezés megkezdése előtt. Ha nem, akkor kap szörnyen elvész a részletekben dolog, hogy nem egészen kommunikálni a többi alkatrész nincs idő.
Alapvetően, meg kell kérni egy madártávlatból a problémákat meg kell oldani. Hátha valamelyik problémák elég kicsik ahhoz, hogy meg lehet oldani, és kitalálni, hogy vajon mit kell kommunikálni a többi megoldás. Gondold azt, hogy egy fekete-doboz egy API a külvilág.
Miután az összes blokkot rájöttek, hogy ha meg kell osztani a feladatot kisebb részproblémával, illetve, hogy van egy elég részletes kilátás nyílik az egész projekt, amely akkor kezdődik a kódot.
Az én tapasztalatom az, hogy a tervezés segít megelőzni a problémákat a jövőben, hogy úgy gondolja, inkább arról, hogy a kód kellene növekedni fog a jövőben, ha kell hozzá semmit stb
A legtöbb esetben akkor mentse töltött időt a tervezésre, ha hibakeresés, vagy kiterjesztése a projekt. Ezenkívül, a durva elrendezés a projekt azt jelenti, hogy könnyebb lesz, hogy segítsen kiépíteni a fekete doboz van szüksége, így a munka rajta többen, mint magad.
Attól függően, hogy a projekt összetettségétől, szoktam kezdeni végre pad és a papír, és írjuk fel a spec, és néhány pszeudo-kódja a vezérlésre. Aztán lehet, hogy mindig olvassa vissza, hogy míg én kódolás. Ez megkönnyíti, és kevesebb újratervezés, mert nem gondolom, hogy a problémára.
Személyesen ez függ a körét és a projekt összetettségétől, hány ember Dolgozom rajta, és az általános elvárásokat szállítás.
Ez igen fontos, hogy megértsük a teljes elvárásoknak a fél, aki használni fogja a szoftvert. Mindenki részt vesz a projekt közös megértése, hogy mi is dolgozott -, hogy hogyan kommunikáljuk megy sok irányban.
Túl gyakran, az érintett feleket a szoftverfejlesztés nem veszik észre, hogy a kommunikáció a felek között gyakran a legkritikusabb és alulértékeltek a projekt részét - és a fő oka a projekt balesetek.
Miután tapasztalat egy csomó befejezetlen projektek , én inkább, hogy végre egy egyszerűsített változata az üzleti folyamatok az én személyes fejlesztési módszertan.
Ezek általában követik a következő szerkezetű:
Azt sört kávét és kézműves pár szendvicset.
Tényleg attól függ, hogy a projekt. Dolgoztam néhány projekten a védelmi iparban került 2 év részletes tervezés előtt, hogy egyetlen sor kódot, és ültem le, és köpült ki néhány kisebb segédprogramok csak néhány kér egy e-mailt egy 3D-s vagy textúra művész egyetlen ülés egy zacskó perecet és egy csésze Joe.
Hogy képes fejleszteni folyamatábrák, UML diagramok, use-case szótárak, és részletes kódolási szabványok előtte egy szép módja annak, hogy a dolgok szervezett, és minden bizonnyal megéri a nagyobb projektek, nagyobb csapatok, és a kritikus projektek. De ezek a dolgok időt vesz igénybe, és gyakran túlnő a kisebb projektek számára.
Az egyetlen dolog, amit tényleg meg kell biztosítaniuk, hogy van megfelelő ismeretekkel rendelkezik a problémakör. Ha nem, akkor tölti az időt előre, találjon meg, amíg meg nem mindig érdemes az időt.
Amikor én voltam a „vízesés” módja a dolgok írnék több száz oldalas dokumentumokat mutatja az összes részletet, lehet fedetlen a kutatások során. Ahhoz, hogy ez a hatalmas kötetet dokumentáció tenném általában
Az elmúlt néhány évben már együtt halad Agile (SCRUM) és megtették egy teljesen más megközelítés.
Azt kell mondanom, hogy Agile csökkenti a ráfordított idő, írás dokumentumok bomlani, amint a tinta DRYS. A termék tulajdonosa kap, hogy az eredmények sokkal gyorsabb módon. Ami azt jelenti, hogy kapnak, hogy a projekt megy a helyes irányba idővel - még ha ebbe az irányba változik dolgozunk.
Tartsuk szem előtt, hogy van egy időben és egy helyen mindkét módon fejlődik. Nem szeretnék építeni Jet szoftvert Agile!
Még mindig az egyetemen, és én még nem tapasztalat létrehozása nagyszabású szoftver rendszerek, de ...
Az első dolog, amit meg kell tenni, hogy a munka, mi akart. Eddig nekem, ez általában egy feladat specifikáció, de a valóságban ez magában beszél az ügyfélnek. Nagyon.
Aztán dolgozni, hogyan kell csinálni, mire van szükség. A viszonylag kis program, hogy én már dolgozom, én általában képeznek a fejemben egy durva ötlet, hogy mi a programom fog kinézni (milyen fontos része a program, és hogyan lépnek kölcsönhatásba egymással). Ez magában foglalhatja a tüskék, ha nincs ötlete, hogyan egy része a program működni fog. Nem hiszem, hogy ez a megközelítés (ezt az egészet a fejemben) a skála nagyon jól, de a kérdés az volt, kérve, amit valójában csinálni ...
Amint tudom, hogy több vagy kevesebb, mit akarok csinálni, leülök, és írjuk be a kódot. Itt van, hogy én észlelt problémákat, mire gondoltam.
Nem hiszem, minden alkalmazott pszeudokódokra tervezni egy algoritmust. Szerintem pszeudokódját túl alacsony szinten tervezni a nagy darabokat a program.
Én csak akkor kell használni egy folyamatábra egy alkalommal, hogy segítsen a tervezés során a programban - vissza, amikor én tanultam összeszerelés és egészen új programozási (és ez hasznos). A mitikus Man-Month a következőket mondja: „A részletes ütés-by-csapás folyamatábra, azonban egy elavult zavaró, alkalmas csak a kezdeményező kezdőknek való algoritmikus gondolkodás. ... én még soha nem láttam egy tapasztalt programozó, aki rutinszerűen részletes folyamatábrák megkezdése előtt programokat írni.”
IMO 5 perc előre tervezni = 1 óra kódolás ....
Így sokszor van, hogy menjen vissza, és gondolja át a helyzetet, mert nem tervez semmit.
A legfontosabb része legyen a folyamatábrán.
Az egyéb részletek néha lehet gondoskodni a repülni.
Felhívom kiterjedt folyamatábrák és írjon pszeudo kódot a bonyolultabb funkciókat. Úgy érzem, a rajz a folyamatábra lehetővé teszi számomra, hogy refactor bevezetése nélkül hibákat véletlenül. Csinálok egy vizuális rajz papíron, mint egy folyamatábra is segít kitalálni, ha a logika valóban helyes. Ez csak tényleg működik a kis - közepes projektek, ahol a legtöbb műszaki ismertek.
Több tapasztalat, hogy szükség van, hogy dolgozzon kiterjedt folyamatábrák és kiírja az összes funkció pszeudo-kód válik feleslegessé azonban, mielőtt eléri a ponton azt javasoljuk, hogy tervezi, mielőtt kódot.
