Jump to content
php.lv forumi

PHP, OOP un plānošana


eglitis

Recommended Posts

vismaz man skjiet, ka visus tos UML un citus riikus izmanto kur ir tieshaam nopietni projekti. apjomiigus darbus taisiit peec uudenskrituma metodes ir kaa ir.

21020[/snapback]

 

Pat apjomiigiem darbiem reaali visbiezhaak tiek izmantota prototipeeshana, jo klienti nehera nejeedz, ko vinjiem iisti vajag.

 

Bet kaut kaadas nelielas webaplikaacijas galveno ideju es parasti uzkjeepaaju ar rakstaamriiku uz papiira.

Link to comment
Share on other sites

Mani arī nomoka šis jautājums.

Pagaidām puslīdz uz papīra uzmetumu uztaisu un aiziet, bet..

 

Varbūt vajag tā:

...

1.Apskatās vai iekš DB jau neeksistē tāds mainīgais

1.1. Ja eksistē - Neko nedaram.

1.2. Ja neeksistē - pieveinojam.

2.Noķeram POST

2.1.Pārbaudam vai visi mainīgie eksistē

2.1.1.Eksistē - Pārsūtam uz galveno lapu

2.1.2.Neekistē - atmetam uz reģistrācijas lapu

2.2. Ja eksistē mainīgais x, tad aizūtam meilu uz adresi x

2.2.1. Neizdevās nosūtīt - paziņo par neveiksmi

2.2.2. izdevās - redirektējam uz reģistrācijas un paskam, ka meils nosūtīts

3. blablabls

...

 

Mēģināju aptuveni nodemonstrēt vienā failā notiekošo. (Tas nav reāls fails, tikai piemērs)

 

No otras puses - kamēr šādu sarakstu sarakstīs, paies ievērojams laiks...

 

--------------------

Cits variants - vienu un to pašu funkciju aprakstot:

A:

1. izveidojam defaulto mapīti

B:

1.Apskatamies vai mape eksistē

1.1. Ja eksiste.....

1.2. Ja neeksistee...

 

Domāts īsā un garāka varianta apraksts.

-----------------------

 

Pēc šāda principa (sīka iztirzājuma) esmu rakstījis vienu projektu. Bija pilnīgs murgs sarakstīt, bet kodējot nekas nebija jāpiedomā - tikai jāprogrammē un jāiemet acs ko tad nu jādara tālāk...

 

 

Varbūt ir kaut kas labāks, kā uztaisīt foršu struktūriņu?

man nepatīk tie Visio un taml. jo kad viņos sataisa - tā vai tā ir diezgan sarežģīts tas izskats..

Link to comment
Share on other sites

1.Apskatās vai iekš DB jau neeksistē tāds mainīgais

1.1. Ja eksistē - Neko nedaram.

1.2. Ja neeksistē - pieveinojam.

2.Noķeram POST

2.1.Pārbaudam vai visi mainīgie eksistē

2.1.1.Eksistē - Pārsūtam uz galveno lapu

Tas, ko veic tu, ir pseidokoda rakstīšana. Arī tas ir paņēmiens, bet pseidokodam i daudzas nepilnības, piemēram, tas nesniedz pietiekami pārskatāmu kopattēlu. Sīkai detalizācijai gan der perfekti - šādi var izveidot sarežģītus algoritmus un pēc tam ērti pārtulkot vajadzīgajā programmēšanas valodā. Bet vienkāršiem algoritmiem tas, manuprāt, ir lieks laika kavēklis.

Edited by eglitis
Link to comment
Share on other sites

man nepatīk tie Visio un taml. jo kad viņos sataisa - tā vai tā ir diezgan sarežģīts tas izskats..

Nu nav jau tik traki.. Blokshēmas sanāk ok un var krietni vienkāršāk vizuāli saprast notikumu gaidu un procesu nosacījumus..

Link to comment
Share on other sites

Plaanoshana notiek uz papiira, ja plaanoju prieksh citiem - notiek papiirs --> .doc konvertaacija.

 

Izstraadaaju datu baazes modeli.

Izstraadaaju aptuvenu funkcionaalo modeli.

Uz papiira saziimeeju galvenaas klases, aprakstu pinjkjeriigaako metozhu darbiibu, uzlieku uzsvarus, kur vajag uz aatrumu, kur vajag uz modificeejamiibu u.t.t.

 

Buutiibaa projekteejums ir ljoti nenoteests un aptuvens, un programmeetaajam tiek dota diezgan liela riiciibas briiviiba. Laika gaitaa ir pieraadiijies, ka projekteejums ljoti paaatrina kopeejo izstraadi, bet paarlieku siiks projekteejums nav nepiecieshams un, jo siikaak projekteejam, jo vieglaak ielaist kljuudas. Bet iisteniibaa daliijums buutu jaaizveertee peec projekteetaaja un to, kas projektu kodees, kompetences.

