RSS
kcamoglu
| Kişisel Profili ve Sayfası |
| RSS (Tek Kişilik Yazılımevi) |
Bunları Sakın Yapmayın!
Profesyonellerin gerçek yaşam deneyimlerinden…
29 Mart 2010
Yazılımla ilgili kuramsal (teorik) konular dışında, uygulama ve deneyim paylaşımına yönelik bir yazı daha…
Bu konuda sektörde uzun zamandır profesyonel olarak çalışan, alanında uzman tanıdıklarımdan yardım istedim. Sağ olsunlar beni kırmadılar, yoğun tempolarına rağmen geri dönüş yaparak çok değerli deneyimlerini bizlerle paylaştılar.
Bana göre teknik bilgiye daha kolay ulaşılabilir ve maliyeti daha düşüktür. Esas değerli olan deneyimdir. Aşağıda deneyimlerini ve isimlerini bulacağınız bu üstatların hepsine çok çok teşekkür ediyorum.
Lafı çok uzatmadan sizleri deneyimlerle baş başa bırakıyorum.
Saygılarımla.
Kadir Çamoğlu
NOTLAR:
1. Facebook grubumuz http://www.facebook.com/group.php?gid=29006737231
2. Yazılım profesyonellerinin deneyimleriyle ilgili daha fazlası için şu kitaba bir göz atabilirsiniz: http://www.alfakitap.com/kitap.asp?id=&kitapID=3433
3. Sıralamayı cevapların bana geliş tarihine göre yaptım.
4. Metinler direkt olarak bana geldikleri gibidir.
Çağdaş DAVULCU
1. Satış ekibinden bir elemanın analiz ettiği projeye girmeyin !!!
2. Kodu mükemmel bir şekilde yazmaya çalışmayın çünkü mükemmeli ararken proje bitmiyor!!!
3. Projeyi tümüyle analiz etmeye çalışmayın çünkü analiz müşteri tarafından programlama sürecinde değiştiriliyor!!! Günümüzde geliştirilmekte olan projeye müdahale etmeyen tek bir müşteri gösterin bana
4. Üzerinde çalıştığınız projeyi bitiminde müşteriye göstermeyin!!! Büyük ihtimalle müşterinin beklentisi doğrusunda bir çıktı verememiş olacaksınız??? Çünkü müşterinin beklentisi bitmez. Bu yüzden tüm uygulama geliştirme sürecini müşterinin yanında yapın ve günlük onaylar alın.
Atakan KESLER
1- Müşterinin istediğinden daha fazlasını vermeye kalkmayın , öneride bulunabilirsiniz ve kabul olan önerileriniz fazlandırın .
2- müşteri ile teması koparmayın . haberleşin ve proje raporları üzerinden mutlaka geçin. Bu aşamada yeni istek almamaya özen gösterin
3- Detaylı olmayan bir analiz dökümanı ile projeye başlamayın,
Mehmet DEMİRBİLEK
1. Analiz onemlidir. Ama analizi bastaci edip, dipsiz kuyulara, bin besyuz kere degisecek musteri isteklerine mahkum olmayin. Makul bir asamada analizi keserek, uygulamaya gecin. Neticede her uygulama yarimdir, eksiktir.
2. Sakin framework turu kutuphaneler yazmaya kalkismayin. Bu tur fantaziler asla sonraki projelerinizde kullanilamayacagi gibi, bunun uzerine bina ettiginiz projenizin bakimi da imkansiz olacaktir. Elbette isi iyice cigirindan cikartmayip birinci projenizi bitirebilmisseniz.
3. Sakin ekibinizin bilgi ve tecrubesinden daha buyuk islere girismeyin. Hele kurumsal bir firmada iseniz, topu 3. Partilere atmaniz, sizin iceride daha saglikli isler yapmanizi saglayacaktir.
4. Eger bir acik kaynak kodlu proje next-next-next kurulum ile ve maksimim %10 modifikasyonla isinizi gormeyecekse, ondan kacabildiginiz kadar uzaga kacin.
5. Ozellikle extranet uygulamalarinda generic hayaller kurmak gibi bir gaflete dusmeyin. Klonlayin gitsin.
6. Ayri ayri 5 uygulamayi yonetmek, bunlarin birlesiminden olusacak bir uygulamadan daha kolaydir.
7. Asla isi basit tutmayi unutmayin. Eger herhangi bir saglayici basit bir yapi onermisse, performans gibi cazibeli kelimelerin pesine takilip isi yoldan cikartmayin. Bunun yaninda, eger mevzuu akliniza yatmamissa, asla vendorunuzun gazina gelmeyin. (Ornek: her seyi stored procedures tarafina yikmak 3 vakte kadar projenizin copu boylayacagi anlamina gelir.)
8. Test de onemlidir, ama yazilim gelistiricilerin yaptigini iddia ettikleri testlere asla inanmayin, guvenmeyin. Birakin business takimi testleri yapsin. Hem daha saglikli test yapilmis olur, hem de top onlarin yari sahasinda kalmis olur.
9. Sececeginiz teknoloji cok onemlidir. Ama kullanmayi bildiginiz araclari secin. Asla, ilkel duygularla modern teknolojilere yonelmeyin. Bu sizi madara eder.
10. Dogru bildiginizi her zaman soyleyin. Ama ozellikle orta kademe yonetici iseniz, bazen ses etmeyip pes etmek daha basarili sonuclar doguracaktir. Birakin karari yoneticileriniz versin.
11. O kadar da degil, 2 karis kod ile hayata gecirebileceginiz projelere onbinlerce dolar vermeyin, yoneticileriniz vermek istese bile engel olun. Bu sizin meslek onurunuz icin gereklidir.
Nuri ÇANKAYA
Proje planı yapıp duvara asmayın: Çoğu zaman proje başlangıcı çok keyiflidir, planlar yapılır gantt chartlar hazırlanır, sonra da bunlar çıktı alınıp duvara asılır, oysa proje yönetimi yaşayan bir süreçtir, duvara asamazsınız! Her an tüm değişiklikler plana yansıtılmalı, yapılan tüm alt kalem işler hakkında durum bilgisi güncel tutulmalıdır. Kritik yol hesabı yapabilmek proje süresince mümkün olmalıdır. Siz siz olun sakın proje planlarınızı yapıp bir kenara atmayın, duvarlara asmayın; hep güncel tutun ve yaşayan proje yönetim süreçlerine odaklanın.
Mehmet MADEN
1) Requirement analizi tam yapılmadan ve emin olunmadan projenin sonraki adımlarına geçilmemeli
2) Kodlama aşamasında kullanmış olmak için kullanılan (yada alışkanlık olarak) (aslında gerekte olmayan) tasarım desenleri (design patterns) ve fazladan sınıf tanımları uygulanmamalı.
3)Eğitim le ilgili olarak; (özellikle o konuya yeni başlayanlar hedef kitle ise) sınıfta eğitmen tarafından anlatılan konu örnek, alıştırma veya ödevle desteklenmeli. Dersler seminer şeklinde geçmemeli!
Daron YÖNDEM
1. Sakın herşeye “Olur” demeyin.
2. Sakın mükemmelin peşinde koşmayın, yeterli yeterlidir.
3. Sakın para için kod yazdığınızı unutmayın!
:) çok ticari oldu belki bakış açısı ama teknik konulardan “Sakın” demek zor gibime geldi. “Duruma göre değişir” çoğu şey :)
Burak Selim ŞENYURT
Analiz
Bir geliştirici olarak analiz süreçlerine katılmayı ihmal etmeyin. Uygulama geliştirme süreçlerinde müşterinin ihtiyaçlarına planlanan zaman dilimlerinde cevap verebilmek adına geliştiricilerin mümkünse analiz toplantılarına katılmalarında ya da analistlerin edindikleri bilgileri zamanında geliştiricilere aktarmalarında(mümkünse müşteri ile yapılan analiz toplantıları sonrasında düzenli olarak) yarar vardır. Nitekim proje geliştirme sürelerine uyulamamasının en büyük nedenlerinden birisi, geliştirme takımının analiz dökümanını tekrar tekrar okuması veya analiste benzer soruları tekrar tekrar sormasından kaynaklanmantakdır. Buradaki zaman kay bına neden olan faktörleri geliştirme aşamasına başlamadan önce bertaraf etmek adına analist ve geliştirici takımlarının iş birliği son derece önemlidir.
Yazılım Tasarımı
Müşterinin hoşuna gitmesi için tasarımda gereksiz yere model üretmeyin. Özellikle teknik konuda çok bilgili olmayan müşterilerin birazda kendi ekiplerinde göze girmeye çalışan elemanlarının etkisi altında kalarak ürünlerinde "şu da olsun, bu da olsun..." gibi söylemlerine sıklıkla rastlanır. Her söylenenin kabul edilmesi yazılım için uygun tasarımın oluşturulmasını zorlayabilir ve ürünün tamamlanmasını güçleştirebilir. Bu nedenle akla yatmayan hallerde müşteriyi ikna edebilecek şekilde yaklaşılmalı ama kırıcı olmadan gerekçeleri belirterek ilerlenilmelidir. Gerektiğinde alterfnatif planlar veya çözümler önerilerek uygun yazılım ta sarımına yönlendirilmesi sağlanmalıdır.
Müşteri Eğitimi
Müşteri eğitimlerine ön bilgi edinmeden gitmeyin. Müşterinin eğitim alacak personelinin seviyesi, sahip olduğu bilgi birikimi, tecrübeleri, yapmakta oldukları işe eğitimin kalitesini, verimliliğini, süresini doğrudan etkileyen faktörlerdir. Genellikle eğitim konusunun tamamının müşteriye aktarılması çoğu zaman gereksiz olabilir ve çoğu zamanda yetersiz kalabilir. Öyleki müşterinin eğitimden almak istediği asıl bilgileri hızlı ve çabuk teşhis etmek, müşteri sormadan öneride bulunarak katkı sağlamak ve tecrübe aktarımını gerçekleştirmek adına ön bilgilerin edinilmesi eğitmenin işini kolaylaştıracak ve eğitimin kalitesini olabildiğince arttıracaktır.
Algoritma Geliştirme
Matematikten uzaklaşmayın. Her ne kadar uygulama geliştirmek adına işlerimiz kolaylaştıran sayısız framework olsa da zaman zaman çözüm için uygun algoritmaların üretilmesi geliştiricilere kalmaktadır. Bu noktada kullanılacak veya tasarlanacak algoritmaların performans, verimlilik, ölçeklenebilirlik, kullanışlılık vb kriterleri sağlıyor olması önemlidir. Ancak şu bir gerçektir ki algoritmalar matematiksel temellere dayanan ve matematik ile çözülen lineerlerdir. Bu nedenle matematik bilmi ile haşır neşir olmak mümkün olduğunca fazla matematik model bilmek algoritma geliştirme konusunda geliştiricilere epey bir zaman kazandıracaktır. Bu sebepten matematikten uzaklaşmamak mümkün olduğunca yakın durmak ve boş vakitlerde belki de var olan matematiksel algoritmalar üzerinde çalışmak önerilebilir.
Kodlama
Sadece X diline odaklanmayın. Geliştirici ekiplerin çoğu belirli diller konusunda uzmanlaşmıştır. Ancak çoğu büyük çaplı projede müşterinin ürünün geliştirmesine dahil edeceği ekipler ile arada dil uyuşmazlıkları söz konusu olabilir. Müşteri tarafı A dilini iyi bilirken işi alan geliştirme firmasının ekibi B dilini biliyor olabilir. Koordinasyonun sağlanması her ne kadar bazı framework' lerde çok kolay olsa da, müşterinin istekleri doğrultusunda firmanın geliştirme ekibinin B dilinde yazması istenebilir. Bu sebepten geliştiricilerin "hayatım boyunca A ile geliştiririm" demesi çok doğru olmayabilir. Bunun yerine programlama dili temellerini bilmek(nesne yönelimli, fonksiyonel gibi...) ve yazılım geliştirme desenlerini tanımak A, B, C, D gibi diller arasında geçiş yapmayı kolaylaştıracak ve geliştiricinin daha dil bağımsız olmasını sağlayacaktır.
Test
Unit Test deyip geçmeyin. Çoğu geliştirici test yapmayı ihmal eder veya zaman kaybı olan bir süreç olarak görür. Oysaki test süreçleri, uygulama kodu içerisindeki en küçük birimden başlar ve müşteri kabul testlerine(UAT) kadar devam eder. İlk başlarda test edilmeyerek gözden kaçan noktaların UAT aşamasına kadar gelmesi başta zaman kaybı olmak üzere müşterinin ürün geliştirme takımına olan güvenin sarsılmasına neden olabilir. Bu sebeple her geliştiricinin en azından sorumluluk sahasındaki fonksiyonelliklerin testini yaparak işi devretmesi önemlidir.
Fatih DURGUT
1. Eger gelistirmekte oldugunuz proje, bir sirket ici proje ise. Yani musteriniz ayni sirket icerisindeki farkli bir deparman ise. Analizini mumkun oldugunca ekran goruntulerini ekleyerek proje sahibine onaylatin. Genelde istenilen projeler icin yazilan analizler okunmuyor. Urun ortaya cikmaya basladiginda da, “ben bunu istememistim ama” oluyor.
2. Bir yazilim firmasinda proje gelistiyorsaniz, yazilimcilarin motivasyonu projenin sagligi icin cok onemlidir. Sirket icerisindeki work-life balance dikkat etmek gerekiyor. Her proje icin yazilimcilari fazla mesai yaptirirsaniz bu size insan kaybi olarak geri donecektir. Projelerin hak ettikleri sureleri, gerekli buffer time koyarak belirleyin.
Hakan ULAGAN
1. Veritabanı dosyalarını yaratırken ve kullanırken Transaction log ve data dosyalarının performans ve güvenlik açısından aynı disk üzerinde olmamasına dikkat ediniz.
2. Koddan veritabanı bağlantısı yaparken asla, connection string içerisinde , “sa” kullanıcısı gibi tüm veritabanlarına yetkili bir admin hesabı kullanmayınız.
Mustafa ACUNGİL
1. Best practise'lerden haberdar olun, onları göz ardı edip Amerika'yı yeniden keşfetmeyin.
2. Best practise'leri anlayın ve öyle kabullenin, ama niyetiniz anlamak olsun olumsuzlamak değil
3. Değişen şartlarda eski kabullendiğiniz bilgilere körü körüne bağlı kalmayın, güncelliklerini kaybetmiş olabilirler.
Hakan ÇAMOĞLU
1. İşi son ana bırakma: çünkü mutlaka hesaba katmadığın bişeyler olacaktır.
2. İşi yapan değil kullanan olarak düşün: çünkü önemli olan senin sevmen değil müşterinin sevmesidir.
3. Ekstra isteklere hazırlıklı olun: çünkü müşteri her zaman fazlasını ister. Bitmiş işin üstüne bile keşke şu şöyle olsaydı bunu böyle yapsaydık der. Bu yüzden yapılacak herşey baştan belirlenmeli ve ekstra isteklerin ekstra ücret olacağı baştan belirtilmeli. Böylece müşteri başlangıçta daha dikkatli düşünür ve sonradan isteyeceklerinin bir bedeli olacağını bilir.
Tamer ÖZ
Analiz :
Bildiğiniz gibi analiz aşaması bir uygulama geliştirme sürecinin en temel ve en önemli aşamasıdır. Dolayısıyla analiz aşamasında yapacağınız bir yanlış veya atlayabileceğiniz bir nokta ileride projenin uzamasından, müşteri tarafından kabul görmemesi gibi ciddi problemlere yol açabilmektedir. Dolayısıyla analiz safhası projenin başarısını direkt olarak etkilemektedir. Analiz safhasının projenin en önemli safhası olduğunu unutmayınız. Analiz safhasında yapılmayacak şeyleri sıralamak gerekirse bunların başında analiz safhasını kısa tutmak gelecektir. Bu belki de en çok yapılan hatadır. Müşteriniz sizden adres defteri uygulaması gibi fonksiyonlarını ve özelliklerini kolayca tahmin edebileceğiniz bir uygulama istiyorsa bile mutlaka analizi mümkün olduğu kadar detaylı yapmak gerektiğini, basit bir uygulamada bile isteklerin çok farklılaşabildiğini unutmayınız. Bunun yanısıra analizi bir aracı ile değil direkt iş sahibi ve uygulamayı kullanacak son kullanıcı ile yapmanız ortaya çıkabilecek yanlış anlaşılmaları engellemek adına ciddi bir önlem olacaktır. Analizi sonlandırmadan ve gereksinimleri ortaya çıkarmadan teknoloji ve platform seçimini yapmayınız. Teknoloji ve platform seçimini yaparken bir uygulamanın bugünkü koşullarını değil 3 sene kullanıldıkan sonraki koşullarını da düşününüz. Örneğin uygulamanın 3 sene sonraki kullanıcı sayısı, veri miktarı neler olacak gibi soruları iyi analiz edip teknoloji seçimi yapınız. Aksi durumda performans sorunları ile karşılaşmanız olasıdır.
Ekran Tasarımı :
Yazdığınız bir uygulamanın ekran tasarımını yaparken gerek diğer uygulamalarda olan ortak özellikleri, standartları gözardı etmeyiniz. Örnek vermek gerekirse geliştirdiğiniz uygulamalarda Tamam ve İptal düğmelerinin yerlerini Windows’ta bulunduğu gibi Tamam düğmesi solda olacak şekilde yerleştiriniz, Kaydırma çubuğunu sağa ve aşağıya koyunuz, kısayol tuşlarını insanların çoğunlukla kullandığı uygulamalarda bulunan tuşlar ile aynı yapınız. Bunun yanısıra son kullanıcının kullanım alışkanlıklarını da iyi analiz edip ekran tasarımlarını ona göre yapmanız gerekmektedir. Uygulamanın alfa veya preview aşamasında yapacağınız kullanıcıın bilgileri hangi sıra ile doldurduğu, en çok hangi düşmeleri kullandığı ve nereleri kullanmakta zorluk yaşadığı gibi gözlemler bu noktada işinizi kolaylaştıracaktır. Tabi ki burdaki en önemli diğer noktalardan biri çok karmaşık ekranlardan kaçınmaktır.
Kodlama :
Uygulama geliştirme aşamasında kodlama için kullanacağınız standartlarınızı bir projeye başlamadan önce mutlaka belirleyiniz. Bilhassa bir takım tarafından geliştirilen uygulamalarda herkes istediği gibi yazsın şeklinde bir yaklaşımda kesinlikle bulunmayınız. Mutlaka bir mimari yaklaşım benimseyiniz. Bir diğer nokta ise uygulama geliştirirken kodlama aşamasında uygulamanın gereksinimleri konusunda çok fazla değişiklik olmayacağı düşünülmektedir. Ancak gerçek hayat maalesef bu kadar toz pembe değildir. Yapılan araştırmalara göre müşterilerin istekleri kodlama sırasında 20% civarında değişmektedir. Bu değişiklik taleplerini karşılamak adına uygulama kodunda günü kurtarmak adına kodlama standartlarınızın dışına çıkacak şekilde değiştirmeyiniz. Bu değişiklikler size zaman kazandırıyor gibi gözüksede ileride daha çok zaman kaybına neden olacaktır. Çok uzun ve karmaşık metodlar yazmaktan kaçınınız, metodlarınızı 30 satırı geçmeyecek ve tek bir fonksiyondan sorumlu olacak şekilde yazınız, isimlerini yaptıkları işi anlatacak şekilde veriniz.
Ahmet HOSO
1. Yeni tamamladığınız bir geliştirmeyi başkalarına da test ettirmeden müşteriye sunmayın :)
2. Müşteri demolarında ön bir senaryo hazırlayıp oradaki senaryoyu adım adım test ederek demoya çıkın. Ve senaryo dışına asla çıkmayın
Ertan DENİZ
1. Yetersiz ihtiyaç analizinden veya değişen ihtiyaçlar sebebiyle, Yazılımınız üzerinde değişiklik olabileceğini… (Buzdolobı üretmiyoruz.)
2. Yazılımın ömrü boyunca, aynı kişiler tarafından sürdürülmeyeceğini , Yazılımı başkalarının devam ettirmesi gerektiğini … (Yazılımda standartları takip etmeliyiz. Kodlama ve tasarım standartları gibi.)
3. Mevcut problemimiz veya ihtiyaçlarımız ile, daha önce başkalarının da karşılaşmış olabileceğini…. (Karmaşıklaşan yazılım çözümlerinin, her kısmının sıfırdan yazılamayacağını düşünmeliyiz. Hazır çözümler kullanmak gibi.)
Kadir ÇAMOĞLU
1. Geliştirme, destek ve operasyon işlevlerini tek bir ekiple yürütmeyin. Mümkünse hepsini ayrı ekipler halinde oluşturun. En kötü ihtimalle geliştirmeyi diğer ikisinden ayırın.
2. Yazılımcılara birim testi dışında testleri yaptırmayın. Alfa testlerini, entegrasyon, yük ve stres testlerini mümkünse ayrı birine/ekibe yaptırın. Olmadı siz yapın. Ama kodu yazana yaptırmayın.
3. Proje ilerlerken Ekibe yeni şeyler öğretmeye kalkmayın. Eğer ekibin öğrenmesi gereken yeni metotlar/teknolojiler varsa bunu proje başlamadan önce öğretin. Ya da proje planına eğitim sürecini katarak zamanlamayı yapın.
Bu konuda sektörde uzun zamandır profesyonel olarak çalışan, alanında uzman tanıdıklarımdan yardım istedim. Sağ olsunlar beni kırmadılar, yoğun tempolarına rağmen geri dönüş yaparak çok değerli deneyimlerini bizlerle paylaştılar.
Bana göre teknik bilgiye daha kolay ulaşılabilir ve maliyeti daha düşüktür. Esas değerli olan deneyimdir. Aşağıda deneyimlerini ve isimlerini bulacağınız bu üstatların hepsine çok çok teşekkür ediyorum.
Lafı çok uzatmadan sizleri deneyimlerle baş başa bırakıyorum.
Saygılarımla.
Kadir Çamoğlu
NOTLAR:
1. Facebook grubumuz http://www.facebook.com/group.php?gid=29006737231
2. Yazılım profesyonellerinin deneyimleriyle ilgili daha fazlası için şu kitaba bir göz atabilirsiniz: http://www.alfakitap.com/kitap.asp?id=&kitapID=3433
3. Sıralamayı cevapların bana geliş tarihine göre yaptım.
4. Metinler direkt olarak bana geldikleri gibidir.
Çağdaş DAVULCU
1. Satış ekibinden bir elemanın analiz ettiği projeye girmeyin !!!
2. Kodu mükemmel bir şekilde yazmaya çalışmayın çünkü mükemmeli ararken proje bitmiyor!!!
3. Projeyi tümüyle analiz etmeye çalışmayın çünkü analiz müşteri tarafından programlama sürecinde değiştiriliyor!!! Günümüzde geliştirilmekte olan projeye müdahale etmeyen tek bir müşteri gösterin bana
4. Üzerinde çalıştığınız projeyi bitiminde müşteriye göstermeyin!!! Büyük ihtimalle müşterinin beklentisi doğrusunda bir çıktı verememiş olacaksınız??? Çünkü müşterinin beklentisi bitmez. Bu yüzden tüm uygulama geliştirme sürecini müşterinin yanında yapın ve günlük onaylar alın.
Atakan KESLER
1- Müşterinin istediğinden daha fazlasını vermeye kalkmayın , öneride bulunabilirsiniz ve kabul olan önerileriniz fazlandırın .
2- müşteri ile teması koparmayın . haberleşin ve proje raporları üzerinden mutlaka geçin. Bu aşamada yeni istek almamaya özen gösterin
3- Detaylı olmayan bir analiz dökümanı ile projeye başlamayın,
Mehmet DEMİRBİLEK
1. Analiz onemlidir. Ama analizi bastaci edip, dipsiz kuyulara, bin besyuz kere degisecek musteri isteklerine mahkum olmayin. Makul bir asamada analizi keserek, uygulamaya gecin. Neticede her uygulama yarimdir, eksiktir.
2. Sakin framework turu kutuphaneler yazmaya kalkismayin. Bu tur fantaziler asla sonraki projelerinizde kullanilamayacagi gibi, bunun uzerine bina ettiginiz projenizin bakimi da imkansiz olacaktir. Elbette isi iyice cigirindan cikartmayip birinci projenizi bitirebilmisseniz.
3. Sakin ekibinizin bilgi ve tecrubesinden daha buyuk islere girismeyin. Hele kurumsal bir firmada iseniz, topu 3. Partilere atmaniz, sizin iceride daha saglikli isler yapmanizi saglayacaktir.
4. Eger bir acik kaynak kodlu proje next-next-next kurulum ile ve maksimim %10 modifikasyonla isinizi gormeyecekse, ondan kacabildiginiz kadar uzaga kacin.
5. Ozellikle extranet uygulamalarinda generic hayaller kurmak gibi bir gaflete dusmeyin. Klonlayin gitsin.
6. Ayri ayri 5 uygulamayi yonetmek, bunlarin birlesiminden olusacak bir uygulamadan daha kolaydir.
7. Asla isi basit tutmayi unutmayin. Eger herhangi bir saglayici basit bir yapi onermisse, performans gibi cazibeli kelimelerin pesine takilip isi yoldan cikartmayin. Bunun yaninda, eger mevzuu akliniza yatmamissa, asla vendorunuzun gazina gelmeyin. (Ornek: her seyi stored procedures tarafina yikmak 3 vakte kadar projenizin copu boylayacagi anlamina gelir.)
8. Test de onemlidir, ama yazilim gelistiricilerin yaptigini iddia ettikleri testlere asla inanmayin, guvenmeyin. Birakin business takimi testleri yapsin. Hem daha saglikli test yapilmis olur, hem de top onlarin yari sahasinda kalmis olur.
9. Sececeginiz teknoloji cok onemlidir. Ama kullanmayi bildiginiz araclari secin. Asla, ilkel duygularla modern teknolojilere yonelmeyin. Bu sizi madara eder.
10. Dogru bildiginizi her zaman soyleyin. Ama ozellikle orta kademe yonetici iseniz, bazen ses etmeyip pes etmek daha basarili sonuclar doguracaktir. Birakin karari yoneticileriniz versin.
11. O kadar da degil, 2 karis kod ile hayata gecirebileceginiz projelere onbinlerce dolar vermeyin, yoneticileriniz vermek istese bile engel olun. Bu sizin meslek onurunuz icin gereklidir.
Nuri ÇANKAYA
Proje planı yapıp duvara asmayın: Çoğu zaman proje başlangıcı çok keyiflidir, planlar yapılır gantt chartlar hazırlanır, sonra da bunlar çıktı alınıp duvara asılır, oysa proje yönetimi yaşayan bir süreçtir, duvara asamazsınız! Her an tüm değişiklikler plana yansıtılmalı, yapılan tüm alt kalem işler hakkında durum bilgisi güncel tutulmalıdır. Kritik yol hesabı yapabilmek proje süresince mümkün olmalıdır. Siz siz olun sakın proje planlarınızı yapıp bir kenara atmayın, duvarlara asmayın; hep güncel tutun ve yaşayan proje yönetim süreçlerine odaklanın.
Mehmet MADEN
1) Requirement analizi tam yapılmadan ve emin olunmadan projenin sonraki adımlarına geçilmemeli
2) Kodlama aşamasında kullanmış olmak için kullanılan (yada alışkanlık olarak) (aslında gerekte olmayan) tasarım desenleri (design patterns) ve fazladan sınıf tanımları uygulanmamalı.
3)Eğitim le ilgili olarak; (özellikle o konuya yeni başlayanlar hedef kitle ise) sınıfta eğitmen tarafından anlatılan konu örnek, alıştırma veya ödevle desteklenmeli. Dersler seminer şeklinde geçmemeli!
Daron YÖNDEM
1. Sakın herşeye “Olur” demeyin.
2. Sakın mükemmelin peşinde koşmayın, yeterli yeterlidir.
3. Sakın para için kod yazdığınızı unutmayın!
:) çok ticari oldu belki bakış açısı ama teknik konulardan “Sakın” demek zor gibime geldi. “Duruma göre değişir” çoğu şey :)
Burak Selim ŞENYURT
Analiz
Bir geliştirici olarak analiz süreçlerine katılmayı ihmal etmeyin. Uygulama geliştirme süreçlerinde müşterinin ihtiyaçlarına planlanan zaman dilimlerinde cevap verebilmek adına geliştiricilerin mümkünse analiz toplantılarına katılmalarında ya da analistlerin edindikleri bilgileri zamanında geliştiricilere aktarmalarında(mümkünse müşteri ile yapılan analiz toplantıları sonrasında düzenli olarak) yarar vardır. Nitekim proje geliştirme sürelerine uyulamamasının en büyük nedenlerinden birisi, geliştirme takımının analiz dökümanını tekrar tekrar okuması veya analiste benzer soruları tekrar tekrar sormasından kaynaklanmantakdır. Buradaki zaman kay bına neden olan faktörleri geliştirme aşamasına başlamadan önce bertaraf etmek adına analist ve geliştirici takımlarının iş birliği son derece önemlidir.
Yazılım Tasarımı
Müşterinin hoşuna gitmesi için tasarımda gereksiz yere model üretmeyin. Özellikle teknik konuda çok bilgili olmayan müşterilerin birazda kendi ekiplerinde göze girmeye çalışan elemanlarının etkisi altında kalarak ürünlerinde "şu da olsun, bu da olsun..." gibi söylemlerine sıklıkla rastlanır. Her söylenenin kabul edilmesi yazılım için uygun tasarımın oluşturulmasını zorlayabilir ve ürünün tamamlanmasını güçleştirebilir. Bu nedenle akla yatmayan hallerde müşteriyi ikna edebilecek şekilde yaklaşılmalı ama kırıcı olmadan gerekçeleri belirterek ilerlenilmelidir. Gerektiğinde alterfnatif planlar veya çözümler önerilerek uygun yazılım ta sarımına yönlendirilmesi sağlanmalıdır.
Müşteri Eğitimi
Müşteri eğitimlerine ön bilgi edinmeden gitmeyin. Müşterinin eğitim alacak personelinin seviyesi, sahip olduğu bilgi birikimi, tecrübeleri, yapmakta oldukları işe eğitimin kalitesini, verimliliğini, süresini doğrudan etkileyen faktörlerdir. Genellikle eğitim konusunun tamamının müşteriye aktarılması çoğu zaman gereksiz olabilir ve çoğu zamanda yetersiz kalabilir. Öyleki müşterinin eğitimden almak istediği asıl bilgileri hızlı ve çabuk teşhis etmek, müşteri sormadan öneride bulunarak katkı sağlamak ve tecrübe aktarımını gerçekleştirmek adına ön bilgilerin edinilmesi eğitmenin işini kolaylaştıracak ve eğitimin kalitesini olabildiğince arttıracaktır.
Algoritma Geliştirme
Matematikten uzaklaşmayın. Her ne kadar uygulama geliştirmek adına işlerimiz kolaylaştıran sayısız framework olsa da zaman zaman çözüm için uygun algoritmaların üretilmesi geliştiricilere kalmaktadır. Bu noktada kullanılacak veya tasarlanacak algoritmaların performans, verimlilik, ölçeklenebilirlik, kullanışlılık vb kriterleri sağlıyor olması önemlidir. Ancak şu bir gerçektir ki algoritmalar matematiksel temellere dayanan ve matematik ile çözülen lineerlerdir. Bu nedenle matematik bilmi ile haşır neşir olmak mümkün olduğunca fazla matematik model bilmek algoritma geliştirme konusunda geliştiricilere epey bir zaman kazandıracaktır. Bu sebepten matematikten uzaklaşmamak mümkün olduğunca yakın durmak ve boş vakitlerde belki de var olan matematiksel algoritmalar üzerinde çalışmak önerilebilir.
Kodlama
Sadece X diline odaklanmayın. Geliştirici ekiplerin çoğu belirli diller konusunda uzmanlaşmıştır. Ancak çoğu büyük çaplı projede müşterinin ürünün geliştirmesine dahil edeceği ekipler ile arada dil uyuşmazlıkları söz konusu olabilir. Müşteri tarafı A dilini iyi bilirken işi alan geliştirme firmasının ekibi B dilini biliyor olabilir. Koordinasyonun sağlanması her ne kadar bazı framework' lerde çok kolay olsa da, müşterinin istekleri doğrultusunda firmanın geliştirme ekibinin B dilinde yazması istenebilir. Bu sebepten geliştiricilerin "hayatım boyunca A ile geliştiririm" demesi çok doğru olmayabilir. Bunun yerine programlama dili temellerini bilmek(nesne yönelimli, fonksiyonel gibi...) ve yazılım geliştirme desenlerini tanımak A, B, C, D gibi diller arasında geçiş yapmayı kolaylaştıracak ve geliştiricinin daha dil bağımsız olmasını sağlayacaktır.
Test
Unit Test deyip geçmeyin. Çoğu geliştirici test yapmayı ihmal eder veya zaman kaybı olan bir süreç olarak görür. Oysaki test süreçleri, uygulama kodu içerisindeki en küçük birimden başlar ve müşteri kabul testlerine(UAT) kadar devam eder. İlk başlarda test edilmeyerek gözden kaçan noktaların UAT aşamasına kadar gelmesi başta zaman kaybı olmak üzere müşterinin ürün geliştirme takımına olan güvenin sarsılmasına neden olabilir. Bu sebeple her geliştiricinin en azından sorumluluk sahasındaki fonksiyonelliklerin testini yaparak işi devretmesi önemlidir.
Fatih DURGUT
1. Eger gelistirmekte oldugunuz proje, bir sirket ici proje ise. Yani musteriniz ayni sirket icerisindeki farkli bir deparman ise. Analizini mumkun oldugunca ekran goruntulerini ekleyerek proje sahibine onaylatin. Genelde istenilen projeler icin yazilan analizler okunmuyor. Urun ortaya cikmaya basladiginda da, “ben bunu istememistim ama” oluyor.
2. Bir yazilim firmasinda proje gelistiyorsaniz, yazilimcilarin motivasyonu projenin sagligi icin cok onemlidir. Sirket icerisindeki work-life balance dikkat etmek gerekiyor. Her proje icin yazilimcilari fazla mesai yaptirirsaniz bu size insan kaybi olarak geri donecektir. Projelerin hak ettikleri sureleri, gerekli buffer time koyarak belirleyin.
Hakan ULAGAN
1. Veritabanı dosyalarını yaratırken ve kullanırken Transaction log ve data dosyalarının performans ve güvenlik açısından aynı disk üzerinde olmamasına dikkat ediniz.
2. Koddan veritabanı bağlantısı yaparken asla, connection string içerisinde , “sa” kullanıcısı gibi tüm veritabanlarına yetkili bir admin hesabı kullanmayınız.
Mustafa ACUNGİL
1. Best practise'lerden haberdar olun, onları göz ardı edip Amerika'yı yeniden keşfetmeyin.
2. Best practise'leri anlayın ve öyle kabullenin, ama niyetiniz anlamak olsun olumsuzlamak değil
3. Değişen şartlarda eski kabullendiğiniz bilgilere körü körüne bağlı kalmayın, güncelliklerini kaybetmiş olabilirler.
Hakan ÇAMOĞLU
1. İşi son ana bırakma: çünkü mutlaka hesaba katmadığın bişeyler olacaktır.
2. İşi yapan değil kullanan olarak düşün: çünkü önemli olan senin sevmen değil müşterinin sevmesidir.
3. Ekstra isteklere hazırlıklı olun: çünkü müşteri her zaman fazlasını ister. Bitmiş işin üstüne bile keşke şu şöyle olsaydı bunu böyle yapsaydık der. Bu yüzden yapılacak herşey baştan belirlenmeli ve ekstra isteklerin ekstra ücret olacağı baştan belirtilmeli. Böylece müşteri başlangıçta daha dikkatli düşünür ve sonradan isteyeceklerinin bir bedeli olacağını bilir.
Tamer ÖZ
Analiz :
Bildiğiniz gibi analiz aşaması bir uygulama geliştirme sürecinin en temel ve en önemli aşamasıdır. Dolayısıyla analiz aşamasında yapacağınız bir yanlış veya atlayabileceğiniz bir nokta ileride projenin uzamasından, müşteri tarafından kabul görmemesi gibi ciddi problemlere yol açabilmektedir. Dolayısıyla analiz safhası projenin başarısını direkt olarak etkilemektedir. Analiz safhasının projenin en önemli safhası olduğunu unutmayınız. Analiz safhasında yapılmayacak şeyleri sıralamak gerekirse bunların başında analiz safhasını kısa tutmak gelecektir. Bu belki de en çok yapılan hatadır. Müşteriniz sizden adres defteri uygulaması gibi fonksiyonlarını ve özelliklerini kolayca tahmin edebileceğiniz bir uygulama istiyorsa bile mutlaka analizi mümkün olduğu kadar detaylı yapmak gerektiğini, basit bir uygulamada bile isteklerin çok farklılaşabildiğini unutmayınız. Bunun yanısıra analizi bir aracı ile değil direkt iş sahibi ve uygulamayı kullanacak son kullanıcı ile yapmanız ortaya çıkabilecek yanlış anlaşılmaları engellemek adına ciddi bir önlem olacaktır. Analizi sonlandırmadan ve gereksinimleri ortaya çıkarmadan teknoloji ve platform seçimini yapmayınız. Teknoloji ve platform seçimini yaparken bir uygulamanın bugünkü koşullarını değil 3 sene kullanıldıkan sonraki koşullarını da düşününüz. Örneğin uygulamanın 3 sene sonraki kullanıcı sayısı, veri miktarı neler olacak gibi soruları iyi analiz edip teknoloji seçimi yapınız. Aksi durumda performans sorunları ile karşılaşmanız olasıdır.
Ekran Tasarımı :
Yazdığınız bir uygulamanın ekran tasarımını yaparken gerek diğer uygulamalarda olan ortak özellikleri, standartları gözardı etmeyiniz. Örnek vermek gerekirse geliştirdiğiniz uygulamalarda Tamam ve İptal düğmelerinin yerlerini Windows’ta bulunduğu gibi Tamam düğmesi solda olacak şekilde yerleştiriniz, Kaydırma çubuğunu sağa ve aşağıya koyunuz, kısayol tuşlarını insanların çoğunlukla kullandığı uygulamalarda bulunan tuşlar ile aynı yapınız. Bunun yanısıra son kullanıcının kullanım alışkanlıklarını da iyi analiz edip ekran tasarımlarını ona göre yapmanız gerekmektedir. Uygulamanın alfa veya preview aşamasında yapacağınız kullanıcıın bilgileri hangi sıra ile doldurduğu, en çok hangi düşmeleri kullandığı ve nereleri kullanmakta zorluk yaşadığı gibi gözlemler bu noktada işinizi kolaylaştıracaktır. Tabi ki burdaki en önemli diğer noktalardan biri çok karmaşık ekranlardan kaçınmaktır.
Kodlama :
Uygulama geliştirme aşamasında kodlama için kullanacağınız standartlarınızı bir projeye başlamadan önce mutlaka belirleyiniz. Bilhassa bir takım tarafından geliştirilen uygulamalarda herkes istediği gibi yazsın şeklinde bir yaklaşımda kesinlikle bulunmayınız. Mutlaka bir mimari yaklaşım benimseyiniz. Bir diğer nokta ise uygulama geliştirirken kodlama aşamasında uygulamanın gereksinimleri konusunda çok fazla değişiklik olmayacağı düşünülmektedir. Ancak gerçek hayat maalesef bu kadar toz pembe değildir. Yapılan araştırmalara göre müşterilerin istekleri kodlama sırasında 20% civarında değişmektedir. Bu değişiklik taleplerini karşılamak adına uygulama kodunda günü kurtarmak adına kodlama standartlarınızın dışına çıkacak şekilde değiştirmeyiniz. Bu değişiklikler size zaman kazandırıyor gibi gözüksede ileride daha çok zaman kaybına neden olacaktır. Çok uzun ve karmaşık metodlar yazmaktan kaçınınız, metodlarınızı 30 satırı geçmeyecek ve tek bir fonksiyondan sorumlu olacak şekilde yazınız, isimlerini yaptıkları işi anlatacak şekilde veriniz.
Ahmet HOSO
1. Yeni tamamladığınız bir geliştirmeyi başkalarına da test ettirmeden müşteriye sunmayın :)
2. Müşteri demolarında ön bir senaryo hazırlayıp oradaki senaryoyu adım adım test ederek demoya çıkın. Ve senaryo dışına asla çıkmayın
Ertan DENİZ
1. Yetersiz ihtiyaç analizinden veya değişen ihtiyaçlar sebebiyle, Yazılımınız üzerinde değişiklik olabileceğini… (Buzdolobı üretmiyoruz.)
2. Yazılımın ömrü boyunca, aynı kişiler tarafından sürdürülmeyeceğini , Yazılımı başkalarının devam ettirmesi gerektiğini … (Yazılımda standartları takip etmeliyiz. Kodlama ve tasarım standartları gibi.)
3. Mevcut problemimiz veya ihtiyaçlarımız ile, daha önce başkalarının da karşılaşmış olabileceğini…. (Karmaşıklaşan yazılım çözümlerinin, her kısmının sıfırdan yazılamayacağını düşünmeliyiz. Hazır çözümler kullanmak gibi.)
Kadir ÇAMOĞLU
1. Geliştirme, destek ve operasyon işlevlerini tek bir ekiple yürütmeyin. Mümkünse hepsini ayrı ekipler halinde oluşturun. En kötü ihtimalle geliştirmeyi diğer ikisinden ayırın.
2. Yazılımcılara birim testi dışında testleri yaptırmayın. Alfa testlerini, entegrasyon, yük ve stres testlerini mümkünse ayrı birine/ekibe yaptırın. Olmadı siz yapın. Ama kodu yazana yaptırmayın.
3. Proje ilerlerken Ekibe yeni şeyler öğretmeye kalkmayın. Eğer ekibin öğrenmesi gereken yeni metotlar/teknolojiler varsa bunu proje başlamadan önce öğretin. Ya da proje planına eğitim sürecini katarak zamanlamayı yapın.
Toplam 6993 kez okundu.
Oyla:
En Düşük
En Yüksek
YORUMLAR
Toplam 16 yorum
Ziyaretçi yazmış:Yıllarca yazılım geliştirici olarak katıldığım kurumsal büyük projelerde bir çok defa şunu anladım ki;
1. Mümkün olduğunca detaylı, her aşamanın, her isteğin konuşulup karara bağlandığı bir analizin varlığı çok ama çok kritik bir safha
2. Analiz tamamlanmadan kodlamaya geçilmesi çok büyük bir hata
3. Bu koşullara uyan bir analiz yoksa hiç kodlamaya başlamamak çok daha iyi. Çünkü bu koşullarda projenin başarısız olma olasılığı %100..
1. Mümkün olduğunca detaylı, her aşamanın, her isteğin konuşulup karara bağlandığı bir analizin varlığı çok ama çok kritik bir safha
2. Analiz tamamlanmadan kodlamaya geçilmesi çok büyük bir hata
3. Bu koşullara uyan bir analiz yoksa hiç kodlamaya başlamamak çok daha iyi. Çünkü bu koşullarda projenin başarısız olma olasılığı %100..
| 30 Kas 2010 18:27 | %100 |  |  | %0 |
Ziyaretçi yazmış:WTF
| 24 Kas 2010 00:48 | | |
Ziyaretçi yazmış:Mehmet DEMİRBİLEK yazılım süreçleri konusunda biraz daha bilgi edinmeli bence
| 18 Eki 2010 12:47 | %100 | | | %0 |
Ziyaretçi yazmış:Güzel bir paylaşım olmuş emeği geçenlere teşekkür ederim.
| 14 Eki 2010 09:47 | | |
Ziyaretçi yazmış:Ben de yazilim gelistiriciyim benim de en buyuk tecrubem bitmek bilmeyen istekler oluyordu. Her akla geleni projeye dahil etmek daha henuz 1 modul bitmeden baska bir istekte bulunmak sonunda projenin bitemeden cope gitmesiyle sonuclandi. Mahkemeye verildim programin bitmedigini ve parasinin verildigini soylediler ben de anlasmayi cikartip gosterim proje 80 saat ve 40 sayfa (1000-3000satir) olacak proje 2 ay icerisinde ilk teslimat ve kurulumdan sonra %10 kod degisikligini veya %10 kod satirini gecmeyecek eklemeler olacak diye bilirkisiye sundum mahkemeyi ben kazandim siz siz olun anlasmalarinizda dikkatli olun.
Musteriye gore ben ismi yarim yaptim 1 senede surse bitirmek zorundayim iyiki mahkemeyle sonuclandi kurtuldum....
Musteriye gore ben ismi yarim yaptim 1 senede surse bitirmek zorundayim iyiki mahkemeyle sonuclandi kurtuldum....
| 27 Tem 2010 00:29 | | |
Bu sayfalarda yer alan okur yorumları kişilerin kendi görüşleridir. Yazılanlardan CHIP Online sorumlu değildir.
Lütfen bu bölüme sadece yorumlarınızı yazın. Teknik yardıma ihtiyaç duyduğunuz konuları lütfen forumda ilgili bölüme veya Uzmanına Sorun bölümümüze yazın, yanıtınızı çok daha sağlıklı ve hızlı olarak alabilirsiniz
 | ||
 |
 |
 |
 | ||
