Maintainable JavaScript / Sürdürülebilir JavaScript Türkçe çevirisi
Sadece JavaScript değil bir çok programlama dili için geçerli konulara deyinen Nicholas c. Zakas'ın harika videosunun Türkçe altyazısını sizler için çevirdim. Umarım herkese faydalı olur :)
0:01 Hepinize katıldığınız için teşekkür ediyorum. Biliyorum günün sonuna geldik
0:06 beyniniz bilgi bombardımanından dolayı erimiş vaziyette.
0:09 Yani, geldiğiniz için minnettarım ve….
0:13 hmmm Spor ceket giyen bir ben miyim?
0:17 Evet, alın size bir ders;
0:21 Sırf JavaScript’in klası (class ile kelime oyunu yapıyor) yok diye siz de öyle olmak zorunda değilsiniz!
0:32 Sunumdaki tek espri buydu, teşekkürler
0:42 Şu sıralar çalıştığım yeni bir projeden bahsetmek istiyorum.
0:46 Projenin adı “Well Furnished”
0:48 Çok anlatmayacağım ama…
0:52 Mobilya endüstrisinde kocaman bir fırsat olduğunu düşünüyoruz.
0:56 hiç değişmeden gelmiş ve
0:59 bizim de mobilya satın alım deneyimi iyileştirmek için
1:03 yapmayı düşündüğümüz bir çok ilginç şey var
1:07 wellfurnished.com girin inceleyin, Aslında
1:11 isimdeki hiç bir ünlü harfi silmediğimiz için de ayrıca guruluyuz :P
1:19 Evet, Bazı kitapların yazarıyım, "High Performance JavaScript",
1:23 bir diğeri "Professional JavaScript for Web Developers", gerçekten ama gerçekten
1:29 sanırım bu iyi bi kitap demek oluyor
1:32 ya da iki yıl boyunca hiç özel hayatın olmamasının işareti bilemedim :)
1:36 Son olarak da "Maintainable JavaScript"
1:41 Bugün kaç kişi bir kitap aldı?
1:42 Ovv, hepiniz! Şahane, şanlıymışsınız ben bir tane bile alamadım.
1:50 but, that's where you want to go if you find this talking interesting and you want to
1:53 learn a little bit more
1:54 um shouldn't go find one of people just had their hands up they have a book
1:58 ve beni Twitter'da takip edebilirsiniz.
2:02 ben @slicknet im Herkes şuan gidip bana tweet atabilir, böylece
2:07 bu odada kaç kişi varmış ben de görmüş olurum
2:10 Şahane. Demiştim size, başlarken yaptığım
2:14 tek espri olmayacak, o sadece başlangıçtı :)
2:17 Hadi "sürdürülebilirlik" hakkında konuşalım, neden önemsiyoruz?
2:21 Bir kodun sürdürülebilir olup olmadığını neden önemseriz;
2:24 Genelde kimse ilk etapta "evet ben bu kodu yazacağım ve...
2:28 ... şimdiye kadarki en sürdürülebilir kod olacak" diye düşünmez.
2:31 genelde pek heyecan verici bir şey değildir bu.
2:34 Önemsiyoruz çünkü genelde zamanımızın çoğu kodu sürdürmekle geçiyor.
2:40 Peki sürdürülebilirliğin farkı nedir? Bilgisayarın başına oturup,
2:45 bir metin editörü açtığınızda; boş bir sayfa gelir,
2:48 işte bu kod yaratmaktır.
2:54 Eğer metin editörünü açıp varolan bir dosyayı açıp yazmaya başlarsanız;
2:58 işte bu kodu sürdürmek oluyor. Peki kaç kişi bu hafta...
3:02 ...tamamen boş bir metin editörü açtı
3:09 ve eller aşağı iner hmmm, Evet oldukça küçük bir yüzde,
3:14 Sanırım buradakilerin %10'u. Genelde bunu yapmazsınız,
3:19 Biryerlerde okumuştum, diyordu ki;
3:22 "metin editörünü açarsınız, boştur ve yazmaya başlarsınız...
3:26 ... bir kahve alır gelirsiniz işte o an kodu sürdürüyorsunuzdur ...
3:30 ... çünkü daha önceden varolan bir kod ile çalışıyorsunuzdur"
3:35 ve işte bu yaptığımız şeyin genelini oluşturuyor.
3:37 Kaç kişi daha önce başkasından kalan bir kodu devraldı? Ovv epey kişi var.
3:42 ve işte bu nedenle sürdürülebilirliği önemsiyoruz.
3:46 Peki kim aslında önemsiyor? Öncelikle şirketiniz!
3:50 aslında bu kanıya şunu düşünerek ulaştım;
3:55 Tamam sürdürülebilir kod şirket için iyi bir şey
3:59 ve kimbilir belki kendinizi birgün INITECH'de bulursunuz. İşin püf noktası şu aslında;
4:03 Şayet kendiniz için keyfi kod yazmıyorsanız, birisi sizi bunun için işe almış ise
4:08 şirkete, o işe, o uygulamaya
4:12 değer katmanız için işe almıştır ve bu yüzden önemserler.
4:16 İşten ayrıldığınızda, yazdığınız kod çalışmaya devam edebilmeli.
4:19 Bu yüzden sizi işe alıyorlar, Eğer sadece siz ordayken çalışmasını isteselerdi,
4:24 bu gerçekten sektörü allak bullak ederdi. Bu yüzden işarkadaşlarınız çok önemserler.
4:31 Aslında herkes başkasından kalan bir kodu devralır aslında,
4:37 İş arkadaşlarınız önemserler çünkü üzeerinde çalıştığınız kod,
4:42 bir gün başkası tarafından devralınacak ve daha önce hiç görmediğiniz bir kod da
4:46 bir gün sizin olacak.
4:50 Yani iş arkadaşlarınız gerçekten bunu önemserler. Bu bizim için biraz zordur,
4:54 çünkü front-end geliştirici, arayüz geliştiricisi olarak çalışan biz web geliştiriciler
4:58 kendi alanımızda bir bakıma nev i şahsına münhasırızdır.
5:02 çünkü yaptığımız işler,
5:06 okulda öğretilmezler.
5:09 ve bu işi yapan kişi sayısını düşününce; bu inanılmaz bir şey!
5:14 Okulda öğretilmez ve herkes kendi başına öğrenir.
5:18 Kaç kişi yaptıkalrını kendi kendine öğrendi? Evet işte.
5:21 neredeyse herkes. Aslında normal olan da bu,
5:25 ve bu gerçekten de çok ilgintir ki kendi kendinize öğrendiğinizde,
5:30 kullandığınız teknik ve yöntemleri
5:34 geliştirme eğiliminde olursunuz.
5:37 Yaptığınız işin bir parçası olarak da bu en iyi yoldur aslında.
5:41 çünkü o sizindir, nasıl işlediğini en iyi siz bilirsiniz, yıllardır yapıyorsunuzdur.
5:45 olmasını istediğiniz şeydir o. Ben buna "Rock yıldızı zihniyeti" diyorum.
5:49 değil mi? "-bu benim tarzım dostum! ben yaptım", "-ama bu...", "-hayır siz anlayamazsınız"
5:53 "-bana göre çok iyi yazılmış bir kod bu"
5:59 "-yaptığım şeyleri bozma yeter"
6:02 "-bu, bu yaratıcı, güzel bir çalışma, siz anlayamazsınız"
6:06 Evet, rock yıldızı zihniyeti.
6:09 Ama ne zaman bir takımla çalışmanız gerekirse, bundan vazgeçmelisiniz.
6:12 egonuzu biraz kenara koyup
6:15 takım için iyi olan ne ise onu yapmalısınız. Ben gerçekten bir spor tutkunuyumdur,
6:19 ve bence spor takımları bu konuda diğer şeylere göre
6:22 gerçekten de iyi birer örnekler.
6:25 Çünkü spor takımları galibiyet için bireysel başarıdan çok,
6:29 bir takım olarak hareket ederler.
6:33 Tabi bireysel başarıya dayalı olan tenis dışında.
6:38 Herneyse, takım çalışması burada konuşmamız gereken şey oluyor aslında.
6:42 Ne zaman sürdürülebilirkten bahsediyorsanız, aslında
6:44 mümkün olan en az sorun ile
6:45 takım olarak başkasının kodunda çalışırsınız,
6:49 aynı şekilde başkası da nasıl
6:50 sizin kodunuz ile çalışır demiş oluyorsunuzdur.
6:53 Peki nedir bu "sürdürülebilir kod"
6:56 Şunu belirtmek isterim ki; "sürdürülebilir kod büyük çaplı değişiklikler...
7:00 5 yıl boyunca çalışmayı sürdüren koddur" Peki neden 5 yıl?
7:05 Aslında, bir yıl insanların kötü bir iş yaptığınızı düşünmesine sebep oluyorç
7:09 Her yıl yaptığınızı sıfırdan yazıyorsanız,
7:14 bu bir şeyleri yanlış yapıyorsunuz demek oluyor. Olayların nereye gideceğini doğru olarak
7:17 öngöremiyorsunuz anlamına geliyor.
7:19 deneyimlerime göre ancak 5 yılda bir
7:22 iş sahiplerini her şeyin yeniden yazılması gerektiği konusunda ikna edebiliyorsunuz.
7:27 5 yıldan kısa olan her süre size bir şekilde iyi bir yazılımcı
7:30 olmadığınız düşüncesi ile geri geliyor.
7:33 Yani, bunun biraz zor olduğunu düşünebilirsiniz.
7:38 çünkü tarayıcı sürümleri yılda bir kaç defa güncelleniyor.
7:42 Chrome bu yıl 12 sürüm mü ne çıkardı, tam bilmiyorum ama...
7:45 en nihayetinde, hiç müdahale etmeden nasıl bu versiyonlar gelirken
7:50 kodunuzun çalışmaya devam etmesini garantilersiniz?
7:53 Anahtar nokta bu aslında. Yeni bir tarayıcı versiyonu geldiğinde
7:57 kodunuzun çalışmaması istediğiniz bir şey değildir.
8:00 Aslında kodunuzun kaç tarayıcı sürümü çıkarsa çıksın çalışmaya devam etmesini
8:05 ve bu aslında mümkün. Bunu daha önce gördüm, başardım!
8:09 Peki bunu nasıl yaparız? Sürdürülebilir kod anlaşılabilirliktir,
8:13 Anlaşılabilirlik ile kastettiğim; şöyle bir bakıldığında
8:16 "hmmm evet bu mantıklı, anlıyorum...
8:20 ...bu kodun ne yaptığını çözmem çok vakit almıyor"
8:23 dediğiniz şey oluyor aslında.
8:25 Baktığınızda mantıklı gelir.
8:28 biraz karışık gelse bile incelendiğinde
8:34 kolay anlaşılabilir olmalıdır.
8:38 Bu gerçekten de önemlidir çünkü devraldığınız kodu
8:44 kodu hatalı olarak algılayabilirsiniz. Bunu ilerde biraz daha açacağım.
8:49 “Uyumlu olmalıdır”, kodunuz tamamen bozulmadan da değiştirilebilir olmalıdır.
8:57 bu zor bir problem. Fakat kodunuzu kim devam ettirirse ettirsin,
9:01 kod değişiklikleri kabul edebilmeli
9:04 Bilinçsiz yapılan her değişiklik ciddi sorunlara
9:09 “Genişletilebilir olmalıdır”, genişletilebilirlik şu anlama geliyor;
9:13 kod daha fazlasını yapabilecek bir şekilde inşa edilmelidir.
9:17 Yani yeni bir özellik eklemek istediğinizde o ksımı baştan
9:21 yazmak zorunda olmamalısınız.
9:22 üstüne inşa etmeye devam edebiliyor olmalısınız.
9:26 “Hata ayıklamaya uygun olmalıdır”, Microsoft Kore'ye bakarsanız,
9:30 bu gerçek hayatta böyle değilmiş(!)
9:33 Debug edilebilir olmak çok önemlidir. Kodunuzu, başkasının, içinde adım adım
9:37 izleyebilecek şekilde
9:38 kurgulamak; sürdürülebilirlik sürecinde inanılmaz
9:43 Ve son olarak “Test edilebilir olmalıdır”; eğer kodunuzu bir şekilde
9:46 unit testler ya da fonskiyonel testler vs yazılabilecek şekilde yazarsanız,
9:51 süreç içerisinde çok zaman kazandıracaktır. Aslında "Writing Testable Code"
9:55 diye yeni bir O'Reilly kitabının çıktığını gördüm.
9:59 ki okunması gereken güzel bir şeye benziyor.
10:04 Compass'ın yaratıcısı Chris Eppstein'in harika bir sözü var;
10:07 "Gelecekteki szie iyi davranın"
10:11 Kodu yazan kişi olarak onu sürdürecek
10:14 olan da siz olabilirsiniz.
10:17 Peki gelecekteki size ne bırakmak isterseniz?
10:20 5 yıl sonra dönüp baktığınızda, neler olduğunu anlayabilmek için
10:26 küçük küçük ip uçları olan bir Indiana Jones labirenti mi
10:30 Hayır, yol boyunca size, gelecekteki size yardımcı olacak
10:34 kırıntılar bırakmak istersiniz.
10:37 Böylece başkaları da ne olup bittiğini anlayabileceklerdir.
10:42 Gelelim Kod kapsamlarına
10:43 Kod kapsamlarının eskiye nazaran daha çok konuşulur olduğunu görmek
10:48 Esas olarak 2 tür kod kapsamı bulunmakta; İlki Kod Stil Kılavuzları,
10:53 bunlar söz dizimi ile, boşluklar vs ile ilgili şeylerdir.
10:56 diğeri ise, belli şeylerin nasıl yapılacağını belirten
11:01 ve temel dizayn desenleri olan Programlama Pratikleridir.
11:06 Stil kılavuzları ile başlayacağım, değeceğim odur ki,
11:10 kod stilleri “geliştiricilerin kod vasıtasıyla birbirleri ile,
11:15 iletişim kurma yoludur”. Kod, herkesin anlayıp konuşabildiği ortak bir,
11:22 ve bu büyük bir projede bile çalışırken,
11:27 sorunsuzca bir dosyadan diğerine akmanızı sağlar.
11:31 Donald Knuth der ki, içinizde var mı Knuth'u bilen?
11:35 harika, kendisi benim idolümdür.
11:38 Der ki; "programlar insanlar tarafından okunabilirler,
11:42 ancak hasbelkader bilgisayarlar tarafından çalıştırılırlar”.
11:46 çünkü tekrar belirtelim; kod geliştiriciler arasında,
11:50 iletişim kurma ortamıdır.
11:53 ve sonrasında ilginç bir şeyler yapsın diye bilgisayarlar tarafından yorumlanır.
11:58 Öncelikle geliştiriciler tarafından anlaşılabilir olmalıdırlar
12:01 doğru değil mi? Bugün makine dili ile kod yazıyor olsa idik,
12:06 doğru olmayabilirdi tabi. O zaman bir çoğumuz da burada olmaz başka bir şeyler yapıyor olurduk.
12:11 Güzel bir kod başkaları tarafından taktir edilir.
12:17 Bir zamanlar kankam Tom ile
12:21 kimin kodu daha güzel diye karşılıklı tweetleştiğimiz
12:24 bir münakaşa yaşamıştık.
12:28 Tabi bunu ilk ya da ikinci buluşmada yapmanızı tavsiye etmiyorum :)
12:32 JavaScript ile ilgili her konuda
12:35 inceleyebileceğiniz ve Doug Crockford'a ait
12:38 bir kaç kılavuz bulunmakta,
12:43 hem kod stillerini hem de
12:46 programlama pratiklerini kapsayan bazı düşünceleri de bulunmakta.
12:49 Google'ın bir JavaScript stil kılavuzu mevcut,
12:55 Google'daki bir çok zeki arkadaş tarafından
12:58 ve devam etmekte olan,
13:01 Stil kılavuzu yapmak isteyen bir çok kişinin başlangıç
13:05 noktası olarak kullanabileceği bir kaynak.
13:09 jQuery, jQuery de bir stil kılavuzuna sahip,
13:12 Tahmin edeceğiniz üzere bunlar stil yönelimi bakımından
13:15 birbirlerinden oldukça farklı şeyler.
13:16 ama bir göz atabilir ve...
13:20 sizin için neyin mantıklı geldiğini görebilirsiniz.
13:24 dojo'nun da bir stil kılavuzu mevcut.
13:27 ve son olarak .... ve ....
13:31 bir araya gelerek kodlama stili hakkında önerilerden ve kapsamlardan oluşan
13:35 bir proje olan Idiomatic.JS'yi yapmışlar.
13:39 Tüm bunlar gerçekten de hangi stili istediğiniz konusunda
13:44 incelemeye başlayabileceğiniz harika şeyler.
13:48 Farklı stil ve kılavuzlara bir nevi kıyaslama ve
13:52 farklarını gösteren bir gözle
13:54 kitabımda da bahsediyorum.
13:57 Hazır olun, çünkü kod stillerinden bahsettiğinizde kendinizi bir kavgada bulacaksınız.
14:03 Hem de çok fena kavga edeceksiniz, ekipteki diğer elemanlardan nefret edeceksiniz.
14:08 çünkü bazıları boşluklar ile girinti verirler,
14:11 bazıları ise tablar ile! Çok ciddiyim, şaka değil!
14:16 Kariyerimde kod girdi türü ile ilgili 45 dakikalık konuşmalar yapmışlığım var.
14:22 Bir saatlik bir kod stili toplantısı ayarlamıştık ve
14:26 45 dakikasını girdi türü konusunda harcadık.
14:31 Bildiğim kadarıyla zamanı kullanmak için pek de iyi bir yol değil.
14:35 Böyle bir şeye bu kadar zaman harcamamalıydık.
14:38 Öte yandan ekiptekilerin birbirleri ile,
14:42 aynı fikirde olmamaları çok da alışılmadık bir şey değil.
14:45 Bu gibi durumlarda bir uzlaşma yoluna gitmelisiniz.
14:50 Hiçbir zaman bir şey iyi, diğer şey ise kötü değildir.
14:53 Önemli olan onu yapmak için bir yol olduğu ve herkesin o yol ile .
14:58 Yani eğer size ait bir iş ise, Rock yıldızıysanız ve girdi için tab kullanıyorsanız,
15:03 ve takımınız boşluk kullanmaya karar verdiyse,
15:05 siz de boşluk kullanın! İyi bir takım oyuncusu olun.
15:10 Çünkü aksi halde kodu açtığınızda şöyle bir şey ile karşılaşabilirsiniz.
15:15 ve bu yüzdendir ki yeni bir işe başlarken hep girdi türü ile başlarım.
15:19 Kaçınız bir metin belgesi açtığında hiç bir şey yapmadan ilk iş olarak
15:23 bütün dokumanı re-indent ediyor? Haah!
15:27 Değil mi? Çünkü sizin stilinizde girdilenmemişse
15:32 kodun ne iş yaptığı hakkında en ufak bir fikriniz bile yoktur.
15:35 Evet, birini seçin,
15:39 değiştirmeyin, karıştırmayın çünkü sonunda şöyle bir şeyle karşılaşırsınız.
15:43 Aslında böyle görünmeliydi, çok daha okunaklı değil mi?
15:47 çok güzel, içimi ısıtıyor, her neyse devam edelim.
15:51 Bir diğer konu ise; "tek satırdaki daha az kod...
15:56 ...daha az merge conflict demektir"
16:00 Biliyorum içinizde sonsuza kadar gidecekmiş gibi
16:04 tek satırda kod yazmayı sevenler var.
16:09 JavaScript'de de gördüm, CSS'de de,
16:13 Bunlar kod ile çalışan tek kişi siz iseniz sorun değil.
16:18 Başkaları ile bir kodda çalışıyorsanız ise sorun oluyorlar.
16:23 çünkü sürüm kontrol sistemleri satırları birleştirmezler! Eğer bütün uygulamanız online ise
16:28 iki kişi aynı anda aynı şey ile çalışırken bu çok büyük bir sorun
16:32 Bu yüzden her şeye biraz yer açmayı tercih ederim.
16:36 Merge conflict'leri engellemek için,
16:39 satırlarınızı mümkün olduğunca kısa tutun.
16:42 “Yorumlar”, benim favori konum!
16:47 “Kod içi dokümantasyon, dokümantasyon yazmaktan...
16:50 ...nefret edenler tarafından yaşatılmaya devam eden bir şehir efsanesidir”
16:55 Dünyadaki en iyi kodu bile yazıyor olsanız,
17:01 hiç bir şey onu iyi konumlandırılmış bir kaç yorumdan satırından
17:04 daha anlaşılır yapamaz. En azından bana göre böyle.
17:09 Yani bu demek oluyor ki; kodun ne iş yaptığını anlayabilmek için
17:14 bütün dosyayı baştan sona okumam gerekmemeli.
17:20 ...evet, sonra bu. Tamam ama bu şekilde o dosyanın tam olarak ne iş yaptığını
17:25 kavramak biraz zaman alıyor.
17:27 Sağa sola bir iki yorum serpiştirilebilir, tabi çok fazla olmamak kaydıyla,
17:31 Kodun yaptığı her şeyi tekrar etmek biraz saçma olur.
17:34 Aynı yemekleri çeşnilendirmek gibi biraz renk katmak tamamen yeterlidir.
17:38 Çünkü bu gerçekten diğerlerinin kodu anlamasını sağlayacaktır.
17:41 Her neyse, dokümantasyon üreticiler için bu tür kod içi dokümantasyonu seviyorum.
17:46 Genelde şunun gibi görünüyorlar, “JavaDoc” tarzı,
17:50 Rica ediyorum, hiç olmazsa metotlarınız için bunu yapın.
17:54 Bundan daha fazlası ikramiye gibi olacaktır.
17:57 En azından bunu yapmak geliştiricilerin anlamasına büyük katkı sağlayacaktır.
18:03 Ayrıca, ilk bakışta anlaması zor olan kodlarda işe yarayabilirler.
18:07 Böyle bir şey yazarken
18:09 sonradan tekrar dönüp baktığınızda şöyle dersiniz;
18:13 “hmm evet bunu biliyorum, bu şu işe yarar, şu da şunu yapar… çünkü ben yaptım”
18:17 İşte tam da burada yorumlara ihtiyacınız vardır!
18:20 Zira sizden başka kimsede bu kodu yazarken sahip olduğunuz,
18:23 bilgi birikimi bulunamaz.
18:25 Bu, YUI den aldığım bir örnek, oldukça uzun bir fonksiyon
18:30 Eğer bu yorumlar olmasaydı,
18:33 ne işe yarar hiç bir fikrim olamazdı.
18:36 Gerçekten çok faydalı oluyor. bunun gibi ufak notlar bırakmak
18:41 ileride size ve bu kod ile haşır neşir olacaklara çok faydalı olacaktır.
18:49 İlk baktığınızda kod size hatalı gibi görünebilir,
18:53 İyi olarak bilinen geliştiricilerin öyle hatalarını gördüm ki,
18:57 çünkü biri yanlışmış gibi görünen biraz sıra dışı bir şey kullandığında,
19:01 yardımsever bir iş arkadaşı çıkar ve “ooo bu komple yanlış olmuş hacııı...
19:06 ...şimdi bunu düzelteceğim ve sen çok sevineceksin...” der
19:11 veee ne olur, başa dönersiniz. Eski bir hata tekrar çıkagelir.
19:16 Hiç hoş değil. Burada, bilmiyorum bu lazer çalışıyor mu ama bir deneyelim,
19:21 Hemm, burada küçük bir eşittirimiz var.
19:24 İlk baktığınızda biraz garip gelecektir.
19:28 çünkü boolean bir değer için kontrol koşulu beklersiniz değil mi?
19:32 ama burada bir değer atama işlemi söz konusu, “gayet açık bir şekilde burada bir hata var….
19:36 ...çift eşittir ekleyeceğim ve….
19:37 … sorunu çözeceğim” tek sorun buradaki olayın kasıtlı olması.
19:41 ve bunu bilebilmemizin tek sebebi kenarına bırakılmış olan ve
19:45 “şunu demek istiyorum, lütfen beni düzeltme”
19:49 diyen ufak yorum satırı.
19:52 Bunun çokça olduğu başka bir yer de;
19:55 Sadece tek bir tarayıcıda bulunan (öhöm IE :)
19:58 bir hatayı düzeltmek için yazdığınız
20:01 tarayıcıya özel kodlardır.
20:05 Çoğu zaman bunu standart kurallar ile yaparsınız ve başka bir tarayıcıda
20:11 ve bu standart olanın burada çalışmadığını görür ve her yerde çalıştığından emin olup
20:15 “hack” lemek zorunda kalırsın.
20:18 Bakınca şunu diyebilirsiniz;
20:19 “hmm bu arkadaş gerçekten ne yaptığını pek bilmiyor galiba...
20:25 ...çünkü bileydi standartlara göre yapardı ki her yerde çalışsın”
20:27 ardından o kısım silinir veeee
20:30 tekrar geri gidilir!
20:31 İlk bakışta hataymış gibi görünen her yerde yorumlar bırakmak,
20:35 gerçekten çok işe yarayabilir.
20:39 “İsimlendirme”, kodlamadaki en zor kısımlardan biri.
20:42 “anlamlı isimlendirmeler yapın”
20:50 İçinizde Kent Pristurus’ın dünkü konuşmasında olan var mı?
20:54 Evet, Kent’i severim, Yahoo’da beraber çalışmıştık.
20:58 Ama, aman Allahım, onun kodlarına bakınca kafam patlayacak gibi olurdu.
21:03 Çünkü yazdığı JavaScriptlerde değişkenleri,
21:07 hep tek karakterle isimlendirir,
21:11 tabi bu onun için anlaması gayet kolay bir şey.
21:15 ama ben onun kodunda çalışmak zorunda kalsaydım
21:21 daha anlamlı isimler ile değiştirmekle işe başlardım. Her neyse Hem değişkenler hem de fonksiyonlar için
21:25 anlamlı isimler kullanmalısınız. Uzunluk konusunu
21:29 Nasıl isimlendirilmeleri gerekiyorsa öyle isimlendirin. En nihayetinde yayına alırken
21:33 isterseniz o isimleri kısaltan bir şey kullanabilirsiniz ama şunu unutmamalısınız;
21:36 kendiniz ve diğer geliştiriciler ile bir nevi o kod vasıtasıyla
21:40 iletişim kurmaya çalışıyorsunuz.
21:42 Evet, anlamlı isimler kullanın!
21:45 Değişkenler belirteç olmalı kitap, kullanıcı vs...
21:48 Fonksiyon isimleri genelde fiil ile başlamalı
21:55 bir iş yapar, fiiller de iş yapar, Sanırım İngilizce öğretmenim
21:58 bu tanımımdan gurur duymuştur.
22:07 Boolean dönen fonksiyonlar genelde “is” ya da “has” ile başlar.
22:11 hede, hodo gibi isimler kullanmaktan kaçınmalısınız.
22:14 tabi tek karakterli adlara göre nispeten daha iyiler ama,
22:23 Bana pek bir faydası dokunmuyor. Bu daha önce gösterdiğim bir koddu
22:27 Aman Allahım ne biçim şey bu!
22:32 tam bir kabus. Bu arada; bu örnek,
22:36 şuan burada ismini vermek istemediğim
22:38 biri tarafından kodlandı.
22:42 JavaScript’de genelde “camelCasing” kullanarak değişkenlerimizi isimlendiriliyoruz.
22:46 Bunun sebebi JavaScript kendi iç değişkenlerini de böyle isimlendirmiş olması aslında.
22:51 camelCasing: her bir kelimenin, bir sonrakinden
22:54 BÜYÜK harflerle ayrılması oluyor
22:58 diğer taraftan, değişkenler, fonksiyonlar vs küçük hafr ile başlar.
23:04 Örneğin buradaki “myName” ve diğerleri işte...
23:09 Peki ya Kısaltmalar? camelCase kullanırken
23:13 benim favori sorumdur :)
23:14 Çünkü şöyle bir durum var: tamam kısaltmalara kelimeymiş gibi davran,
23:17 her şey küçük harf olsun, bir sonraki kelimenin ilk harfi büyük olsun
23:23 kısaltma olarak ele al ve hepsini BÜYÜK harflerle yaz
23:27 Yani, JavaScriptin iç API’na baktığınızda;
23:32 örneğin: “getElementById”
23:36 burada ID kelimeymiş gibi davranılmış. get element by “ıd” (okunuşu vurguluyor)
23:40 tam bir “freudian slip” (bir nevi dil sürçmesi)
23:46 “innerHTML” e baktığımızda...
23:49 ...kısaltma olarak davranıldığını görüyoruz.
23:52 JavaScript’in kendisi bu konuda manyaklar gibi tutarsız.
23:56 Lütfen birini seçin ve ona sadık kalın.
24:00 Benim asıl favorim bu :)
24:11 tamam XML var bu bir kısaltma
24:14 sonra, http var ki bu da kısal…
24:18 … ne oluyor yahu! Hey Allahım...
24:21 hiç tahammül edemiyorum. Bazı istisnalar da mevcut;
24:25 Eğer “sabit” (constant) olarak kullandığınız değişkenleriniz varsa,
24:29 Zira JavaScript’de constant henüz desteklenmiyor.
24:31 Bir çok stil kılavuzunda bütün kelimelerin BÜYÜK harflerle yazıldığı ve
24:35 birbirlerinden alt çizgi ile ayrıldıkları yaklaşım tercih ediliyor ki...
24:39 C/C++ gibi dillerden geliyor ve bu kullanım gayet yaygın.
24:43 Aslında sabit olarak atadığınız bir şeye kazara bir atama yapmanızı
24:46 engellemek açısından baya kullanışlı olabiliyor.
24:50 Yapıcı metotlar; genelde büyük harf ile başlar
24:54 Biraz da programlama pratiklerinden bahsedelim.
24:59 Aslında stil mevzusu bundan çok daha uzun, bir kılavuzu inceleyebilir ya da
25:02 kod stillerle ilgili kitap okuyabilirsiniz.
25:06 Bu konu hakkında 3 saat daha konuşulabilir, gün biter
25:10 o yüzden devam ediyorum. evet, “Programlama Pratikleri”
25:14 Favorim olan bir alıntı; “Bir yazılım kurgusu inşa etmek için iki yol vardır:
25:19 biri, herhangi bir dezavantajı olmadığı gayet açık olan basit yolla yapmak,
25:23 diğeri ise dezavantajının ne olduğu bile belli olmayan karmaşık yoldan yapmaktır.”
25:29 Bu eleman Quicksort’dan gelen bir arkadaşımız.
25:34 Eğer Bilgisayar mühendisliği gibi bir bölümde okuduysanız muhtemelen tanışmışsınızdır.
25:38 Evet, programlama pratikleri sizle beraber başkaları da anlayabilesiniz ve
25:42 bir şeyler bozulmasın diye
25:44 kodunuzu nasıl basitleştirdiğiniz ile ilgilidir.
25:47 Bu bakımdan benim favorim
25:49 “ara yüz katmanlarının ayrı tutulduğundan emin olmaktır”.
25:54 Yani sunum için kullandığınız CSS’iniz, etkileşim için kullandığınız JavaScript’iniz
25:58 ve veri ile yapılandırma için kullandığınız HTML’iniz mevcuttur.
26:04 Yani bunlar mümkün olduğunca ayrı tutulmalıdır.
26:08 Basitçe: akımları karıştırmayın (Hayalet Avcıları geyiği)
26:23 Yani bu kötü bir şey
26:26 Sanırım hepiniz bunun kötü olduğunu biliyorsunuzdur.
26:29 Eğer bilmiyorsanız o daha kötü :)
26:35 HTML kodunuzun içine inline JavaScript koymak
26:38 ne olursa olsun kaçınmanız gereken bir şey.
26:42 Neden mi? Bu noktada “hata ayıklama” kavramına dönmek istiyorum.
26:45 Eğer bir JavaScript hatası alıyorsanız, düzeltmek için nereye bakarsınız?
26:51 JavaScript dosyalarınıza!
26:55 Eğer bir JavaScript hatasıysa HTML içerisinde aramak istemezsiniz.
26:59 Hiç mantıklı değil! Çok fazla zaman kaybı olurdu. Aynı şekilde HTML kodunuzu da
27:05 JavaScript’inizden uzak tutmalısınız.
27:07 JavaScript içerisine gömülmüş uzun uzun HTML metinler
27:10 görmeye hiç tahammülüm yok açıkçası. Neden? Aynı şekilde;
27:14 Eğer arayüz ile ilgili bir aksaklık varsa hatayı nerede ararsınız?
27:18 Template dosyalarınızdaki HTML kodlarında!
27:21 Her şey HTML kodu ile yapılırken JavaScript’in derinliklerinde
27:25 spesifik bir şey üreten
27:27 bir kod aramak istemezsiniz.
27:31 Burada bir uyarı notu var aslında;
27:35 mustache, handlebars gibi şeyleri kullanmayın demiyorum
27:38 Tam aksine, kullanmalısınız! Çünkü size template’lernizi bir arada
27:43 tutma ve sonradan JavaScript’e compile etme imkanı sunuyorlar.
27:47 Ama el ile düzenlemek zorunda değilsiniz.
27:49 Yani arayüz ile ilgili bir sorun olduğunda template dosyasına gidip düzeltebilir
27:52 ve sonra tekrar JavaScript’lerinizin içine dahil edebilirsiniz.
27:56 Bu sorunun önüne geçmek için mükemmel bir yöntem.
28:00 Bir diğer yöntem ise: yapı dosyalarını sunucudan okumak
28:03 ve sayfaya dahil etmektir ama JavaScript’lerinizin içine HTML koymamalısınız!
28:08 Büyük başağrısı sebebidir. JavaScript’i CSS’inizden uzak tutun. Nihayet!
28:14 IE bu özelliği kaldırdı.
28:15 Çok şükür! Bununla ilgili bir anım var aslında, söz veriyorum uzun sürmeyecek.
28:21 Bir kaç sene evvel bir firmada çalışıyordum, California’ya taşınmadan önceydi.
28:25 Bir JavaScript hatası vardı,
28:29 ve bu JavaScript hatasının nereden geldiğini anlayabilmek için
28:32 bir günümü harcadım ama başaramadım.
28:35 Debugger algılayamıyordu ve o zamanlar
28:39 IE6’nın olduğu, Visual Studio kullandığım zamanlardı flan
28:43 Saçımı başımı yolmuştum, o zamanlar saçım vardı tabi :)
28:47 En nihayetinde ne oldu biliyor musunuz?
28:52 Yapabildiğim kadar kaba kuvvete başvurdum, sayfadan JavaScript kodlarını
28:55 fonksiyon fonksiyon, dosya dosya silmeye başladım.
28:57 Ta ki hiç JavaScript kalmayana kadar.
29:05 ve JavaScript hatası yine çıkıverdi :)
29:10 O an neredeyse deliriyordum. Teknik olarak sayfada JavaScript kodu yok iken
29:16 JavaScript hatası olması mümkün değildi.
29:19 Gidip kendimi alkole verecektim ki...
29:22 O gün hangi ilahi güç buna sebep oldu bilmiyorum ama
29:25 kalkmadan önce CSS dosyasına bakma ihtiyacı duydum ve
29:30 şu ifadelerden birini buldum. Sebep oydu!
29:33 Bu tanımlamaya (CSS rule) ulaştığımda
29:36 Evet dedim, ne zaman bir JavaScript hatası görsem
29:40 gidip bakacağım ilk yer CSS değildir
29:45 Değil mi? Bunu yapmamalısınız!
29:48 Aynı şekilde CSS’i JavaScript’in dışında tutmalısınız. Bir elementin stil özelliğini değiştirmek
29:53 pek de iyi bir fikir değildir. Neden? Yine aynı şey.
29:57 Eğer stillendirmeniz ile ilgili bir sorun var ise CSS dosyalarınıza gitmek
30:01 ve orada bulmak istersiniz. JavaScript’e bakmak ve
30:04 nereden geldiğini anlamak için günlerinizi harcamak istemezsiniz.
30:08 Büyük başağrısı. Evet “Olay yakalama”
30:12 bir çok kişi olay yakalayıcıları (event handler) yanlış kullanıyorlar. Burada görüldüğü üzere,
30:17 Bu olay yakalayıcıda çok fazla şey yapılıyor.
30:21 Event nesnesinden bir takım bilgiler alınıyor, bir pop-up yaratılıyor
30:26 ve şekildeki gibi gösteriliyor filan.
30:30 Olay yakalayıcılar çok küçük olmalı ve sadece olayın kendisini yönetmelidirler.
30:34 Bu iyi bir ilk adım.
30:37 Bu yakalayıcı sadece olayın kendisini yakalıyor ve
30:42 bir eylem yapan başka bir şeyi çağırıyor.
30:44 Bu test edilebilirlik için faydalı bir adım.
30:47 Şu vaziyette “showPupup” ı nereden istersem oradan çağırabilirim.
30:51 Bu olay yakalayıcısının içinde olmak zorunda değil.
30:56 “onclick” olayında çağırabilirim, aynı şekilde “mousedown”
30:59 ya da insanları gerçekten kızdırmak istiyorsam “hover” gibi
31:03 bir şeyde de çağırabilirim.
31:06 Normal kullanıcının geçmesi gereken etkileşimlerden geçmeden
31:09 içinden bir parçayı alıp çağırabilmek
31:11 kodunuzu daha test edilebilir yapan şeydir.
31:15 Bu henüz yeterince iyi değil. Çünkü “event” nesnesini parametre olarak kullanıyoruz.
31:19 “event” nesnesini bir yerlere geçirmekten nefret ediyorum. Neden mi?
31:23 Çünkü bu metodu başka bir yerde çağırmak istediğinizde
31:26 Metoda vermek için bir “event” nesnesine ihtiyacınız vardır.
31:31 Bu yöntem aynı zamanda “event” nesnesinden beklediğiniz kadar da şeffaf değildir.
31:35 Örneğin burada “event” objesinden 2 adet bilgi edinmek istiyorum. clientX ve clientY.
31:40 Peki bunları olayın dışında nasıl bileceğim? Aslında Bilemem!
31:44 Bu yüzden “event” nesnesini tamamen dışarı almalıyım.
31:47 Bu şekilde çok daha iyi oldu. Yani “handleClick”; sadece bir sonraki aşama için
31:52 gerekli bilgileri “event” nesnesinden alıyor ve
31:55 gereken yerlere ulaştırıyor.
31:58 Şu aşamada “showPopup” tamamen bağımsız bir fonksiyon.
32:03 Bu şekildeyken X ve Y yi hangi amaçla olursa olsun verebilirsiniz.
32:07 Test için ya da uygulamanızda bambaşka bir yerde başka değerler ile
32:10 kullanmak istediğinizde, nasıl isterseniz artık...
32:12 ve “handleClick” uygulamanızın merkezi bir işlevi olmaktan çıkıp
32:16 arayüzünüzün bir parçası haline geliverir.
32:21 ve olay yakalayıcısını istediğinizde kolayca değiştirebilirsiniz.
32:24 Her açıdan kazanç sağlayan bir yöntem.
32:28 “Size ait olmayan nesnelere müdahale etmeyin!”
32:32 Lütfen… ne olursunuz!
32:36 Bu aslında aşağı yukarı beş yıl önce konuşmaya başladığım bir şeydi.
32:40 ve herkes başımın etini yemeye başlamışlardı. Çünkü;
32:43 “JavaScript dinamik öyle değil mi?, istediğim her şeyi eklerim...
32:48 ...hiç bir sorun olmaz, ben bir rock yıldızıyım, biz bunu yaparız hülööğ!”
32:56 Evet bu bir sorun değil, ancak projede çalışan tek kişi siz iseniz
33:01 Her şeyi istediğiniz gibi bozabilirsiniz.
33:04 Bir takımda çalıştığınız sürece, sahibi olmadığınız objelere müdahale etmek.
33:10 çok kötü bir fikirdir. Neden mi? Çünkü size ait olmayan bir kütüphane veya
33:15 tarayıcı API’ı gibi bu nesneler...
33:19 ...takımda onu kullanan kişilerin onların nasıl çalışacağı
33:22 konusunda bir beklenti içerisinde olmalarına sebep olur.
33:26 Eğer onları değiştirirseniz, var olan beklentilerini sekteye uğratmış olursunuz.
33:30 ve artık en basitinden bir mayın tarlasına dönmüştür.
33:34 Bu aşamada kimse o geliştirme ortamından ne bekleyeceğini bilemez.
33:36 Çalıştığım bir işte tam olarak başımdan geçen bir şeydi aslında bu.
33:40 YUI 2 kullanıyorduk
33:44 “stopEvent” isimli bir metot vardı
33:48 ve bir hata alıyorduk. Resmen ben dahil
33:51 üç geliştirici hatanın nereden geldiğini anlamaya çalışıyorduk.
33:55 Ancak bir kaç gün uğraştıktan sonra sebebini anlayabildik.
34:00 Birisi “stopEvent” metodunu kendi metodu ile ezmişti
34:08 Çünkü spesifik bir kullanımları vardı ve “stopEvent”’in başka bir şey için daha kullanışlı olacağını düşünmüşlerdi.
34:11 Hiç birimize de söylenmemişti. Biz de dokümantasyonu baz alarak
34:16 kullanmıştık ve her şey birbirine girmişti.
34:19 Diyeceğim o ki; metotları ezmek kötü bir şey, yenilerini eklemek de en az onun kadar beter.
34:24 Çünkü tarayıcılar ilerde ne ekleyecek bilemezsiniz.
34:28 İleride tarayıcının ekleyeceği ile aynı isimde
34:32 bir şey eklemiş olabilirsiniz.
34:36 Aynı şekilde çalışmama ihtimalinden dolayı bu bir problem teşkil ediyor.
34:40 Yeri gelmişken JavsScript kütüphanesi olan “PrototypeJS”
34:44 “document.getElementByClassName” isimli metodu icat etti.
34:48 Bu metot HTML5’e eklenmeden önce PrototypeJS’in bir parçasıydı.
34:51 HTML5 PrototypeJS’den kopyaladı.
34:52 ve gayet güzel bir fonksiyondur bu arada.
34:56 Problem ise PrototypeJS’in bunu kendince yapmış olması
35:01 ve HTML5’in ise ondan oldukça farklı bir şekilde entegre etmesiydi.
35:04 PrototypeJS kullananlar için bir uyumsuzluk söz konusu oldu.
35:09 HTML5 tarayıcılar çıkmaya başlayınca kullanıcıların kodları bozuldu.
35:15 PrototypeJS temelde doğru şeyi yapmaya çalışmıştı.
35:19 Demişlerdi ki; eğer bu fonksiyon daha önceden olsaydı ezmeyeceklerdi
35:22 ama olmadığı için eklemişlerdi. İkisinin oldukça farklı olmasından dolayı,
35:25 orijinal versiyona göre kodlarını yazanlar
35:30 HTML5 versiyonu çıkınca sorun yaşamışlardı.
35:34 Talihsiz ama sahip olmadığınız nesnelere metotlar eklememeniz
35:37 gerektiği konusunda güzel bir ders.
35:40 Eğer daha fazla bilgi isterseniz bununla ilgili oldukça uzun bir blog yazım da mevcut
35:45 Ayrıca kitapta da yer almakta. Devam edelim. “Global değişken ve fonksiyonlardan kaçının”
35:50 Bunu daha önce bir çok kez duymuş olmalısınız. Bir önceki örneğim
35:54 bu konuda oldukça kötüydü.
35:56 Telafi etmek için global bir kapsayıcı katman içine aldım.
36:00 “Kendi hatalarınızı fırlatın” Bu geliştiricilerin yeterince yaptığı bir şey değil.
36:06 Genç bir geliştiriciyken
36:10 Bir şarkının başlangıcı gibi oldu :)
36:13 Java ile çalıştığım o dönemlerde
36:17 Hakikaten bir şarkının başlangıcı gibi oldu bak :)
36:20 Neyse… “throw” ifadesini çok görürdüm.
36:24 throw new Exception, ne diye bunu yaparsın ki? bir hataya yol açıyorsun!
36:29 Bir geliştiricinin bütün işi hataların önüne geçmek değil mi?
36:33 O zamanlar çok mantıksız geliyordu
36:35 Artık daha yaşlı ve bilgeyim
36:38 Yani, bilgelik tartışılabilir tabi. Şunu fark ettim ki
36:43 hata fırlatmak gerçekten ama gerçekten faydalı olabiliyor.
36:46 Kodunuz içinde size yol göstermek için kullanabileceğiniz
36:48 bir diğer not da hata fırlatmadır aslında.
36:51 Hata oluşma ihtimali olan ve hatayı tespit etmesi
36:54 zor olan bir yerde gerçekten faydası dokunabiliyor.
36:59 Örneğin bu fonksiyon “element” değişkeni null ise çalışmaz.
37:03 ve gerçekten “sınıf adı null olamaz” gibi saçma bir tarayıcı hatası alırsınız ki...
37:06 bu size hiç bir şey ifade etmez,
37:11 Kodun derinliklerine inersiniz ve hatanın nerde oluştuğunu bulmaya çalışırsınız..
37:14 Breakpoint koyarsınız vs...
37:16 ve sonunda anlarsınız. Bir hata oluştuğunda sebebinin ne olduğunu
37:21 bilmemekten nefret ederim.
37:23 Bu hiç hoş değildir. Yani eğer kendi hatalarınızı fırlatırsanız; basitçe kendinize “Eğer bu şart sağlanırsa, ...
37:27 işte hatanın sebebi bu”
37:29 diyen bir not bırakmış olursunuz.
37:34 Eğer null bir element geçilirse bir hata fırlatıyorum.
37:38 Ben her zaman metot adını da hataya koyarım,
37:41 Çünkü hatayı hızlıca bulabilmem için epey faydası dokunuyor diye düşünüyorum.
37:45 ve sonrasında asıl hatayı bulur ve düzeltirim.
37:49 Tabi abartmamak da lazım.Staticly typed (C#, Java) dilleri taklit etmeye çalışmayın.
37:53 Her fonksiyonun her parametresi için yapmayın.
37:59 Sadece sonucunda hata göreceğiniz ya da
38:02 bir API’yi açığa vuran durumlarda
38:05 o fonksiyon için en önemli bir ya da
38:09 iki değişken için kullanılmalıdır.
38:13 Sadece başkalarına yardımcı olmaya çalışın.
38:17 Bu özellikle YUI ve jQuery gibi kütüphaneler için oldukça önemlidir ve gerçekten güzel yapıyorlar.
38:20 Bir şey çağırırken eğer null bir parametre geçerseniz
38:22 Sizi açıklayıcı bir hata mesajı ile uyarıyorlar
38:26 bu da kolayca hatayı bulmanızı ve düzeltmenizi sağlıyor.
38:31 “Boş (null) karşılaştırmaları azaltın” Evet şuna benzer bir çok kod görüyorum.
38:35 “Bu şey null değilse bir şey yap” anlamına gelen bu örnek genelde
38:39 yeterince spesifik değildir.
38:43 Değeri null olarak atanmış ve sonradan değişme ihtimali olan
38:47 bir değişkeniniz olduğu sürece değerinin değişip değişmediğinin kontrol etmek
38:51 genelde boş olup olmadığını anlamak için yeterli değildir.
38:55 Örneğin burada “items” null değilse
38:59 bir takım işlemler yapacaksınız.
39:02 Tamam ama bunu anlama geliyor;
39:07 Değer olarak true, one ya da herhangi bir metin geçebilirsiniz.
39:11 Bu şekilde gider ve başarısız olur.
39:14 Bunun gibi bir “instanceof Array” ifadesi kullanmak
39:18 gerçekten faydalıdır.
39:21 Çünkü neyi amaçladığınız daha açıktır,
39:24 ve sizi başarısızlığa uğrayacak değerlerden korur.
39:30 Eğer belirli bir türe göre kontrol yapıyorsanız “instanceof” kulanabilirsiniz.
39:35 “Nesne instanceof Yapıcı” ondan türemiş ise true dönecektir
39:40 ve “typeof” sadece basit değerler içindir. metin, bool, sayı gibi
39:47 fonksiyonlar için bile gayet iyi iş görür. Bu arada
39:51 “typeof == ‘object’” olduğunu düşünersek… aman diyim dikkatli olun!
39:58 “Ayarlar verisini ayrı tutun”
40:01 JavaScript içerisinde string ya da
40:04 başka değerleri görmeyi pek sevmiyorum.
40:08 Bunlar uygulama ayarları veya değişebilecek şeyler olabilir.
40:13 Örneğin buradaki kullanıcıya gösterilecek bir hata mesajı ve
40:16 yönlendirme adresi mevcut.
40:18 Emin olun bu ikisini de ilerde değiştireceksiniz.
40:23 Muhtemelen yayına almadan önce bir çok kez değiştireceksiniz hem de.
40:28 bunları uygulama kodlarından ayrı tutmak isteyebilirsiniz.
40:32 Çünkü, bu değerleri
40:36 değiştirirken uygulamanın işleyişiyle alakalı
40:39 başka şeyleri bozabilirsiniz.
40:40 Her değer değiştiğinde, uygulamanın çalışıp çalışmadığından emin olmak için
40:44 unit testleri tekrar çalıştırmak zorunda olmamalısınız.
40:47 Bunlar şekildeki gibi ayırmak iyi bir ilk başlangıç.
40:51 Bütün URL’ler, kesinlikle hepsi!
40:56 asıl JavaScript kodlarınızın dışında tutulmalıdır.
41:00 Çok sık değişirler. Diğer taraftan kullanıcıya sunulan metinler,
41:03 önceki örnekte gördüğümüz HTML gibi şeyler için template kullanılmalıdır.
41:07 mustache, dust gibi şeyler kullanılmalıdır. Her sayfada kaç kayıt gösterildiği gibi,
41:12 tekrar eden tekil değerler,
41:14 yani birden çok kez kullanılan css class ismi,
41:18 bir şeyin maksimum değeri vs gibi şeyler.
41:23 işte böyle şeyler kodun dışında tutulmalıdır.
41:26 Çünkü bunlar değiştirmek icap ettiğinde dosyadan dosyaya atlayıp
41:29 aramaktansa, tek bir noktada bulmak istersiniz.
41:34 İşte bundan dolayı “props2js” isimli bu küçük aracı yazdım.
41:39 Java daki .properties ayar dosyasını alıp sizin için
41:43 JavaScript’e dönüştürüyor.
41:48 Böylece projenizdeki ayarlarınızı, anahtar=değer ikilisi (key, value pair)
41:54 şeklinde kolayca yönetebilmenize olanak sağlıyor.
41:58 Evet, son bölüm…“İşleri otomatize etmek”
42:02 Bundan birkaç sene evvel arayüz geliştirmede JavaScript vs için
42:08:otomatizasyondan bahsettiğimde neredeyse hiç yok gibiydi..
42:14 Ama artık ortalıkta bir çok araç var.
42:18 Burada sadece fikir vermek için şöyle bir üzerinden geçeceğim,
42:22 kitapta çok daha fazlası var, bir sürü online kaynak da mevcut.
42:26 Derleme işlemleri (build proccess) bence sihir gibi bir şey.
42:29 JavaScript geliştiricilerin buna çok geç kavuşmaları
42:33 beni gerçekten üzüyor.
42:36 Fikir şu aslında: bir takım dosyaları alıp bir şekilde işleyip birleştirilmiş tek bir ya da
42:40 birkaç dosya elde etme işlemi oluyor.
42:46 Şahane bir şey, hayatınızı gerçekten çok kolaylaştırıyor.
42:49 Böylece kodunuz çok daha sürdürülebilir oluyor. Çünkü
42:54 Herşeyin olması gerektiği gibi olup olmadığını kontrol etmek için
42:58 her türlü kontrol ve test işini otomatik olarak yaptırabiliyorsunuz.
43:01 Derleme işleminden bahsederken bir kaç aşamalı bir süreçten bahsediyor olabiliriz.
43:06 Debug kodu eklemek ya da silmek, dosyaları birleştirmek,
43:10 dokümantasyon üretmek, kodun geçerleme, test etmek,
43:13 sıkıştırma, sunucuya göndermek bunun gibi her şey.
43:17 Bunlar otomatizasyonun harika kısımları diyebiliriz.
43:20 Bu konuda yardımımıza koşan bir çok araç mevcut.
43:23 “JS-build-tools” bir ön işleyici,
43:27 bulabildiğim kullanımı en kolay olanlardan.
43:30 Kodları kolayca “debug” mod ya da “diğer” mod
43:35 olarak ayırabiliyorsunuz.
43:37 C’deki gibi #ifdef kullanabiliyorsunuz
43:41 ve dokümantasyon için en popülerlerinden biri olan
43:47 JSDoc kullanabiliriz. Bu arada bütün bu sunumu
43:51 internete koyacağım, bu adresleri filan not almakla uğraşmayın.
43:53 YUIDoc bir diğeri JSDoc’a benzer bir şekilde çalışıyor.
43:58 “docco” biraz farklı, kaynak koda göre dokümantasyon üretiyor.
44:04 Kod geçerleme için kullanabileceğimiz “JSLint” var
44:08 Crockford, sitesinin tasarımını değiştirdiğinden beri
44:13 sunumumu güncellemek için bekliyorum amaa….. vav :)
44:18 Ayrıca bir kaç fazladan ayarı bulunan “JSHint” de mevcut
44:22 Dosyaları sıkıştırmak için “YUIcompressor”
44:25 Uzunca bir süre bu işin standardı olarak kabul gördü. Çünkü,
44:30 değişken adlarını değiştiriyordu.
44:33 Uzun fonksiyon ve değişken isimlerini sizin için daha kısa olanlarıyla değiştiriyordu.
44:42 Bu aralar daha popüler. Kodunuza garip bir şeyler yaparak
44:46 daha da sıkıştırıyor. Bir çok proje ona geçiyor.
44:52 Ayrıca YUICompressor ve UglifyJS gibi
44:58 benzer şeyler yapan Google’ın “Closure Compiler“ ı da var.
45:01 ek olarak başka araçları da mevcut.
45:06 Bunlara ek olarak bir Java derleme aracı olan
45:10 “Apache Ant” i da gerçekten seviyorum.
45:13 JavaScript için gerçekten harika çalışıyor.
45:17 Çünkü dosyaları birleştirme,
45:19 sıkıştırma gibi faydalı bir çok şeyi kendi içinde barındırıyor.
45:22 YUICompressor’ün yazarı olan Julien Lecomte
45:25 Ant’ın kullanımı ile ilgili güzel bir makale yazmıştı.
45:29 JavaScript ve CSS’i derlemeyle ilgili flan...
45:33 Son zamanlarda JavaScript tabanlı görev yürütücü olan
45:42 Tamamdır, “Acele etsen iyi olur” uyarımdı :)
45:47 Evet Grunt JavaScript tabanlı bir araç
45:52 Hakkında küçük bir makale de mevcut.sunumdan sonra göz atabilirsiniz.
45:56 Evet, derleme için aslında bir çok
46:00 farklı derleme işlemine ihtiyacınız var.
46:05 Yayınlama, geliştirme, test ve herbiri farklı şeyler yapabilir.
46:09 Esasında yayın sürecinin sürekliliği bakımından lokalde geliştirici
46:15 olarak çalışmak için harika bir yoldur
46:20 Ve son olarak, kod stil kılavuzları
46:26 aynı dili konuşması bakımından çok önemlidirler.
46:29 Birbirinden ayrılmış katmanlar, hata ayıklama için çok faydalıdırlar.
46:33 İyi programlama pratikleri yine hata ayıklama bakımından
46:37 Kod organizasyonu ve otomatizasyon, çıldırmamanız işçin yardımcı olur
46:39 ve sizi son bir söz ile başbaşa bırakıyorum.
46:44 “Her zaman, sizden sonra kodunuzu devralacak kişinin nerede yaşadığınızı...
46:47 ...bilen saldırgan bir psikopat olduğunu düşünerek kod yazın”
46:49 Hepsi bu, işte bana ulaşabileceğiniz yollar.
dailybridgerton
blakekathryn
romaincrisis
snowghoul
kianamaiart
pixelskylines
janainaart