Büyük projelerin kod organizasyonu, idaresi ve başa çıkılması [php]

[Brigand]

Selamlar;

Büyük projeler bildiğiniz gibi kodları arttıkça idaresi zorlaşır karmaşıklaşır.

Böyle olunca sistemi büyütmek zorlaşır. Object Oriented kodlama ile bu biraz çözülür ama object oriented olarak çok düzenli kodlama olmadan yine kod karmaşası muhakkak developerların canını sıkar.

Örneğin benim şu ana kadar gördüğüm en düzenli PHP projesi IPB'dir (invision power board).

Ben kendi bir projeme kodların en düzenli ve geliştirilmeye en yatkın olması için yeniden düzenleme yapmak istiyorum. Gerekirse tüm dosyaları tekrar düzenlemek istiyorum ama izlenecek en iyi çözüme karar veremiyorum.

Mesela site modullere bölünebilir, Php-Nuke sitelerinde görmüşsünüzde modules.php?name=forums, modules.php?name=accounts gibi, ama çok basit olarak yapılmış, direk forums.php gibi dosyaları include ediyor.

IPB biraz daha gelişmiş, her modül object oriented olarak kodlanmış ve hepsi birbiri ile mükemmel uyumlu olarak dizayn edilmiş. Ayrıca IPB'nin bir ana classı bulunmakta ve bütün diğer classlar bu class üzerinden database veya session gibi işlemleri gerçekleştirmekte.

Burada belirttiğim gibi büyük sistemler için, php ile nasıl bir organize sistemi tercih edilmeli? Bu işlemin birçok varyasyonu vardır; ama onlarca değil yüzlerce sayfa olabilecek bir durum var ve organizasyon işlemi mükemmel olmalı yoksa işler gittikçe zorlaşır.

Her sayfanın;
1) her sayfanın otomatik çalıştırılacak php kodu
2) içinde form varsa (ki genelde var) get veya post ile veri işleyecek ikinci bir kod
4) o sayfada kullanılacak gerekli classlar, functionlar vs...
5) her sayfada kullanılan classlar, functionlar vs...
6) javascript kodları
7) tema html dosyaları

8) Aynı classları, functionları kullanan ayrı session ve ayrı html dosyaları ile admin panel ve dosyaları

Büyük bir projeyi en düzenli, güzel geliştirilebilir ve en rahat şekilde nasıl organize etmeli? Neleri klasörlemeli, sayfaları object-oriented olarak tüm sistemle nasıl senkronize etmeli? gibi sorular aklımda...

Bu konuda tutorial varmıdır? Video tutorial varmıdır? Ebook varmıdır? Sizin fikirleriniz, önerileriniz, çözümleriniz varmıdır?

[Mum_Chamber]

bu sorunu çözmenin yollarından biri event kullanmaktır. temel kodu yazarsın, sonradan eklemek istediğin herşeyi eventler sayesinde modül olarak eklersin, herşey süper organize kalır.

phorum o konuda çok başarılı bence bir incele

[senko]

Brigand said:

Büyük bir projeyi en düzenli, güzel geliştirilebilir ve en rahat şekilde nasıl organize etmeli?

ehehe bu sorulara yanıt verebilmek için yazılım mühendisliği okuyon zaten :)

[Brigand]

Bekleyemicem bikaç yıl daha Selçuk kaynak olsun ebook filan ne olursa boş durmıyım finaller bitiyor haftaya :)

[Brigand]

Mum_Chamber said:

bu sorunu çözmenin yollarından biri event kullanmaktır. temel kodu yazarsın, sonradan eklemek istediğin herşeyi eventler sayesinde modül olarak eklersin, herşey süper organize kalır.

phorum o konuda çok başarılı bence bir incele

Bu konuda hiç dökümantasyon yokmudur mum, tek çaremiz yapılmış open source projeleri incelemek midir ki?

[elesso]

kodlarını anlaşılmaz yapki firma senin kıymetini bilsin hehe.

[Mum_Chamber]

dokumantasyonu muhakkak vardır, ben zor yolla öğrendim, o yüzden hala onun eksikliğini çekiyorum. kaliteli birşeyler bulup da paylaşan olursa da çok makbule geçer.

[elesso]

projenin kilit adamı olmak istemiyorum diyosunuz ha

[di]

bkz : design pattern.

Dunyayi yeniden kesfetmeye gerek yok bu tip konularda. Bir kac basarili framework incelerseniz -ki favorilerimden biri code igniter'dir- gercekten guzel ve duzenli yapilar kullandiklarini gorebilirsiniz.

