Kāpēc PHP tik ļoti sux'o, bet tomēr mēs visi to lietojam

[codez]

Runa jau nav par to, ka web izstrādē kāds raksta kaŗtošanas algoritmu vai bināro koku, bet gan par to, ka labam programmētājam ir jāizprot kā šīs lietas darbojas iekšienē, jo tad viņš var iepriekš prognozēt daudzas lietas cik ātri un efektīvi strādās un izvēlēties risinājumus atbilstoši tam. Lai gan ikdienā tev nav jāraksta šādas lietas, tācu ir jāstrādā ar rīkiem, kuros šīs lietas ir realizētas. Piemēram, ja tu zini kā strādā btree, ko izmanto kā indeksu mysql tabulās, tad tu vari droši prognozēt, ka atlasīt 1 ierakstu no 1`000`000 ierakstiem pēc indeksētas vērtības ir tikai x2 lēnāk kā no 1`000 ierakstiem, jo zini, ka meklēšana btree ir ar sarežģītību O(log(N)). Tālāk, saprotot kā tiek būvēts binārais koks, nav jāzīlē kā strādā indeksi ar variākiem laikiem un cik efektīvi ir iespējams atlasīt ierakstus pēc vērtību intervāliem vairāko laukos, piemēram, a>5 and a<10 and b>15 and b<20. Zinot to, uzreiz var izdomāt, vai attiecīgā lieta strādās pietiekami ātri, vai ir jādomā optimizācija, vai jāizmanto kāds cits indeks, piemēram spatialāis rbtree.

Liela daļa web developeru pārāk nepilnīgi izprot daudzas no šīm lietām, tāpēc pielaiž daudz muļķīgu pieņēmumu un līdz ar to kļūdu.

[Psihius]

codez

 

Un vienalga jomas specifika nozimē ļoti daudz, pat darbs ar to pašu datu bāzi stipri atšķirās starp WEB un sistēmas programmēšanu. WEB'a responce time/latency ir kritisks, sistēmās programmēšanā tas parasti nav tik svarīgs un ļoti daudzas lietas liek uz datu bāzes procedurām un pagaidīt pāris sekundes nav nekas traks.

Un ar datu bāzēm vispāri ir ļoti atkarīgs no konkrēta projekta - kas strādā vienā projektā otrajā var bremzēt tā kā traks un ir jāparkonfigurē datu bāzi attiecīgi.

[nemec]

Es, kā galveno programmētāja īpašību uzskatu laba un uzturama koda ražošanu. Un rezultāta mērķis ir strādājošs produkts.

 

Vēl es fanoju par TDD izstrādes metodi — sākumā rakstām testus un tad tikai kodu. Protams, codez olimpiāžu ģēnijs kaut kādas koda vietas realizēs labāk par parastu programmētāju, bet galvenais, manuprāt, ir testi. Pat ja programma nebūs mega "optimizēta" (ar 5-zvaigžu meistaru), tā jebkurā gadījumā strādās korekti un mēs varēsim jebkurā laikā veikt pārtaisīšanu (refaktoring). Jo galvenais mērķis, vismaz man, ir strādājošs produkts.

 

Otrajā vietā es liktu programmētāja pieredzi un zināšanas, jeb cik daudz softu ir apčamdījis un izpētījis. Es uzskatu, ka daudz vērtīgāk ir izpētīt linux kodolu, nekā iemācīties no galvas sortēšanas algoritmus.

 

Un tikai 3. vietā es ieliktu perfektu algoritmu pārzināšanu.

Edited May 17, 2012 by nemec

[Mr.Key]

Nebūt nav tā, ka tie, kas ir labi teorētiķi, ir arī labi praktiskā darba darītāji. Un otrādi.

 

Un ne vieni, ne otri nav noniecināmi, diemžēl abās pusēs gadās pa kadriem, kuriem kaut kas sāp un šo sāpi kompensē ar varas izrādīšanu - teorētiķi skandina, cik visi dumji un neko nezin, diletanti, savukārt, dedzina grāmatas utt.

 

Peace! :)

Edited May 17, 2012 by Mr.Key

[Mr.Key]

Runa jau nav par to, ka web izstrādē kāds raksta kaŗtošanas algoritmu vai bināro koku, bet gan par to, ka labam programmētājam ir jāizprot kā šīs lietas darbojas iekšienē, jo tad viņš var iepriekš prognozēt daudzas lietas cik ātri un efektīvi strādās un izvēlēties risinājumus atbilstoši tam. Lai gan ikdienā tev nav jāraksta šādas lietas, tācu ir jāstrādā ar rīkiem, kuros šīs lietas ir realizētas. Piemēram, ja tu zini kā strādā btree, ko izmanto kā indeksu mysql tabulās, tad tu vari droši prognozēt, ka atlasīt 1 ierakstu no 1`000`000 ierakstiem pēc indeksētas vērtības ir tikai x2 lēnāk kā no 1`000 ierakstiem, jo zini, ka meklēšana btree ir ar sarežģītību O(log(N)). Tālāk, saprotot kā tiek būvēts binārais koks, nav jāzīlē kā strādā indeksi ar variākiem laikiem un cik efektīvi ir iespējams atlasīt ierakstus pēc vērtību intervāliem vairāko laukos, piemēram, a>5 and a<10 and b>15 and b<20. Zinot to, uzreiz var izdomāt, vai attiecīgā lieta strādās pietiekami ātri, vai ir jādomā optimizācija, vai jāizmanto kāds cits indeks, piemēram spatialāis rbtree.

