Autor Zpráva
Jcas
Profil *
Už jsem to jednou zmínil, že jako začátečník mám největší problémy se stavbou scriptu.

Snažím se vždycky si namalovat nějaký vývojový diagram a z toho vycházím. Musím říct, že mi to moc nejde. Buď tam vždy něco zapomenu, nebo se z toho stane naprosto nepřehledný obrázek.

Je pravdou, že jsem vlastně ještě nenašel článek, který by se zabýval touto problematikou.
Výsledky jsou katastrofické :)))) Ono to sice funguje, ale je to hrůza.
V praxi to potom vypadá nějak následovně.

function delejNeco($pole, $index)
Jéé, já potřebuji aby ta funkce znala ještě jednu hodnotu. Tak ji tam prostě přibouchnem.
function delejNeco($pole, $index, $prvek)

Nebo: if(podminka). A sakra. další situace, kterou potřebuji odstředit. Tak ji tam prostě přibouchnem. if(podminka) { if(podmínka2)
A sakra, ještě jedna if(podminka) { if(podmínka2) {if(podmínka3)

Musím říct, že tohle je asi jedna z nejttěžších věcí, kterou při psaní php pozoruji. A to když do toho ještě zapojím DB, tak to opravdu stojí za to)

příkl.
Zrovna nyní jsem se dostal do podobné situace, kdy mi z toho vznikají příšernosti. Může za to možná špatná volba stavby na začátku.
- uživatel vkládá do Db data
- rozdělil jsem if-else situaci, kdy je na stránce poprvé a vkládá nová data a kdy je upravuje. Pro jednotlivé okamžiky jsem nastavil buď UPDATE, nebo INSERT.
- při standart postupu není problém, protože při prvním přístupu se uloží vše a do nepovinných polí se uloží NULL. Při druhém přístupu už provádím pouze UPDATE.
- chvilku mi trvalo, než jsem pochopil, proč to nefunguje. Já si totiž v phpmyadmin uložil pár cvičných dat, kdy jsem nevyplnil vše. A ejhle, najednou je celý script na prd, protože nemůžu UPDATOVAT něco, co neexistije.
- Napřed jsem si říkal, že to nevadí, protože návštěvník bude postupovat dle toho, co jsem mu nachystal. Ovšem pak jsem si uvědomil, že když někdo první přístup zabije a vrátí se k němu později, tak se dostane do přesně té samé situace.
- Člověk si řekne - jednoduchá situace-ošetříme ji. Ale najednou se objeví jedna souvislost, druhá, třetí a už to jede. přibouchnem tohle tam, přibouchnem tohle tady atd atd.


Celý script je na velké H a můžu začít znova.
final
Profil
Jcas:
elý script je na velké H a můžu začít znova
pointa?
CZghost
Profil
Jcas:
Chápu, že potřebujete pomoct, ale bez konkrétnějších informací jsme bezradní. Takhle nevíme, co Vás přesně trápí, kde je ta chyba. Jestli už máte nějaký kód, sem s ním, chyba se dá najít po prozkoumání pár řádků, takže nepodstatné části vyházet (komentáře ke kódu bychom také rádi uvítali, je těžké se vyznat ve stovce řádcích kódu bez patřičné dokumentace). A volil bych lepší název tématu, Pouze pokec evokuje jenom potřebu se vyfňukat, že Vám něco nejde. Řekněte nám, co, a my Vám zase na oplátku řekneme, jak to vyřešit. Bohužel nikomu do hlavy nevidíme a už vůbec ne přes internet, nejsme jasnovidci, telepatii opravdu neovládáme.
jenikkozak
Profil
CZghost:
Přečti si prosím znovu jeho dotaz. Nechce řešit konkrétní problémy ve skriptu. Ptá se, jak si správně práci naplánovat, aby ji pak nemusel záplatovat.
Joker
Profil
Jcas:
tohle je asi jedna z nejttěžších věcí, kterou při psaní php pozoruji
Ano, návrh programů je převážná většina „programátorského umění“.
Bouchání kódu může být zdlouhavé, ale jinak to zvládne kdekdo. Podobně jako třeba na stavbě vykopat na daném místě výkop daných rozměrů. Na to nejsou potřeba zvláštní schopnosti.
Náročné na odbornost je právě to určení, kde má být výkop a jaké má mít rozměry. Analogicky u programování.

Ale najednou se objeví jedna souvislost, druhá, třetí a už to jede.
Tady na první úrovni pomůže přemýšlet o návrhu kódu a psát kód tak, aby byl snadno rozšiřitelný.
V uvedeném příkladu:
Identifikoval jsem uživatele jako entitu v systému. Z toho vyplývá, že budu potřebovat objekt(y) reprezentující uživatele. Zjistil jsem, že potřebuji o uživatelích držet nějaká data. Skoro u všeho, o čem se drží data, jsou potřeba čtyři základní operace zvané CRUD: Create, Read, Update, Destroy. Takže budu nejspíš na příslušném místě* potřebovat ty čtyři operace pro uživatele.

když někdo první přístup zabije a vrátí se k němu později, tak se dostane do přesně té samé situace.
Zvláštní. Pokud už něco uložil, není problém to aktualizovat. Pokud ještě nic neuložil, má se teprve záznam vytvořit.
Tady nejspíš problém bude konstrukce podmínky, kdy se má dělat INSERT a kdy UPDATE.
CZghost
Profil
jenikkozak:
V tom mu asi málokdo poradí. Všude se řeší konkrétní problémy, to by si musel přečíst nějaký článek, jak si správně naplánovat práci, aby potom nemusel zbytečně ladit spoustu chyb. Stejně bude mít práci plně ve svojí režii, nikdo tu práci za něj neudělá, to by si ji musel zaplatit.

final:
Nejlepší bude si asi neprve sepsat osnovu, co vlastně chcete dělat a co by to mělo dělat. Potom si nakreslit vývojový diagram, jak to bude fungovat, klidně na to spotřebujte celý balík papíru :-) potom si napsat základní kostru a doplnit kód. Víc Vám poradit nemůžu, je to Vaše práce, my ji za Vás udělat nemůžeme. to už si budete muset zrežírovat Vy sám. Každopádně budete muset ladit chyby, nikdo není dokonalý, aby hned napoprvé napsal bezchybný kód.
Koukám, že mě Joker předběhl :-) Tak jsem v podstatě opapouškoval a shrnul jeho slova :-)
Medvídek
Profil
Jcas:
Co se týká funkcí, raději předávám pole parameterů (samozřejmě záleží na situaci, ale dopředu vždy vím, co tou funkcí budu chtít obstarávat).