MVC'nin etkisi de buyuk bu konuda.

Ben CI'dan etkilenip kendi yapimi cikardim ve hemen her turlu projede kullanabilecegim hos bir yapi cikti.

O sebeple derim ki Code Igniter ve Zend Framework'u bir incele. Aradigini tek seferde bulursun bence.

[Brigand]

Yaw onlar da aşırı gelişmiş di çok karmaşık sistemler gibime geliyor sanki. en azından kullanımları öyle, kodlarını açıp incelememiştim tabi. Ne bileyim php biliyosan bi php'nin yarısı kadar bişe daha öğrenmen gerekiyor onları kullanman için, ben böyle düşünüyorum yani zamanında yaptığım küçük bir inceleme ile, yanlış olabilir.

[di]

Iste o sebeple, baska bir konuda da dedigim gibi; RTFM

=)

[Brigand]

Bak şimdi baktım, birçok şey gözüme çarptı hemen örnek vereyim

echo $this->input->ip_address();

Şimdi neden böyle bir fonksiyon koyarlar ki? zaten $_SERVER['REMOTE_ADDR'] ile erişiyorsun gelen user'ın ipsine. Tamamen kod kalabalığı ve gereksizlik :)

Aslında benim hazır bir framework kullanmak yerine kendi sistemimi geliştştirmek istememin nedeni de bu :)

Neyse sağolasın adam gibi okuyayım onu inceleyim, bir de http://www.phparch.com/c/books/id/0973589825 bu kitaba bakayım, sanırım güzel birşeyler olur :)

Çok teşekkürler, başta di olarak herkese :)

Başka fikirleri olanları da dinlemekten mutluluk duyarım tabi :)

[Mum_Chamber]

yeri gelmişken, MVC olayına ben katılmıyorum. daha doğrusu, "mvc her zaman en iyi çözümdür" önergesine katılmıyorum. mvc olayı son dönemin "hype"larından biri. yoksa yıllardır database abstraction layer ve template engine'ler kullanılıyor. eğer amaç bunların kullanımını desteklemekse, hep destek, tam destek. yoksa ille mvc olacak diye birşey yok.

[Brigand]

Niye ki yaw

Ayrıca MVC sadece fonksiyonları ve objeleri model, view ve controler altında gruplandırmaktan başka birşey değil değil mi? Yanlış mı biliyorum yoksa?

[Pluton]

Ben bu sorunun cevabını uzun süredir arıyorum ve hala net bir cevap bulabilmiş değilim. mesela bende vBulletin'in dizaynını çok beğeniyorum. Ama ne kadar incelesemde hep biyerlerde bi bozukluk oluyor. Şimdilerde kendi tarzımla yapmaya başladım. Daha doğrusu bana nasıl kolay görünüyorsa öyle kodluyorum.

[riglous]

Brigand said:

Bak şimdi baktım, birçok şey gözüme çarptı hemen örnek vereyim

echo $this->input->ip_address();

Şimdi neden böyle bir fonksiyon koyarlar ki? zaten $_SERVER['REMOTE_ADDR'] ile erişiyorsun gelen user'ın ipsine. Tamamen kod kalabalığı ve gereksizlik :)

Aslında benim hazır bir framework kullanmak yerine kendi sistemimi geliştştirmek istememin nedeni de bu :)

Neyse sağolasın adam gibi okuyayım onu inceleyim, bir de http://www.phparch.com/c/books/id/0973589825 bu kitaba bakayım, sanırım güzel birşeyler olur :)

Çok teşekkürler, başta di olarak herkese :)

Başka fikirleri olanları da dinlemekten mutluluk duyarım tabi :)