Liela daļa web developeru pārāk nepilnīgi izprot daudzas no šīm lietām, tāpēc pielaiž daudz muļķīgu pieņēmumu un līdz ar to kļūdu.

MySQL gadījumā svarīgāk ir apzināties, ka viņa query optimizātors ir, khmm... maigi sakot, dīvains. Īpaši interesanti ir tad, kad praksē izrādās, ka query ar vienu where nosacījumu izpildās ļoti ātri, jo izmanto indeksu, bet ja where nosacījumu sakabina ar OR, tad indeksu vairs neizmanto un sākas full scan, protams, OR vietā nākas izmantot UNION. Ko teiksi? :D

 

Par to, ka web developeri bieži nepilnīgi izprot daudzas lietas, piekritīšu. Bet tāpēc jau arī viņi ir izvēlējušies web developmentu, jo tur galvenais, ka poga spiežas un kaut kas izmainās, un visi atpleš mutes aiz sajūsmas :)

Edited May 17, 2012 by Mr.Key

[codez]

MySQL gadījumā svarīgāk ir apzināties, ka viņa query optimizātors ir, khmm... maigi sakot, dīvains. Īpaši interesanti ir tad, kad praksē izrādās, ka query ar vienu where nosacījumu izpildās ļoti ātri, jo izmanto indeksu, bet ja where nosacījumu sakabina ar OR, tad indeksu vairs neizmanto un sākas full scan, protams, OR vietā nākas izmantot UNION. Ko teiksi? :D

Tur jau tā lieta, ka tas ir ne tikai praksē, bet jau pašā teorijā, jo btree pēc būtības nekārto parametrus uzreiz pēc vairākiem parametriem, bet gan pa priekšu pēc viena un tad pēc otra. Un, ja zin teoriju, tad nav jālauza galva, kas būs efektīvi un kas nebūs.

 

Par to, ka web developeri bieži nepilnīgi izprot daudzas lietas, piekritīšu. Bet tāpēc jau arī viņi ir izvēlējušies web developmentu, jo tur galvenais, ka poga spiežas un kaut kas izmainās, un visi atpleš mutes aiz sajūsmas :)

Nu tā jau ir, bet ir jau arī būtiskas atšķirības arī tajā paša web developmentā, teiksim, vai nu tu taisi kārtējo CS lapu saviem 15 draugiem, vai arī taisi nopietna izmēra portālu vismaz 100k lietotājiem dienā, izmanto websocketus realtime aplikācijām, vai nodrošini servisus ar pamatīgām background datu apstrādēm. Otrajā gadījumā cilvēks bez kārtīgām teorētiskām zināšanām, vienkārši aplauzīsies pie efektivitātes nodrošināšanas.

 

 

 

P.S.

Principā tiem, kas uz PHP atnākuši pa tiešo, es iesaku veltīt nedēļā vienu, divus vakarus tieši algoritmisko problēmu risināšanai tai pašā c++ un izmantojot to pašu olimpu vai, piemēram, spoj. Un uzkačāt algoritmisko problēmu risināšanas spējas vismaz līdz 3* uzdevumiem. Tas ir analoģiski, kā hokejisti, nevis visu laiku mācās spēlēt hokeju, bet iet un trenē muskuļus arī trenežieru zālē. Šijā analoģijā algoritmisko problēmu risināšana ir muskuļu trenēšana.

[Kavacky]

Par to, ka web developeri bieži nepilnīgi izprot daudzas lietas, piekritīšu. Bet tāpēc jau arī viņi ir izvēlējušies web developmentu, jo tur galvenais, ka poga spiežas un kaut kas izmainās, un visi atpleš mutes aiz sajūsmas :)

Piemērs nepareizs, jo ne jau tikai webā galvenais, ka poga spiežas. Webā vismaz kaut kādu ātrdarbību vajag, bet kaut kādās uzņēmumu CRM, kuras devo gadus 15, tur atsevišķs programmētājs vispār pārzina max 0.05% koda, ko pats ir rakstījis, smagākā matemātika tur ir cikla mainīgajam pieskaitīt 1, bet ātrdarbība ir pohuj, jo visi tāpat pieraduši, ka forma var pusminūti lādēties. Vot tur var kodēt pilnīgākie mērkaķi, kas apguvuši lasītprasmi, lai speceni izlasītu, pārējo jau kaut kā piemuhļīs.

[daGrevis]

[Psihius]

Kavacky labi pateica, diemžēl tā bieži un ir. Un pēc savas pieredzes zinu ka atrast labu programmētāju ir liela problēma.

