Bildiğiniz gibi Kod Basitliği kitabını bölüm bölüm inceliyorduk. Geçen yazımızda tasarımın zorluklardan bahsetmiştik. Bugünkü yazımız ise diğer üç yazımıza göre biraz uzun olacaktır. Umarım en keyifli şekilde okursunuz. Bugünkü yazımızın 3 temek başlığı yazılım tasarım denklemi, tasarımın kalitesi ve öngörülmeyen sonuçlardır. Eğer hazırsak başlayalım :)
Tasarımcılarının ilk sordukları sorusu , yazılıma nasıl karar veririm ? Onlar bir problemle karşılaştıklarında en iyi çözümü bulmaya çalışırlar. Bir konu hakkında kesin doğru veya yanlış gibi ifadelerden kaçınırlar. Bunun yerine hangi çözüm daha iyidir konusunda yoğunlaşırlar. Örneğin bir tasarımın yüzlerce farklı çözümü vardır, fakat tasarımcı onu minimuma indirgeyerek daha sonra o kalan çözümler üzerine yoğunlaşmaktadır. Bu bence genel olarak bizlerin (belki diğer milletler için de öyledir, bilemiyorum) büyük problemlerden biridir. Tek doğru benim çözümüm mantığı. Bundan kurtulmamız lazım. Herkes kendi doğrusunu tabi ki savunabilir. Bundan doğalı da yoktur, ama bunu asla tek veya olması gereken doğru gibi yansıtmamalıdır.
Yazılım Tasarım Denklemi
Aşağıdaki denklem yazılım tasarım denklemi olarak sorularımıza cevap verecektir.
D=V/E
D: Değişikliğin olma arzusudur. Yani bu değişikliğin olmasını ne kadar istiyoruz.
V: Değişikliğin değeridir. Yani bu değişiklik kullanıcıya ne kadar yardımcı olacaktır.
E: Değişiklik için harcanan çaba. Yani bunu ne kadar sürede çözeriz.
Temel olarak ifade etmek istediğimiz , değişikliği yapma arzumuz değişikliğin değeri ile doğru , işle ters orantıdır. Biz bir isteğe haklı veya haksız demekten ziyade bunun değerini ölçmeli ve ona göre bu değişikliğin yapılıp yapılmamasına karar vermeliyiz. Aslına bakarsak farkında olmasak da biz bunu kaba taslak yapıyoruz. Bir iş geldiğinde onun aciliyetini ne kadar zaman alacağını nereleri etkileyeceğini ne kadar süreceği gibi konular hakkında karar verdikten sonra o işi yapmaya başlıyoruz. Burada ise iş biraz daha sistematiğe vurulmuş.
Değer
Değeri denklemdeki yerini açıklayacak olursak, yapılan değişikliğin ne kadar insana yardım edebileceği olarak tanımlayabiliriz. En önemli konu insanlara yardım etmektir. Yaptığın değişikliği önemli olduğunu gösteren bir çok yol vardır. Bunlardan biri yazılımcının sahip olduğu tecrübeye dayanır.
Değerin olma ihtimali ve potansiyel değer: Değer iki yapıdan oluşur. Değerin olma ihtimali , yapılacak değişikliğin kullanıcıya nasıl yardım olacağı ve potansiyel değer ise ne kadar kullanıcıya hitap edeceğidir. Bazı kelimeleri Türkçe'ye çevirmek konusunda sıkıntılar yaşıyorum maalesef. Kulağı tırmalıyor gibi, bu konuda fikirlerinizi bildirirseniz memnun olurum.
Örneğin:
- Bir özellik hayat kurtarabilir, fakat olma ihtimali milyonda birdir. Bu özelliğin olma ihtimali çok düşüktür fakat potansiyel değeri çok yüksektir. Körler için bir özellik eklediğinizi düşünün. Bu özelliği kullanan kör kullanıcı oldukça azdır , fakat bu özellik olmazsa kör kullanıcı sizin programı kullanamayacaktır.
- Eğer bir özellik kullanıcıları gülümsetecekse fakat tüm kullanıcılar tarafından kullanılabilecekse bunun potansiyel değeri düşük fakat olma ihtimali yüksektir.
Bunlarla birlikte aşağıdaki özellikleri değerlendirmeye katmak gerekir:
- Ne kadar kullanıcı bu özelliği kullanacak (yüzde kaç) ?
- Ne kadar sıklıkla kullanılacak ?
- Ne kadar değerli olacak ?
Zarar Dengesi : Bazı özellikler eklemeniz kullanıcıları rahatsız edebilir. Mesela uygulamaya reklam eklerseniz bunun size getirisini ve sizden götürdüklerini iyi hesaplamalısınız.
Kullanıcılar için değeri : Bazı özelliklerin size anında bir getirisi yoktur. Siz belki onları geliştirmek için çok uğraştınız, fakat bu geliştirdiğiniz özelliğiniz ya kullanımı zor veyahut kullanışsız bir özellik olabilir. Doğal olarak bu özellik kullanıcılar için hiç hükmündedir. O yüzden bir özellik eklerken kullanıcılar için ne ifade ettiğini de göz önüne almalısınız.
Çaba : Kısaca "işçi saat" olarak tanımlayabiliriz. 100 işçi bir işi 1 günde yaparsa 50 işçi 2 günde yapar. Bildiğimiz işçi havuz problemine döndü :) ama gerçekte bu tabi ki böyle değildir. Özellikle yazılımda hiç böyle değildir. Hatta ülkemizde en çok yapılan hatalardan biri de yetişmeyen projelerde eleman eklemek veya fazladan mesai yaptırmaktır. Dikkat edin bazı iş ilanlarına çok acil eleman ararlar. Ben özellikle böyle ilanlardan mümkün olduğunca uzak durmaya çalışıyorum. Sebebi de plansızlığın göstergesi olması. Bunu hesaplamak çok zor hatta imkansıza yakındır. Bir özellik eklerken sadece harcanan zaman değil , tüm çabalar göz önünde bulundurmak gerekir. Tüm yazılımcılar birlikte düşünmeli ve buna karar vermeli. Kısaca değişim maliyettir.
Bakım : Denklemimiz gayet basit fakat zaman unsurunu göz ardı ettik. Programa değişikliği monte etmek tek başına yeterli değildir, bunun bir de bakım ücreti var. Örneğin muhasebe ile ilgili bir program yazıyorsunuz ve kanunlardaki vergi değişiklikleriyle ilgili her sene değişen kanunlara göre güncelleme yapmanız gerekecektir. Böylece çalışan koda testler yapılmak zorunda kalıyorsunuz.
Bir değişiklik yaptığımızda iki şeyi göz önünde bulundurmamız lazım: Şimdiyi ve geleceği. Sisteme bir özellik eklediğimizde şimdiki kullanıcıların işini kolaylaştırdığımız gibi, ileride kullanıcımız olacak kişilere de yardım ediyoruz.
Tüm bunlarla birlikte formülümüzü güncellememiz gerekir. Çünkü sadece yeni özellik için harcanan çabayla(Ei) birlikte bakım için harcanan çaba(Em) da eklenecek. Değer içinse özelliğin bugün(Vn) ve geleceğini(Vf) ekleyecek olursak, denklemin tamamı şöyle olacaktır:
D= (Vn+Vf)/(Ei+Em)
Denklemi indirgemek : Bakım için harcanan çaba ve değerin geleceği ikisi de zamana bağlıdır. Böylelikle bunları gerçek dünyada uyguladığımızda ilginç şeylere sebebiyet verir. Bunu göstermek için işimizi parayla hallediyormuş gibi yapalım. "Değer" bize ne kadar kazandıracağı ile hesaplarken, "Çaba" ne kadara maliyete sebep olacağı ile hesaplarız. Bu örneği gerçek dünyada kullanmamalısınız, fakat şimdilik işleri basitleştirecektir.
D= ($10.000 + $1000/gün) / ($10.00 + $100/gün)
yazdığımız formülü yukarıdaki değerlerle karşılaştırın. Değişikliği bugünkü değeri 10.000$ iken gelecek her gün için 1.000 $'dır. Aynı şey için çaba için de geçerlidir. Günleri 10 , 100, 1000 diye arttırdığımızda ilk başlangıçtaki Vn ile Ei artık önemsiz hale gelecektir. Böylece formülümüzü
D= Vf / Em olarak güncellenmiştir.
Hatırlayanlar olur mu bilmem ama kimyada kd kç değerleri vardı. Değerler çok küçük olduğunda çok küçük olan değer ihmal edilirdi. Burada da ona benzer bir işlem var. Günlük süre arttığında artık diğer kısmı görmezden gelip formül basitleştiriliyor.
Neyi istiyorsunuz veya istemiyorsunuz : Burada üzerinde durmanız gereken ilk şey yapacağınız bakımın vereceğiniz çabaya değip değmeyeceğidir. Burada günlük maliyetlerinizi ve karşısında onun için günlük harcanan çabayı yazabilirsiniz. Bunu beş gün için belirtip çıkan tabloya göre bu değişikliği yapıp yapmayacağınıza karar vermelisiniz. Ör;
| Gün | Çaba | Değer | Gün | Çaba | Değer | |
| 1 | $10 | $1,000 | 1 | $1,000 | $0 | |
| 2 | $100 | $100 | 2 | $100 | $10 | |
| 3 | $1,000 | $10 | 3 | $10 | $100 | |
| 4 | $10,000 | $1 | 4 | $0.00 | $1,000 | |
| 5 | $100,000 | $0.10 | 5 | $0.00 | $10,000 | |
| Toplam | $1,111.10 | $1,111.10 | Toplam | $1,110 | $11,110 |
Yukarıdaki tabloları incelerseniz 1.tablodaki geliştirmenin size uzun vadede zarar ettireceğini görürsünüz. 2.tablo için ise tam tersi geçerlidir. Belirli bir süre maliyeti/çabanın 0 olmasıyla birlikte geliştirmenin size bir yükü kalmayacaktır. Buradan şu sonuca varabilirsiniz.
Bakımın maliyetini azaltmak uygulamanın maliyetini azaltmaktan daha önemlidir. Çünkü bildiğimiz gibi programı yazmak belirli bir süre devam edecek ve daha sonra kullanıma alınacaktır, fakat bunun bakımı yıllarca sürecektir. O yüzden başlangıçta bazı konularda fedakarlık yapmak , sonradan elinizi fazlasıyla rahatlatacaktır. Tercihimizi doğru yapmamız o yüzden çok önemli.
Tasarımın Kalitesi
Yazılımın bir insana yardımcı olması kolaydır, fakat zor olanı yazılımın milyonlarca insana on yıllarca yardım etmesidir. Fakat yıllar içinde kullanıcılar bu yazılımı kullanmaya devam edecek mi ? Cevap ise gelecekteki programlama işinin şimdikinden daha fazla olacağıdır.
Eğer programınızı "çalışsın yeter" mantığıyla geliştirirseniz, ileride bunun bakımı çok daha zor olacaktır. Bakım zorlaştığında kullanıcılara yardımcı olmak da zorlaşacaktır (yazılımın ilk amacı). Eğer yeni özellikler ekleyemez ve hataları düzeltemezseniz yazılımınız kötü tasarlanmıştır.
Yazılımın kalitesi yıllar içinde kullanıcıya yardımcı olmasıyla orantılıdır.
Eğer yazılım sadece bir kaç saatliğine yazıyorsanız , kodun tasarımına , kalitesine dikkat etmenize gerek yok, fakat hedefiniz on yıllarsa mutlaka bir tasarımınız olmalıdır. Hiç bir zaman kesin hükümlerde bulunmayın. Yapınızı esnek tutun. Çünkü ileride tahmin etmeyeceğiniz şeyler karşınıza çıkabilir. Özellikle müşteri taleplerini göz önüne aldığımızda esnek yapının ne kadar önemli olduğunu daha rahat kavrarız. Bazen inanılmaz talepler gelebiliyor ve bunlar da hep acı tecrübelere vesile olur. Okuduğum bir yerde tecrübe için ona ihtiyacınız olmadığında ortaya çıkan şeydir demişti. Çok hoşuma gitmişti bu söz. Üzerinde düşünülmesi gerektiğine inanıyorum.
Öngörülemeyen Sonuçlar
Yazılımı tasarladığınızda gelecek bizim odak noktanız olmalı. Bununla beraber en önemli şeylerden biri de :
"Gelecek hakkında bilemeyeceğiniz şeyler vardır." Bu gerçekten de öyledir. Yazılımı tasarlarken ileride ne olacağını kestiremeyebilirsiniz. "Yazılımcıların en ölümcül ve genel hatalarından biri olmayan gerçeği tahmin etmeleridir."
Örneğin, 1985 yılında bozulan disketlerin tamiriyle ilgili bir yazılım yapıldığını düşünün. Yazılımın tüm parçaları diskin kullanımına bağlıydı. Öyle olduğunda şuan yazılım hiç kullanılmaz olurdu. Çünkü şuan disketler kullanılmıyor. Programcı , kullanıcıların her zaman disket kullanacağını tahmin eder fakat bu yanlıştır. Şuan belki de aynı şeyi usb bellek için düşünüyoruz. Ama belki de ileride farklı teknolojiler ile birlikte onlar da kullanılmaz hale gelecektir. En basitinden usb 2.0'lerin kullanımı gün gittikçe azalıyor. Artık usb 3.0'ler kullanımında gözle görülür bir artış vardır.
Kısa vadeli planlamalar tabi ki yapılabilir, fakat uzun planlar bizi yanılgıya düşürebilir. Ama bununla birlikte uzun planlamalar kısalarından daha önemlidir. Çünkü tasarımı uzun vadeye göre yapmak zorundayızdır.
Eğer kendinizi güvende hissetmek istiyorsanız tasarımınızı tahminlere göre değil gerçeğe göre tasarlamalısınız.
Şimdiye söyleyeceklerim şimdiye kadarki söylediklerimle çeliştiğini düşünebilirsiniz, fakat gerçek böyle değildir. Gelecek tasarımdaki en önemli şeylerden biri olabilir, fakat geleceği değiştirmeye izin vermek ve geleceği tahmin etmek birbirinden farklı şeylerdir.
Bir örnekle açıklamaya çalışalım. Yemek yemek ve açlıktan ölmek arasında basit bir seçim yapmak zorunda kaldığınızı düşünün. Hangisini seçersiniz tabi ki hayatta kalmayı. Bunu seçerken amacınız yemek yiyeyim de yarın bir bebeğin hayatını kurtarayım olmasına gerek yoktur. Çünkü siz her halde yemek yemelisiniz ve hayatınıza devam etmelisin. Benzer olarak yazılımı geliştirirken geleceği tahmin etmeden yazılımı daha iyi yapmaya çalışmak gerekir.
Burada istisnalar var. Şöyle ki bazen kısa vadeli planlamalarda tahmin yapmak mümkün olabilir ve bunu göz önünde bulundurabilirsiniz. Burada kriter şu olmalı : O işin olacağından kesinlikle emin olmalısınız. Yoksa ne kadar zeki olursanız olun geleceği tahmin edemezsiniz.
Hadi bir örneğe göz atalım. CD 1979'da ortaya çıktı. Kasetlerin yerini aldı, fakat kim bilebilirdi 20 sonra onun yerine ondan 50 kat daha hızlı DVD'ler alacak. Şimdi ise blueray'lar çok aktif olmasa da onlar da DVD'lerin yerini alıyor. Hatta daha ötesi artık bu tarz okuyucular bilgisayarlara konulmuyor. Çoğu bilgisayar üreticisi maliyetten kurtulmak veya bilgisayarı inceltmek amacıyla artık bu sürücüleri kullanmıyor. Buradan da yola çıkarak yazılımın dayanağı prensipler olmalıdır. Kanunları, gerçekleri rehberiniz edinmelisiniz. Bu gerçek ve kanunlar bile bazen yeterli olmayabilir, ama size yol göstereceği bir gerçektir.
Yazılım tasarımını hayallere değil gerçeklere dayandırmak dileğiyle. Hoşça kalın
Hiç yorum yok:
Yorum Gönder