Iyide o duzeni sagliyor zaten. Gerekli fonksiyonlari bir arada gruplamak ve daha sonra bunlari, okuyucu icin anlamli bir dilde yazmak amac. Baktiginda hmm bu neydi denmemesi gerekiyor. Ben $_SERVER['REMOTE_ADDR']'i gorursem, bu neydi diye acar google'da bakarim, 15 saniye icinde ogrenirim. Ama "echo $this->input->ip_address();" bunu gorursem, google'a gitmeme gerek kalmaz. Sen bu gun sadece PHP kullandigin icin, daima $_SERVER['REMOTE_ADDR']'in ne getirdigini hatirlayabilecegini dusunuyorsun. Ama isin icine birbiriyle alakasiz, bir suru dil girince, onu hatirlamayacaksin bile.
Program yazarken sadece deger donduren basit fonksiyonlar yazilir daima. Debug eden tecrubesiz kisiler genelde cok laf eder boyle islere, her bir fonksiyon bir baskasina yonlendirdigi icin. Amma velakin o kodu asil kullanacak kisi icin cok daha kolaydir ve aslinda o is sayesinde proje debug edilebilir bir hal alir. Yoksa her kodu main()'in altina yazaraktan sayfalarca kod olusturulabilir.
Daha once de dendigi gibi yazilim muhendisliginin konusu bunlar. Dikkat edilmesi gereken 3 5 nokta var. Ondan daha ayrintisini dersini alip gormen gerek.
- Daima ayni pattern'da yaz. Mesela
if () {
}
diye yaziyorsan, daha sonra
if()
{
}
diye yazma (Genel olan ilk yazdigimdir. JS'de ilkini kullanmak zorundasin mesela).
- Zincir seklinde ilerleme. Programi yoneten main() olsun. O da spesifik fonksiyonlari calistirmasin. Bunun icin bizim yeni baslayanlara onerimiz pseudo kod yazmak ve daha sonra yazilacak fonksiyonlara benzer isimler vererek amaclarini belirtmek. Bu yorum ekleme, aciklama kisminda da cok yardimci oluyor.
- Proje daima kagit ve kalemle baslar. Kagida yazmak cok uzun suruyor, ben hemencecik programi yaparim dersen o is olmaz. Bu, genelde yerine oturmamis taslari gozardi etmek icin soylenir, ama insan kendi kendisine de itiraf edemez. Bu yanilgiya dusme. Eger yazip cizemiyorsan proje tam oturmamistir. Pasalar gibi yazip cizersen hem ileride dusunmen gerekenleri simdiden dusunmus olursun.
- Her projenin girisi, gelismesi, sonucu vardir. Giriste iskeleti kurup ayaga kaldirirsin. Sonra olmasi gereken ozellikleri eklersin. Daha sonra da kullanima hazir hale getirirsin. Bunun disinda bir de programlama sirasi vardir. Onda da once sorunu belirtmen gerekir. Daha sonra muhtemel cozumleri sunarsin. Bu cozumlerin arasindan, istenen ise gore en uygununu secersin (bazen en kapsamli en uygundur, bazen en hizli yazilabilen en uygundur). Sonra tasarlarsin. Anca bundan sonra programi yazip hatalari degerlendirmeye baslarsin. Sonra surekli hatalari duzelterek tekrar test etmen gerekir. Yukaridaki baslikta soyledigim gibi kod yazma kismi isin 1/5'idir aslinda.
- Daima, daima, daima kod yazarken yorum ekle. Neyin ne icin yapildigini yaz. Debug asamasinda cok rahat olacaktir. Asla, "ben bunu hatirlarim nasilsa, cok net yahu" deme. Aradan 5 sene gectikten sonra basit bir return'u bile algilayamayacagin zaman olur (ensende 10 kisi sorunumuzu coz! diye paniklerken, senin ne yaptigini biliyor gozukmen gerek).

Moduller halinde projeyi olusturmakla her bir modul icin bir class olusturmak arasinda pek bir fark yok. Onemli olan her bir modulun kendi icinde tutarli olmasi.

PHP ya da baska bir dil icin bu degismez. Ha class kullanimi vs. sadece dilin tipine gore degisir (3 tip dil vardir, programlama dilleri CS2XX). Ama bu senin programlama aliskanliklarini degistirmez.

Son olarak da madem bir proje, o zaman dogru duzgun backup alarak ilerlemek gerekir. Bunun icin de svn kullanmak iyi bir cozum olur.

[bonesoul]

di said:

bkz : design pattern.

Dunyayi yeniden kesfetmeye gerek yok bu tip konularda. Bir kac basarili framework incelerseniz -ki favorilerimden biri code igniter'dir- gercekten guzel ve duzenli yapilar kullandiklarini gorebilirsiniz.

MVC'nin etkisi de buyuk bu konuda.

Ben CI'dan etkilenip kendi yapimi cikardim ve hemen her turlu projede kullanabilecegim hos bir yapi cikti.

O sebeple derim ki Code Igniter ve Zend Framework'u bir incele. Aradigini tek seferde bulursun bence.

tam bende mvc diyecektim, CI baya bir sure kullandım sonra CI fork olan kohana ya gectim. herkesede tavsiye ederim.

[Ractamainus]

rig; $_SERVER['REMOTE_ADDR'] bilinmiyorsa, ip_address() metoduyla karşılaşıldığında ve içeriğine bakıldığında, yine googlanması gerekir =)

