Precizitás vs. gyorsaság
2010-09-16T10:48:13+02:00
2011-01-26T22:19:04+01:00
2022-07-19T04:28:08+02:00
  • manapság a coder és a program tervező általában egy személy?


    Nagyon régen ugye úgy volt a tipikus üzleti pojekteknél, hogy volt rendszerszervező, meg a kóderek. A kóderek majdnem szakmunkásként voltak kezelve, szinte a szájukba volt rágva, hogy mit kell csinálni.
    Aztán bonyolódtak a rendszerek.
    Ekkor tipikusan az terjedt el, hogy van a rendszer-specifikátor, ő írja a rendszer-specifikációt: mit kell tudnia a rendszernek. Aztán van az architekt, ő meg megtervezi a rendszer technológiai struktúráját. A többiek meg 'programoznak': nincs annyira a szájukba rágva minden mint régen.
    Ezzel tipikusan két gond van: Az egyik, hogy az architeknek, hogy ezt a pozíciót ellássa hihetetlenül jó és gyakorlatias programozónak is kell lennie egyben. Az architekt pozíció meg vonzotta a lilaködös bullshitelőket, így az architektek 80%-a árt a projektjeinek az átgondolatlan lilaködös tollvonásaival.
    Hasonlóan a rendszer specifikátorokkal: kb. jellemzően azokat bízták meg ezzel sok projekt esetén, aki buta a programozáshoz. Pedig ez a pozíció a legfontosabb, ide kellene a legintelligensebb ember, és bizonyos technikai dolgokban is nagyon ott kellene lennie (a GUI libraryk lehetőségeit, UX fogalmakat álmában is ismernie kellene.)

    Manapság szvsz. azért lett divat az agilis módszertan, mert az okos programozók rájöttek, hogy jobban el tudják látni a specifikátori és az architekt pózíciót saját maguk: ők, akiknek szakmai felkészültségük is megvan, és a készülő szoftverrel kelnek, fekszenek.
    Persze nagy projekteknél kell külön szeély, aki a specifikátor. Sok cégnél termékmenedzsernek hívják. Komolyabb helyeken már rájöttek, hogy ez a kulcspozíció, és nem csak anyagilag becsülik meg, hanem intelligens embert alkalmaznak erre a pozícióra. Sok helyen nem, ott születnek a gyenge termékek. Személy szerint én úgy gondolom, hogy ilyen pozícióra csak olyat szabad alkalmazni, aki mellesleg kiváló volt programozó (ha nem is John Carmack, de azért az átlagnál jobb), technikai gondolkodású ember, és PLUSZ még jó azokban a dolgokban, ami ide kell. (pl. UX szakértő, ismeri a célpiacot, stb...) Továbbá jobb helyeken a termékmenedzser nem ráerőlteti a dolgait a többiekre, hanem kikéri a programozók véleményét is, hátha nekik is vannak jó ötleteik (de ő dönt).
    Mutasd a teljes hozzászólást!
  • Kisebb projekteknél amiket mostanság láttam vagy ugyanaz. Persze nagy projekteknél biztos van rendszerszervező, de én vagy 20 éve nem láttam olyat. Szerencsére.

    A gányolás általában három esetben van:
    1. Amikor a fejlesztésre nincs elég erőforrás (=nincs idő tervezni).
    2. Amikor inkompetens a fejlesztő (felvették a projektre a PHP-s Pistikét aki most jutott túl a PHP teljesen hülyéknek 24 óra alatt című mű első fejezetén ócsóért).
    3. Amikor a felhasználónak menet közben támadnak ötletei, és ezt a menedzsment nem tudja hárítani.
    Mutasd a teljes hozzászólást!
  • Nem győzöm hangsúlyozni, hogy tizensok éve kiestem a szakmából, szóval bocs, ha hülyeségnek tűnik a kérdés: manapság a coder és a program tervező általában egy személy? (nem sufniprojektekre gondolok természetesen)
    Vagy ebben a megfogalmazásban a "hülye főnök" lenne a tervező?

    Mutasd a teljes hozzászólást!
  • Leginkább a koncepció hiányát, a tervezési hiányosságokat, az átgondolatlanságot, az ad-hoc csináljunk gyorsan valamit ami messziről olyan mint ami működik dolgot. Az ha valaki gányol alapvetően vagy a hanyag coder, vagy a hülye főnök hibája.
    Mutasd a teljes hozzászólást!
  • Ennyi erővel viszont majdnem minden gányolás, mert minden gyakorlati (a legtriviálisabbaknál bonyolultabb) problémára fogsz találni bármilyen szempontból jobb megoldást több idő ráfordítással, több tudás megszerzésével.
    Mutasd a teljes hozzászólást!
  • Inkább:
    Amikor tudom, hogy valamit nem úgy kéne megcsinálni ahogy, de most az egyszer _ideiglenesen_ mégis úgy _helytelenül_ csinálom meg, hogy kész legyek hamar. Majd ha lesz időm kijavítom.. Aztán többnyire úgy marad.. Az gányolás.

    Szóval a fent említett érzés fennálásakor az ember tényleg gányol, de biztos van eset, amikor ez nem áll fent, de mégis gányol az ember. Mert azért gány kódot sajnos úgy is csinálhat valaki, hogy azt hiszi az jó/szép megoldás pedig például csak tudatlan. Jó persze lehetne vitatkozni, hogy ilyen csak kevésbé gyakorlott/tanult stb. embereknél van, de ez utóbbi már relatív mihez-képest dolog már...

    Egyébként amit írtál az ettől még hasznos és így átfogalmazva egyet is értek vele, csak szerintem nem ilyen egyszerű a dolog...
    Mutasd a teljes hozzászólást!
  • Az a gányolás, amikor tudom, hogy valamit nem úgy kéne megcsinálni ahogy, de most az egyszer _ideiglenesen_ mégis úgy _helytelenül_ csinálom meg, hogy kész legyek hamar. Majd ha lesz időm kijavítom.. Aztán többnyire úgy marad.
    Mutasd a teljes hozzászólást!
  • "Ti mit tartotok amúgy gányolásnak ?"


    Ez szerintem megérne egy külön mesét, erről szvsz. nyitnod kellene új topikot. Bár félő, hogy a gányolás mindenkinek más, és emiatt egy-egy "példakódnál" elszabadulna a pokol...
    Mutasd a teljes hozzászólást!
  • Igazából ha elolvasod, hogy mi a célja a refaktorálásnak, akkor annak az ellentettje jelenti azt, hogy gány.
    Mutasd a teljes hozzászólást!
  • Jó ez a topik.
    Ti mit tartotok amúgy gányolásnak ?
    Gondolom mindenkinek mást jelent és függhet az alkalmazástól is, de kb. kinek mit jelent?
    Mutasd a teljes hozzászólást!
  • Jó, hát a tervezéssel nem lehet spórolni, viszont ha normálisan meg van tervezve, akkor már nehéz "gány deszkamodellt" csinálni.
    Mutasd a teljes hozzászólást!
  • Félig igaz.
    Ha jól megtervezett, a részleteket szem előtt tartó (nem implementál is, de a "helyét", lehetőségét megtartó) a kód, ami persze működik is, akkor jó eséllyel lehet szépíteni, továbbfejleszteni, optimalizálni.

    Egy gány deszkamodellből azonban nehéz lenne szép végeredményt kihozni.
    Mutasd a teljes hozzászólást!
  • Ahogy LC mondta:
    Előbb tervezz és utána programozz.

    Az optimalizálást meg hagyd mindig a végére. Elsőre elég, ha működő kódot írsz, utána ha még van idő meg pénz rá, akkor lehet optimalizálni, hogy gyors is legyen. (A másik, hogy kódolás közben úgysem tudod eldönteni, hogy mi lesz a szűk keresztmetszet, azt csak a működő programnál tudod megnézni profiler-rel.)
    Mutasd a teljes hozzászólást!
  • hogy valami nem okés a mostani megoldással, lehet ezt szebben is

    Jah ismerős az érzés, nálam csak az a baj, hogy van amikor 1-2 nap után jön csak meg az ihlet, hogy hogy lehetne igazán jól, addig meg csak vergődök...
    Mutasd a teljes hozzászólást!
  • Másik témában idésztem be Joel honlapját és eszembe jutottál.
    Ezt érdemes elolvasnod: http://hungarian.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef...
    Mutasd a teljes hozzászólást!
  • ps. nagy kár hogy nem ismertelek 2 évvel ezelőtt úgy mint most, mert sztem ...vajó csapatot alkotattunk volna
    Mutasd a teljes hozzászólást!
  • Műalkotás és termék - ezek a szavak szelik ketté itt az állapotteret:
    A termék attól kezdve termék, hogy a szükség hívja életre. A műalkotás pedig azért műalkotás, mert a készítő nem törődik semmiféle kötöttséggel. Ritkán persze előfordul, hogy egy terméknek induló dologból valami tökélyre csiszolt eredmény jön ki és vice-versa, de szerintem viszonylag ritka eseménynek számít ha mégis így sikerül.

    Azt is érdemes megnézni, hogy akik valami tényleg nagyot csináltak a világban, azok általában mindig úgy tekintettek a munkájukra mint műalkotás, vagy legalábbis teljesen a sajátjuknak érezték. Persze ezt nem biztos hogy mindenki ebben a kontextusban írja le, van aki megszállottságról és hasonlókról beszél, de csak a szavak mások, a lényeg ugyanaz.

    Nem tudom ki és hogy van vele, de én ha kicsit átnézek a világtörténelmen azt látom, hogy a két irányvonal kezd távolodni egymástól a felhasználási célokat figyelembe véve: azaz a költőket jó esetbe óva intik a termékszerű műárasztástól, a programozókat pedig a piac szabályozza határidőkkel. De ez más területeken is így van. Kialakult az emberekben egyfajta kép, hogy mi számít munkának és mi művészetnek és ez valahogy default skatulyázza, hash-eli a foglalkozásokat. Persze van néhány pillanat, amikor az ember megérti a kézzel faragott tetőgerenda és a házilag teljes gondossággal szemelt szőlőjű bor izét és zamatát, de az ácsmesterséget és a festést ha egy kisgyerektől megkérdezik, szerintem ő is szétválasztja művészet és munka kategóriába.

    Ez az egész marhaság, szerintem káros egyébként az emberi lélek egészségére nézve, esetleg az egész emberiségére is, de amíg szükség lesz, termékek is lesznek. Az olyan társadalom, melyben minden ember a munkáját szívből végzi, élvezettel és lélekből, sajnos egyelőre egy utópisztikus lehetőség, ami csak akkor életképes, ha mondjuk olyan szintre érne az erkölcsi és technikai fejlődés, hogy senkinek se kellene félnie akkor se, ha semmit se csinálna, csak dömperezne mint 5 évesen. Hiszen ténylegesen semmit csinálni unalmas az már és akkor is lennének elvetemült emberek, akik szórakoznának letűnt világok titkaival, vagy hipermodern kvantumfizikával. Hiszen az emberi lélek végső soron mindig alkotni akar, ha pedig olyan környezetbe kerülne, ahol nem kényszer mit csináljon és hogyan, pontosan azt csinálná amihez a legjobb hozzányúlnia.
    Szerintem eljön még a mi időnk

    ui.: Amit leírtam, nem csak ránk vonatkozik programozókra. Remélem azért túl nagy offnak nem tűnik ez a filozófiai magvetés.
    Mutasd a teljes hozzászólást!
  • Nálam az igazán nagy probléma leginkább azzal volt/van, hogy leragadtam a fejlesztésnél. Hiába tervez az ember osztályokat és nem egyből kódol, az még mindig túl technológiai gondolkodás. És mivel 12 éves korom óta programozok és az egyetemen is ezt tanultam, automatikusan rááll az agyam a fejlesztési problémák megoldására. Tudatosan erőltetni kell magamat, hogy álljak fel, menjek sétálni, gondolkodjak a userek problémáin és ne egyből megoldásokon, végezzek piackutatást, ismerjem meg a konkurrens termékeket.


    Pedig az hogy alapból ilyen a hozzáállásod nagy kincs.
    Én épp a fordítottja vagyok, túl sok tervezés, kevés kivitelezés, és az emberek döntő többségére ez jellemző.
    Milliószor előrébb járna ez az ország, ha az átlagember olyan lenne mint te és nem szenvedve god-complexben, hogy minden egyedül akar megoldani (mint pl. én ).
    Mutasd a teljes hozzászólást!
  • Dorkaaaa Spartaaaaa!
    Mutasd a teljes hozzászólást!
  • szia Banderasz,

    1. létezik:)
    2. mindig csak jól specifikált munkákat vállalj el.
    3. ha te tervezel, mindig hagyj rá elég időt, és ezt nyomatékosítsd a megrendelő felé is.
    4. ne köss a rövid határidő miatt olyan kompromisszumokat, amikkel szakmailag nem értesz egyet
    5. ne vállald túl magad

    valaki itt említette a saját projecteket. valóban, azokon tudod bemutatni önmagadnak és világnak, hogy milyen munkát adsz ki a kezedből

    (aki figyel a részletekre, nem felületes, értékelni fogja a minőséget. btw, a vitaindítón is látszik, szépen tördelt, fogalmazott, helyesírási hibáktól mentes...:)

    D.
    Mutasd a teljes hozzászólást!
  • Kedves Banderasz!

    Az előttem szólok már nagyon sok okos dolgot elmondtak, de remélem ezt is hasznosnak fogod találni.

    Végezd el azt a munkát, amit megrendelnek tőled, legjobb tudásod szerint, a többivel ne törődj. Senki sem fizeti ki neked, ha kijavítod mások balfogásait, senki sem köszöni meg, viszont jól letolnak, ha késel a határidővel. Csak a Te részedre koncentrálj.

    Többéves programozói tapasztalatom alapján kijelenthetem, hogy mindenki "gányol". Nem egyformán jár az agyunk ezért ugyanarra a problémára különböző megoldások születnek. Mindenkinek értelmi szintje és tudása szerint. Valakinek biztos az a kód "gányolás" ami Te írsz. Sokféle program kódjába beleolvastam már és néha elcsodálkoztam, hogy egyáltalán hogyan képesek működni.

    Ha mindenki "gányol", képzeld milyen hibák lehetnek az operációs rendszerben (bármelyikben). Nem véletlenül érkezik naponta frissítés.

    Csak pénzért javítsd mások kódját!
    Ne foglalkozz a hibákkal. Fogadd el, hogy olyan-amilyen. Ha valami tényleg otromba hibát találsz (végtelen ciklus, biztonsági kockázat, stb.), azt se javítsd ki! Jelentsd a főnöködnek (megrendelőnek) és csak akkor javítsd, ha megfizeti.

    Legyenek saját fejlesztéseid!
    Itt aztán vérre menőig optimalizálhatsz. Határidő nincs. Erre tényleg büszke lehetsz: "Igen ezt Én csináltam!". Tapasztalatot szerzel és tanulsz, ami visszahat az igazi munkádra. Kis szerencsével később visszahozhatja az árát.

    Sok szerencsét!

    Üdvözlettel
    kjaron
    Mutasd a teljes hozzászólást!
  • a forráskóddal sokszor nem vagyok "elégedett",


    Nálam is van ilyen, de szvsz. ez kivédhetetlen, nem lehet előre megtervezni mindent jól. Mindenképpen meg kell tanulni refactor-olni, ami egy nehéz mesterség, sokat kell gyakorolni, de nagyon fontos. Erre nincs recept, én nem hiszek a módszertanokban. Valahogy tudat alatt tervezgetni kell az ember fejében egy sok featurrel rendelkező ütős terméket, de részletesen megtervezni és leprogramozni egy kevés feature-t tudó lecsupaszított dolgokt kell először, hogy lehessen viszonyalg jól tervezni (de közben a fél agyunkkal azért odafigyelni a későbbi valószínű feature-ökre). És utána még így is óhatatlanul refactor, ha úgy érezzük. Ez művészet.
    Nálam az igazán nagy probléma leginkább azzal volt/van, hogy leragadtam a fejlesztésnél. Hiába tervez az ember osztályokat és nem egyből kódol, az még mindig túl technológiai gondolkodás. És mivel 12 éves korom óta programozok és az egyetemen is ezt tanultam, automatikusan rááll az agyam a fejlesztési problémák megoldására. Tudatosan erőltetni kell magamat, hogy álljak fel, menjek sétálni, gondolkodjak a userek problémáin és ne egyből megoldásokon, végezzek piackutatást, ismerjem meg a konkurrens termékeket. Erőltetni kell, hogy a programozó beröződéseimet gyengítsem. Amúgy az, hogy felállni és elmenni sétálni, az a technikai problémák megoldásában is segít. Nem akkor kell ezt csinálni, amikor nem működik valami, hanem amikor érzem, hogy valami nem okés a mostani megoldással, lehet ezt szebben is.
    Mutasd a teljes hozzászólást!
  • egyetértünk, ezért használtam az idézőjeleket
    Mutasd a teljes hozzászólást!
  • Pld. egy garázsprojektnél elhiszem, hogy a minőség felülírja a határidőt, "komolynak" tartott fejlesztésnél nem.


    Igen, csak végül a 'komolytalan dolgok'-ról derül ki sokszor, hogy azok a legkomolyabbak.

    Egy nagy cégnél a középvezetők sokszor nem látják a lényeges dolgokat. Ezek a managerek sokszor se a matrketinghez, se a usability-hez sem pedig a programozáshoz nem értenek igazán, vagy ha értenek is, nem látnak rá a lényeges problémákra, mert nincsenek benne napi szinten. Ráadásul sokan közölük viszonylag kártékonyak, leginkább a céges politikával foglalkoznak. És ezek az emberek hozzák a döntéseket.

    Egy garázscég alapítói ezzel szemben olyasmit kezdenek csinálni, amiért lelkesednek, vagyis a termék lelkével közvetlen kapcsolatban vannak, illetve olyan technológiákat használnak és úgy, ahogy azt a legjobbnak tartják. Sokan közülük elbuknak finanszírozottság vagy üzleti érzék vagy tudás hiányában (startuphoz lényegesen több tudás kell, mint egy átlag álláshoz), de a garázscégekből kerülnek ki a legértékesebb dolgok is. Kevés fejlesztő végezi a munkáját a részletekre való olyan odafigyeléssel, akkora kreativitással és olyan minőségben ahogyan Steve Wozniak összerakta az első Apple-t.
    Mutasd a teljes hozzászólást!
  • szerintem Banderasznak nem az a problémája, hogy milyen eszközöket, módszereket, praktikákat használjon a munkájának gyorsabbá, könnyebbé tételéhez, hanem egyszerűen az, hogy "rabja" annak, ha valamit jobban-szebben tud kódolni, vagy esetleg "gányolt kóddal" találkozik a projektben, akkor ne "javítsa ki", és bizonyára "frusztrálja" az is, amikor azt hallja: "vidékre jó lesz, pesten meg úgy sem nézik" (nyilván a menedzsmentnek "kicsit" mások az érdekei, mint a fejlesztőnek)

    saját projekt egyébként jó, csak ott is az a veszély, hogy mivel (jó esetben) állandóan fejlődik az ember, hiába tervezett előre, sajnos sokszor hajlamos visszanyúlni, újraírni, átírni egyébként már működő kódrészleteket az említett menet közben születő újabb ötletekről már ne is beszéljünk, azaz tényleg nehéz eljutni az 1.0-ig (legalábbis nekem nem sikerült még);

    az igazi művészet: "tudni kell mikor abbahagyni" (újabb közhely)

    én az összes kisebb, már "befejezett" ötletemnél úgy jártam, hogy egyszer csak nem folytattam őket, működőképesek stb., de a forráskóddal sokszor nem vagyok "elégedett", hiába na: "Aki a Basic-et ismeri meg először, abból sosem lesz igazi programozó." (értelmezésem szerint a rögtön kipróbálok a gép előtt valamit (lsd. a Basic Terminál "filozófia", a nyelv megjelenésekor a 60-as években), az nem vezet jóra és habár előre meg lehet tervezni valamit talán 100%-ra is, csak én nem nagyon tudom megállni, hogy kódolásnál stb. mégsem térjek el a tervtől, persze ekkor lehet új tervet csinálni, de az ember ugye - ha már ott ül a gép előtt - egyből kódol(ni akar))
    Mutasd a teljes hozzászólást!
  • Hali!

    Nekem ilyen régen volt (marminthogy szépen, odafigyelve a reszletekre is): 20 fôs cég ugyviteli rendszere, az elso jopár hánapban hajtás, azután lehet havi fixben ( = nincs para) szépen odafigyelni minden apró részletre, ami a megbizhatosagot, karbantarthatóságot növeli. Végül is azért dolgozunk, hogy kesobb ne kelljen dolgoznuk.
    Ha az ido hianya miatt tulsagosan gány egy projekt, az késôbb ugyis megbosszulja magát, azt' lehet utolag ujrairni ganyolas nelkul, (vagy lelépni, kinek mi a szimpatikusabb :D). Optimizalni is meg csak annyira, hogy lazan elfusson az ugyfel hardverjén (kiveve ha pont az optimalisság a cél vagy tanulas/hobby).

    Mutasd a teljes hozzászólást!
  • apropos, hogy a kérdésedre is válaszoljak: én úgy "oldottam meg", hogy nem kötök kompromisszumot, vagy legalábbis kerülöm és bevállalom ennek minden következményét (bizonytalan megélhetés, sokkal több idő eltöltése a munkával, mit ahogyan azt megfizetik, "remeteélet", stb.), lehet persze az is, hogy valamikor ez megtérül, de nem "befektetésként" választottam, hanem azért mert nem tudok máshogy "működni" (mondjuk megtehetem, mert nincs gyerekem, apámat nem kell támogatnom, több felmenőm meg már nem él, ...)
    Mutasd a teljes hozzászólást!
  • hogy ma már a minőség a másodlagos, és a mennyiség élvezi a prioritást?


    Ez nem 'ma már' kérdése szvsz., ezek időtlen dolgok. Mindig voltak/vannak/lesznek piacok, ahol a nagyon magas minőség számít és erre van is fizetőképes kereslet, és olyanok is, ahol nincs fizetőképes kereslet a nagyon magas minőségre. Vesd össze a nyolcvanas évek végén a 'lengyelpiacon' 200 forintért árult kvarcórákat a többszázezter forintos svájci órákkal; illetve minden történelmi korban fogsz ilyeneket látni.
    Jó hír az, hogy vannak esetek, ahol a minőség számít. És nem csak az 'exkluzív' szoftverekre kell gondolni, hanem arra is, ahol nagy tömegben el tudják adni, amit csinálsz. Ahol egy olyan alkalmazást fejlesztenek, amit millióan vesznek meg / használnak, ott napokat eltökölnek még olyan kis részletekkel is, hogy mekkora legyen egy text-field. Eleve felvesznek külön usability experteket, külön frontend specialistákat, külön backend specialistákat, külön vizuális designereket.
    A rossz hír az, hogy az olyan állások száma, ahol minőség a lényeg, messze eltörpül az olyan állásokhoz viszonyítva, ahol a mennyiség a lényeg. Főleg Magyarországon: ide a nagyobb külföldi cégek már eleve csak akkor jönnek, amikor már brute-force akarnak fejleszteni. (úgy hívják, hogy outsourcing).
    Pl. irreáliselvárni, hogy Józsi bácsi hentesboljának webes megjelenésének fejlesztése meg tudja finanszírozni, hogy a fejlesztők ezen éljék ki kreativitásukat.

    Szvsz. valamilyen szinten bele kell törődni, hogy nem nagyon lehet művészkedni a legtöbb munkahelyen.
    Én a saját side-projektemet használom arra, hogy igazán minőséget alkossak. De ott is bűvészkedni kell azzal, hogy hogyan nyessem vissza a featuröket, hogy még ebben az életben legyen használható 1.0-ás verzió, miközben figyelek a minőségre.

    Összefoglalva: én már rég rájöttem, hogy csak olyan projektben tudom kiélni a kreativitásomat, amit teljesen én kontrollálok, és nem hogy főnököm nincs, de még egy olyan megrendelőm sincs, ami kvázi főnöknek tekinthető (tehát nem egyedi megrendelésről, hanem termékről van szó). Addig amíg ebből nem tudok megélni, addig kompromisszumokat kell kötni, ez van.
    Mutasd a teljes hozzászólást!
  • Én megpróbálok minden olyan részt ami minden projektben közös egyszer megírni, minél jobban, ez egyrészt gyorsabb munkát eredményez (mert már a kód nagy része meg van írva), másrészt minél kevesebb új kódot kell írni, annál kevesebb a lehetőség a gányolásra.
    Ezenkívül ha egy feladatot gyakran el kell végezni, arra scripteket írok, így nem kell minden projekt elején már ezredszer megírni ugyanazt az üres XHTML, CSS fájlt, stb.
    Mostanában pedig még egy olyan megoldáson is gondolkozok, ami fejlesztés közben elemzi a kódjaimat, és figyelmeztet ha valamit nem pont úgy kéne csinálni mert nem lesz valid a HTML, vagy nem fog lefutni a PHP, bár ez még csak ötlet szinten létezik.
    Mutasd a teljes hozzászólást!
  • A kettő együtt kell.

    Tapasztalataim szerint alapvetően két dolog van ami ebben segíthet:

    1. Az adott munkához a lehető legkorszerűbb eszközt használd. Pl. egy form/report/query designer sok felesleges munkát levesz az ember válláról, és az a pár kilobyte amivel ezek több kódot generálnak nem összemérhető azzal az időmennyiséggel amit megspórolsz velük. Ráadásul a kódgenerátor jóval ritkábban hibáz mint te.

    2. Előbb tervezz és utána programozz.

    Ami viszont ellene hat azok általában a felhasználók akiknek támadnak időnként ötleteik, általában 10 perccel az átadás előtt... Az ilyet viszont a menedzsment feladata kezelni.
    Mutasd a teljes hozzászólást!
Címkék
abcd