Merhaba, Çevik süreçler ve dokümantasyon kelimeleri geçtiği için bir linkte ben paylaşmak istedim.
http://37signals.com/svn/posts/838-ask-37signals-how-do-you-document-code Kolaylıklar. 2012/1/2 Serdar KÖYLÜ <[email protected]> > 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 > -- *Onur Özgür ÖZKAN* ***lab2023 - internet teknolojileri* www.lab2023.com
_______________________________________________ Linux-programlama mailing list [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