php'den zerre anlamam ama oop mantığında bakarsak, oradaki sorunun cevabı ip_address metodunun dahil olduğu class'da gizli aslında. çünkü o nesne, belirli bir mantık dahilinde iş yapmakla yükümlü. ip almak da bu mantığa uyuyorsa, orada olması faydalıdır bir kere.. çünkü o nesneyi kullanan adam, onun eksikliğini hissedebilir (tekerleği olmayan arabayı kullanmaya çalışmak gibi bir örnek veresim geldi). tabii bir de ortam şartları değişebilir. sadece ip almak yetmeyebilir vs.. o zaman tüm proje üzerinde $_SERVER['REMOTE_ADDR'] bulmak yerine, tek bir class'da değişiklik yapmak yeter. code maintainability böyle bir şey..

ama şu unutulmamalı brigand; oop bilmek, bir nevi bir romanın alt yapısının nasıl olması gerektiğini bilmek gibi bir şeydir. yani şurda herkes bir roman yazmaya kalksa, giriş-gelişme-sonuç sıralamasını bildiğinden, buna uyar. dilbilgisi kurallarına da hakimiz (syntax). lakin bu iyi roman yazacağız anlamına gelmez değil mi? oluşturduğun class'ların, görevlerine bire bir uyması ve başkalarına konfor sağlaması, programcının yeteneğiyle ilgili biraz da.. bu ezberlenecek bir bilgi değil kanımca.

code convention konusu da çok önemli kesinlikle. en azından benim çok dikkat etmeye çalıştığım bir konudur ama ben o konuda da rig gibi düşünmüyorum (çok muhalif gibi oldum). misal eskiden hep
if ()
{
}
diye kullanırdım.
bir süre sonra çok rahatsız oldum. çünkü tek satırlık if sorguları oluyordu alt alta bir iki tane.. ve sayfanın çok fazla aşağı kaymasına sebep oluyordu (süslü parantezlerden dolayı). bu da kodu okuyanın ilk bakışta, kodun alt tarafındakileri görmemesine sebep oluyordu.
sonra yeri gelince
if ()
{
}
yeri gelince
if ()
//...
diye kullanmaya başladım if sorgusunu. her zaman aynı biçimde değil ama kodu okuyanı şaşırtmayacak kadar düz.

burda şunu önemle belirtmek isterim. kodu yazarken, syntax'ını bilmeyen bir adamı göz önünde bulundurmaya çalışmak anlamsızca. misal süslü parantezin kullanılabileceğini bilmeyen bir adam varsa, kodu yazan adam bunu düşünemez. düşünmemeli de.

sonra mvc konusuna gelince. müm'e katılıyorum. her proje mvc için uygun ortam olmak zorunda değil.

bence projeden projeye, standartlar değişebilir. önemli olan proje içinde standartların tek ve o projeye uygun olmasıdır.

biliyorum, çok soyut yazdım çünkü php dünyasına uzağım. konu çok ilgilendiğim bir konu ama php üzerine yanlış yazabilirdim.

[di]

Cok basit bir ornek vereyim -kahvaltiya kacicam da =P.

$_SERVER['REMOTE_ADDR'] bazi ozel durumlarda isinize yaramayabilir. Yine de ek satirlarla bu durumu handle edebilirsiniz.

Lakin butun bu durum icin her seferinde bir kac satir yazmak yerine neden ip_address diye bir fonksiyonunuz olmasin ?

Adamlar bu sekilde yaptilarsa vardir bi bildikleri. Acip ip_address neymis ne iceriyormus diye bir bakmak lazim. En koturu riglous'un dedigi okunabilirlik olayi var.

edit : yanlis yazmisim bi yeri.

[armagan]

Mum_Chamber said:

yeri gelmişken, MVC olayına ben katılmıyorum. daha doğrusu, "mvc her zaman en iyi çözümdür" önergesine katılmıyorum. mvc olayı son dönemin "hype"larından biri. yoksa yıllardır database abstraction layer ve template engine'ler kullanılıyor. eğer amaç bunların kullanımını desteklemekse, hep destek, tam destek. yoksa ille mvc olacak diye birşey yok.

mvc uzun zamandır var. wikipedia'ya baktım da 1979'da çıkmış. 5 yıl önce filan bir php projesinde kullanmıştık, güzeldi ancak hazır mvc framework kullanmıştık oturup mvc alt yapısı kodlamak kastırıcı iş.

büyük bir projeyi kolay idare etmenin en güzel yani modüler yapı. elden geldiğince ufak parçalara bölmek.

