Joel on Software   Joel'den Yazılım Üzerine

Diğer Türkçe "Joel on Software" makaleleri

Diğer İngilizce "Joel on Software" makaleleri

Yazara e-posta gönderin (Sadece İngilizce)

1982 yılında ailem İsrail’de ilk çıkan bir IBM-PC’yi teslim aldı. O kadar heyecanlanmıştık ki satıcının dükkanında oturup uzun süre kişisel bilgisayarın limandan gönderilmesini beklemiştik. Babamı her nasılsa 2 disket sürücülü, 128 K bellekli tam teşkilatlı seriden almak için ikna etmiştim. Bilgisayara ilaveten nokta vuruşlu bir yazıcı (hızlı dökümler için) ve Brother marka mektup kalitesinde basan ve çalıştığında makinalı tüfekten farklı olarak sadece daha fazla ses çıkaran bir Daisy wheel yazıcı almıştık. Sanıyorum var olan tüm donatıları almıştık: PC-DOS 1.0, 75 $ değerinde BIOS’un tüm kaynak kodlarını içeren teknik başvuru el kitabı, Macro Assembler, ve müthiş bir 80 sütunlu (küçük harfli!) IBM tek renkli ekran. İsrail’in o zamanki tuhaf ithal vergisi dahil tüm alışveriş bize 10,000 $’a mal olmuştu. Çok pahalı!

BASIC dilinin çocuklar için bir dil olduğunu, spagetti türü kod yazmanızı gerektirdiğini ve beyninizi sulandırdığını “herkes” biliyor. Bu nedenle üç disketle gelen ve 600$ değerindeki IBM Pascal derleyicisini satın aldık. Derleyicinin ilk derleme adımı (pass) birinci diskette, ikinci derleme adımı ikinci diskette, ve bağlayıcı (linker) üçüncü diskette idi. Basit bir “merhaba, dünya” programı yazıp derledim. Toplam geçen süre 8 dakika idi.

Hımm. Bu oldukça uzun bir süre. Tüm işlem adımlarını otomatik hale getiren bir toplu iş (batch) dosyası yazdım ve toplam süreyi 7,5 dakikaya indirdim. Daha iyi. Fakat Othello’nun akıllara durgunluk veren sürümüne benzer bir program yazmaya kalkıştığımda, zamanımın çoğu derlemeye gidiyordu. Profesyonel bir programcı bana “Tabii” dedi, biz derleme yaparken ofiste mekik tahtası bulunduruyoruz ve derleme devam ederken bizde mekik çekiyoruz dedi. Birkaç aylık programlamadan sonra çok güçlü karın kaslarına sahip oluyorlarmış.

Günlerden bir gün Danimarka’dan Compas Pascal adında bir program çıktı. Philippe Kahn bu programı satın aldı ve Borland Turbo Pascal olarak adını değiştirdi. Turbo Pascal , IBM Pascal’ın yaptığı her şeyi yapmasına ilaveten metin yazım programı dahil olmasına rağmen sadece 33K bellekte çalışması ile herkesi hayrete düşürmüştü. Asıl şaşırtıcı olan ise küçük bir programı bir saniyeden kısa bir sürede derliyor olmasıydı. Sanki hiç adı duyulmamış bir firmanın, saatte 1,000,000 kilometre hız yapan ve dünyanın etrafında bir karıncanın hasta olmadan içebileceği su miktarı kadar benzin harcayarak dolaşabilecek bir Mercedes kopyasını duyurması gibi bir şeydi.

Bir anda, çok daha verimli çalışmaya başladım.

Bu benim ODY(REP) döngüsünü öğrenmemle başladı. ODY’ın anlamı “Oku, Değerlendir,Yaz (Read, Eval, Print)” olup Lisp yorumlayıcısının nasıl çalıştığını tanımlar: Lisp girdiyi “okur”, onu değerlendirir ve sonucu yazar. Örnek bir ODY döngüsü aşağıda olduğu gibidir: bir şey yazıldığında lisp yorumlayıcı onu okur, değerlendirir ve sonucu yazar.

Daha büyük ölçekli bir çalışmada kod yazılırken ODY döngüsünün Düzenle-Derle-Test Et olarak adlandırılan makro-sürümünde çalışılır. Kod düzenler, derler, test eder ve nasıl çalıştığı görürsünüz.

Dikkatli bir gözün fark edebileceği gibi burada program yazmak tekrar tekrar aynı işlemlerin yapılmasını gerektirmektedir. Bu nedenle Düzenle-Derle-Test Et döngüsü ne kadar hızlı yapılırsa o kadar verimli bir çalışma ortamı elde edilir. İşlemin doğal hız limiti olan erişilebilecek en yüksek hız; anında derlemedir. Bu yüzden bilgisayar yazılımcılarının çok hızlı donanım istemeleri ve derleyicileri geliştirenlerin ellerinden gelenin en fazlasını yapmaya çalışmaları, Bilgisayar Biliminin herkes tarafından kabul edilen en birinci talebini yani çok hızlı Düzenle-Derle-Test Et döngüsünü elde etmek içindir. Visual Basic dili bunu yazılan her satırı ayrıştırıp (parsing) anlamlandırarak (lexing) yapar, böylece son derleme süper hızlı olur. Visual C++ aynı işlemi artımlı derleme, ön derlemeli başlıklar ve artımlı bağlama ile sağlar.