Link to comment
Share on other sites

mums skolaa maaciija taadu tuuli kaa Grade, arii laba manta.

21095[/snapback]

 

Fun fact: Grade ir NE formaataa - EXE failu formaats, ko Microsoft izstraadaaja speciaali Windows 3.x sisteemaam.

Es skaidri redzu, ka akadeemikjiem liekas, ka interfeiss neko nenoziimee (tie, kam naacies sadarboties ar DI, sapratiis), bet nu kaa tiem pasniedzeejaiem nav kauns slaveet aizveesturisku riiku kaa pashu labaako un paardot taadu, nemaz nedomaajot par uzlaboshanu? Blah. Varu dereet, ka vinji tur taa sakodeejushi, ka uzlaboshanu veikt tagad ir praktiski neiespeejami. Nejeegas.

Link to comment
Share on other sites

Par šīm lietām ir vērts sākt domāt tikai tad, ja projektā atbildība ir dalīta un projekts ir liels. Savādāk nevienam tas nav vajadzīgs. Pat ieviešot biznesa vadības sistēmas shēmas tiek zīmētas tā ļoti nosacīti un parasti aprobežojas ar use-case diagrammām. Normāli programmeris pats visu izdomā un uztaisa. Piesaistot relatīvi nelieliem projektiem kaut kādus sistēmanalītiķus un shēmu zīmētājus - izlietoto resursu overheads diemžēl ir stipri par lielu - viens otru nesaprot, dalās domas par metodēm un 80% laika aiziet diskusijās par virtuālo optimumu, kā rezultātā pat ja šis optimums tiek sasniegts, rezultāts ir ~10% labāks par to, kas būtu radies, ja koderis būtu strādājis viens.

 

Par cik tehnisko dokumentāciju tāpat neviens neraksta, tad drūmā realitāte ir tāda, ka ja koderis aiziet no darba, uzņēmums zaudē klientus. Un tiešais cēlonis tam ir tas, ka vienmēr visiem visu vajag jau vakar, un mūsu nabadzīgajā valstī proj.vad. pats sevi ir gatavs apsolīt klientam verdzībā, lai tik dabūtu kārtējo pasūtījumu. Kamēr no katra kodera ir atkarīgi tikai daži klienti tikmēr OK - neviens īpaši nepārdzīvo - suņi rej, karavāna anyway kustās - tāda dzīve. Bet ja tiek veidots softs, kuru plānots pārdot 100+ kopijās, tad jau varbūt arī kāds sāk aizdomāties - "a kas būs ja notiks šitā..." un pievērst uzmanību sīkumiem, t.sk. dokumentācijām, testēšanai, performancei un tml. A par cik web projekta vai weblapas izstrāde (šis tomēr ir php forums) ir katram klientam ar kaut ko unikāls pasākums, kur budžets tipiski ir zem 1000 Ls, tad nafig palielināt izstrādei nepieciešamo resursu vairākas reizes??? Galvenais lai viss ir strādājošs un ātri gatavs. Beta-notestēs pats klients :)

 

Pēdējo gadu laikā esmu pastrādājis kādos programmēšanas 4 uzņēmumos (visi diezgan labi pazīstami LV, viens no viņiem UK), no kuriem divos taisīju web-based projektus, otros divos kodēju risinājumus vienai grāmatvedības/ERP sistēmai - diemžēl klašu diagrammas un tml. plānošanas esmu redzējis tikai tik pat daudz cik jūs visi - respektīvi - aiz neko darīt pats mēģinājis zīmēt. Varbūt nav noveicies vienkārši... :(

 

No softa pasūtītāja parasti par daudz prasīts ir jau tas, ka šis skaidri spēj nodefinēt savas prasības. Un no proj.vad/konsultanta/analītiķa (nu whatever - kurš uzklausa klientu) ir par daudz prasīts lai viņš kaut ko adekvāti saprastu. Un šajā atklāsmes stadijā sāk likties, ka ne waterfalls, nedz arī rapid metodoloģijas te neiet cauri - softu jāsāk rakstīt no user manuāļa :) Bet tipiski ir tā, ka klients grib kaut ko vienu, koderis uztaisa kā viņš to lietu redz, un klients, kad viņam pārgājis pirmais šoks no ieraudzītā, piekrīt uz kompromisu - t.i. - uzlabot to kas ir uztaisīts lai varētu darīt lietas kā viņš ir iedomājies, savādāk viņš pārtērēs savu budžetu reizes 3 :) Protams no tā var izvairīties, ilgstoši kopā ar klientu analizējot viņa problēmas, bet tad patiešām pati kodēšana sastāda max. 30% no visa darba, un tam šeit neviens nav gatavs morāli.

Link to comment
Share on other sites

×
×
  • Create New...