[Kojiroh]

Ractamainus said:

ama şu unutulmamalı brigand; oop bilmek, bir nevi bir romanın alt yapısının nasıl olması gerektiğini bilmek gibi bir şeydir. yani şurda herkes bir roman yazmaya kalksa, giriş-gelişme-sonuç sıralamasını bildiğinden, buna uyar. dilbilgisi kurallarına da hakimiz (syntax). lakin bu iyi roman yazacağız anlamına gelmez değil mi? oluşturduğun class'ların, görevlerine bire bir uyması ve başkalarına konfor sağlaması, programcının yeteneğiyle ilgili biraz da.. bu ezberlenecek bir bilgi değil kanımca.

Bu konuya katılıyorum. Yani herkes kod yazabilir, hatta herkes OOP yazabilir. Ama önemli olan, OOP'u da, OOP'un o üç prensibini de gerektiği yerde, verimli biçimde kullanmak. Bunun da tutorial ile olcak bi şey olduğunu sanmıyorum.
İşte yazılım mühendisliği bu tarz sorunlar için var. İyi, verimli, güçlü kod yazmak ve bunu en uygun yolla yapmak, böylece proje ne kadar büyük olursa olsun kararlılığı ve verimliliği sürdürebilmek için neler yapılması gerektiğini bulmak için. Yaptığın bi programda OOP'a gerek var mı, veri akışı nasıl olacak, programın kullanıcıyla etkileşimi nasıl olacak bunları tespit etmek için. Design pattern'lar, süreç modelleri, geliştirme sürecinin modellenmesi, IEEE'nin bunlar için getirdiği standartlar vs. her şey bunun için var.
İşte bu yüzden, bana kalırsa en önemli nokta, sırf büyük projeler için değil, küçük olsun büyük olsun, yazılacak her program için proje yönetimi uygulanması. Zira bu sırf programın yazılma sürecini değil, her sürecini (analysis, design, programming, deployment, testing, maintenance) geliştirecektir.
Bunun için de en sağlıklı yöntem, "şu şu proje için hangi modeli seçeyim"'i değil, direkt olarak yazılım mühendisliği öğrenmek.

[Brigand]

Şimdilik şöyle bir düzen yapmaya başladım


> God class: Bütün classları birbirine bağlayacak class

> Core classlar: Her sayfada yüklenen ve ortak işlemler yapan, örneğin "sesssion sys" gibi classlar.

> Library classları: Kısmi olarak kullanılan, her zaman çağrılmayan örneğin "user sys" gibi classlar

> Plugin classları: "cookie encrypt, smooth thumbnail" gibi bugün var, yarın başka bir alternatifi ile değişebilecek most-common system classları.

> Module classları: Sayfaları yapılandıran, örneğin login sayfasına gidince html sayfayı mı gösterecek, yoksa email password verilerini mi işleyecek karar veren ve ona göre library kullanacak classlar

> Module class'ı ile çalışan template engine class'ı

> Language dosyaları (sırf düzen olsun diye yapacam, çift dil kullanmak değil php dosyası içinde cümle kullanmayayım diye)

Biraz düzenlenmeye başladı gibi geldi bana bakalım tabi ki daha da geliştirmek lazım.

[riglous]

@Ractamainus, ip_address() fonksiyonu "muhtemelen ip adresi geri donduruyodur" diyip gecebilirsin, $_SERVER'i kullanirsan, illaki ne oldugunu ogrenmek zorundasin. Demek istedigim buydu.

Kodu tek sayfaya sigdirmak guzel tabi, yani okuyan icin yardimci ama benim demek istedigim daha cok kitap yazar gibi kod yazilmamasi icindi.

	if(1=1){echo 'asd';}while(1=1){echo 'asd';return 1;                          }

	

gibisinden veya indentation'lari farkli farkli yapmak (ayni seviyedeki satirlar icin) vs. vs. Obur taraftan yeni baslayanlara koydugumuz bir kural vardi, alismalari icin: herhangi bir fonksiyon, ekranin uzunlugunu gecmeyecek. Eger geciyorsa mutlaka onu parcalamanin bir yolu vardir; bolup daha anlamli hale getirmek lazim. Hal boyle olunca pek de sorun olmuyor sayfaya sigip sigmamasi.

@Brigand, her is icin ayri tip yaratirsan, sonra bir de tiplerin kutuphanesini olusturup iyice kafa karistirirsin.
main olur, library olur, moduller olur, gui olur. Sonra illaki ayirmak istiyorsan bu basliklarin altinda yaparsin ayrimi.