Šis raksts ir kā pārdomas uz php|a izlasītu rakstu “Programming: you’re doing it wrong“. Izlasīju un aizdomājos, ka pamatdoma ir ļoti precīza – lai kā mēs programmētu, mēs to darām nepareizi. T.i. – programmējot mēs izvēlamies kādu konkrētu pieeju, bet vēlāk izrādās, ka tā nav bijusi pareiza. Lai gan brīdī kad darbs tapa, pieejai nebija ne vainas. Reizām mēs paši sakām, ka mūsu iepriekšēji darbi ir uztaisīti nepareizi, bet visbiežāk citi to saka par mūsu darbiem vai mēs par citu darbiem.

Klasika. Programmētājs A pārņem programmētāja B kodus tālākai izstrādei. Ko A teiks pēc 30min, kuru laikā būs pētījis kodus? Tas !@#$% B visu tik nejēdzīgi (nepareizi) uztaisījis, ka neko te nevar glābt – viss jāmet ārā un jātaisa pareizā veidā. Ja C pārņems darbu no A, ir liela iespējamība dzirdēt tieši to pašu, ko teica A.

Bet lieta jau ir tāda, ka pats programmēšanas stils bieži vien ir sekundārs. Galvenais ir lai kods dara to, ko tam ir jādara. Nav OOP sliktāks vai labāks par funkcionālo programmēšanu. Nav viens patterns labāks par citu. Ja izmantotā lieta dara to kas jādara, tad uztaisīts ir pareizi – neskatoties uz to kā tieši tas ir izdarīts.

Protams, ir jau arī galējības. Piemēram, produkts strādā, bet tā, ka kaut ko pielikt klāt ir problēmas. Bet arī šie gadījumi nav (stipri lielākajā daļā gadījumu) tāpēc, ka izmantota viena vai otra pieeja programmēšanai. Gluži vienkārši programmētājs (vai pasūtītājs) nav ņēmuši vērā potenciālo produkta attīstību. Savukārt ja kods nestrādā (ir kļūdas izpildē, drošības problēmas utt.), tad tur jau nav runas par to ir vai nav pareizi izdarīts.

Ar visu šo es gribēju teikt, ka bieži vien aizraujamies ar viena ideālā programmēšanas veida meklēšanu. Lasām jaunākās teorijas koda strukturēšanā utt. Bet ar to nevajag aizrauties. Protams, ir jāmācās un jāiet laikam līdzi. Vienīgi der atcerēties, ka pat pēc jaunākā modes kliedziena programmētā lieta būs nepareiza, ja vien viņa nestrādās tā, kā paredzēts.