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.
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.
🔥23👍6
Bir kutubxona ishlatganda uning eng sodda holini implement qilib korishga odatlanishni maslahat beraman. Shu yol bilan kutubhonaning qilib berayotgan ishining qanchalik murakkabligini bilsa boladi.
👍17🔥3
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.
- "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.
👍15
Yangi dars boshladik
https://www.youtube.com/playlist?list=PLn8TR1nMED9bapVTZrouMB988Tf9fN9HA
https://www.youtube.com/playlist?list=PLn8TR1nMED9bapVTZrouMB988Tf9fN9HA
🔥4
Testing boyicha birinchi darsimiz
https://youtu.be/PzPZxJkP7rc
https://youtu.be/PzPZxJkP7rc
YouTube
Test yozishga kirish
Intro into testing
Sources: https://github.com/ravshansbox/testing-demo
Sources: https://github.com/ravshansbox/testing-demo
👍12
Test yozish darslaridagi project sourcelarini shu joyga joylab boramiz:
https://github.com/ravshansbox/testing-demo
https://github.com/ravshansbox/testing-demo
GitHub
GitHub - ravshansbox/testing-demo
Contribute to ravshansbox/testing-demo development by creating an account on GitHub.
🔥9👍2😁1
Interviewlarda "React element" va "React node" farqlari so'ralganda shunga qarab javob bersak boladi
👍4
Looplarda shu yol bilan bitta callbackni hamma elementlar uchun ishlatsa boladi.
Birinchi misolda har element uchun yangi callback yaratilyapti, ikkinchisida esa hammasi uchun bitta ishlatilyapti
Birinchi misolda har element uchun yangi callback yaratilyapti, ikkinchisida esa hammasi uchun bitta ishlatilyapti
👍24