TDD'yi (Test güdümlü geliştirme) iki hafta önce küçük bir gösteri yaparak iş arkadaşlarıma tanıttım. Yeni işyerimde ilk defa sunum yaptığım için benim için zor oldu. Ek olarak, hala öğrenmekte olduğum bir konuyu tartışacaktım. Yine de bunu yapmak için ilham aldım, çünkü bunu yaparak hem bilgimi paylaşabileceğimi hem de ne kadar öğrendiğimi görebileceğimi biliyordum. İşte olaydan çıkardığım genel izlenimler ve çıkardığım dersler.

"Her şeyi" öğrenene kadar beklemeyin

TDD ile kurumsal düzeyde çok fazla deneyimim olmadığı için önce biraz korktum. Sonra anladım ki asıl amacınız "akıllıca" görünmek yerine paylaşmaksa, bir kalabalığa yeni bir kavram getirmek için uzman olmanıza gerek yok. Bir sorunun cevabından emin değilseniz veya bilmiyorsanız söyleyin. Yine de kişiyi uygun kaynağa yönlendirebilir veya yanıtı araştırıp daha sonraki bir toplantıda grupla paylaşabilirsiniz. Bilginizi paylaşmadan önce "her şeyi" öğrenene kadar beklerseniz, sonsuza kadar beklemeniz gerekecek.

Ancak, izleyicilerinizin zamanını da boşa harcamak istemezsiniz. Sonuç olarak sunumunuzun sınırlarını belirlemeli ve ele alacağınız konuları yeterince planlamalısınız.

Sunumunuzun sınırlarını tanımlayın

Benim durumumda konuşmamı 30 dakika tutmaya ve sadece bir örnek kullanmaya karar verdim. Her şeyi bu zaman kısıtlaması içinde tamamlamak için basit bir örnek olan “ Doğru Parçası Kavşağı ” problemini seçtim. Ancak, bu örneğin bile 30 dakikalık bir sunum için çok uzun olduğu ortaya çıktı, bu yüzden dönüştürmeye karar verdim. bir “ Hat-Hat Kavşağı ” problemine dönüştürür.

Sunumumu üç ana bölüm halinde yapılandırdım. TDD'ye ve çözmeye çalıştığım konuya kısa bir giriş yapmak ilk adımdı. Çok fazla zaman almak istemediğim için problem tanımını ve tekniğe ilişkin minimum bilgiyi bir metin belgesine yazdım. İkinci bölüm, yaptığım işlemler ve bunların arkasındaki nedenler hakkında yüksek sesle konuşurken TDD kullanarak sorunu çözmek için kod yazmaktı. Son bölüm 5 dakikalık soru-cevap şeklindeydi.

İyi hazırlanmak

Hazırlanmak için bir haftam vardı. Sorunu birkaç kez kendi başıma çözmek için TDD'yi kullanarak başladım ve ardından süreci göstermek için test senaryoları için ideal sırayı aradım. Test senaryolarını görünmelerini istediğim sırayla düzenledim, ardından test senaryoları oluşturduğum vakaları temsil eden bazı basit çizimler oluşturmak için paint'i kullandım. Bundan sonra, tüm örneği birkaç kez daha kodladım. Ancak bu sefer sanki sunum yapıyormuş gibi kod yazarken konuştum. Toplamda 7-8 saat hazırlık üzerinde çalıştım.

Zevk almak!

Hata yapmanın insani bir davranış olduğunu kabul edip performansınız için endişelenmek yerine anın tadını çıkarmaya çalışırsanız, daha iyi sonuçlar elde edeceğiniz bir sır değil. Kolay olduğunu veya herkes için işe yaradığını söylemiyorum ama sunumum boyunca bir hata yaptığımda aşağılanmış hissetmektense kendime gülmeye ve deneyimin tadını çıkarmaya çalıştım. Microsoft işe alma sürecinden geçtiğimde uyguladım. Görüşmecilerden birinin yaptığım aptalca bir hataya işaret ettiğini hatırlıyorum ve üzülmek ya da hayal kırıklığına uğramak yerine onunla bu konuda sadece güldüm ve düzelttim. işe alındığım için işe yaradığına inanıyorum.

Çözüm

Kişinin kariyeri boyunca ve yaşamı boyunca öğrenmeye devam etmesi çok önemlidir. Belki de bundan daha önemli olan, sahip olabileceğiniz düşünce veya fikirleri ifade etme yeteneğidir. Her ikisini de uygulamanın belki de en etkili yöntemi, yakın zamanda öğrendiğiniz bir şeyi açıklamaya çalışmaktır. Bunu yaparak, anlayışınızdaki boşlukları tespit edebilecek ve başkalarının bilgisine katkıda bulunabileceksiniz. Önümüzdeki haftalarda çeşitli konularda bunu yapmaya devam etmeyi ve deneyimlerimi gelecekteki bir gönderide yazmayı düşünüyorum.

O zamana kadar mutlu öğrenmeler!