Dev thinking loud

Oldingi misolimizdagi useState funkciyasining ozgartirilgan varianti, endi natijamiz boshqa

Mana shu kodda konsolga 3 ta qiymat chiqadi, ular qanday qiymatlar va nega bunday natija oldik? (Bu misol reakt steyt hukining tabiatini yaxshiroq tushinishga yordam beradi)

script elementlarda async va defer attributlar tasiri vizual ko'rinishi manba: linkedin

Test yozish (amaliy dars 3) https://youtu.be/dZ-AE-xdi8E

Test yozish darslaridagi project sourcelarini shu joyga joylab boramiz: https://github.com/ravshansbox/testing-demo

Test yozish (amaliy dars 2) https://youtu.be/JJgPdPA5eU8

Test yozish (amaliy dars 1) https://youtu.be/lJApALl3cro

Basic tooling setup https://youtu.be/xjhawdJkElY

Testing boyicha birinchi darsimiz https://youtu.be/PzPZxJkP7rc

Yangi dars boshladik https://www.youtube.com/playlist?list=PLn8TR1nMED9bapVTZrouMB988Tf9fN9HA

Test yozish (testing) haqida gapirilganda quyidagi savollar ko'p beriladi: - "Automated test" yozishga ko'p vaqt ketib qoladi, bu tajriba o'zini oqlaydi mi? - "Manual test" yetarli emas mi? - Qanday qilib implementation yozmasdan unga test yozish mumkin? Bular juda asosli savollar va bejiz berilmagan. Birinchidan, "manual testing" va "automated testing" bir-birining o'rnini bosmaydi, bu ikkalasi ham "software testing"ning tajribada ishlatiladigan "branch"lari hisoblanadi. Ikkinchidan, ha, "automated test" yozishga ko'proq vaqt ketadi, ayniqsa bu tajribani yangi boshlagan paytda bularga ketadigan vaqt nisbati juda katta bo'ladi, tajriba shakllanishi bilan bu nisbat kamayishni boshlaydi. Lekin bitta fakt bor, "automated test"lar yozilgandan keyin ularning "run" qilishga ketadigan vaqt "manual testing"ga ketadigan vaqtdan ancha kam. Va bu "process" ko'p marta qaytarilganda bu farqdan yutilgan vaqt ortib boradi va bora-bora test yozishga ketgan vaqtni "compensate" qilib "foyda" (vaqt hisobida) ham keltirishni boshlaydi. Endi, hop, test yozishni boshladik, TDD ishlatishimiz shart mi? Bu test yozishning keyingi darajasi, agar test yozish tajribasi yangi boshlangan bolsa maslahat bermayman, chunki dasturchida bu tajribaga nisbatan "frustration" paydo qilishi mumkin. Testing APIlar, toollar, tajribalar bilan tanishgandan keyin, terminologiyasiga yaxshiroq kirishgandan keyin TDDga switch qilish maqsadga muvofiq deb oylayman. Bu tajriba dasturchidan biznes talablarni oldindan ko'ra bilish, kod yozmasdan oldin miyyasida "dasturlash"ni o'rganishni talab qiladi. Mana shu instinktlar ozgina "develop" qilingandan keyin TDD dasturchi uchun intuitiv tuyulishni boshlaydi va bir muddatdan keyin voz kechilmas tajribaga aylanadi. Umuman olganda, bu tajriba xalqaro kompaniyalarda dasturchining "invaluable skill"laridan deb baholanadi. Shu skill yetishmasligidan xatto interviewni fail qilish ehtimoli ham bor.

Bir kutubxona ishlatganda uning eng sodda holini implement qilib korishga odatlanishni maslahat beraman. Shu yol bilan kutubhonaning qilib berayotgan ishining qanchalik murakkabligini bilsa boladi.

Dasturchi deganda shaxsan meni hayolimga biron masalani (business case) yechish yo'lida (finding a solution) ketma-ket (sequential) qaror/tanlov (decision) qiladigan odamni tushunaman. Bu qarorlarni odatda o'z bilimi (knowledge) va tajribasi (experience) asosida qiladi, bular o'z navbatida boshqalarning (community) shu kabi masalalarni yechishdagi bilim va tajribalariga (best practices) tayanadi. Shu joyda bir narsani unutmaslik kerak, odatda masalaga yechim potencial jihatdan juda ko'p bo'ladi (bizning ko'zimizga bir yoki bir nechta yechim charaqlab koringani bilan) va har bir yechimning yaxshi va yomon tomonlari bo'ladi. Dasturchining vazifasi bu yaxshi va yomon tomonlarni taroziga tortib masalaga to'griroq yechimni topish. Mana shu jarayonida dasturchi obyektiv va ochiq fikrda (open-mind) bo'la olishi juda muhim. Insonning bazi narsalarga (bizning holatda yechimlarga) ong osti hissiyotlari bo'ladi (unconscious bias), inson bu hissiyotlarni nazorat qila olmasligi mumkin lekin uning shuurida (awareness) bolishi kerak va bu uning tanlovlarda obyektiv bo'la olishiga halaqit qilmasligi kerak. Shu joyda yana bir nuqtani takidlab otishimiz kerak, eng yaxshi tajribalar (best practices) doimiy bo'lmaydi, ularning tabiati o'zgaruvchan, shuning uchun ularni o'rganganda nima sababdan ular eng yaxshi tajriba (best practice) ekanligini ham o'rganing, chunki bu sabablar ertaga eskirganda bu tajribalar "eng yaxshi" maqomini yo'qotishi mumkin.

Muammo nimada?