Tavs Ajax ielādes ātrūms.

[Wuu]

Cik ir minimālais ielādēs laiks ko varētu sasniegt no brīža kad tiek nosūtīts JSON caur ajax un tiek saņemta atbilde. Vai 200ms ir ok? Gribētos ātrāk. Mēru ar Firebug. Ja tā vispār ir pareizais veids mērīt. Vienkārši tiek lietota pusjēla Windows mašīna (Nav mana izvēle). Kādā ir kolēģu pieredze šajā jautājumā?  Ja 200ms ir stipri par lēnu, varētu papēti šo jautājumu.

[jurchiks]

Nestrādāju viens pats (izņemot vienu projektu, pie kura pašlaik vairs nestrādāju, projekta autors klusē jau kopš vasaras vidus, projekts klusi grozās un viss notiek), nedz arī pie maziem projektiem, visi ir lieli un veiksmīgi. Tu arī man bāzīsi testus rīklē?

 

Tevis minētajiem vienkāršajiem un "krutajiem" variantiem nav nekāda sakara ar optimizāciju, tās gluži vienkārši ir sākotnējās versijas un to attīstība. Par tādu sīkumu izstrādi jau no paša projekta sākuma neviens te nerunā, tu te ej galējībās tāpat kā daGrevis.

 

 

@daGrevis - t.i. tu raksti testus, bet nenodarbojies ar TDD?

Edited September 18, 2014 by jurchiks

[daGrevis]

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

[codez]

jurchik, kā jūs garantējat, ka mainot kaut ko vienā vietā, kaut kas netiek salauzts citā vietā, ja nav testu?

[jurchiks]

Nekad ar to nav bijušas problēmas, un es programmēju jau vismaz četrus gadus.

Es vienmēr cenšos rakstīt īsas un vienkāršas funkcijas, kuras dara tikai vienu lietu un neko citu.

Ja tu raksti super-funkcijas, kuras dara krasi atšķirīgas lietas atšķirībā no parametriem, tad tā jau ir tava problēma.

 

Vispār, situācija "mainot kaut ko vienā vietā, kaut kas netiek salauzts citā vietā" ir raksturīga spageti kodam.

Edited September 19, 2014 by jurchiks

[Kemito]

Ja Tu raksti mazas funkcijas/objektus, tad tos iztestēt noteikti nav grūti. Uzrakstīt pārus testus arī neprasa augstāko pilotāžu, bet gan vēlēšanos, tad vismaz piektdienas vakarā ar mierīgu sirdi var deployot un iet dzert alu.

Testus var rakstīt kaut vai pēc mēneša vai diviem, ja zini, ka nāksies papildināt lapu ar kādu funkciju.

Testu rakstīšana vien liek tikai iedziļināties tajā ko dari, nevis tupi cerēt, ka viss ies. Varbūt vienā projektā Tev ir ok, nāks nākošie, var gadīties, ka nestrādā. Raksto testus vari teju skipot vispār sadaļu kurā ver pārlūku un skaties vai konkrētā funkcija strādā.

Sākumā loģiski, ka tas liksies ilgāk, jo agrāk arī kodu uzrakstīt prasīja ilgāk, nekā tagad.

Testi ir štelle, un kamēr lāga nepamēģinās, tikmēr nesapratīs līdz galam kapēc.

Edited September 19, 2014 by Kemito

[daGrevis]

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

[Kasspars]

Iesācēji programmētāji uzskata, ka zin visu. Pro programmētāji uzskata, ka nezin neko

[jurchiks]

@Kemito - kā tu ieviesīsi testus projektā, kurš ir apritē jau 9-10 gadus un pie kura strādājuši desmitiem programmētāju? Un vai tas būs tā vērts?

Kā tu uzrakstīsi testu, kas pārbauda, vai kaut kāda lapa vai dizaina elements izskatās pareizi visos vajadzīgajos pārlūkos?

Un visbeidzot, kā tu pārbaudīsi VISU, ne tikai to, kas TEV ienāk prātā? Neba nu rakstīsi simts testus, lai izķidātu absolūti visus vienas funkcijas iespējamos return values, ieskaitot corner cases. Tā ir ārkārtīga laika izšķiešana.

 

@daGrevis - vai tev tā ir ierasta lieta, ka kolēģi lauž tavu kodu?

 

TL;DR - paturiet savus testus pie sevis, un es neteikšu, kur jums tie jābāž. Nekad nevajag citiem uzmākties.

 

 

@Kasspars - "Pro programmētāji uzskata, ka nezin neko."

Vai tiešām?

Edited September 19, 2014 by jurchiks

[daGrevis]

> vai tev tā ir ierasta lieta, ka kolēģi lauž tavu kodu?

 

Jā, un otrādi. Gribi teikt, ka pie vainas slikts kods?

[gurkjis]