Ancak, birden fazla geliştirici ve test yapandan oluşan bir ekipte çalışmaya başladığınızda daha büyük ölçekte olmak koşuluyla (fraktallar gibi!) aynı döngü tekrar karşımıza çıkar. Test yapan, kod içinde bir hata bulur ve hatayı rapor eder. Programcı hatayı düzeltir.  Test yapan kodun düzeltilmiş sürümünü elde edinceye kadar ne kadar süre geçer? Bazı firmalarda bu Raporla-Düzelt-Yeniden Test et döngüsü birkaç haftayı alabilir, bu da tüm firmanın verimsiz çalıştığı anlamına gelir. Tüm geliştirme adımlarının düzenli bir ritimde çalışması isteniyorsa, Raporla-Düzelt-Yeniden Test Et döngüsünün sızdırmaz hale getirilmesi üzerine kafa yormak gerekir.

Bunu yapmanın iyi bir yolu oluşturmanın günlük yapılmasıdır (günlük oluşturma). Günlük oluşturma tüm kaynak kodlarının otomatik, günlük ve tam bir şekilde oluşturulmasıdır.

Otomatik – çünkü derlenmesi gereken kod her günün belirli bir saatinde derlenecek şekilde cron işleri (UNIX için) veya zamanlandırılmış görev servisi (Windows için) kullanılarak ayarlanır.

Günlük – ve hatta daha sık. Muhtemelen sürekli oluşturma çok daha caziptir ancak biraz sonra ele alınacak nedenlerden dolayı yapılmasının bazı zorlukları vardır.

Tam – muhtemelen kodunuzun birden fazla sürümü vardır. Birden fazla dil sürümü, birden fazla işletim sistemi veya basit/gelişmiş sürüm. Günlük oluşturma bunların hepsini oluşturmalıdır. Ve derleyicinin muhtemelen hatalı olabilecek artımlı yeniden oluşturma özelliklerine bağlı kalmaksızın tüm dosyaların yeni baştan oluşturulması gerekir.

Günlük oluşturmanın birçok yararından bazıları aşağıda olduğu gibidir:

1. Hata düzeltildiğinde test yapanlar yeni sürümü çabucak elde edebilir ve hatanın gerçekten düzelip düzelmediğini kontrol edebilirler.
2. Geliştiriciler yaptıkları değişmelerin üretilen 1024 sürümden herhangi birinde bozulmaya neden olmayacağını, masalarında test için bir OS/2 işletim sistemi bulundurmaya gerek kalmaksızın, kendilerinden emin olarak bilirler.
3. Planlı günlük oluşturma işleminden hemen önce geliştiriciler, kod değişikliklerini kontrol ederek “oluşturmayı bozan” – yani kimsenin derleme yapamadığı bir duruma neden olacak kod bırakmayarak - diğerlerinin başına çorap örmezler. Bu çok sık olan durum, tüm yazılım ekibi için eski windows sürümlerinin mavi ekran hata durumu gibidir ve programcıların oluşturdukları yeni bir dosyayı kaynak kodu havuzuna eklemeyi unuttuklarında meydana gelir. Oluşturma kendi bilgisayarlarında normal çalışır, fakat bir başkası kod havuzundan kodları teslim almak istediğinde bağlayıcı hatası alır ve herhangi bir işlem yapamadan donar kalır.
4. Ara ürünleri test eden pazarlama, pilot müşteriler ve benzeri yerlerde kullanıcılar tamamlanmamış versiyon yerine daha eski ve istikrarlı bir sürümü belirli bir süre kullanabilirler
5. Tüm günlük oluşturmaların arşivini tutarak, tuhaf bir hata oluştuğunda ve hatanın nedeni hakkında hiçbir fikriniz olmadığında, arşiv içinde ikili (binary) arama yaparak, hatanın kod içinde ilk oluştuğu yeri bulabilirsiniz. İyi bir kaynak kontrol sistemi ile hangi kod değişikliğinin bu hataya neden olduğu bulunabilir.
6. Test yapan, programcının düzeltmiş olduğunu düşündüğü bir hatayı rapor ettiğinde, test yapan hangi oluşturmada hatayı gördüğünü söyleyebilir. Bu sayede programcı düzeltmeyi ne zaman teslim ettiğini bularak hatanın gerçekten düzeltilip düzeltilmediğini belirleyebilir.

Günlük oluşturma için şu işlemler yapılmalıdır. İlk olarak elde edebileceğiniz en hızlı bilgisayar ile hazırlanmış günlük oluşturma sunucusuna ihtiyacınız var. Kod havuzundan halihazırdaki tüm kaynak kodlarını teslim alan (kaynak kontrol sistemi kullanıyorsunuz değil mi?) ve piyasaya sürülen her sürüm için en baştan oluşturan bir betik (script) yazın. Eğer bir kurulum veya ayar programınız varsa onu da oluşturun. Müşteriye gönderdiğiniz her şey günlük oluşturma işlemi tarafından en baştan üretilmelidir. Her oluşturmayı tarihini belirten ayrı bir dizine yerleştirin. Betiğinizi her gün belirli bir saatte çalıştırın.

