Mr.Key

Es kaut kur lasīju, ka tādi programmētāji (vīrieši) , kas čurā sēžus, arī raksta labāku kodu, nekā tie, kas to dara stāvus.

Nekad negribētu būt tāda Mr."pareizā" kolēģis, tev noteikti arī putekļi uz kolēģu galdiem traucē pareizi programmēt un visa diena aiziet, lai pukstētu un mācītu citus kā dzīvot.

 

Turklāt tavs pieņēmums arī ir nepareizs. Mana pieredze rāda, ka tie, kas skaistāk runā parasti mazāk arī saprot, galvenais "lejot ūdeni" nevajag aizmirst salikt pēc iespējas vairāk terminu, lai gudrāk izklausās.

Runāt un rakstīt ir divas dažādas lietas. Tas ir viens. Otrs - pilnīgi piekrītu, ka ūdens liešana un terminu iespraušana, lai gudrāk izklausās, vieš pamatotas(!) aizdomas, ka tas tiek izmantots, lai kompensētu reālo spēju trūkumu. Taču, ja esi eksperts, ātri sapratīsi, vai cilvēks runā tukšu vai nē. Īpaši, ja termini tiek lietoti nepareizi, to ļoti ātri iespējams konstatēt. Tie, kas vēlas apspriest lietas būtību, meklē saprotošas ausis un apspriež tematu, lai atrastu pareizāko risinājumu. Tie, kas vēlas nomaskēt savu neprasmi, tie piedzied ausis.

 

Un, kas attiecas uz kolēģiem, komandas parasti veido cilvēki ar līdzīgām vērtībām. Diez vai man sāpēs, ka noteikta daļa, redz, nekad negribētu mani par kolēģi. Cilvēki ir dažādi, tas ir tikai normāli.

Pietrūkst programmētājam nepieciešama īpašība - uzcītība! Taču to var "ārstēties" un iemācīties būt uzcītīgam. ;)

Attiecībā uz pirmo - tieši tā. Attiecībā uz otro, domāju, ka diez vai. Vieglāk ir paņemt uzcītīgu cilvēku un pievērst programmēšanai, nekā censties pāraudzināt neuzcītīgu programmētāju. Ja man būtu iespēja, es mestu ārā no darba neuzcītīgus programmētājus un viņu vietā ņemtu pilnīgus iesācējus. Kaut kur tiku lasījis lielu uzņēmumu vadītāju teikto, ka to, vai no programmētāja - iesācēja iznāks lietas koks vai nē, var saprast dažu mēnešu laikā. Un ka uzcītīgs juniors gada - divu laikā sasniedz augstu līmeni. Neuzcītīgo programmētāju gadījumā pat desmit gadu pieredze neko labu neizsaka, jo tā ir slikta prakse, kas atkārtota gadu no gada.

Parasti tādu Kristiānu kods arī ir šausmīgs. Ja cilvēks neprot gramatiski pareizi rakstīt un literāri glīti izteikt savu domu, ir jābūt ļoti, ļoti naivam, lai ticētu, ka programmēšanā tāds izpaužas daudz augstākā kvalitātē. Nē, patiesībā dzīvē tas tā arī ir - kods ir šausmīgs, samocīts, neglīts un pats autors dižojas ar attaisnojumiem "man tas bija par grūtu", "man nebia vaidzibas iespringt ko piesienies", utt.

Njā, tie HTML tagi pa gongu nesit.

Piemēram, rakstot view helperi, ir gan HTML tagi, gan PHP kods. Lai nu kā, tādu praksi esmu manījis daudzos projektos, pret kuriem izjūtu respektu.

Skati drīkst saturēt if/else. Es gan nodalu to tā, ka skatos izmantoju konstrukciju if (): endif;, kas vienmēr ļauj saprast, ka tas ir skats, nevis php kods. Cits jautājums ir par veidņu dzini - katram savi nosacījumi. Smarty, piemēram, ir savas izteiksmes, bet "mustache" logic-less veidnes nesatur konstrukcijas, jo veidņu attēlošanu veic kods, kurš gan satur konstrukcijas, utt.

