Par programmēšanu

Sacerēja kategorijā Kods

Vakardien pavisam nejauši mazliet iesaistījos vienā tviterdiskusijā, kas sākās ar tēzi par WordPress un beigās izvērtās pagarā diskusijā par OOP un dažnedažādu programmēšanas ietvaru (freimworku tiem, kas nav pazīstami ar latvisko terminoloģiju) imantošanu.

Izdomāju, ka man ir mazliet garāks viedoklis un tas nekādi 140 simbolos neietilpst. Tad nu tā:

Mums programmētājiem ļoti patīk diskutēt par to, ka kaut kāds viens programmēšanas veids ir labs un kaut kāds cits ir slikts, katram no mums ir ļoti spēcīgi viedokļi par vienu vai otru programmēšanas veidu un šie viedokļi mēdz atšķirties un pats smieklīgākais – mums visiem ir zināma daļa taisnības, tajā pat laikā, tas galīgi nav būtiskākais.

Galvenais mūsu darba mērķis ir atrisināt klienta problēmu. Klienta problēma var būt jebkas – kaut vai kaut kādas informācijas par sevi publicēšana internetā (arī pazīstams, kā mājaslapa). Mēs šo te viņa problēmu varam atrisināt daudzos un dažādos veidos, galvenais, ka tā tiek atrisināta. Un tālāk jau nonākam pie tā, kā tad tieši mēs izvēlēsimies veidu kā risināt viņa problēmu.

Te ir jāatcerās, ka otra būtiskākā lieta, kas mums, kā programmētājiem ir jāzin: mums ir jāspēj balansēt dažādi, atvainojos par žargonismu, treidofi.

Paskaidrošu – mēs varam lietotājam lapu uztaisīt Wordpresā, ar to viņš iegūs pazīstamu un gadiem pārdomātu lietotāja saskarni administrācijas daļā, iespēju piesaistīt lētus programmētājus uzturēšanā, bet zaudēs lapas ātrdarbībā, kā arī programmētāju produktivitātē, ja vajadzēs kaut ko ļoti, ļoti citādāku nekā Wordpresa izstrādātāji ir izdomājuši. Tāpat varam utaisīt lapu izmantojot kādu no OOP ietvariem, te ieguvumos būs tas, ka lapa nedarīs tās lietas, kas tai nav jādara, programmētājam būs vieglāk izdabāt klienta vēlmju niansēm, bet būs jāpaterē laiks pie administrācijas rīku izveides, kā arī administrācija noteikti nebūs ar tik ļoti bagātām iespējām, vai arī tās izstrāde aizņems daudz laika, kā arī būs nepieciešami programmētāji ar attiecīgā ietvara zināšanām, lai uzturētu lapu. Tik pat labi varam lapu rakstīt perlā un ieguvumos būs plašas iespējas ar dažādu tekstuālu datu manipulēšanas iespējām, tomēr nez vai kāds to pēc tam spēs uzturēt (hotja, nākotnes ienākumu nodrošināšana arī var tikt uzskatīta par plusu programmētājam) (btw, ja mums te ir kāds perla gurū, padomā varbūt tu gribi pārcelties uz Amsterdamu, mums te booking.com tādi noder). Vēl ja klientam ir vajadzība pēc megaātrdarbības, tad vispār varam visu rakstīt C vai, pasarg dievs, asemblerī, bet ticu, ka tur lielais vairums pēc plusu mīnusu izvērtēšanas ir sapratuši, ka ātrdarbības ieguvums lielākajā daļā gadījumu neatsver ieguldītās izmaksas.

Mans personīgais viedoklis ir tāds, ka OOP web izstrādē ir kruta un izcili un palīdz man ietaupīt manu dārgo izstrādātāja laiku, tomēr esmu šo laiku ieinvestējis sava OOP mikroietvara radīšanai, kas ļauj man koncentrēties uz tām lietām, kas man ir nepieciešamas, tomēr, jā, apzinos, ka manam ietvaram nav to iespēju, kas ir lielākiem ietvariem un tas nav tik ļoti notestēts kā, piemēram, kaut vai tas pats CI. Savām personīgajām vajadzībām pēc treidofu izvērtēšanas esmu izdomājis, ka tas man der. Tāpat ticu, ka Endijs ir izvērtējis plusus un mīnusus tiem PHP ietvariem, ko viņš izmanto un ir izdomājis, ka tas der viņam. Diskusijas ir ļoti forši, bet galvenais tomēr ir apmierināts klients un atalgojums par padarīto darbu mūsu kabatā.

 

Raksts publicēts kategorijā Kods. Iemet grāmatzīmēs tiešsaiti.

