kodaman.org

Diğer geliştiricilerin kodlarını okuyun.

Daha iyi yazmak için daha iyi okumak gerekir. Okunacak kodlar olarak API'lerin örnek kodları gibi ufak ve öğretici yanı pek bulunmayan satırlar yerine daha geniş içerikli yazılımların, özellikle açık kaynak yazılımlarının gittikce yaygınlaştığı bir dönemde, üzerine gidilmesi çok daha uygun olur.

Daha kısa methodlar yazın.

Uzun methodlar; zor anlaşılmaya, iyileştirilmenin zorlaşmasına ve Java ya da C# gibi gözetimli (managed) dillerde yavaşlığa sebep olur.

Kısa methodları yazarken yapılacak işin özüne inmeye çalışın. Bu şekilde method isimleride kısalmış olur ve kolay adlandırılabilir.

Kısa methodların kullanımı test aşamasında yardımcı olduğu gibi, güncelleme esnasında da kolaylık sağlar. Yapılacak işe odaklanmayı kolaylaştırır. Örneğin öğrencilerin not ortalamasını hesaplayan ve bunları veritabanına giren bir method yerine, hesaplamayı ve veri girişini ayrı methodlarda yaptırılır ise öğrenci not ortalama kriterleri değiştiğinde bilgi girişi için her hangi bir değişiklik yapılmamış olur. Aynı şekilde değişen bir veritabanı ya da tabloları söz konusu olduğunda hesaplar ile ilgili bir işlem yapmaya gerek kalmaz.

Programlama günlüğü tutun.

Yazılım geliştirme, diğer mesleklere göre çok daha esnektir. Öyleki esneklik bazen bunun bir meslek olduğunu unutturmaya kadar varabilir. Bu durumlarda gelinen noktanın ve başarılan işlerin kaydedilmesi önem kazanır. Bazı geliştiriciler, bir takım araçlar ile, örneğin kaynak kontrolü ve hata yönetimi gibi, görevlerini tanımlar ve başarılarını kaydederler. Fakat bu yeterli olmayabilir.

Programlama günlüğü sadece bir öğrenme aracı değil aynı zamanda ileriki hataları önlemek için de önemli bir yardımcıdır.

Programlama günlüğüne günlük olarak verilen kararları, soruları ve konuşmaları girebilirsiniz. Resmi bir tasarım dokümanı oluşturacak kadar bilgi olmadığı durumlarda bir depo işlevi görecekmiş gibi kayıt tutabilirsiniz. Örneğin; patronunuz ya da çalışma arkadaşlarınız ile yaptığınız görüşmeler, tasarımdaki değişim konuşmaları, yalnış giden kısımlar, yenilikler için fikirler, tehlikeli ya da zor anlaşılır kod satırları günlüğe yazılması olası konulardır.

Programlama günlüğünü çevrimiçi tutmanız sizin kolayca yazabilmenizi ve ilgili kişilerin rahatça takip edebilmesini sağlayacaktır. Şirket içinde yerel bir ağ günlüğü de olabiliceği gibi, internet üzerinde de olabilir. Özellikle ağ günlüğü formatında olması, kişiselliği arttıracaktır. Her yazar, kendi yazdıklarında sorumludur.

Yeni programlama dilleri öğrenin.

Yeni bir dil öğrenmek, yeni birşey öğrenmenin zevki yanı sıra ufkumuzda genişletir. Her geliştiricinin bildiği gibi, hiç bir dil mükemmel değildir. Yeni bir dil öğrenmek çok çeşitli olabilir; bildiğiniz, çok sık kullandığınız bir dile çok farklı bir dil öğrenmeyi de seçebilirsiniz ya da bildiğiniz dilin normalde girmediğiniz detaylarına yolculuğa başlayabilirsiniz.

Önce birim testinizi yazın.

Önceden kabül edilmiş, klasik görüş, hatasız bir yazılım için önce tüm program yazılır, derlenir. En sonunda da denemeleri yapılır. Fakat tecrübeler gösteriyor ki günlük yapılmayan testler sonucunda sağlıklı bir ürüne ulaşmak gerçekten zordur. Aynı yazılımın derlenmesi gibi testlerde her adımda yapılması gereklidir. Derleme esnasında geliştirme platformunuz sadece dil yazım hatalarını veya veri tipi sorunlarını sizlere söyleyebilir. Öte yandan birim test ile kullandığınız algoritma ile karşılaşabileceğiniz potansiyel hataları öğrenebilirsiniz. Derleyiciniz statik özellikleri kontrol ederken, birim test ile dinamik özellikleri kontrol etme şansına sahip olursunuz.

Bir birine bağlı nesnelerle çalışmak durumdayken birim test yapmak gerçekten zahmetli bir iştir. Bu gibi durumlarda kendi kendinize bu fonksiyonu nasıl test edebilirim diyerek cevabınız doğrultusunda birim test için hazırlanabilirsiniz.

Kısacası, eklemek istediğiniz özellikler için birim testi önceden yazınız. Eğer özellik için bir test yazabilirseniz, devamında bu testi doğrulayacak koduda yazabilirsiniz. Önceden yazılmış kodları test için tekrar gözden geçirirken fark etmeden hatalar ekleme şansınız da doğabilir. Sonuç olarak, birim testleri sonradan eklemeniz, en azından, önceden sorunsuz olan kısımlara zarar verebilir.

Teknik özellikleri yazın.

Teknik özellikler kod yazma ile alakası olmadığı için sıkıcı ve gereksiz gelebilir. Fakat bunlar sıkıcı olsa bile, asla gereksiz değillerdir.

Teknik özellikler, yazmakta olduğunuz yazılımı kullanıcılara, müşterilere, patronunuza anlatmak için önemli bir araçtır. Geliştirme sürecinde, iyi yazılmış teknik özellikler, en verimli çalışma saatleriniz olabilir.

Teknik özellikleri yazarken, teknik detaylardan bahsetmekten kaçınmanız da gerek yoktur. Örnek kodlar, resimler gibi içeriği zengin tutarak kendinizide rahatlatabilirsiniz. Çok resmi ve bürokratik yazımlardan kaçınınız.

İlla resmi bir teknik özellik yazılması istenildiğinde, dilediğiniz şekilde yazdıktan sonra sizden istenilen hale getirmek çok daha kolay olur.

Kendi orjinal özelliklerinizi ekleyin. İleride fikirlerinizi iş arkadaşlarınız ile paylaşmayı kolaylaştırır.

Zamanı bahane edip, yazmaktan kaçmayın. Teknik özelliklerin yazılmadığı bir program, aynı bir evin inşasından önce taslağa sahip olmamak gibidir.

Özelliklerin kapsamında; düşündüğünüz tüm işlevsellikleri yazın, işlevselliklerin nasıl eklenebileceğini, sınıfların kullanımını, temel algoritmaları ve/veya veritabanlarını tanımlayın. Tüm bu detayların eklenmesi için süreleri de belirtmeniz önünüzü görmekte sizin için faydalı olabilir.

Teknik özellikleri yazmak, zor olabilir fakat yaptıkça bir alışkanlığa dönecektir. Başlangıç olarak ufak işlevselliklerin özelliklerini yazın ve daha sonra bunları tüm sisteme doğru genişletin.