Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Kodun anlaşılabilirliği için nasıl bir yol izliyorsunuz standartlarınız nedir ?
#1
Çok programcının olduğu işlerde yazılan bir kodun anlaşılabilirliği nasıl sağlıyorsunuz ? Bir yazılıma 5 yıl sonra baktığınızda bir değişkenin nerde nasıl kullanıldığını nasıl biliyorsunuz ya da yeni gelen bir yazılımcı kod yazarken kafasına göre mi ilerliyor yoksa eline verdiğiniz belli standartlarınız var mı ? Özellikle @Abdullah ILGAZ ,@Fesih ARSLAN , @Tuğrul HELVACI, @uparlayan   (Alfabetik sırayla Smile ) hocalarımın taktiklerini çok merak ediyorum.

Saygılarımla,
Topluluk mopluluk yok :/
Cevapla
#2
Ben yazılım işinde olmadığım için ekiple nasıl bir yol izleniyor detaylı bir bilgim yok.

şurdaki makale sorunun bir kısmına bir cevap olur inş.

http://www.delphican.com/delphi-de-dokum...pilir.html

Bu arada bu dökümanı hazırlayan üstad olupta " Üstad kim biz kim" diyecek kadar mütavazi Uğur abimize Teşekkür ediyorum...Çok faydası oldu bu dökümanın.
Cevapla
#3
Merhaba,
Özel sektörde bir proje grubu içerisinde bulunmadım. Bir kamu kurumunda kurumsal uygulamalar geliştirdim. 
Kisel fikrimi söyleyeyim. Benim için en büyük kriter "Nasıl Bulmak İstiyorsan Öyle Bırak." Smile
Proje bir depo gibidir. Büyük bir depoda istediğiniz ürünü elinizle koymuş gibi bulmak için ne yaparsınız?
- Tüm ürünlerin, ürün grubuna göre ayrıştırılması, benzer ürünlerin ise kendi içerisinde ayrıca kategorize edilmesi veya sıralanması gerekmektedir. Aynı zamanda depodan ürünleri çıkarmak için de iyi bir ekipmana ihtiyacınız olacaktır.
Uzun bir aradan sonra açtığınız bir projede, istediğiniz metoda en kısa zamanda ve kolay bir şekilde ulaşabiliyorsanız bana göre en ideal kodlama tekniğini kullanmışsınız demektir. 
Bu nasıl mümkün olabilir?
- Öncelikle yazılan kodun, Object Pascal kodlama standartlarına uygun olması çok önemlidir. Bileşen, sınıf, tip ve metohd isimlendirmeleri bu standartlara göre yapılmalıdır. 
Oluşturulan tüm sınıf ve tipler belli bir hiyerarşiye (kodsal disipline) sahip olmalıdır. 
Örneğin GorevTakip.Giris.Personel.AdiSoyadi veya GorevTakip.Gorev[0].Durumu
Yukarıdaki örnekte ilk tip, iş tanımını yapmakta, altındaki diğer tipler ise bu iş ile ilgili olan ve amacına göre sınıflandırılmış diğer alt tipleri göstermektedir.
Mümkünse projenin ve kodun dokümantasyonu yapılmalıdır. 
Kod içerisinde ise metod açıklamaları (summary) ve satır içi açıklamalar (comment, region vb.) mutlaka yapılmalıdır.
En önemlisi ise proje sürümlerinin her aşaması, bir SVN sistemiyle kayıt altında alınmalıdır.
While true do; Hayat döngüsü, kısır değildir! Yapılan bir yanlış, o döngünün dışına çıkmanızı sağlayacaktır.
WWW
Cevapla
#4
(05-12-2018, Saat: 08:31)boreas Adlı Kullanıcıdan Alıntı: Çok programcının olduğu işlerde yazılan bir kodun anlaşılabilirliği nasıl sağlıyorsunuz ? Bir yazılıma 5 yıl sonra baktığınızda bir değişkenin nerde nasıl kullanıldığını nasıl biliyorsunuz ya da yeni gelen bir yazılımcı kod yazarken kafasına göre mi ilerliyor yoksa eline verdiğiniz belli standartlarınız var mı ? Özellikle @Abdullah ILGAZ ,@Fesih ARSLAN , @Tuğrul HELVACI, @uparlayan   (Alfabetik sırayla Smile ) hocalarımın taktiklerini çok merak ediyorum.