Par pārējo - parasti konkrētās lapas kods izveido lapas HTML, kurš vēlāk tiek ietverts layoutā. Tas var notikt kaut vai tā, ka ar output buffering uzkrāj HTMLu, kuru rada konkrētās lapas kods, iemet to mainīgajā $content un tad ietver layout skriptu, kur "echo $content". Datu padošana skatam - atkarīgs no tā, kā tiek realizēts tavs MVC, taču vispārīgi - kontrollera kods sagatavo datus un padod skata objektam. Papēti Zend, Symphony u.c. ietvaru izmantotos principus.

Kāpēc uzreiz OOP? Mierīgi var iztikt, tā jau tikai gaumes lieta koda skaistināšanai

Tieši tā, tā vpār kaut kāda figņa kas visu tikai sarežģī un neļauj daudz un ātri strādāt

dizainers vs. dizaineris ...

paļdies, palasīšos

arī es... kā gan es to varēju nezināt? Bet lūk tā:

A secure version of the WebSocket protocol is implemented in Firefox 6 (named MozWebSocket), Google Chrome 14, Opera 12.10 and Internet Explorer 10.

laikam vairs nevajadzēs risinājumus ar flash.

Uztaisi, ka otrais izsaukums ir kā callback pirmās funkcijas beigās, un tiek iebarots tajā setTimeout(). Var ne kā parametru, bet kā globālo mainīgo.

 

Vai arī uztaisi, ka ar setInterval tiek gaidīts, kad beigsies pirmā funkcija un tad palaiž otro.

prieks, ka kāds vismaz piedzimst par programmētāju. :)

Ne gluži, bet to, vai ir materiāls, kuru vērts slīpēt, var saprast ātri. Konkrēti šeit acīs duras frāze "izmēģināts pilnīgi viss". Acīmredzot, kaut ko tomēr neesi vēl izmēģinājis ;)

 

Pamēģini sākt visu no 0 un tad skaties, kurā punktā pazūd tie burti. Noņem tos set charset, set names, pamaini tabulām, konekcijai charsetus. Nešķiet interesanti, netrīci līksmē to darīt? Tad pagaidi, kad pašam radīsies interese. :)

Domāju, ka datoru vari pārdot, nopērc planšetīti, varēsi browsēt webu utt.

Pirmo reizi dzirdu šādus principu nosaukumus, bet, pēc tā, ko tie izsaka - es teiktu, ka jā! :-)

 

$account->decMoney($total);$account->increaseSpace($amount);

Manā variantā nepārādās atkarots koda paterns.

Manā variantā nav iespējams palaist garām izņēmumus: pietrūkst nauda, pietrūkst space, nevar nopirkt vairāk space, kā maxspace un visus citus, kuri šai gadījumā netiek apskatīti un pārbaudīti, bet varētu rasties.

Var gan, skat. kā:

 

$account->increaseSpace($amount);

 

Ja var aizmirst biznesa loģiku, tad to var aizmirst arī šādi - aizmirstot noņemt naudu. ;)

Tāpēc, ka pasaulē tu neesi vienīgais.

Izcili!

 

Neesmu darbojies citās jomās, varbūt tur tas nespēlē tik ļoti lielu lomu, nekā programmēšanā, tāpēc nekrīt acīs tik ļoti, ja šo faktu ignorē. Varbūt citās jomās tos, kuri negrib pieņemt šo faktu, vienkārši izgrūž. Piemēram, atnāk celtnieks uz darbu un pasaka, ka viņam nepatīk standarta ķieģeļi, viņam gribas katru ķieģeli savādāku un tie pamati arī, nu priekš kam tie vajadzīgi... Domāju, ka tur ar tādiem nediskutē, kā programmētāju vidū - mēģina pārliecināt, ka, redz, vajadzētu tā kā ievērot labās prakses, derētu tā kā patternus pielietot utt.

 

Tad tādi izgrūsti, "neviena nesaprasti", šie cilvēki pamana, ka varbūt varētu programmēt - maldīgi pieņemot, ka tur var darīt visu tā, kā gribās pašam.

