(self) questioning

Recently, I have realized that how important it is to ask questions while reading (reviewing our colleague’s code), to make better a decision and to explore possibilities while resolving a problem. I’ll try to explain why questioning is important here.

I think (after informed by those books in the reference and my own reflection) there are several benefits:

  • To make sure that you understand correctly before making a criticism (more: reference 1)
  • It activates our analytical brain: exploring possibilities (more: reference 2)
  • To make a better decision (more: reference 3)

Simply we can ask ourselves following questions: why, why not, what if  kind of questions that can activate our analytical brain and widen our perspective. Thus, we are starting to explore/brainstorm the possibilities instead of limiting ourselves by the System1 which is automatic response of our brain in current situation.

So if you only do what the requirement says without self-questioning, you may say that you did a job done but the true value of your work is less valuable than the job that you could have done while questioning yourself.

In other words, the work you have done without self-questioning, you execute only the given work. But when you question yourself, you may figure out what customers are trying to solve. And if you have courage to tackle it through experiments in order to help them, your work would be much more valuable than before, you not only execute but also took the initiative and having better result.

References

Тэгэхээр би сонгодог уу эсвэл дууриамал тестийн аргаар хөгжүүлэгч үү ?

Орчуулгыг бүтэн эхээр нь та wordpress-ээс болон   gitbook.com  -с  үзэх боломжтой.

Энэ асуултанд итгэлтэйгээр хариулахад хэцүү. Хувьдаа бол би үргэлж хуучинсаг барилтай сонгодог TDD-р хөгжүүлэгч, үүнийгээ өөрчлөх шалтгаануудыг одоо хүртэл олоогүй л байна. Би дууриамал TDD-р хөгжүүлэгчийн үнэнхүү давуу талыг олж харахгүй байгаа ба би тестээ гүйцэтгэлтэйгээ холбохоос гарах үр дагаварыг илүү анхаарч үздэг.

Энэ намайг дууриамал аргаар хөгжүүлэгчийг ажиглаж байхад гайхшруулдаг зүйлүүдийн нэг. Би тестээ бичиж байхдаа үйлдлээ (behavior) хэрхэн хийхээ биш, харин үр дүндээ анхаарч ажиллах дуртай. Дууриамал аргаар хөгжүүлэгч тэгэх байх гэсэн нөхцлүүд (expectations) -ээ бичихийн тулд хэрхэн SUT (System Under Test буюу Тестлэгдэж буй объект) -оо хэрхэн бичих тогтмол талаар бодож байдаг. Би үүнтэй ерөөсөө дасаж өгдөггүй.

Мөн би өөрөө дууриамал TDD-г тоглоомоос илүүтэй өөр зүйл дээр оролдож үзэхгүй байгаадаа зовж явдаг. Миний Тестээр Хөтлөгдөх Хөгжүүлэлт (Test Driven Development) аргаас сурсанчлан, бодит зүйл дээр оролдож үзэлгүйгээр аливаа аргыг (technique-г) шүүмжлэх нь хэцүү. Би дууриамал аргад үнэмшилтэй, түүндээ дуртай олон сайн хөгжүүлэгчдийг мэднэ. Хэдийгээр би өөрөө сонгодог аргад үнэмшилтэй боловч, би хоёр талын давуу, сул талуудыг таньд тунгаан бодох боломжтойгоор өөрийнхөө чадах чинээгээрээ шударгаар хэлж өгч чадна.

Тиймээс хэрэв дууриамал арга таны анхаарлыг татаж байвал би таньд оролдоод үзэхийг санал болгож байна. Ялангуяа хэрэв таньд дууриамал TDD-р сайжруулах боломжтой асуудлууд байгаа бол энэ нь илүү үр дүнтэй байх болов уу. Үүнд би хоёр зүйлийг дурьдаж болж байна. Эхнийх нь хэрэв тест ажиллахгүй (fail) болох болгонд та маш олон цагийг зарцуулдаг бөгөөд шалтгаан нь тест цэвэрхэн fail хийхгүй буюу ажиллахгүй болсон тест таньд хаана алдаа байгаа талаар нарийн хэлэхгүй байгаа бол. (Та үүнийн мөн сонгодог TDD аргаар илүү нарийн тодорхойлогдсон (fine grained) тестүүдийг бий болгож шийдэж болно.) Хоёр дахь нь хэрэв таны объектууд хангалттай үйлдлүүдийг агуулахгүй байгаа бол дууриамал тестийн арга хөгжүүлэгч багыг тань илүү үйлдлүүдээр баян объектуудыг үүсгэхэд тань туслах болно.

 

Нийтлэлийг бүтнээр нь мөн gitbook.com -с унших, татаж авах боломжтой. Холбоос https://www.gitbook.com/book/erheme318/mocks-aren-t-stubs

Нийтлэлийн эх сурвалж:
http://martinfowler.com/articles/mocksArentStubs.html#SoShouldIBeAClassicistOrAMockist

Бүтээгдэхүүнээ бид яагаад тестлэх шаардлагатай вэ ?

Яагаад тестлэх шаардлагагүй вэ ?

  • Хэрэглэгч байхгүй
  • Дээд зэргийн чадварлаг мэргэжлийн ажилчидтай (суперменүүдтэй) тул тестлэх шаардлагагүй
  • Маш богино хугацааны дахин шинэчлэгдэх, нэмэлт өөрчлөлтүүд ордоггүй, нэг л хийгдсэн бол дахин шинэчлэх шаардлагагүй
  • Тетслэх боломжгүй
  • Тестлэх үнэ нь бүтээгдэхүүний үнээс илүү
  • Өмнө нь хэзээ ч алдаа, гомдол гарч байгаагүй, хэрэглэгчээс гомдол ирдэггүй

 

Хэрэв таны хийж байгаа аливаа бизнесийн бүтээгдэхүүн одоо болтол ямар ч тест хийдэггүй, чанар шалгах процесс байхгүй байсаар байгаа бөгөөд шалтгаан нь дээрх жагсаалтанд байхгүй л байгаа бол таны бизнес амжилтаас нилээн хол байгааг сануулмаар байна.

Үргэлжлүүлэн унших

Өмнөх үг

Өнөөдөр 2010 оны 1-р сарын 15-ны өдөр. Сайхан нар гийсэн өдөр байлаа.

Дараа дараагийн бичлэгүүдээрээ  Practical Symfony номын 24 хичээлийн эхний хичэлийг орчуулан тавих болно.
Энэхүү ном нь PHP Symfony Framework анхлан сурахад зориулагдсан өдөр бүрийн хичээлийг багтаасан.

Энэхүү номыг уншиж дуусгаснаар symfony Framework талаар суурь мэдлэгтэй болох бөгөөд цаашид хөгжихэд ихээхэн тустай болов уу,

Энэ хуудсанд орчуулгын талаар санал хүсэлтийг авна.  Орчуулах ажил маань миний сонирхлын дагуу хийгдэж байгаа ба ямар хурдтай хийгдэхийг би таашгүй.  Бусад хүмүүс ч бас энэхүү ажилд оролцоно гэдэгт найдаж байна.

Have  fun!