Saygılarımla,

Aslında benimde çok merak ettiğim bir konu  .

(05-12-2018, Saat: 09:35)Fesih ARSLAN Adlı Kullanıcıdan Alıntı: Merhaba,
Özel sektörde bir proje grubu içerisinde bulunmadım. Bir kamu kurumunda kurumsal uygulamalar geliştirdim. 
Kisel fikrimi söyleyeyim. Benim için en büyük kriter "Nasıl Bulmak İstiyorsan Öyle Bırak." Smile
Proje bir depo gibidir. Büyük bir depoda istediğiniz ürünü elinizle koymuş gibi bulmak için ne yaparsınız?
- Tüm ürünlerin, ürün grubuna göre ayrıştırılması, benzer ürünlerin ise kendi içerisinde ayrıca kategorize edilmesi veya sıralanması gerekmektedir. Aynı zamanda depodan ürünleri çıkarmak için de iyi bir ekipmana ihtiyacınız olacaktır.
Uzun bir aradan sonra açtığınız bir projede, istediğiniz metoda en kısa zamanda ve kolay bir şekilde ulaşabiliyorsanız bana göre en ideal kodlama tekniğini kullanmışsınız demektir. 
Bu nasıl mümkün olabilir?
- Öncelikle yazılan kodun, Object Pascal kodlama standartlarına uygun olması çok önemlidir. Bileşen, sınıf, tip ve metohd isimlendirmeleri bu standartlara göre yapılmalıdır. 
Oluşturulan tüm sınıf ve tipler belli bir hiyerarşiye (kodsal disipline) sahip olmalıdır. 
Örneğin GorevTakip.Giris.Personel.AdiSoyadi veya GorevTakip.Gorev[0].Durumu
Yukarıdaki örnekte ilk tip, iş tanımını yapmakta, altındaki diğer tipler ise bu iş ile ilgili olan ve amacına göre sınıflandırılmış diğer alt tipleri göstermektedir.
Mümkünse projenin ve kodun dokümantasyonu yapılmalıdır. 
Kod içerisinde ise metod açıklamaları (summary) ve satır içi açıklamalar (comment, region vb.) mutlaka yapılmalıdır.
En önemlisi ise proje sürümlerinin her aşaması, bir SVN sistemiyle kayıt altında alınmalıdır.

Teşekkürler , çok açıklayıcı olmuş . hepsine kesinlikle katılıyorum , ama uygulama konusunda maalesef çok eksiğim. Sad
Cevapla
#5
Merhaba,

Özel sektörde "aynı standartlarda" kod yazabileceğiniz bir ekip olduğu zaman değişken, fonksiyon isimlendirmelerinden hangi fonksiyonun hangi sınıfta, datamodule'de veya pas dosyasında doğrudan implement edildiğini öğretmenize gerek kalmaz.

Aynı standartlara yükselteceğiniz yazılımcılar için ise yapmanız gereken tek şey; "empati"

@Fesih ARSLAN bey'in söylediği gibi; "nasıl bulmak istiyorsan öyle bırak" felsefesi bu alandaki en büyük yaklaşımdır. Nitekim aynı doğruyu ben de şu sözlerle söylerim hep; "bu kodu birisi bana bıraksa nasıl en çabuk anlardım?" sorusu üzerine bana soru sorabileceği tüm karmaşık noktaları yorum satırları, summary blokları ve açıklayıcı dokümanı olan proje varsa fonksiyonun ne işe yaradığını, argümanları ve return değerlerini açık açık belirtirim.