Un diemžēl tieši PHP tā ir krietna liela problēma, jo ir daudz tādu kas jau strādā pa 5-10 gadu, bet tālāk par vidējo līmeni pat nav ticis - reti kāds nonāk līdz lieliem krietniem projektiem kur ātrdarbība, arhitektūra un datorzinātnes ir svarīgas. Viss tas nav vajadzīgs vizītkaršu web lapu taisīšanai. Tā pat ar tām CRM sistēmām - lielākā daļa pat neiedziļinās (bet tie, kas tiešām izprot sistēmu var dabūt ļoti krietnu naudu, 2-3x vairāk nekā vidēji mierīgi - man kolēģis ar MS Sharepoint bija strādājis - bija ļoti labi piedāvājumi viņam, tikai ņemties ar to viņam nu ļoti negribas un ņemsies tikai ja nebūs izvēles).

Edited May 18, 2012 by Psihius

[edgarsj]

Par šo tēmu Stackoverflow meetupā bija laba ierosme. Doma, ka vajadzētu ieviest programmēšanas inženieru sertifikāciju (organizē programmētāju asociācija or smth), kurā būtu nepieciešams uz vietas atrisināt kādu netriviālu uzdevumu (ne tikai algoritmiski, bet arī ar puslīdz lietojamu UI utml.). Un risinājumu pārbaudītu uz ne tikai to, vai ir atrisināta problēma, bet arī veidu kā tas izdarīts (piem. ja for cikla vietā ntās rindiņas koda, tad izgāzies).

 

Tas garantētu, ka cilvēks ar šo sertifikātu nav vienkārši code monkey, bet reāli izprot un spēj izdarīt.

[Psihius]

edgarsj

Priekš PHP ir Zend PHP Certification - tā pat tuvu nav viegla un diezgan labi norāda uz cilvēka līmeni. To nav iespējams nodod vienkārši iegaumējot PHP dokumentāciju - ir jābūt nopietnai praktiskai pieredzei, es teiktu kādi 3-4 gadi sarežģītos projektos lai aptvert visu to, ko sertifikācijā prasa - un vienalga būs pāris vietas kurām ir jāgatavojas. Man jau 7-8 gadi pieredzes un joprojām dažās tēmas man praktiski nav praktiskās pieredzes un ir cītīgi jāgatavojas pāris nedēļas lai nebūtu viens liels fail.

Pats draņķīgais tur ir tas, ka ir jautājumi par ļoti specifiskām lietām kuras var zināt tikai no prakses.

Edited May 18, 2012 by Psihius

[edgarsj]

edgarsj

Priekš PHP ir Zend PHP Certification

 

Jā, priekš PHP. Tā ir tāda specifiska sertifikācija. Pamatdoma augstāk minētajam bija vispārēja programmēšanas profesionāļu sertifikācija.

[Mr.Key]

Par šo tēmu Stackoverflow meetupā bija laba ierosme. Doma, ka vajadzētu ieviest programmēšanas inženieru sertifikāciju (organizē programmētāju asociācija or smth), kurā būtu nepieciešams uz vietas atrisināt kādu netriviālu uzdevumu (ne tikai algoritmiski, bet arī ar puslīdz lietojamu UI utml.). Un risinājumu pārbaudītu uz ne tikai to, vai ir atrisināta problēma, bet arī veidu kā tas izdarīts (piem. ja for cikla vietā ntās rindiņas koda, tad izgāzies).

 

Tas garantētu, ka cilvēks ar šo sertifikātu nav vienkārši code monkey, bet reāli izprot un spēj izdarīt.

Ļoti strīdīgi, izskatās pēc sapņa par brīnummetodi, kas nesīs atbildes uz visiem sāpīgajiem jautājumiem. Nē, tā nebūs, joprojām diplomētie un bļembotie programmētāji rakstīs līku kodu, muldoņas daudz muldēs un maz darīs, vienrinžu fani uzkārs produkcijas un to kluso, nemanāmo čali atcerēsies tikai tad, kad viņš būs aizgājis prom un neviens nesapratīs, kāpēc pirms tam viss strādāja, bet tagad nekas neJiet...

 

:))

[Kaitnieks]

 

Pamatdoma augstāk minētajam bija vispārēja programmēšanas profesionāļu sertifikācija.

 

Šo domu Makonnels mēģina jau gadiem aktualizēt (sk. grāmatu Professional Software Development) (pie tam, nevis vienkārši piedāvājot sertifikāciju, bet gan licenzēšanu, ar domu, ka profesionāli ar IT izstrādi drīkst nodarboties tikai licenzētie speciālisti), bet, ja godīgi, tad mūsu profesija tam vēl nav gatava un vispār šī ir ļoti pretrunīga tēma.

Pašlaik vispraktiskākais vienotās sertifikācijas pielietojums varētu būt iepirkumu konkursu kritērijos valsts iestāžu pasūtījumos. Diez vai tas garantētu, ka cilvēks ir produktīvs speciālists, tāpēc uzņēmumi joprojām veiktu kandidātu pārbaudes, taču iestādēm, kas no IT vispār nekā nesaprot, vismaz būtu kaut kādi salmiņi, pie kā pieķerties.

[Kavacky]

ja godīgi, tad mūsu profesija tam vēl nav gatava

Kāpēc tad nav?