Yeterince şey söylenmiş. Dökümantasyon baştan olmalı. UML filan. Ama bu biraz hayal. Bu sadece bir ütopya. Bu belki kodların bir kaç kişiyle, ahanda şu yapılacak diye yazıldığı günlerde anlamlı olabilirdi.
Yazılım işini doğası farklı. baştan bir proje önünüze gelmiyor. genellikle projeler, bir yandan yapılırken, diğer yandan genişletiliyor. Yani, ne geveliyorum? Toplam Kalite Yönetiminde, genel düstur, amerikan modelimsi bir şey. Tam olarak öyle diyemeyiz ama kabaca. Sadece bir ad koyabilmek için. Bu durumda süreçler vardır, bu süreçler devamlı geribeslemelerle iyileştirilir ve ortaya bir ürün çıkar. İyileştirme işlemi de ürün maliyet ve kalitesini iyileştirir, en azından söylev bu yöndedir. Şimdi böyle bir süreçte, yazılım gibi bir ürün üretilirse ne olur? Basitçe, olmaz. Çünkü aslında yazılımın oturacağı yer, müşteride bir sürecin kendisidir. Bu da yazılımın sürekli geri beslemelerle daha iyi bir süreç olmasını gerektirir. Pek çok iş bilmeyi kağıttan okununca oluyor sanan, bu noktayı kaçırır. Ve işte böyle baştan dökümantasyon, sonradan dökümantasyon gibi sihirli değnekler arar. Ama yazılım aleminde gümüş kurşunlar yoktur (bkz: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html ) Peki ne olur? Uzatmayayım, bu nedenle japon modeline benzer tky yöntemleri yazılım için öngörülmüştür, geniş çapta. En iyi bilineni ise, CMMI mevzusudur. İşi CMMI'a uydurmak, ki bu dökümantasyon gibi sorunları da aşabilmek için CMMI gayet iyidir, başka bir dert olmaktadır. Ama bunların orta yolu yazılımı evrimsel bir süreç gibi yazmak olmuştur. işte Adaptive Development ve bilhassa Extreme Programming bu noktada öne çıkar ve bu yükü hafifletir. Fakat, CMMI'da bir gümüş kurşun değildir ve sertifikasyon derdiniz yoksa, size bir sürü iş çıkarır. Peki o zaman ne yapmak gerekir? Aslında yapılacak şey bellidir. CMMI gibi şeylerin yüküne girmeden, işi kotarmak. Bunun da yolu, kodu dökümana ihtiyaç duymayacak, duysa bile çok temel bir kaç kağıtta olayı çözecek şekilde yazmaktır. Ha, CMMI gibi işleri boşverin demek değil bu. Eğer kaynak sorununuz varsa, dur bir dökümantasyon yapayım önce, bitti bir dökümantasyon yazayım moduna girmemektir aslolan. Bunu sürecin bir parçası olarak görmek ve zaten bir yazı olan kodu, okunur, anlaşılır düzgün şekilde yazmak, layer ve partisyonları somutlaştırmak gibi şeyler yapmaktır. Burada yapılan bir hata, doxygen gibi şeylerle avunmaktır. Bunlar iyi midir? Hiç sanmam. Ben doxygen çıktılarının hiç bir yaraya merhem olduğunu görmüyorum, kullandığım api'lerde. Yani ne demek istiyorum? Kodu öyle yazın ki, // veya /* */ bloklarına ihtiyacınız olmasın. Kod kendini açıklasın. Bu işin pratik yolu budur. Buna ilave bir kaç sayfalık text, sizin sorununuzu gidermeye yeter. O da süreç içinde zaten kendisi ortaya çıkar. Ama projedeki adam sayısı artıyorsa, 3 kişi dahi olsa, büyük bir projeyse, artık CMMI gibi bir şeye geçmek, çok daha akıllıca olacaktır. Sertifikasyona gerek yok, ama iyidir. Sadece o mekanizmaları uygulamak ve bir sisteme sahip olmak, çok şeyi değiştirir. 2011/12/12 Mehmet Özgür Bayhan <[email protected]>: > UML notasyonları aradığınız.Yalnız burada önemli olan yazdığınızı notasyona > dökmek değil.İşin mühendislik kısmı burada başlıyor zaten.Programcı ile > mühendisin ayrıldığı yerlerden bir tanesi.Tasarımınıza göre kod > yazmalısınız.Kodunuza göre tasarım desenleri değil (: > > 12 Aralık 2011 17:36 tarihinde Nuri AKMAN <[email protected]> yazdı: >> >> Arkadaşlar, >> >> Program yazıyorum ve üzerinden zaman geçtiğinde neyin ne olduğunu ve nasıl >> çalıştığını unutuyorum... >> >> Kod içinde bir çok açıklama yazıyorum, değişken adlarımı açık ve anlaşılır >> veriyorum. Böylece kodu okuyarak hafızamı canlandırıyorum. >> >> Ancak, bu durum hoşuma gitmiyor. Zaman zaman bir kullanıcı 3 yıl önce >> yazdığım bir ekranda "Şu hesap da bu rakama dahil mi?" diye sorduğu zaman >> tek tek incelemek zorunda kalıyorum herşeyi.... >> >> Durum böyle olunca, program çalışma mantığının dokümante edilmesi fikri >> oluştu aklımda: Bu ekrana girildiğinde önce şu fonksiyon çağrılır, sonra >> şu, şunu kontrol eder vs.vs.vs. Yani, programın çalışması sırasında yaptığı >> her şeyi FlowChart tarzı bir şekilde dokümante etmeyi düşünüyorum. >> >> FlowChart yeteneğinde bir programla bu iş yapılabilir, ancak programın >> kalbini/ana ekranını böyle tarif etmek çok uzun sürer ve takibi zor >> olabilir. >> >> Acaba bu konuda tavsiye edeceğiniz bir program/metod var mı? >> >> Selamlar, >> Nuri Akman >> >> >> _______________________________________________ >> Linux-programlama mailing list >> [email protected] >> https://liste.linux.org.tr/mailman/listinfo/linux-programlama >> Liste kurallari: http://liste.linux.org.tr/kurallar.php >> > > > _______________________________________________ > Linux-programlama mailing list > [email protected] > https://liste.linux.org.tr/mailman/listinfo/linux-programlama > Liste kurallari: http://liste.linux.org.tr/kurallar.php > _______________________________________________ Linux-programlama mailing list [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