Bet tieši šāda izmantošana man nepatīk

Man nepatīk, ka uz darbu jāiet 9-18. Ļoti nepatīk. Bet, iespējams, ir iemesls, kāpēc pasaule tā iekārtota. Tas pats attiecas uz programmēšanu.

Vai arī tu varētu izbeigt būt daunis, jo ņehuj kaut ko pārbaudīt pa vidu visās reizēs, kad tiek izsaukta metode, ja var pārbaudīt tikai vienreiz - pašā metodē?

 

Ar tādu centību un tieksmi vairāk darīt tev grāvji jārok, nevis jāprogrammē. Jo no minētajiem tikai grāvju rakšanā ir svarīgs izraktā grāvja garums; jo garāks, jo labāk.

Tu piedāvā visās metodēs "pārbaudīt tikai vienreiz - pašā metodē"?

 

Kāpēc tik ļoti centies regulēt, kuram nebūt programmēt? Varbūt Tu pats zemapziņā baidies no atklāsmes, ka esi izvēlējies neīsto jomu un tāpēc centies atgrūst citus? Dīvaini...

Piedāvāja man tur darbu. Divreiz. Nu ja jau tu to tik ļoti izcel...

Nākas skumji atzīt, ka man nav piedāvāts nevienu reizi... :-( Vai tas bija tā, ka ja teiktu "jā", tad uzreiz parakstītu līgumu un piedāvātāji nebija rekrūteri?

Bet tur jau tā lieta, ka ievietot šo pārbaudi zemākajā līmenī un vienu reizi ir daudz vienkāršāk un ar daudz mazāku iespēju, ka tas tiks aizmirsts.

Piemēram, ievietot, vai lietotājs ir autorizējies, vietā, kur tiek pieprasīts autorizēts lietotājs. Parbaudīt vai nauda pietiek, vietā, kur tā tiek noņemta. utt.

Tālāk, lai cik vietās tev vajadzētu pēc tam autorizētu lietotāja kontu, vai noņemt naudu, tev šī pārbaude jau būs. Pat elementārās darbībās var būt desmitiem dažādu iemeslu, kāpēc konkrētā darība nevar tikt izpildīta, ja katrai darbībai tiks rakstītas pārbaudes visiem šiem iemesliem, agri vai vēlu, kāda pārbaude tiks aizmirsta un noteiktos apstākļos tiks izpildītas darbības, kuras nedrīkstēja pildīt.

 

Piemēram, dzēšot kontu, netika izdzēsta sesija. Tas ir piemērs, mazvarbūtīgs, pat uzskatāms par bugu. Bet šeit nav runa par procentuālo varbūtību kā tādu, bet gan par principu - par to, ka tas teorētiski ir iespējams un katrai darbībai uzrakstīt visus iespējamos pārbaudes nosacījumus un to daudzās kombinācijas ir sarežģīti un tā ir reāla vieta kļūdām.

Jā, jautājums, kā nodalīt atbildību par to, kurš veic šo pārbaudi?

Viens variants ir modeļos, taisot tight-coupling. Cits variants ir FC + ACL, kas nodrošina, ka attiecīgās kontrolieru metodes ir pieejamas autorizētam lietotājam. Bet, piemēram, batch skripts, kurš ielādē pasūtījumus, kas tiek novilkti CSV failā no citas sistēmas, varētu negribēt nekādu autorizācijas pārbaudi, neskaitot to, ka tiek nodrošināta šī avota uzticamība. Autorizācijas pārbaude modeļos vairs nebūs tik ērta, ne tā?

Redz, tu pat nespēj par visām situācijām iedomāties, bet eksepšanu gadījumā nav jāiedomājas. Ja būs anomālija, tad atbildīgā vieta izmetīs eksepšanu un sliktākajā gadījumā lietotājs saņems paziņojumu par tehnisku kļūmi, nevis aplikācijas mēģinās veikt absurdas darbības.

Tātad, kā šāda situācija var rasties.

1) Lietotājs atver tabu, kurā ir pirkums.