17 Thoughts.

  1. Pareizi, ka liec uzsvaru uz apmierinātu klientu. Man patika kā tika noslēgta viena no nesen apmeklētam konferences lekcijām. Konferencēs parasti runā par clean code, design patterns, testing. Un mēs varam taisīt kodu, kurš atbilstu visiem šiem principiem. Bet ja kods nenodrošina biznesa prasības (klienta prasības), tad tas ir crapy code, neskatoties uz to cik “pareizs” tas ir.

    Runājot par OOP. Lielāko plusu es tajā redzu tieši ilgtermiņa izmantošanā. T.i. – periodu X rakstot un uzturot kādu kodu, to ir vieglāk darīt pie prātīga OOP/OOD nevis, piemēram, funkcionāla koda. Bet ja tieši par FW… tad šobrīd esmu jaunos meklējumos. Turklāt var jau rakstīt savu app izmantojot servisa slāni virs framework. Tad ir iespēja vienu nomainīt pret citu, nebojājot/neaiztiekot pašu app kodu. Protams, papildus servisa slānis sarežģī lietas, bet vismaz nepadara produktu atkarīgu no kāda specifiska FW. Varam jau arī rakstīt paši savus FW, bet nevajag aizmirst, ka visticamāk neesam gudrāki par tiem, kuri uzraksta lielos FW. Ja tomēr gribās, tad ieteiktu pašam rakstīt skeletu, kurā izmantot jau gatavas komponentes. Ātrāk, lētāk, ērtāk.

  2. Nu vēl jau ir tā, ka biznesa prasība var būt arī ātri uztaisi kaut ko, pohuj kā, galvenais, lai kaut cik strādā un nē mums to vajag tikai vienam īstermiņa pasākumam, kurš notiek noteiktā datumā. Šādos gadījumos var gadīties, ka pēc plusu un mīnusu ātrās izvērtēšanas OOP/FW kods var būt prasībām neatbilstošs, īpaši ja nav nekādu iepriekš veiktu iestrādņu atbilstošajā FW. Vēl mēdz būt reizes, kad (un tas ir samērā biežs gadījums), ka tev ir vienkārši jāveic izmaiņas kaut kādā sen uzrakstītā kodā un tur bieži vien ir vienkārši jākodē tādā paradigmā, kādā ir uzrakstīts iepriekšējais, ja vien tev nemaksā par refaktorēšanu/visa pārrakstīšanu.

  3. a nav tā ka ir bišķi kāposti ar zapti sajaukušies – i mean ir bišķi atšķirība tomēr starp cms (wordpress), freimworku (CI) .. un no tā arī visas sāpes nesaprašana

  7. PHP nav galvenais. Var būt arī RoR (nav ne jausmas kas tas ir :), ja tik viss tiek uztaisīts tā lai strādā un atbilst tam, ko gaidu :)

  8. Nu te gribētu teikt, ka lai arī no vienas puses šķiet, ka CMS un FW ir divas pavisam atšķirīgas lietas, tomēr šajā gadījumā vēlētos teikt, ka manā kontekstā tos var salīdzināt – abi tomēr ir rīki mērķa (kaut kādas interneta vietnes izveides) sasniegšanai. Nesaku, ka viens vai otrs ir labs vai slikts – saku tikai to, ka mērķi var sasniegt dažādi un mūsu uzdevums ir izvērtēt šos rīkus un izvēlēties risinājumu tā, lai mērķis tiktu sasniegts pēc iespējas veiksmīgāk.

  9. Man, kā cilvēkam, kam ir jāsēž klienta pusē vai pa vidu starp programmētāju un klientu, ir stipri pie kājas, kādā veidā programmētājs nodrošina rezultātu. Bet praktiski vienmēr svarīgs ir laiks un iespēja adaptēt sīkumus. Tad nu sanāk tā, ka vienam klientam ērtāk ir iemācīt WordPress administrēšanu, bet citam — jātaisa savs admin panelis ar maksimāli ierobežotu ievades/rediģēšanas kļūdīšanās iespēju skaitu, jo savādāk viņš kaut ko pats sačakarēs. Tajā brīdī tad arī ar programmētāju būtu jāizrunā un jāsaliek pa plauktiņiem galarezultāta plusus un mīnusus.

  15. Atkarīgs no konteksta – plašākā kontekstā ne ar ko, ja skatās savukārt ļoti specifiski, tad var uzskatīt, ka programmēšana ir tīri attiecīgā koda uzrakstīšana, tomēr šādai definīcijai īsti negribētos piekrist, jo arī tajā brīdī, kad šķietami ir tikai jāuzraksta kods, jebkurā gadījumā ir jāatcerās par mērķiem un jāsaprot, kā tos vislabāk sasniegt.

    Tipiskais piemērs, ko var pieminēt ir tas, ka programmētājam vienmēr ir jāizdomā un jāpiņem lēmums vai uzrakstīt “vienkāršu” kodu, kas ļoti vienkāršā veidā apmierinās kādu šībrīža vajadzību, bet būs grūtāk labojams nākotnē, vai arī pavadīt ilgāku laiku, bet iespējams ietaupīt kaut kādu laiku nākotnē, kad būs jāisteno nākamais līdzīgais mērķis.
    Šajā brīdī it kā vienkāršā programmēšana jau pārvēršas par izstrādi.

Atbildēt

Jūsu e-pasta adrese netiks publicēta. Obligātie lauki ir atzīmēti kā *