Nu ja, nevar lietas iedalīt tikai melnā un baltā. Māksla arī tad rodas, kad Tu primāri bliez projektu "pa rupjo" un ātri, bet tai pat laikā kods ir kvalitatīvs, taču tas nāk tikai ar laiku. Tāpēc, ja nesanāk apmierinošu vidusceļu izpildīt, tad variē ar taktiku - vienā gadījumā cērt pa ātro, citā spied uz kvalitāti (nu, piem. saviem hobij projektiem). Un tad ar laiku  šīs abas taktikas apvieno. Un tā tas arī citur dzīvē, ņem praktizē galu A, tad B un pēc tam jau varēsi pa vidu šiem turēties, jeb var teikt, ka pratīsi abas lietas reizē.

 

Par testiem - nu es arī pagaidām kā Jurchiks, pret tiem atņirdzu savus zobus, jo man liekas, ka tas ir pārāk sarežģīti (apjomīgi), tāpēc man to negribas darīt. Visur, kur ir apjoma darbs, es domāju kā to apiet, lai man nebūtu kā robotam tās lietas jāknabā pa vienai.

 

Vienkāršāk būtu tā: man ir aplikācija, kurai ir koka struktūra no aktivitātēm, kas veidojas, staigājot pa UI (t.i. simulējot lietotāja visus iespējamos ceļus,ko tas varētu izstaigāt). Dažādi user-generated events (piem. keyboard entry). Attiecīgi viss kods tiktu izpildīts no paša augstākā abstrakcijas slāņa (nevis individuālas metodes testējot). Un tā kā tas notiek no pašas augšas, tad jau testu apjoms vairs nav tik liels :) Otrs tas,ka tiktu testēts tikai un vienīgi tas,kas aplikācijai tiešām nepieciešams. Ķeram exceptions un log messages. Testus palaižu ar 1 pogas spiedienu, vai periodiski, vai uz dažādiem datu setiem, utt. 

 

Tur, protams, ir vēl "brīvie gali", kas vēl nav skaidri, kā to visu ideju nosiet, tā lai praksē strādātu.

Edited September 19, 2014 by gurkjis

[codez]

TL;DR

daGrevis uzrakstīja vienu īsu teikumu. Kāpēc tas ir par garu un kāpēc tu atsakies to lasīt?

[jurchiks]

@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.

 

@gurkjis - kurš te iedala lietas melnā un baltā? Ja tu domā, ka tas esmu es, tad kāpēc tu tā domā?

Par to koka struktūru un tās testēšanu - izklausās jau jauki, bet reālās aplikācijās tas parasti nav tik vienkārši.

+testus it kā vajadzētu palaist pirms katra kommita vai vismaz pusha (ja izmanto GIT).

 

@codez - tas TL;DR bija par MANU postu... Reading comprehension, do you have it?

Edited September 19, 2014 by jurchiks

[daGrevis]

> @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.

[codez]

Tas nozīmē, ka jūsu 9-10 gadus vecajā projektā nevien no 3rd party bibliotēkām netiek atjaunināta uz jaunāku versiju?

Pat nelielas izmaiņas 3rd party bibliotēkas api var nobrucināt kādu aplikācijas daļu. Testu gadījumā to uzreiz noķer, kamēr bez testiem bug-s karājās, līdz kāds useris to uziet. Un šis izmaiņas var būt ne tikai dokumentētas, bet arī dēļ buga, kurš ieviesies slikti testētā 3rd party sistēmā.

Tad man vēl ir tādi jautājumi:

Jums tajā 9-10 gadus sistēma taču mēdz būt bug-i?

Jūs vispār izmantojat bug tracking sistēmu?

Un, ja jums ir bugi, tad kādi ir šo bugu biežākie iemesli?

Edited September 19, 2014 by codez

[gurkjis]

@gurkjis - kurš te iedala lietas melnā un baltā? Ja tu domā, ka tas esmu es, tad kāpēc tu tā domā?

Par to koka struktūru un tās testēšanu - izklausās jau jauki, bet reālās aplikācijās tas parasti nav tik vienkārši.

+testus it kā vajadzētu palaist pirms katra kommita vai vismaz pusha (ja izmanto GIT).

 

- diskusijas augstāk to tā iekrāsoja, taču definēsim a) "melnu" un b) "baltu":

a) domā tikai par to, lai ārējais rezultāts ir labs, bet nepadomā par to,vai nebūs pēc tam baigais murgs projektu tālāk attīstīt

b) domā tikai par koda kvalitāti, aizmirstot, kas pasaulei ārēji ir vajadzīgs

 

tagad iedomājies skalu 

A.............B, kur A = 0 un B = 1.0

un piešķir sev vērtējumu, kurā punktā atrodies

 

ja esi intervālā no 0.25 līdz 0.75 , tad es neteiktu, ka esi tikai melns vai balts. 

 

Kā arī, šo forumu lasa vairāki cilvēki, es nerakstu konkrētām personām, bet ideju sēklas, ko apgremot, varu pa ceļam aizņemties.

Edited September 19, 2014 by gurkjis