Genel olarak okunduğunda evet güzel bir yazı.Ama biraz detaylıca deşince belirli noktaların gözden kaçmış olduğu gözüküyor.Özellikle benim gözüme takılan iki nokta var.
Birincisi Agile ve XP mantığında yatıyor.Orta ve küçük ölçekli projeler için evet güzel olmakla beraber projenin büyümesi halinde iletişim kopuklukları gelişim sürecini oldukça sekteye uğratıyor.Heleki testerlar ile developerlar arasında iş arkadaşlığının ötesinde bir uyum varsa işler sarpa sarıyor.1 senelik olarak öngörülen bir genelkurmay projesinin bu iletişim bozukluğu ve testerların yayvanlıkları sayesinde nasıl 1.5 seneye uzadığına ve hala bitmemiş olduğuna adım adım şahit olduk. Ha evet müşteriyi de projeye dahil ettiğiniz için durumu müşteriye açıklaması daha kolay oluyor fakat sonuç olarak projenin hesaplana(maya)n bitiş süresini 1.5 kat aştığı ve hala bitmemiş olduğu gerçeğini değiştirmiyor.-Proje en son ne durumdaydı bilmiyorum- Ayrıca eğer kesin müşteriniz yoksa yani yazılımınız "generic" bir yazılım ise süreç zaten külliyen sekteye uğruyor.Heleki çevik programlama yöntemlerinde yükün bindiği "tester"lar işlerini düzgün yapmıyorlarsa sonuç eşimin e-posta adresine gelen başkasına ait e-fatura oluyor (: Keza anladığım kadarıyla arkadaş tek kişi.Pair programming ile işini halledişi gözümün önüne geldi bir an (((: Sonuç olarak agile tekniklerin işe yararlığı kanıtlanmış olmakla beraber fazla abartıldığını düşünüyorum.Heleki yumurta kapıya dayanınca birşeyler yapmaya alışmış bir millet için... İkinci bir şey ise kod içi ve dışı dökümantasyonla ilgili.Çoğu kişi öyle yada böyle yaz*ma*makla beraber kesinlikle yazılması gerektiğini düşünüyorum.Kodun satır sayısı kallavi boyuta ulaştığı -veya bazen ulaşmadığı- zaman hiçbir kodun kendini açıklayabileceğini düşünmüyorum. Özellikle nesne yönelimli programlamanın dışına çıktığınız zaman.Çinli bir firmaya sağladıkları m68k işlemcili bir cihazla beraber verdikleri api'nin rezalet ve eksik dökümantasyonu yüzünden 6 ay boyunca dümdüz saydırdığımı iyi bilirim.Verdikleri C kütüphaneleri hiç de öyle kendini açıklamıyordu-Fakat ilginç bir şekilde yazdıkları kodun kalitesi oldukça iyiydi -. (: Sonuç olarak: *"Yeterince şey söylenmiş. Dökümantasyon baştan olmalı. UML filan. Ama bu biraz hayal. Bu sadece bir ütopya.*" Sadece size denk gelmemiş... İyi çalışmalar. 2 Ocak 2012 18:59 tarihinde Serdar KÖYLÜ <[email protected]> yazdı: > 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 >
_______________________________________________ Linux-programlama mailing list [email protected] https://liste.linux.org.tr/mailman/listinfo/linux-programlama Liste kurallari: http://liste.linux.org.tr/kurallar.php