$params = array(
        'Targets'           =>  array($customerMail),
        'SenderAddress'     =>  'zakaznicka.linka@xxx.cz',
        'SenderName'        =>  'Zákaznická linka XXX',
        'LanguageCode'      =>  'cs',
        'DistributorId'     =>  '1112',
        'TemplateName'      =>  'XXXApp-InfoMail',
        'HiddenTargets'     =>  array('janda@xxx.cz', 'zavrel@xxx.cz'),
        'Values'            =>  array(
            "M" => array(
                "Subject"   =>  $subject, 
                "Message"   =>  $message, 
            )
        )
    );
    
    if(isset($file) AND file_exists(CSV_PATH.FTP_CSV_NAME)){
        $params['Attachments']  =  array(
            array(
                'FileName'      => FTP_CSV_NAME,
                'Path'          => CSV_RPC_PATH.FTP_CSV_NAME,
                'ContentType'   => 'text/x-csv', 
                'Encoding'      => 'base64'
            )
        ); 
   }
   
   $emailResponse = RpcAutoLoginCall('Message.Send', 'Email', $params);
   
Actimel
Profil
Tady asi těžko radit něco konkrétního, protože každý bude mít k vývoji trochu jiný přístup.

Třeba já jsem po několika pokusech se složitým plánováním, snažením se si představit danou situaci a vymyslet na to něco strašně skvělého a efektivního. Když jsem něco takového už měl v hlavě nebo na papíře a snažil se to přenést do kódu, téměř vždy jsem přišel na to, že jsem zanedbal nějakou maličkost nebo dokonce i nějakou závislost. Takže veškeré plánování, které zabralo spoustu času, bylo v podstatě zbytečné. Tak jsem začal více programovat než plánovat, vždy jen něco promyslím, představím pár situací a programuji. Jak to mám napsané, tak to projdu vyzkouším a snažím se kód ještě co nejvíce zjednodušit a zefektivnit.

