daGrevis

> Es jau teiktu, ka tas ir salauztās "don't fix what's not broken" mentalitātes dēļ - kods strādā, značit uzlabot nevajag, značit neviens nekad to arī nelasa, un ja tur ir bags, tad neviens par to neuzzin līdz brīdim, kad kaut kas šāds uzpeld. Šoreiz es tev piekrītu. :)

Mhm. Šitas ir pat lielāks par Heartbleed.

Nu bļin ja tu esi atpalicis, savā kantorī sežot un neko nedarot, plus vēl nemāki izstāstīt kāpēc tev ir taisnība un kāpēc man nav, nemaz nerunājot par apvainojumiem, kas vienkārši parāda tavu nožēlojamo līmeni, tad nav jēgas nemaz te runāt. Wannabe nolādētais...

Pilnīgas muļķibas. Testētājam nevajadzētu mācēt programmēt, kur nu vēl jāredz kods. Testētājs, jeb QA, ir cilvēks, kurš pārbauda, vai implementētā sistēma dara to, ko ir prasījis bizness, — tas, kas ir aprakstīts specifikācijā. Viņš to lieto no tāda skatpunkta, kā to redzēs potenciālais klients. Web gadījumā, tas ir caur browseri. Testētājs cenšas salauzt sistēmu. Iemesls, kāpēc QA neredz kodu ir tāds, ka testus, kuri zina par kodu un tā struktūru, raksta programmētāji. Progremmātāji raksta kodu un raksta testus, kas testē viņu uzrakstīto kodu. Sistēma, kurā cilvēks, kurš kodam raksta testus ir cits, nekā tas, kurš rakstīju kodu, ir ļoti neefektīva, jo uzrakstītam kodam uzrakstīt testus un daudzreiz grūtāk. Ja tu biji domājis, ka ir QA, kurš dara to, ko es aprakstīju, — attiecīgi testē kā to redzēs klients, bet viņam ir pieejams kods — tas arī ir ļoti neefektīvi. Ja QA var redzēt kā sistēma strādā, tas ir tāds pats simple testings, ko veic programmētājs jau rakstot kodu — pārbaude rakstot, ka kods dara to, ko tam vajadzētu darīt. Jebkurā gadījumā, diezgan absurdi. Par to, kas “ir normāli“ vai nē, — nesmuki izteicos. Datu struktūrai, kas ir datubāzē, vajadzētu būt aprakstītai kodā, kaut vai tikai tāpēc, lai tā būtu versiju kontrolē un visa vēsture būtu redzama. Tam obligāti nevajag būt ORM, SQL faili ar CREATE TABLE būtu pietiekami (neērti, bet pietiekami). Tas, ka tu kko modelē gudrā veidā nenozīmē, ka tam, ko esi uzmodelējis, nevajag būt nekur aprakstītam, izņemot reālo produkcijas datubāzi. Es arī tabulas un to relācijas zīmēju uz whiteboard, pirms tās pārkonvertēju uz modeļiem. Tas, ko vēlējos teikt — datubāzei ar datiem nevajadzētu būt original source par to kāda ir datubāzes struktūra.

Datubāze tiek modelēta no modeļiem, nevis otrādi. Normālā gadījumā.

Neviens neteica, ka būs viegli. Bet šāda prakse tiek piekopta milzīgajās sistēmās.

Tāpēc roll-outo jaunās izmaiņas pa daļām. Sākumā tikai dažiem procentiem visu lietotāju un tad, ja viss ir smuki, palielini ciparu.

Viens vārds — shared state. Divi vārdi.

> Tieši tā, tāpēc agile nosaka iterācijas ciklu - vai uz šo konkrēto brīdi kods strādā vai nē, nestrādā - reject, strādā - accept Tieši tā. Kāds ir izpildījis mājasdarbu. :)

> Nuu unit-testus arī var rakstīt unit-testu unit-testiem, kas testē skatus. Jautājums ir, vai no tā ir kāda jēga un LEAN. Atkarībā no tā, kā projekts ir strukturizēts, un kas, kāda veida kods un cik daudz, ir kontrolerī, bet es domāju, ka _unit_-testi kontrolerim arī ir diezgan svarīgi. Protams, testi testiem ir absurds.

Nuu unit-testus arī var rakstīt kontroleriem un whatnot, ja māk mockot un patchot.

Nē. Ja bilde būs redzama, tā būs paņemama. Best bet būtu watermark.

