Jau nuo knygos išleidimo, tikslus jos pavadinimas I. Jansch “Guido to enterpise PHP development”, norėjau ją nuspirkti ir perskaityti. Tuo metu galvojau, kad gal ji man bus kiek per sudėtinga, tačiau dabar galiu drąsiai pareikšti, kad tada ji būtų buvusi man įdomesnė Apie tai ką perskaičiau norėčiau pasidalinti su jums, tam, kad patys galėtumėte susidaryti nuomonę ar vertą skaityti

Knygos apimtis: 265 psl., 3 dalys, kurios susikirstytos į 18 skyrių. Knygą apibendrinsiu perbėgdamas per kiekvieną.

From the Attic to the Cubicle

Pasakojama apie PHP evoliucija ir kas įtakojo šios programavimo kalbos išsivystymą iki dabartinio lygio. Atradau pakankamai įdomią nuorodą evoliucijos gerbėjams – http://museum.php.net.

PHP verslui

Minimi autoriaus pastebiami PHP privalumai:

• sukurtai web’ui
• lengva išmokti
• programinės įrangos pasirinkimas
• išplitimas
• pragmatiškumas

Manau su visais šiais punktais galima sutikti, bei taip pat, jie jau daug kartų girdėti, todėl nieko naujo neišgirsta.

Bandoma pagvildenti kokie yra PHP integracijos į verslą iššūkiai:

• “Easy to Learn, Difficult to Master” (per gražus posakis, kad versčiau ). Nors PHP, kaip programavimo kalba, lengvai išmokstama ir yra pakankamai lanksti, bet reikia sukaupti nemažai žinių ir patirities, norint sugebėti priimti teisingus sprendimus.
• objektų gyvavimo laikas – 1 request’as. Palyginama su Java.
• interpretavimas prieš kompiliavimą. Pagrindiniai minusai – sistemos greitis ir tai, jog kompiliavimo metu yra matomos visos klaidos.

Skyriaus pabaigoje yra palyginimas su kitomis populiaromis programavimo kalbomis:

• Ruby
• Java
• .NET
• Python
• Perl

Komanda

Vienas iš labiau patikusių skyrių, nes aprašoma galima komandos sudėtis ir kokius vaidmenis kiekvienas tūrėtų atlikti:

• Klientas
• Analitikas
• Programinės įrangos projektuotojas
• Sistemos projektuotojas
• Programuotojas
• Vyr. programuotojas
• Grafikos dizaineris
• Testuotojas
• Projekto vadovas
• “The account manager” – žmogus atsakingas už komunikaciją su klientu. Dažniausiai tai būna tas pats asmuo kaip ir projekto vadovas.
• Sistemos administratorius
• Kodo mentorius – žmogus, kuris peržiūri kodą prieš jį paleidžiant į viešumą. Taip pat, atsakingas už tai, kai prie vienos integracijos (projekto) dirba keli programuotojai. Tokiu atveju jam reikia užtikrinti kodo vientisumą.
• Mokytojas – žmogus, kuris klientą apmoko kaip reikia dirbti su sistema.

Nemažai rašoma ir teikiami pasiūlymai kaip reikėtų kelti darbuotojų kompetenciją:

• sertifikavimas
• savišvieta. Apima literatūros skaitymą ir tai kas, šiuo metu, yra “ant bangos”
• bendruomėnė. Si9loma nuolat palaikyti ryšį su ja.
• konferencijos

Ir pabaigai rašoma apie tai kaip reikėtų surinkti komandą. Kaip pasiekti tikslinę auditoriją.

Tikslų išsiaiškinimas

Skyriuje rašoma apie tai, kad prieš pradedant programuoti reikia išsiaiškinti kokie yra kliento norai ir kokio galutinio rezultato jis tikisi bei parengti funkcinę specifikaciją (o ar gali būti projektas valdomas kitaip?).

Vienintėlė nauja ir naudinga skyriaus informacija buvo “MoSCoW” principas. Juo galima remtis, kai reikia apkarpytis projektą arba išskaidyti į vystymo etapus.

MoSCoW principas susideda iš:

• Must-haves – funkcijos be kurių projektas negalėtų veikti.
• Should-haves – funkcijos, kurios tūrėtų būti paleidžiant projektą.
• Could-haves – funkcijos, kurios būtų gerai, jei būtų projekte.
• Won’t-haves – funkcijos, kurių tikrai nereikia.

Manau netolimoje ateityje išbandysiu šį principą ir pažiūrėsiu kaip jis praktijoje atrodo.

Planavimas

Minimas “planavimo paradoksas”. Jei programuotojas projektą įsivertina, kad darys 40val., tai nesvarbu kaip jam gerai seksis daryti užduotis, jis vistiek, projektą baigs po 40val., nes dirbs per daug atsipalaidavęs. Todėl, jei jam projektą reikėtų padaryti per  30val., tai didėlė tikimynė, kad per tiek laiko jis jį ir padarytų

Architektūra (kodo)

Vienas iš nuobodžiausiu skyriu, nes jame kalbama apie dalykus be kurių normlaus PHP programavimas yra neįmanomas (arba sunkiai įmanomas). Nemažai dėmesio skiriama objektinio programavimo (oop) principams bei design pattern’ams. Buvo nuobodu, tad nemažai perverčiau. Galima pasidžiaugti tik tuom, jog tai buvo vienintėlis skyrius, kuriame yra kodo pavyzdžių.

Supažindinama kas yra UML (Unified modeling language), pateikiami keli diagramų tipai, bei minimi įrankiai su kūriais galima kurti diagramas.

Skyriaus pabaigoje supažindinama su duomenų baze (DB) – kas tai yra ir kokie panaudojimo būdai. Vėliau prieinama prie ORM ir išvardinami pliusai bei minusai.

Įrankiai

Skyrius skirtas visiškiems pradinukams (programavimo), nes yra rašoma apie editorius, kodo debug’inimą, kas versijų kontrolė ir kokie tipai, bei problemų registravimo įrankiai.

Building blocks (bekuriant kodą)

Vienas iš pagrindiniu skyriaus akcentų (su kuriuo labai sutinku) – “neišradinėkit dviračio ten kur jo nereikia”. Kam kurti kažką savo, kai rinkoje yra gerų ir išbaigtų alternatyvų. Pateikiama nemažai pavyzdžių, kai projekto vystytojai save apgaudinėja ir bando įrodyti, jog jų projektas yra unikalus. Taip pat, minima nemažai progrmaninės įrangos “visiems gyvenimo klausimams” (frameworks, tvs, ecommerce ir t.t.).

Saugumas

Prabėgom aprašomi pagrindai bei pasiūloma perskaityti I. Alshanetsky “Guide to PHP security” knygą. Šią knygą man teko skaityti ir manau, kad bet kuris save gerbiantis programuotojas tūrėtų bent jau praversti

Vystymas

Šiame skyriuje minimas D.R.Y. (don’t repeate yourself) principas bei jo privalumai. Taip pat, dokumentacijos ir kodo kultūros svarba. Dokumentavimui siūloma naudoti “phpDoc”, o kodo kultūrai siūloma apsibrėžti kodavimo standartą bei pateikiami keli pavyzdiniai.

Kokybės užtikrinimas

Skyrius nuo kurio tikėjausi sužinoti ką nors naujo. Iš dalies šį tą sužinojau, bet ne tiek kiek norėjau.

Projekto/kodo kokybę siūloma užtikrinti:

• programuotojo testavimu – programuotojas peržiūri savo kodą.
• funkciniu testavimu – yra apibrėžiamos funkcijos, kurios bus išleistos su versija ir testuotojas arba programuotojų komanda testuoja.
• aplinkos testavimas – siūloma peržiūrėti aplinkas, kuriose bus talpinamas projektas. Tai apima serverį, kliento aplinką
• našumo testavimas – vienas iš varbiausių dalykų tai puslapio atsako laikas, todėl vienas iš tikslingesnių būdų nustatyti tokioms apkrovomos yra “stress” testai.
• automatiniai testai:
  • unit testai – puikiai tinka funkciniams reikalavimams ištestuoti. Siūlomi naudoti “PHPUnit” arba “SimpleTest”.
  • taip pat, paminėti “Selenium” testai, kurie tinkami UI (User Interface) testavimui.