2) Lietotājs atver otru settingu tabu, kurā ir konta dzēšana. Tā kā, piemēram, likumdošana nosaka, ka lietotāja datus paturēt nedrīkst (piemēra situācija), konts jādzēš.

3) Izdzēš kontu 2. tabā.

4) Taisa pirkumu 1. tabā.

Šādā situācijā 4. punktā būtu jābūt "Neesi autorizējies", ja vien tā forma nez kapēc hidden datos padod lietotāja ID tā vietā, lai lietotāju noteiktu pēc sesijas ID. Exception varētu izlido tad, ja pirkumu taisa lietotāja dzēšanas laikā un pieprasījuma sākumā lietotājs vēl nav izdēsts, bet, kodam nonākot līdz tranzakcijas uzsākšanai, lietotājs jau ir izdzēsts.

 

Te arī rodas jautājums, vai tad, kad kods, kurš pieņem, ka lietotājs ir autorizējies un eksistē, tiek veikts pirkums, iespēja, ka klients vairs neeksistē, ir izņēmums (metam Exception), vai daļa no biznesa loģikas (redirect uz login lapu)? Vai tas tiek realizēts programmas kodā vai datubāzē? Ja datubāzē ir pilns ar nosacījumiem, vai tos dublēt kodā (negribētos), jeb kodā uzķert DB Exception? Utt.

Nu ja aizmirsi apstrādāt šo izņēmumu, tad lai labāk met tādu lietotājam. No otras puses, ja tie ir IFi, tad šo kļūdu jau būs problemātiski atrast (lietotājs nevarēs nopirkt, bet kāpēc tad ej un meklē kodā, jo kāds aizmirsta apstrādāt šo situāciju).

 

Tas, kā šī lieta varētu praktiski realizēties, ir Exception, ko izraisa datubāzes nosacījumu (constraints, rules) neizpildīšanās. Ja domā programmā veidotus nosacījumus, kas izmet Exception gadījumam, ja šie nosacījumi tiek aizmirsti, tad tas tā interesanti sanāk. Un ja nu aizmirsīsi izveidot nosacījumu, kas izmet Exception gadījumiem, ja tiek aizmirsti nosacījumi? :-)

Izņēmumsituācijas ir dažādas, par to MS piemēru runājot, man tā izskatās pēc pārbaudes, vai sistēmas dati ir korekti. Vienkāršs piemērs:

 

 

// Kāda datubāzes modeļa kaut kāda metode:
 
$rows = $dataTable->find($id);
if (count($rows) == 0) {
    // Nav atrasts
    // Web aplikācijas GET gadījumā nav exception
    // Bet IR Exception, ja tas ir kodā, kur zināms, ka $id ir tikai reāli eksistējoši DB ieraksti.
    // Un to izlemj metode, kas izsauc (kontrolierī, citā modelī), tāpēc te tikai return.
    return false;
} elseif (count($rows) > 1) {
    throw new Company_Developers_Drunk_Exception('Kaut kas neticams, nav PK!');
}
 
// Normālais gadījums
...

 

Tādejādi, piemēram, ja lido ārā Exception, tad ir skaidrs, ka sistēmā kaut kas darbojas nepareizi, darbība neraisa uzticību un situācija prasa izpēti. Un, visticamāk, programmas labojumu. Iespējams - apkārtrisinājumu, izveidojot programmatisku rīcību, ja zināms, kas jādara kāda konkrēta Exception gadījumā.

 

Tāpēc arī negribētos biznesa loģikai izmantot Exceptions, jo jau pašā sākumā ir zināms, kā jārīkojas katrā situācijā un ka būs jārīkojas, jo neatstās taču tā, ka sistēma izvada pircējam rezultātu "Sistēmas kļūda: nepietiekams preces atlikums. Gadījumā, ja kļūda atkārtojas, lūdzam sazināties ar tehnisko dienestu."