Yeni birisini mevcut projeye dahil ettiğiniz zaman birçok noktaya dependency (bağımlılık) olan kütüphanelere ilk aşamada dokunması riskli olur. Eğer yeni kişinin kodlarını birleştirdikten sonra testlerini yapacak vaktiniz veya planınız yoksa. Bu yüzden başka modüllerle ilişkisi olmayan veya en az ilişkisi olan veya en az riskli bulduğunuz modüllerde yapılacak iyileştirmeleri yada tamamen modülün geliştirilmesini devrederek başlarsınız.

Biz genellikle Database-First prensibi ile uygulama üretiyoruz. Yani database-driven application dediğimiz veritabanı uygulamalarında koda dokunacak kişinin önce veritabanına hakim olması veya en azından tablolara dair aklındaki birçok sorunun ortadan kalkması gerekir. Bu da projenin içindeki etkisine doğrudan katkısını etkileyen bir unsur. Öncelikle neyi kodlayacağını bilmeli.

OOP yaklaşımında üreteceğiniz projelerde DB-First prensibinden ötürü tüm tablolar, viewler, stored prosedürler için varlıklar tanımlanır. Böylelikle ihtiyaç doğrutulsunda neye ne zaman ne şekilde ihtiyacının olacağını da kestirebilir.

Tam bu noktada çok katmanlı yapılar ortaya çıkıyor. Design Pattern (tasarım deseni) kavramı, yazılımınızın ihtiyaçlarını tespit ettikten sonra çıkartacağınız şablonu belirlemenizi kolaylaştırır. Belirleyeceğiniz şablona göre katmanlar ve neyi nerede tutacağınızı belirlersiniz. Örn: veritabanına erişim sadece Data Access Layer için mümkün olmalı. Uygulama içinde herhangi bir yerde bir (select-insert-update-delete) vt işlemi olursa işlemi yönetecek sınıf kesinlikle ilgili tablonun (veya varlığın) data access sınıfı olmalıdır. Bu sınıftan alınan ham veriyi taşıyan, try catch ve kontrollerden geçiren bir iş katmanı Business Logic Layer olmalı. Presentation (sunum) katmanı ise soyut olarak business katmanından beslenmeli. Böylelikle uygulamadaki veri akışının temel bir mantığı oluşur.

Bu kadar şeyi neden anlattım? Oluşturacağınız disiplin, prensip, kavram, şablon, tasarım, desen, veya ne demek isterseniz, sizin belirlediğiniz standartları kendisi oluşturur. Yeni birisine en azından girip mevcut bir modül için tüm yapıyı görmesi, kısa sürede sizin stilinize ayak uydurmasını sağlayacaktır.

50+ satırlık kod blokları olduğu yerde kesinlikle region kullanırım. Bazen bazı fonksiyonlarda 5 satır kod bile olsa region kullanırım. Bir projede assembly kütüphanesinin topladığı bir veriyi işleme ve manipülasyon işlemleri için 3 satırı region yapmışlığım vardır. Bunun sebebi kodun okunurluğunu arttırmaktır.

"İyi/temiz bir kod, başka geliştirici/ler tarafından rahatlıkla okunabilen ve geliştirilebilen koddur."
Cevapla
#6
Kodlarda ve prosedür isimlerinde "Button1", "Edit1" kullanılmaz.

Fonksiyon isimlerini de her zaman Türkçe adlandırırım.
Böylelikle o kısmın üçüncü parti değil, kendi yazım olduğu bellidir.

Ayrıca yardımcı fonksiyonları ana koddan ayrı tutarım.
Çok genel fonksiyonlar ise başka sabit bir dizinde durur.

Kodun kolay okunması şarttır. Tüm kodları birkaç sene sonraki kendim için yazarım.
Cevapla
#7
Object Pascal http://edn.embarcadero.com/article/10280
Java https://www.oracle.com/technetwork/java/...150003.pdf
Python https://www.python.org/dev/peps/pep-0008/
ben buralara bakıyorum başka diller içinde google'da arama yapabilirsiniz örnek "c++ code conventions"