Skyriaus pabaigoje minima TDD (Test-Driven Development) prakita bei “Continous Integration” įrankiai.

Optimizavimas

Opitimizavimui siūloma naudoti profiler’ius, tam, kad būtų galima identifikuoti lėčiausias sistemos vietas. Identifikavus tokias vietas, siūloma naudoti kešavimą. Minimi  įvairūs kešavimo būdai (duomenų kešavimas, puslapio kešavimas).

Nemažai skyriaus kalbama apie duomenų bazės optimizavimą. Siūlomi sprendimai kaip būtų galima identifikuoti lėčiausias užklausas.

Pabaigoje minimas sistemos aparatinės įrangos optimizavimas.

Deployment

Rašoma apie skirtingas aplinkas bei įvairias jų galimas variacijas:

• production – pagrindinė sistemos aplinka, kurią mato visi vartotojai ir ja naudojasi.
• development – programuotojo darbinė aplinka.
• test – testinė aplinka.
• acceptance – aplinka, kurioje dalis vartotojų (klientų) peržiūri ją ir jei patvirtina, tai yra išleidžiama į production aplinką.
• debug – klaidų paieškos aplinka.

Kita skyriaus dalis skiriama galimiems projekto atnaujinimo metodams. Viskas aprašoma teoriniame lygmenyje.

Implementacija

Gan nuobodus skyrius, kuriame rašoma apie procesus po projekto paleidimo, o tai apima:

• dokumentaciją
• mokymus kaip dirbti su sistema
• marketingą
• vartotojų nuomonės įsiklausimas

Operations

Rašoma apie veiksmus, būtinus atlikti po projekto paleidimo. Mini veiksmai:

• sistemos stebėjimas – įvariių sistemos parametrų stebėjimas.
• saugumo atnaujinimai – saugumo pataisymų integravimas į sistemą.
• log’ų peržiūra

Taip pat, siūloma susidaryti veiksmų planą, kuriuo reikėtų vadovautis, kai sistema nulūžta. Tokio plano tūrėjimas, manau labai teisingas sprendimas, nes būna atvejų, kai reikia reaguoti greitai ir nėra laiko per daug mąstyti (adrenalinas ima viršų).

Palaikymas

Trumpiausias knygos skyrius, kuris apima – kodų pakeitimų integravimą į sistemą, sistemos administravimą ir problemų sprendimą.

Programavimo metodologijos

Vienas iš paskutinų ir vienas iš įdomesnių skyrių apima programavimo metodologijas:

• waterfall
• rapid application development
• agile – šiai metodologijai skiriama visai nemažai dėmesio ir pateikiami keli pavyzdžiai.
• ITIL (The Information Technology Infrastructure Library) – man visai nauja ir negirdėta praktika. Ši praktika apima ne tik sistemos vystymą iki paleidimo, bet ir sistemos valdymą po jos paleidmo.

Projekto valdymas

Paskutiniame skyriuje rašoma apie projekto valydmą. Įdomesnė dalis, kurią derėti pasiskaityti daugumos įmonių vadovams, tai “sharpening the saw”. Šiame poskyryje pateikiama istorija apie medkirtį, kuris kirto medžius su buku kirviu, nes netūrėjo laiko jį pasigalasti.

Reziume

Apibendrinant visą kngyą, tai galėčiau pasakyti, kad tikėjausi daug daugiau. Nieko per daug naujo nesužinojau. Dar kaip vieną iš minusų galėčiau įvardinti Zend produktų “stumimą”. Labai dažnai minimas “Zend Server”. Manau, tai nėra blogai, bet tokiais atvejais reikėtų paminėti ir alternatyvas. Juolab, kad pats “Zend Server” nieko per daug savo neturi. Jis tik apima jau egzistuojančius komponentus ir suteikia jiems UI

P. S. jei ką nors domina koks nors konkretus skyrius, tai galiu rašykite komentaruose ir ktiu straipsniu galėsiu daugiau jį pagvildenti (pateikti daugiau info ir savo pamąstymų).

P. P. S. taip pat įdomi nuomonė tų, kurie nepatingėjo ir perskaitė visą apžvalgą. Kaip manote ar kitas knygos apžvalgas reikėtų išskaidyti per keletą įrašų?