Tek Kişilik Yazılımevi-Kategoriler
Tek Kişilik Yazılımevi önceki yazılar:
kcamoglu - TOP 5
- İyi Bir Yazılımcı Olmanın Reçetesi
- Yazılım Mühendisliği Nedir?
- Yazılım Geliştirme ve Analiz
- Hangi Programlama Dilini Öğrenmeliyim?
- Yazılım Geliştirme Süreci
Tek Kişilik Yazılımevi-Arşiv
- 2011 Aralık
- 2011 Eylül
- 2011 Ağustos
- 2011 Temmuz
- 2011 Mayıs
- 2011 Nisan
- 2011 Şubat
- 2011 Ocak
- 2010 Aralık
- 2010 Ekim
- 2010 Eylül
- 2010 Ağustos
- 2010 Temmuz
- 2010 Haziran
- 2010 Mayıs
- 2010 Mart
- 2010 Şubat
- 2010 Ocak
- 2009 Aralık
- 2009 Kasım
- 2009 Ekim
- 2009 Eylül
- 2009 Ağustos
- 2009 Temmuz
- 2009 Haziran
- 2009 Mayıs
- 2009 Nisan
- 2009 Mart
- 2009 Şubat
- 2009 Ocak
- 2008 Aralık
- 2008 Kasım
- 2008 Ekim
- 2008 Eylül
- 2008 Ağustos
- 2008 Temmuz
- 2008 Haziran
- 2008 Mayıs
- 2008 Nisan
- 2008 Mart
- 2008 Şubat
CHIP Online Yazar Blogları
Yazarlarımızdan, editörlerimizden sizlere...
 | Cem Sinanoğlu Nokia değil Nokir, iPhone değil Ay-Phone! |
 | Selim Öztürk Motorola – Google Apple’a karşı |
 | Rik Ferguson Şapşal olma, sessiz ol! Şapşal olma, sessiz ol! |
 | Selçuk İslamoğlu 2012 Felaketine ne kadar hazırız? |
 | Zeynel Öztürk Facebook'un bilinmeyenleri! |
CHIP Dergisi: Mayıs 2012
İşbirliği ortaklarımız
Cep telefonları |
Ekran kartları |
Masaüstü |
Notebook |
Ses kartları |
Webcam |
Klavye & Fare |
Yazıcılar |
Tablet
Ev Sineması
Mp3 Player | Usb Bellekler | Video kameralar | Fotoğraf Makinesi | Taşınabilir diskler | LED & LCD Tv | Monitörler | OEM | PDA
Navigasyon | Oyun Konsolu
Copyright © CHIP Online 2012 | Doğan Burda Dergi Yayıncılık ve Pazarlama A.Ş.
Hürriyet Medya Towers 34212 Güneşli - İstanbul
Hürriyet Medya Towers 34212 Güneşli - İstanbul