> Ja piecas reizes pārlasa visas vietas, kur maināmais kods tiek izmantots, ir iespējams. Keyword: readability. Tu esi tik naivs. :)) > Ātrāk bagu atrast, nekā uzrakstīt testus, kas to bagu atradīs. Tikai ieskaiti to laiku, ko tev vajag manuāli pārbaudīt katru fīču, kas pirms tam it kā strādāja, pirms tika uzrakstīta jaunā fīča. **Automātiskie** testi **katru reizi**, pie izmaiņas. > Nē nu ja codez tiešām raksta testus, tad viņš tiešām ir True man. A man likās, ka ja tu to nedari, tevi neņem darbā normālās vietās. :( Gribu teikt, ka tas ir like must-do labiem programmētājiem, ne tā? > Un bez labiem testiem, tu nevis ātrāk bug-u atradīsi, bet vispār nezināsi, ka tāds eksistē, līdz kādam lietotājam produkcijā kaut kas nestrādās. Sentry.

Labs, briedis! Tikai nevajag tik garus testus un iesaku padomāt, vai tiešām gribi glabāt punktus kā float. > Tiem, kam ir pieredze ar testēšanu - kad jūs tos testus rakstāt? Tiešām piekopjat "testi vispirms, kods pēc tam"? Jo varbūt, ka man ir līkas rokas un es nespēju pats sevi paredzēt, bet bieži vien mēnesi pēc projekta sākšanas tā struktūra ir tik atšķirīga no sākotnēji iecerētās, ka pirms tam rakstītie testi vnk ir bezjēdzīgi. Nevajag to visu tik ļoti nodalīt — koda rakstīšanu un testu rakstīšanu. Uzraksti testu, kas pierāda, ka simple case vienkārši strādā. Tad uzraksti jaunu testu, kas pieliek jaunu, (nedaudz) sarežģītāku testu. Tas nofeilos. Pamaini implementāciju tā, ka abi testi ir zaļi. Bieži vien būs jāparaksta visa metode, un nebūs jāuztraucas, ka kkas tiek salauzts — iepriekšējie testi tev pierāda, ka rezultāts ir tāds pats. Rinse and repeat. Zinu, ka jūs heitojat citas valodas, bet kad rakstīju savu Lisp dialektu, testi bija tieši tādi, kā es tikko stāstīju. https://github.com/daGrevis/diy-lisp/tree/master/tests Tie ir totāli unit-testi. Šeit, piemēram, ir integrācijas testi manam blogam. https://github.com/daGrevis/daGrevis.lv/blob/master/dagrevis_lv/blog/tests.py Oh, un vēl viena doma, kas papildina šo: > Nevajag to visu tik ļoti nodalīt — koda rakstīšanu un testu rakstīšanu. Testi tiek mainīti non-stop, ar kodu rakstīšanu tu raksti jaunus un maini vacos, jo tie lūzīs un that's the point.

Kolēģis uzrakstīja, maģiski strādā (mostly). :D

Mēs lietojam Grunt un viņš visu sapako pats.

> @daGrevis - ja kolēģim jālauž tavs kods, lai dabūtu gatavu kaut ko citu, tad es uzskatu, ka jā, pie vainas ir slikts/nefleksabls kods. Tā nevajadzētu būt. Tu nesaproti. Kods nav jālauž — tas salūzt darot kko citu.

> vai tev tā ir ierasta lieta, ka kolēģi lauž tavu kodu? Jā, un otrādi. Gribi teikt, ka pie vainas slikts kods?

Ja tu nelauz savu kodu, un kolēģi nelauž tavu kodu, ko jūs tur īsti taisat tad — kontaktformu?

TDD nozīmē testi pirms koda. Cenšos tā, bet ne vienmēr tas tā sanāk.

> Pilnīgas muļķības. Vai tu tiešām uzskati, ka bez TDD nav iespējams rakstīt fleksablu kodu? Tas ir nesalīdzināmi grūtāk. Un nejauc TDD ar testiem.

> Un testus vispār te nevajag pīt iekšā. Ja tu neraksti testus, nav brīnums, ka savādāk kā perfect-with-first-time nevar, jo pēc tam mainīt būs pārāk sarežģīti. Vai tu raksti testus? Jo ja nē, tad nav jēgas nemaz skaidrot...

Ar kolēģi strīdējos kas ir UUID un kas nav, un uzgāju šo te jautājumu. Labs piemērs, kas ir optimizēts un slikti lasāms, un neoptimizēts, bet labi lasāms, manuprāt. :) http://stackoverflow.com/a/2117523/458610 http://stackoverflow.com/a/105074/458610

> Man vienīgajam liekas, ka vairums šajā topikā atbildošo cilvēku programmē stilā "ka tik ir"? Labāk ir kkas, kas dod business value, nekā nekas, jo izstrāde ir pārāk ilga, jo projekts ir over-engineered. Protams ar to “pa ātro“ nevajag ieiet galējībās, un testi, manuprāt, ir must-have, lai to izdarītu. > Vajag taču veselo saprātu izmantot, pirms ķeries klāt pie projekta. Iemācies kā var paredzēt, vai startaps būs veiksmīgs vai nē, un pastāsti P. Grahamam vai jebkuram citam, kas investē startapos kā to darīt. :)