Īsāk nenozīmē saprotamāk, saprotamāk nenozīmē īsāk. Kā jau te tika minēts, Exceptions izmanto izņēmumsituācijām, nevis biznesa loģikas kontrolei. Ja biznesa loģika ir gara un sarežģīta, tad tas tā arī ir. Kā novērst koda dublēšanu un kur izvietot šo sarežģīto loģiku? Tas ir arhitektūras lēmums, jau minētā izvēle starp fat controllers/thin models vai thin controllers/fat models. Vai šo darbību veiksim kontrolierī, vai konta (account) modelī, vai pat veidosim atsevišķu modeli? Ja veidojas gari, nepārskatāmi IFi, tos var saīsināt, pārnesot uz metodēm ar pašdokumentējošiem nosaukumiem, kontrolierī vai modeļos un IFu saturu aizvietojot ar šo metožu izsaukumiem.

 

Nesaku, ka ar Exceptions nevar panākt līdzīgu rezultātu, bet... arī ar GOTO var daudz ko izdarīt. Es gan tā nedarītu. Esmu tā darījis, tas kods man pašam nepatīk un tika/tiek pārtaisīts. Exceptions neiesaka lietot tā, kā to apraksti Tu. Laika trūkuma dēļ nevaru iedot atsauces vai izveidot koda paraugu, taču, ja tas nav pavisam droši, vismaz es esmu pārliecināts, ka tā pat ir slikta prakse. Un arī koda vienkāršošana reizēm, bet ne vienmēr, nozīmē tieši to, ka kods tiek izveidots garāks un darbojas lēnāk, un to izveidot aizņem ilgāku laiku. Taču, vai Tu zini, ko nozīmē uzturēt ātri un pa savam izveidotu sistēmu un ieviest tajā izmaiņas?

+marrtins, F3llony

Aiziet iekurt krāsni un pārskaitīt sveces.

Atsevišķs AJAX kontrollieris? Kontrolieris var būt viens un tas pats, AJAX gadījumā datus atgriež AJAX formātā, ne AJAX gadījumā parastajā formātā. Man, piemēram, patīk ZF risinājums, kurā iespējams ieslēgt konteksta slēdzi, kas, konstatējot, ka pieprasījums ir AJAX (pēc header), skatam piešķirtos datus atgriež AJAX formātā, attiecīgi, izslēdzot layout un view. Vienu un to pašu action metodi var izmantot nemaz nemainot to (metodi), jo konteksta "ķeršanu" ieslēdz kontroliera modeļa init() metodē. Lūk, DRY! Pielietojums: attēlo lapas sākotnējo ielādi ar view, un, ja klients atbalsta JS, HTML piedāvā lapas atjaunošanu (vai pāršķirstīšanu, utml.) ar AJAX, saites downgreidojas uz HTML saitēm, ja JS nav. Attiecīgi, bez JS viss notiks tāpat, tikai ar pilnu lapas pārlādēšanu. Tā kā klienti bez JS šobrīd nav aktuāli (laikam), tad reālākais lietojums ir tāds, lai Google varētu indeksēt visas lapas, nevis tikai pirmo.

 

Account modelī funkcija, kas pārbauda, vai accounts ir autorizējies? Tas varētu būt novecojis variants. Kā jau teikts, autorizācija ir kontroliera atbildība, autorizēties var daudzos dažādos veidos.

 

Exceptions derētu lietot izņēmumsituācijām, nevis ļoti atbilstošām pārbaudēm. Cik zinu, Exceptions mētāšana nav efektīvs veids pārbaužu veikšanai gan no programmas izpildes viedokļa, gan no koda uzturēšanas (saprotamības) viedokļa. Vēl arī jautājums par tranzakcijām - pārbaudot konta atlikumu, tajā sekundes daļā, kad tiek veikts pirkums, tas var izmainīties. Kā to risināt, kurā brīdī iesākt tranzakciju un kā izvairīties no deadlock?

 

Kontrolieri ir dažādi, tipiski web FW satur FrontController un ActionController, vēl arī nodala fat models/thin controllers vs. thin models/fat controllers - divas dažādas pieejas. Primāri daudz ko nosaka FW izvēle. Ja izvēlas gatavu FW ar labu arhitektūru, atliek vienkārši tai sekot. Ja ir vēlme ieciklēties uz savu FW un ignorēt jomas attīstību turbo tempos, var jau darīt arī tā...