“Do. Or do not. There is no try.”
Cevapla
#8
Sıradan her programcı bilgisayarın anlayabileceği kodlar yazabilir.
Sadece iyi programcılar insanların da anlayabileceği kodlar yazarlar.

Martin Fowler (http://martinfowler.com/)


Eğer kodunuza açıklamalar yazma ihtiyacınız varsa kötü giden birşeyler var demektir. Kodunuzu yeniden yapılandırın.
WWW
Cevapla
#9
Pascal / Delphi kullanımı kapsamında bir ekipte yer alma fırsatım olmadı (olsa harika olur, birbirimize çok şey katarız), daha çok elektronikçilerle yan yana çalıştım fakat ekipte çalışma düsturuna yabancı da değilim. Şöyle izah etmeye çalışayım;

Ekip olarak çalışılacaksa ilk şart ekibin aynı dili konuşuyor, "aynı kavramlarla" fikir alışverişimde bulunuyor olması gerekir. Yani birisi kendisini veya derdini ifade ederken karşısındaki adamın algı parametreleriyle ona izah edemiyorsa zaten bunların iletişim kurmalarının pek bir olanağı yok. O nedenle önce ekiptekilerin birbiriyle "kavram bazında" aynı dili konuşması şart, eksik kalan bir ekip üyesi varsa oturulur, o arkadaş "o ekip tarafından" eğitilir.

Bu durum geçmişteki siz ile şimdiki benliğiniz arasında da geçerli. Dünkü insan değilsiniz. Her gün yeni bir şeyler öğreniyoruz, kendimizi geliştiriyoruz ve 3-5 ay sonra eski kodlarımıza baktığımızda "bu kodu ben mi yazdım" diye soruyoruz. Maalesef, bu soruyu kendime çok sormuşumdur. Oturup kendimle bu konuda nasıl baş edebilirim diye hayıflandığım çok oldu...

"Kendime karşı" aldığım önlemleri şöyle sıralayabilirim;
  • Konu karmaşıksa Akış Diyagramları kullanıyorum. Bunu sadece kendim için bile olsa mutlaka yaparım.
  • Etkileşim karmaşıksa Durum Diyagramları kullan. Bu da öyle...
  • Kalıpların dışına çıkmamaya çalışırım. Çıkacaksam bunu bir şablon halinde duvara asar veya çıktısını alıp kolay ulaşabileceğim bir yerde dosyalarım.
  • Her ne yazıyorsam adını düzgün koymaya özen gösteririm. Yani amaca yönelik, kısa ve öz isimlendirme yaparım, ileride o fonksiyonu veya değişkeni yeniden gördüğümde "bu neydi" diye kendime veya bir başkasına sormama gerek kalmaz.
  • Biz program yazmıyoruz arkadaşlar. Biz bir çözümün hikayesini / çözüm senaryosunu yazıyoruz. O nedenle yazdığımız kodlarda, metodlarda, değişkenlerde isimlendirme yaparken bunu kulak arkası yapmamamız lazım. 
  • Solid prensiplerini uygulamaya dikkat ediyorum, çünkü insanı ve projeyi gerçekten disipline ediyor ve sizi belli bir rotaya sokuyor.
Peyami Safa:"Yaşlanarak değil, yaşayarak tecrübe kazanılır. Zaman insanları değil, armutları olgunlaştırır"
Can Yücel:"Toprak gibi olmalısın! Ezildikçe sertleşmelisin! Seni ezenler sana muhtaç kalmalı! Hayatı sende bulmalı"
Sinan Canan:"Bildiğini zannettiğin an hiç bir şey öğrenemezsin"
WWW
Cevapla
#10
(05-12-2018, Saat: 15:50)uparlayan Adlı Kullanıcıdan Alıntı: Pascal / Delphi kullanımı kapsamında bir ekipte yer alma fırsatım olmadı (olsa harika olur, birbirimize çok şey katarız), daha çok elektronikçilerle yan yana çalıştım fakat ekipte çalışma düsturuna yabancı da değilim. Şöyle izah etmeye çalışayım;

Ekip olarak çalışılacaksa ilk şart ekibin aynı dili konuşuyor, "aynı kavramlarla" fikir alışverişimde bulunuyor olması gerekir. Yani birisi kendisini veya derdini ifade ederken karşısındaki adamın algı parametreleriyle ona izah edemiyorsa zaten bunların iletişim kurmalarının pek bir olanağı yok. O nedenle önce ekiptekilerin birbiriyle "kavram bazında" aynı dili konuşması şart, eksik kalan bir ekip üyesi varsa oturulur, o arkadaş "o ekip tarafından" eğitilir.

Bu durum geçmişteki siz ile şimdiki benliğiniz arasında da geçerli. Dünkü insan değilsiniz. Her gün yeni bir şeyler öğreniyoruz, kendimizi geliştiriyoruz ve 3-5 ay sonra eski kodlarımıza baktığımızda "bu kodu ben mi yazdım" diye soruyoruz. Maalesef, bu soruyu kendime çok sormuşumdur. Oturup kendimle bu konuda nasıl baş edebilirim diye hayıflandığım çok oldu...

"Kendime karşı" aldığım önlemleri şöyle sıralayabilirim;
  • Konu karmaşıksa Akış Diyagramları kullanıyorum. Bunu sadece kendim için bile olsa mutlaka yaparım.
  • Etkileşim karmaşıksa Durum Diyagramları kullan. Bu da öyle...
  • Kalıpların dışına çıkmamaya çalışırım. Çıkacaksam bunu bir şablon halinde duvara asar veya çıktısını alıp kolay ulaşabileceğim bir yerde dosyalarım.
  • Her ne yazıyorsam adını düzgün koymaya özen gösteririm. Yani amaca yönelik, kısa ve öz isimlendirme yaparım, ileride o fonksiyonu veya değişkeni yeniden gördüğümde "bu neydi" diye kendime veya bir başkasına sormama gerek kalmaz.
  • Biz program yazmıyoruz arkadaşlar. Biz bir çözümün hikayesini / çözüm senaryosunu yazıyoruz. O nedenle yazdığımız kodlarda, metodlarda, değişkenlerde isimlendirme yaparken bunu kulak arkası yapmamamız lazım. 
  • Solid prensiplerini uygulamaya dikkat ediyorum, çünkü insanı ve projeyi gerçekten disipline ediyor ve sizi belli bir rotaya sokuyor.

Solid prensiplerini uygulamaya dikkat ediyorum, çünkü insanı ve projeyi gerçekten disipline ediyor ve sizi belli bir rotaya sokuyor.

Sayın uparlayan beyin izniyle  birkaç gündür  http://aliozgur.net/2018/03/02/solid/    adresindeki kuralları öğrenmeye çalışıyorum.
İnşaallah faydalı olur.
"…De ki: "Hiç bilenlerle bilmeyenler bir olur mu? Şüphesiz, temiz akıl sahipleri öğüt alıp-düşünürler" (Zümer Suresi, 9)
Cevapla


Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
  [Çözüldü] - Google Cloud Platformunda OAuth 2.0 ile Dinamik Token Nasıl Alınır? Fesih ARSLAN 14 577 21-05-2019, Saat: 13:11
Son Yorum: Bay_Y
  ORM için öneri OBK 4 223 25-04-2019, Saat: 16:43
Son Yorum: kodamelesi
  Bir query'i birden fazla yerde nasıl kullanırım ? boreas 4 131 24-04-2019, Saat: 12:27
Son Yorum: Abdullah ILGAZ
  Windows Oturumu Açılmadan Program Nasıl Çalışır theSinan 15 970 15-04-2019, Saat: 00:15
Son Yorum: theSinan
  StatusBar nasıl resim ekliyebilirim? burak 6 335 12-04-2019, Saat: 18:55
Son Yorum: SimaWB



Konuyu Okuyanlar: 1 Ziyaretçi