• Kodların teslim alınmasından tüm sonuçların kullanıcılar tarafından indirilmek üzere web sunucuda (bu sunucu geliştirme aşamasında bir test sunucusu olsa dahi) bir yere yerleştirilmesine kadar nihai oluşturma için gerekli tüm işlemlerin günlük oluşturma betiği tarafından yapılıyor olması hayati önem taşır. Bu oluşturma işlemi hakkında sadece tek bir  programcının kafasında “dökümante” edilmiş herhangi bir bilginin olmadığını garanti etmenin tek yoludur. Bu sayede sadece Merve’nin kurulumu bilmesi ve onunda bir otobüs kazası geçirmesi nedeniyle ürünün teslim edilememesi gibi bir durumla asla karşılaşmazsınız. Juno (daha önce çalıştığım uluslararası bir firma) ekibinde, en baştan tam bir oluşturma yapmak için bilmeniz gereken oluşturma sunucusunun nerede olduğu ve “Günlük Oluşturma” simgesine nasıl çift tıklanacağı idi.
• Kodlarınızı piyasaya sürmeden önce küçük bir hata bulunduğunda bu hatanın günlük oluşturma sunucusunda düzeltilip kodun piyasaya sürülmesinden daha akla ziyan bir şey olamaz. Altın bir kural olarak sadece, en baştan itibaren tüm kodları teslim edilmiş, tam ve temiz olarak oluşturulmuş bir günlük oluşturma sonrası piyasaya sürülmelidir.
• Derleyicilerinizi en üst uyarı seviyelerine ayarlayın (Microsoft dünyasında –W4; gcc dünyasında ise –Wall) ve herhangi bir uyarı ile karşılaşıldığında duracak şekilde ayarlayın.
• Günlük oluşturma yarıda kaldığında tüm ekibin çalışmasının durması riski vardır. Her şeyi durdurun ve sorun çözülünceye kadar oluşturmayı tekrarlayın. Bazı günlerde birden fazla günlük oluşturma yapabilirsiniz.
• Günlük oluşturma betiğiniz, hataları e-posta üzerinden tüm geliştiricilere iletmelidir. Log dosyalarını ”hata” ve “uyarı” kelimelerini tarayacak şekilde grep programından geçirerek sonuçlarını postalamak çok zor değildir. Betik aynı zamanda durum raporlarını herkesin erişebileceği şekilde bir HTML sayfasına ekleyerek programcı ve test yapanların hangi oluşturmanın başarılı olduğunu görmelerini sağlayabilir.
• Microsoft Excel yazılımı hazırlanırken uyguladığımız ve çok işe yarayan bir kural, oluşturmayı bozan kişinin oluşturma işlemlerinin bakımından bir başkası oluşturmayı bozana kadar sorumlu tutulmasıydı. Programcıları oluşturma işleminin çalışır durumda olması için teşvik etmesine ilaveten, hemen hemen herkesin oluşturma işleminin nasıl yapıldığını öğrenmesini sağladı.
• Eğer tüm ekip aynı zaman diliminde çalışıyorsa, en iyi günlük oluşturma zaman öğle yemeği arasıdır. Bu sayede herkes yemekten önce değişikliklerini teslim eder, oluşturma yemek süresince çalışır ve yemekten dönüldüğünde eğer oluşturma işlemi yarıda kaldı ise düzeltmek üzere herkes hazırdır. Oluşturma düzeltilir düzeltilmez yine herkes oluşturmanın bozulması nedeniyle başlarına bir çorap örülme korkusu olmaksızın son değişmelerini kontrol edebilir.
• Eğer ekibiniz iki ayrı zaman diliminde çalışıyorsa, bir zaman dilimindeki ekip diğer zaman dilimindeki ekibin başına çorap örmeyecek şekilde zamanlamayı ayarlayın. Juno ekibinde, New York ekibi, New York saati ile akşam 7’de teslim edip eve giderdi. Eğer oluşturma bozuldu ise Hindistan ekibi çalışmaya başladığında (New York saati ile akşam 8) tüm gün çalışamaz durumda beklerdi. Bu durum üzerine her ekip evine gitmeden bir saat önce çalışacak şekilde iki günlük oluşturma yapmaya başladık ve problemi tamamıyla ortadan kaldırdık.

İlave okumalar için

• Günlük oluşturmanın hazırlanması Daha iyi kod için 12 adım’dan birini oluşturacak kadar önemlidir.
• Pascal Zachary’nin kitabı “Showstopper” da Windows NT ekibi tarafından hazırlanan oluşturmalar (haftalık) hakkında birçok ilginç bilgi var.
• Steve McConnell’ın günlük oluşturma hakkındaki görüşleri burada