Myslím si, že je důležité se naučit kód přepisovat, než to smazat a začít psát znovu. I přes to, že to přepisování bývá hodně nepříjemné, bývá rychlejší a méně bolestivé, než dělání dané věci znovu.

Ale jak jsem psal na úvod, každému bude vyhovovat něco jiného, jen si myslím, že jako začátečníkovi, je zbytečné trávit příliš mnoho času na papíře.
Joker
Profil
Jcas:
Ještě jsem zapomněl napsat, že samozřejmě přemýšlet dopředu na té základní úrovni dost pomůže, aby se kód nemusel pořád předělávat, ale jinak je úplně normální, že se průběžně mění požadavky a ukáže se, že doposud dobře fungující kód je potřeba nějak upravit.
Tomu se říká refaktoring a je to docela běžné.
Ale týká se to úpravy aplikace pro nové požadavky, ne neustálého předělávání kódu při tvorbě jednoho zadání.

CZghost:
Já bych doporučil programovat objektově a v tom případě bych vývojové diagramy vynechal.

Spíš bych začal tím, co se honosně jmenuje use case diagram. Prostě si vezmu mou (budoucí) aplikaci a kdo (co) všechno tu aplikaci má používat. Což samozřejmě neznamená „Pepa, Jana, můj notebook, …“, ale role, např. uživatel, administrátor, atd. (Jeden konkrétní člověk může mít víc roli, takže třeba že Pepa je administrátor, ale zároveň může aplikaci používat i jako normální uživatel, ničemu nevadí, prostě má dvě role.)
Pak dám pro každého z nich dohromady, co všechno může s aplikací dělat (třeba uživatel si může založit účet, může se přihlásit, odhlásit, …).
A pak si pro každé použití udělám seznam, co se při něm všechno musí stát/udělat.
Jcas
Profil *
Pěkně jste se rozpovídali. Děkuji.
Nazval jsem to pouze pokec schválně. Nechci řešit konkrétní věc. Jediné to konkrétní je to naplánovaní práce.
Kreslení diagramů mi fakt nejde. Když někde vidím nějaký namalovaný, tak ho většinou pochopím a je to super. Ale jak si ho mám namalovat sám, tak to je hrůza.

Jinak jsem nyní zkoušel novinku a je to dost dobrý. Začít komentáři. Udělat si takovou osnovu a pak ji vyplnit kodem.

// připojit potřebné soubory
// ověřit přístup na stránku
// načíst data z DB
// IF - byl odeslán FORM
   // - kontrola formuláře
// ELSE - Form ještě nebyl odeslán
atd. atd
yFang
Profil
Jcas:
Většinou, když děláš nějakou aplikaci, si nevystačíš s jedním skriptem, je potřeba je nějak propojovat, aby to logicky dávalo smysl a bylo to udržovatelné a rozšiřitelné (žádná aplikace nezůstane v podobě, ve které byla vytvořena). V aktuálně používaných PHP frameworcích se používá architektura MVC (Model, View, Controller) nebo něco obdobného, myslím, že by pro tebe mohlo být zajímavé, něco si o tom přečíst. Ne nutně o nějakém frameworku, ale obecně, jak MVC funguje.
Pokud nemáš vůbec zkušenosti s OOP, doporučuji začít nejprve nějakými základy o objektovém programování, naučit se přemýšlet o programu trochu jinak, než jen jako o nudli kódu, která něco dělá, tak jak je napsaná.

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm: