PHP Centeri avaleht Skriptikogu Küsimuste-vastuste leht Teadete vaatamine ja saatmine Foorum - koht küsimiseks Otsingumootor Siit saad infot meie kohta

Kasutajanimi:  
  Parool: 
  Registreeri!   Unustasid salasõna?

Foorumid Programmeerimine Kogemused Disainifilosoofia
Autor Abi Postitus Abi

hardip

Postitusi: 32
Tase: 3
Olek: Offline

Hinnang: Administratiivhinnang: 4/10Administratiivhinnang: 4/10Administratiivhinnang: 4/10Administratiivhinnang: 4/10
Disainifilosoofia

PHP kood:


//tagastab kas boolean true või integer -1
function funktsioon1() {
   if (
== 1) return true
   
else return -1;
}



Nüüd kui tahaksin ehitada teise funktsiooni - 'funktsioon2', mis kasutab 'funktsioon1'-te.
Kas funktsioon2 võib [eetiliselt] 100% eeldada, et funktsioon1 tagastab alati lubatud väärtused/väärtustüübid, või peaks funktsioon2 tegema ka omapoolse kontrolli?

Millist stiili üldiselt kasutatakse ja milline on kõige praktikas kõige jätkusuutlikum?

29.06.2008 22:14:42 Vajutades siia näed kasutaja hardip profiili

fax
Upsakas kontoritarve

Postitusi: 1195
Tase: 9
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Jah ja ei. Kui sulon rangelt tegemist nii öelda internal funktsioonidega, ja sa tead mis sealt kindlasti tuleb ja funktsioon midagi ootamatut ei tagasta või siis üldse vastust võlgu ei jää. Ise kasutan toppelt kontrolli, seda ka põhjusel, et teine kord suudab PHP oma patchleveli uuendamisel ka "imeliselt" käituma hakata ja näiliselt lihtsate funktsioonide puhul täiesti jaburaid asju tagastada või siis lihtsalt "huvitavalt" funktsioneerida.. Ja eks teadnud vanarahvas juba rääkida et toppelt ei kärise

___________________________________________________
Kui olete saanud täna hommikul hakkama 6 võimatu asjaga, miks siis mitte lisada sellele veel programmeerimine ?

29.06.2008 22:25:04 Vajutades siia näed kasutaja fax profiili

hardip

Postitusi: 32
Tase: 3
Olek: Offline

Hinnang: Administratiivhinnang: 4/10Administratiivhinnang: 4/10Administratiivhinnang: 4/10Administratiivhinnang: 4/10
RE: Disainifilosoofia

Seega, kui uuendada funktsioon1-e definitsiooni, siis peaks muutma ka kõikide teiste funktsioonide koodi, mis sellele tuginevad ["topelt ei kärise" tagajärg].

Pikkade ahelfunktsioonidega tekiks jälle ka see probleem, et tagastatavaid võimalusi tekiks järjest juurde - kui lisada veateateid alamfunktsioonide tagastiste kohta...

29.06.2008 22:31:37 Vajutades siia näed kasutaja hardip profiili

fax
Upsakas kontoritarve

Postitusi: 1195
Tase: 9
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Ma ise olen koodi disainis võtnud aluseks unixi filosoofia, et üks käsk ehk php's funktsioon peab ühte asja tegema aga seda hästi -- muidugi funktsiooni väiksuse siiski hoian selle piiri peal, et funktsioon ise mõttetu poleks aga samas, ei hakkaks lohisema stiilis, et keedab koob ja küpsetab. Ja funktsioonid kirjutan siis nii läbi planeeritult, et ka muutumise vajadusel säiliks ühilduvus teiste funktsioonidega.. Vähemalt ise pean seda halvaks koodi disainiks kui nii öelda internal funktsiooni muutmise tagajärjel pean hakkama teisi funktsioone üle käima, mis temast sõltuvad. Küll jah kui tõesti tekib vajadus tekitada funktsioonile juurde miski lisa omadus siis püüan seda alati sedasi teha, et olemasolevat ühilduvust ei lõhu ja samas uued temast sõltuvad funktsioonid saaksid uusi omadusi kasutada.. Aga eks elukutselised progejad kommenteerivad täpsemalt..

___________________________________________________
Kui olete saanud täna hommikul hakkama 6 võimatu asjaga, miks siis mitte lisada sellele veel programmeerimine ?

29.06.2008 22:47:49 Vajutades siia näed kasutaja fax profiili

balduran

Postitusi: 21
Tase: 2
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Peaksin ära mainima, et funktsioon2 ei tohiks kontrollida funktsioon1 tulemus mitte kunagi!!
Iga funktsiooni kasutamise eelduseks peab olema, et funktsioon tagastab alati soovitud väärtuse. (Või eeldatava vea, aga mitte kogematta mingit suvalist jura)

Üldiselt PHP-s funktsioone ei tohiks kasutada. Vahel on vaja, aga siis minimaalselt. Lõppeb sellega, et app läheb keeruliseks. (OOP on võtmesõna)

Nüüd aga tekibki küsimus, et mis siis kui ma funktsioon1-te muudan, siis läheb kõik ju katki
Vastus sellele on unit-testing. Ehk siis on olemas testid, mis testivad su igat funktsiooni. Kui kirjutad funktsiooni kirjutad sellele ka testid mis kontrollivad kas ta ikka teeb seda mis peaks tegema. Kui midagi muudad ja eelnev funktsioneerimine enam ei toimi, siis test kukub läbi ja kohe näed, et ahhhaaa, viga ja saad uurida, et milles probleem.
Soovitan uurida unit testimise kohta. Teeb suuremate applikatsioonide arendamise kordi lihtsamaks.
PHP-le hea library selleks on simpeltest.

Siin aga kindlasti küsige endalt, et kui suurt asja te ikkagi teete. Kui teete lihtsat kodulehte, siis on see overkill, aga kui juba keerukamat süsteemi, siis on see väga hea. Võtab veidi rohkem aega, aga hilisemaid arendusi on väga mugav teha, sest ära rikkumise oht on minimaalne.

Ja nüüd lugesin kuupäeva, et ilgelt vana teema... aga no kui jutt on juba olemas...

18.10.2008 23:48:09 Vajutades siia näed kasutaja balduran profiili

morgoth
Koodikindral


Postitusi: 395
Tase: 6
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Suht asjalik jutt baldurani poolt, liigutan vastavasse alafoorumisse, et oleks ka teistele õpetuseks.

20.10.2008 23:55:40 Vajutades siia näed kasutaja morgoth profiili

paawo


Postitusi: 83
Tase: 4
Olek: Offline

Hinnang: Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10
RE: Disainifilosoofia

* Ära kunagi väärtusi otse väljasta. Sul on ju kaks infotüüpi vaja eri kohtadesse suunata. Saadud info väljastada ja viga salvestada koodiarendajale nägemiseks. Nii saab $v2ljund olla järgmisesse funktsiooni jõudnuna ainult tühi või täidetud (loe - õige info).
* Kirjuta igale infot töötlevale tegevusele juurde ka vastav vealause. Pole ju mõtet mingst debuggerist rääkida kui pool koodi töötab puha jumala abiga.
* Kõigepealt analüüsi, mida sa antud koodiga tahad saavutada. Ühte asja annab vähemalt 4 moodi kirjutada.
PHP kood:

<?php

$sisend 
'piits';
if(isset(
$sisend)) 
{
    
$v2ljund 'laisk';
}
 else 
{
    
$viga 'ei tööta';
}

############################################

function tsirkus($sisend$v2ljund$viga
{
    if(isset(
$sisend)) 
    {

        switch(
$sisend
        {
            case 
'piits':

            
$v2ljund 'laisk';
 
            break;

            case 
'pr22nik':

            
$v2ljund 'usin';

            break;

            default: 

                
$viga 'ei tööta';
        }
    }
}

############################################

function piits($sisend$v2ljund$viga
{

    if(isset(
$sisend)) 
    {
        
$v2ljund 'laisk';
    }
     else 
    {
            
$viga 'ei tööta';
    }

}

function 
pr22nik($sisend$v2ljund$viga
{

    if(isset(
$sisend)) 
    {
        
$v2ljund 'usin';
    }
     else 
    {
            
$viga 'ei tööta';
    }

}

############################################

class tsirkus
{

    function 
piits($sisend$v2ljund
    {

        if(isset(
$sisend)) 
        {
            
$v2ljund 'laisk';
        }
         else 
        {
            
viga($sisend$v2ljund);
        }
    }

    function 
pr22nik($sisend$v2ljund
    {

        if(isset(
$sisend)) 
        {
            
$v2ljund 'usin';
        }
         else 
        {
            
viga($sisend$v2ljund);
        }
    }

    function 
viga($sisend$v2ljund
    {

        if(isset(
$sisend)) 
        {
            
$v2ljund 'ei tööta';
        } 
    }

}

?>


1. Kui kirjutad midagi lihtsat, mis terve projekti jooksul ainult korra kasutatakse siis las see olla otse loodi lahti kirjutatud;
2. Kui koodi oleks mitmes eri osas vaja aga selle eri osad töötlevad ühte tüüpi infot siis kirjuta see ühe funktsioonina; a.la. andmebaasist tuleva väga pika infojada lehekülgedeks jaotamine - ühte tüüpi kindel ülesanne.
3. Kui töö käigus on vaja tegeleda mitme eri tüüpi tegevustega (mille osa võib täenäoliselt vaja minna ka mõne muu ülesande jaoks) siis kirjuta mitu funktsiooni. - a.la. template töötamine koosneb vähemalt kahte erinevat tüüpi tegevusest: tekstifaili stringiks lugemisest ja stringist väärtuste ümbernimetamisest.
4. Kui koodi töötlemiseks vajaminevad väärtused on muutuvad kahe eri lehekülje vahel siis kirjuta need classi.
Ja enamus väärtusi, millega sa tegeled on alati väga kindlalt määratletud. ntx. templatet parseldad sa ju igal lehel sama rutiiniga ja lingid tekivad samuti lehe päisesse ja jalusesse sama koodiga.
Aga meetmed mis vajavad klassi on ntx. lehe enda eri osade kokkupanek: päis, meta-info, js (on/pole leheküljel), css(on/pole leheküljel), body (mingi public moodul või administratsiooniosa), jalus. Siin on andmed äärmiselt muutlikud ja on mõtet klassi kasutada et vajaminevaid asju pidevalt vahetada.
Kahjuks enamik programeerijaid, kes pruugivad küll poolte probleemide kodeerimiskäigu unepealt õieti ära öelda, võtnud pähe mõtte, et class-id on mingi de-facto standard milles kõike tuleb enamasti kirjutada ja analüüsivad oma koodi samapalju kui tigu mõtleb tuumafüüsikast.

Seda postitust on muudetud 2 korda (viimati muudeti 2008-10-22 15:26:42 paawo poolt)

22.10.2008 15:15:13 Vajutades siia näed kasutaja paawo profiili

muidumeez
Ignorantia non est
argumentum


Postitusi: 3864
Tase: Administraator
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Tsiteeritud tekst:
Kahjuks enamik programeerijaid, kes pruugivad küll poolte probleemide kodeerimiskäigu unepealt õieti ära öelda, võtnud pähe mõtte, et class-id on mingi de-facto standard milles kõike tuleb enamasti kirjutada ja analüüsivad oma koodi samapalju kui tigu mõtleb tuumafüüsikast.

Esiteks, eesti keeles on klassid, mitte class-id. Teiseks, klasside kasutamine ei ole mingi stadard, vaid klasse kasutatakse OOP paradigmas, mis ei ole mingi stiil, vaid mõte. Siduda klasside kasutamist vähese analüüsivõimega on tiba pentsik, et mitte öelda rumal. Nagu ühes teiseski teemas juttu oli, et pole oluline, millises stiilis (või paradigmas) sa kirjutad, kui kood on pask, siis on ta pask.

___________________________________________________
An Opinion Is Like An Asshole -- Everybody Has One

22.10.2008 16:32:17 Vajutades siia näed kasutaja muidumeez profiili

paawo


Postitusi: 83
Tase: 4
Olek: Offline

Hinnang: Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10
RE: Disainifilosoofia

Seda muidugi, koodil ja koodil on alati vahe - pasa kirjutamist ei vabanda miski.
Ma tahtsin lihtsalt tähelepanu juhtida, et see ObiektOrienteeritud Programeerimises kokkulepitud klassipõhised aated pole minu tähelepanekute kohaselt kõige praktilisem viis asjade kirjapanekuks.
Usin pisifirmjuht, kes tavaelus palkab kenastitoimivasse paarist inimesest koosnevasse muhedasse tööseltskonda suhtekorraldaja lihtsalt sellepärast, et tema tuttav suurfirmaomanik on seda sunnitud oma firmas tegema on minuarust sama pentsik kui mõni usin programeerija kirjutab kindla sisendi ja väljundiga koodilõigu klassina. Kõige effektiivsem tuleb kood, mis on minu märgitud 4 arendutsükklit läbides jäänud omale sobivasse kohta pidama. Aga egas probleemi polegi enne selle tunnistamist olemas ja ühel meist on alati vähem õigus. Tehke sellest kõigest omad järeldused ja kirjutage koodi nagu ise paremaks peate.

22.10.2008 18:16:04 Vajutades siia näed kasutaja paawo profiili

balduran

Postitusi: 21
Tase: 2
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Paar mõtet mis mulle veel pähe torkasid...

Olenevalt veast tasuks ka ära mainida Exceptionid (PHP 5-s täiesti olemas)
Nende kaitseks lihtne lause "Vahel tekivad vead kohas kus nendega ei osata veel midagi peale hakata, aga kuskil kaugemal oleks selleks ideaalne koht." Returnidega on aga sinna ideaalsesse kohta raske jõuda, try {} catch() {} teeb aga imet.

paawo koodi puhul jäi silma, et väljund antakse argumendina. Koodis polnud &$valjund, &$viga jne... (reference peaks vist ka olema). Igaksjuhuks, et kui keegi loeb seda näidet... ei taha tähti närida
Omapärane stiil muidugi PHP jaoks.

Üldiselt võibki vaidlema jääda, et mis/kuidas õige on kui ei ole määratud projekti suurust/mahtu.

Pisikese asja jaoks kõlbab põhimõtteliselt mida iganes. Kui see sai kähku (päev-kaks) valmis, siis on seda ka ju odav hiljem paremini uuesti teha
Keskmiste/Suurte projektidega aga tasub mõelda VÄGA palju arhitektuurile ja kuidas asja üles ehitada. Neil on väga kuri omadus ajas muutuda - EHK tuleks saavutada lihtne laiendatavus.

Klasside plussid on väga suured kui projektil on keeruline äriloogika. (Kuhugi lisatakse see, siis tuleb sinna panna uus hind ja kuhugi mujale lisada veel see. Kuna aga kuhugi mujale lisati nüüd see, siis tee veel seda ja seda jne... Kui seda lisamist tehakse ühes kohas, on kõik nummi, aga kui neljas kohas ja veel pisut erinevat moodi on põrgu lahti OO lähenemisega aga saab selliseid juhte üsna selgelt ära lahendada.)

Klassidega on asju väga hea kirja panna, kuna nad imiteerivad realset elu.
Kasutaja ja tema
omadused (private $username, private $password) ja
tegevused (public function logout()),
staatilised/üldised tegevused (public static function login( $username, $password) )

Funktsioonidega on sellist asja palju keerukam kirja panna.
Tulemuseks oleks manual, siis:
Manuali tuleks ikka leht Kasutaja ja tema võimalused... aga kõik oleks väga hajus...

Jälle pikk jutt hilja öösel.. :p



23.10.2008 02:23:59 Vajutades siia näed kasutaja balduran profiili

paawo


Postitusi: 83
Tase: 4
Olek: Offline

Hinnang: Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10
RE: Disainifilosoofia

Tsiteeritud tekst:
Üldiselt võibki vaidlema jääda, et mis/kuidas õige on kui ei ole määratud projekti suurust/mahtu.

Pisikese asja jaoks kõlbab põhimõtteliselt mida iganes. Kui see sai kähku (päev-kaks) valmis, siis on seda ka ju odav hiljem paremini uuesti teha
Keskmiste/Suurte projektidega aga tasub mõelda VÄGA palju arhitektuurile ja kuidas asja üles ehitada. Neil on väga kuri omadus ajas muutuda - EHK tuleks saavutada lihtne laiendatavus.

Klasside plussid on väga suured kui projektil on keeruline äriloogika. (Kuhugi lisatakse see, siis tuleb sinna panna uus hind ja kuhugi mujale lisada veel see. Kuna aga kuhugi mujale lisati nüüd see, siis tee veel seda ja seda jne... Kui seda lisamist tehakse ühes kohas, on kõik nummi, aga kui neljas kohas ja veel pisut erinevat moodi on põrgu lahti OO lähenemisega aga saab selliseid juhte üsna selgelt ära lahendada.)


See on muidugi õige, et funktsioonidele ei anna hästi erinevaid väärtusi ette sööta.
Väärtusi võib tulla eri kohtades väga erineval hulgal.

Näiteks teeme päringu tabelistest tabel1, tabel2, tabel3 info välja võtmiseks,
kus vaja kätte saada
tabel1 id ja group,
tabel2 name ja group_id mis vastaks tabel1 id-le ning
table3 value ja name_id mis vastaks tabel2 id-le nimg kuvaks 5 väärtuse

Klassil on hea, saab juurde lisada ainult need väärtused mida hetkel töödelda on vaja:

PHP kood:

$info =  NEW data();
$what "SELECT id, group FROM tabel1";
$info -> sql($what);
$what "SELECT name, group_id FROM tabel2 WHERE table1.id='table2.group_id'";
$info -> sql($what);
$what "SELECT value, name_id FROM tabel3 WHERE table2.id='table3.name_id' AND table3.id='5'";
$info -> sql($what);
$how '<div>{tabel1.group}: {table2.name} ({table3.value})</div>';
$info -> get($how);
$info -> error();
print 
$info -> $get_data;



Mulle aga tundus see üsna lohisev ja liiga pikalt kirjutatav kood.
Nii ma töötasingi välja stringitöötlus-loogika, mis annab väga lihtsa süntaksiga funktsiooni edasi keerukad väärtusteseosed sama edukalt kui seda teeb klass.

PHP kood:

$get_what 'tabel1: id, group | tabel2: group_id[ tabel1&id; ], name | tabel3: name_id[ tabel2&id; ! JOIN.left; AND(5); ], value';
$get_how '<div>{tabel1.group}: {table2.name} ({table3.value})</div>';
get_data($get_what$get_how$get_err$get_info);
if((empty(
$get_err)) && (isset($get_info))) 
{
    echo 
$get_info;
}
 else 
{
    echo 
$get_err;
}



<- andmete kättesaamine andmebaasist on üks kindel ülesanne, millel on kindlad sisend ja väljundväärtused ja ma saan sellele funktsioonile edasi anda seostatud väärtusi sama edukalt kui klassiga. Ja kõige naljakam on see, mida keerulisemaks kood läheb, seda kergem on minu koodiga väärtusi edasi anda - midagi peale väärtuste enda pole vaja juurde kirjutada!
Hakkab mingi vahe välja kooruma, keeruliselt koostatava, teiste tarkusel põhineva, tölbi konveierkoodi ja oma koodi võimekuse võimalikult kergelt kirjutada püüdmise vahel?

23.10.2008 04:52:28 Vajutades siia näed kasutaja paawo profiili

balduran

Postitusi: 21
Tase: 2
Olek: Offline

Hinnang: Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10Administratiivhinnang: 10/10
RE: Disainifilosoofia

Minu kogemus näitab aga seda, et just muutmine ja lisamine on keerulised protsessid. Infot kätte saada on väga lihtne.

See kuidas sa seda infot praegu välja võtsid on muidugi üks variant. Minu kogemuse järgi kui on vaja lihtsalt infot kätte saada ei tasuks (ega tohikski) kasutada klassi. Palju parem on array, sest array on palju kiirem kui objekt.

Kui ma nüüd mööda ei pannud, siis antud päring  peaks olema realiseeritud siiski niimodi:
SELECT t1.id, t1.group, t2.name, t2.group_id, t3.value, t3.name_id FROM tabel1 as t1
LEFT JOIN tabel2  as t2 ON (t1.id = t2.group_id)
LEFT JOIN table3 as t3 ON (t2.id = t3.name_id)
WHERE t3.id = 5
Ja tulemuseks võiks täiesti vabalt olla array. Seda juhul, kui me ei tegele info muutmisega, vaid kuvamisega.
(Olenevalt tabelite sisudest tuleks joinide järjekordi muuta, kas FROM osa - saab parema performance. Näiteks t3 peaks olema kindlasti FROM osas. Ei ole mõtet otsida välja kõik veerud tabelist1, joinida need tabeli2-ga ja siis võtta ainult see mille t3-e id on 5.)

Minu mõttemaailm keerleb ORM/ActveRecord patternite ümber ja see tähendab, et kui ma tahan kasutada objekti tabelist 1,2,3 siis tulebki kolm objekti mida ma siis muuta saan. (Mitte üks nagu sinu näites)
Sinu näite objekt on hajusa struktuuriga ja sama hea kui array.


Kujundust ei tohiks ÜLDSE andmebaasi layerisse toppida. See peaks olema täiesti teine teema.

Aga eks igalühel on omad meetodid ja igal meetodil omad plussid ja miinused.. Igaüks valib meetodi selle järgi mis tundub temale/ja projektidele  parim. Oluline on olla aga tuttav erinevate meetoditega!




23.10.2008 18:15:58 Vajutades siia näed kasutaja balduran profiili

paawo


Postitusi: 83
Tase: 4
Olek: Offline

Hinnang: Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10Administratiivhinnang: 5/10
RE: Disainifilosoofia

Väga õiged tähelepanekud.
Hoidsin kirjutusstiili lahmiva ning näited pinnapealsed, et leiduks ikka vastajaid kes tõestaks mu väidetele vastupidist. Aga konstruktiivset kriitikat tuleb õnneks niisamagi
Eks ma vaevusingi sõna võtma, et teised prooviks ka rohkem kastiväliselt mõelda.
Igatahes mulle pakub programeerimise juures kõige rohkem huvi just olemasolevate protsside analüüsimine ja ümbermodeleerimine universaalsemate koostamislahenduse leidmiseks - lõpuks ju taandub ju kõik scripti koostamiseks kuluvale ajale. Kas sa töötad siis lahendusega mis on nii puhevile aetud et 50 programeerijal kulub selle koostamisele 50 päeva või oled suutnud välja töötada lahenduskäigu kus 5 progrejat saavad 5 päevaga sama tulemusega hakkama.

23.10.2008 22:07:01 Vajutades siia näed kasutaja paawo profiili
Kokku: 25949 registreerunud kasutajat, 9711 teemat, 54603 postitust.
Täna on laupäev, 19. oktoober 2019. Kell on 00:17.

    Vaata selle lehe printerisõbralikku versiooni

Avaleht   -    Skriptikogu   -    Teated   -    Foorum   -    Reklaam   -    Tagasiside   -    Kasutamise reeglid

© Copyright 2002-2019 PHP Center. Kõik õigused reserveeritud.