Kategoriler


SON YORUMLAR
işsiz
bilgisayar mühendisi şu amk asp.net te şu get ile id i almayı bi öğrenemedim sikim böle işi php en iyisi better then
Ali yıldırım
Merhaba arkadaşlar c,c++,java,c#,php ödevlerinize uygun ücret ile yardim edebilirim iletisim=ali.yildirim.94@hotmail.com
Zekeriya
Microsoft ne iş yaparak bu kadar parayı kazanıyor?Sadece işletim sistemi ve ofisten bu kadar para gelir mi?118 bin çalışanı olupta neden bu kadar az yazılım yapıyor?Örnek grafik,animasyon,veri kurtarma,oyun vesaire.Bana kalırsa bir işletim sistemi bir çok işi kendi yapar.Dışarıdan herhengi uygulamaya ihtiyaç duymaz.Biz hala dışardan winrar yüklüyoruz.Neden işletim sitemini ve ofisi geliştirmiyor?Neden telefon piyasasına girmiyor?Ama kendi orjinelliğiyle,kendi anlayışıyla.Android veya ios.a yazılım yazmak zorlarına gitmiyor mu?Kendileri yazılmcı iken başkalarının yazdığı yazılımı kullanmaktan rahatsız olmuyorlar mı?Mesala o öyle mi yapılır?Şöyle bir özellikte olsaydı demiyorlar mı?Bahsettikleri çalışanların çoğu (72 bini) dışarda insan kaynaklarıyla uğraşıyorlar anladığım kadarıyla.Merkezdeki çalışan sayısı az.Güzel yazılımlar bekliyoruz.
Tutku
Teşekkürler sayende hayallerim yıkılmadı herkes diyordu meslek yok şu yok bu yok diye gerçeği söylediğin için teşekkürler b///k
Kaan
C#, Asp.net, Java SE, Java EE, Spring Framework, Android, C++, C, PHP ödevlerinizde yardımcı olabilirim. Geçmişte yaptığım projelerden birkaç tanesini https://github.com/kaan8792 adresinden inceleyebilirsiniz.Not: Whatsapp üzerinden iletişime geçerseniz daha hızlı cevap verebilirim. İletişim için; Mail: kaan8792@gmail.com | Whatsapp: 05428339141
Ercan Sezdi
Elektrik elektronik mühendisliği okuyorum. Python ve C++ ödevlerinizi, python bitirme projelerinizi makul ücretler karşılığında yapabilirim. İletişim:ercansezdizero@gmail.com
Tatar Ramazan
Bırakın bu saçmalıkları ahirete çalışın. Özel sektörde namaz bile kılamazsınız. 3 günlük dünya için uğraş dur. Boş işler. Ben 22 yıl eve kapandım çalıştım 11 yaşından beri. İş dünyası ve kızlar yüzüme bile bakmadı. Mezunlar yoğun rekabet içinde kıvranıyor. Maaşlı eleman olmak için çırpınıyorlar. En zor işi yaptıracaklar size. Diğer taraftan bir sürü kişi kolay iş yaparak mercedese biniyor. Adam din kültürü öğretmeni oldu. Verdiğim emeğin çok daha azını verdi. Manken gibi de karı aldı. Biz ortada kaldık. Kemalizm boş vaadler sunuyor size. Laik kapitalist firmalar çoğunuza köpek gibi davranacak. Atatürkçü anne babalarınız ve öğretmenleriniz ahiretinizi düşünmüyor. Gaflet ve dalalet içinde yaşıyorsunuz. Ölünce çarpılırsınız. Bir sabah namazı özelde 20 bin maaş almaktan daha hayırlıdır. Çünkü ahiret sonsuzdur.
ismet
10. madde ne zamana gelir bekliyorum.
Tatar Ramazan
Bu iş zordur. Yüksek kapasite gerekir. Bazı firmalar ALES 85 olsa iyi olur diye ilanda yazar (would be an asset). İyi para kazanan, iyi kariyer yapanların çoğu ilk 5 bine girmiş adamlardır. Ben 16500.üncü olmuştum. Bizim bölümün birincisi bile öyle havada kapılmadı. Benimle aynı yerde sayılır konum ve para olarak. Çoğunuz en fazla bir kurumsal firmada vasat bir maaşa çalışırsınız. O da iyiyseniz. Ne Devlet ne de özel size iyi para vermek istemeyecek. Yoğun rekabet var. KPSS lisans çok zorlaştı. 2006-2008 arası sorularda 85-90 yapardım. Şimdi 75 puanı geçemiyoruz. Bu durumda çoğu özel firma tabii ki yüksek maaş vermez muhtaçsınız onlara diye. Mesleğin ve sektörün sıkıntılı taraflarını yazdım 20 madde çıktı. Yazılımcı olacaksanız bari javacı olun. Microsoft devamlı yeni teknoloji çıkarıyor. 3 senede eskirsiniz. Javada rakip daha az. 10 yıl deneyimliyim. 8 bin maaşa bile devlete giremiyorum bilişim uzmanı olarak. Site sahibi yazmış "Ayrıca 10 yıllık tecrübelere sahipseniz genellikle şirketler size çok yüksek maaşlar yerine hisse yada kar payı önermeye başlayacaklardır." He he öyledir(!..) Ben Ankarada özelden bizim kuruma kaçan 5-10 yıl deneyimli 10 kişi gördüm. 10 yıl deneyimli bilişim uzmanı aldık. Zavallı adama 3 kat maaş vermeleri gerekirken 2 kat olarak aldılar (5 yıl ve üstü deneyimde 3 kat brüt ücret veriliyor normalde). Her yer en iyi adama en az para vermeye çalışıyor. Hayattan adalet beklemeyin. Ben 10 yıldır milyar dolarlık zenginler gibi çalıştım yer yer. 10 tane teknolojiyi A dan Z ye öğrendim. Binlerce sorun çözdüm kod yazdım. Sonra MVC-Core modası çıktı. İş dünyası beni anında deliğe süpürdü. Memurluktan istifamı versem aç kalırım aç. Daha yükselmem gerekirken, çok iyi paralar kazanmam gerekirken düştüğümüz hale bak. Verdiğim emeğin onda birini vermeyenler benden çok daha iyi hayat yaşadılar ve de yaşamaya devam ediyorlar. Mesela adam mesleki ve İngilizce bilgisi olarak boş tenekeydi. Yurtdışına gidiyor devamlı. 1 sene kalıyor. Her gidişinde 10 tane ülke dolaşıyor. Ticaret yapıp yolunu buluyor. Ben size çalışmayın demiyorum. Hiçbiriniz başarılı, mutlu olamazsınız demiyorum. Umudunuzu koruyun. Bir kısmınız iyi yerlere gelecektir tabii ki. Ama önemli bir bölümünüz aradığını bulamayacak. Belediyeye bile almayacaklar. Çalışmazsanız toplum sizi suçlar. Çalışın ki en azından ben çalıştım ne yapayım meslek fos çıktı dersiniz. İnsanlar zalimdir. Cahildirler. Halden anlamazlar. Kıytırık harita mühendisi torpille Belediyeye girer. Onu adam görürler görüntüsü boyu da varsa. Sen çok daha kalitelisindir ama işsiz kalsan sana saldırılar. Düz mantıkla hareket ederler. İnce düşünemezler. Site sahibi para kazanamamaktan değil saygı kazanamamaktan korkun diyor. Şunu belirteyim ki: İş dünyası size köpek gibi davranacak. Toplum size saygı bile duymayacak. Kız da vermeyecekler. Verecek kızları yok zaten. Hepsinin sevgilisi var. Mezun olunca az sövün lan. Yazıktır. Milletin anası, karısı, bacısı var. Sizdeki de iyi cesaret haa! Derece yapanlar mühendislikten kaçıp Tıbbı yazıyor. Siz cesur davrandınız bu hengameye soktunuz kendinizi. %10-15 iniz yolunu bulur. Diğerleriniz için El-Faaaaaatiha!...Bilişim çağı, geleceğin mesleği de iyi keklemişler sizi. Doğrudur her şey yazılımla oluyor. Yapılacak daha çok yazılım var. Çok yazılım talebi var. Ama iyi para kazanıp bi bok olamıyorsun ki. Sen bir bankaya başvuruyorsun senin gibi 3000 kişi de saldırıyor. Benim gibi memur (kariyer uzmanız biz mühendisin bir üstü) olan arkadaş 7600 TL maaş alıyor. İstanbulda 6000 TL ye 6 yıl deneyimli adam çalıştırıyorlar. 2 çocuklu aile ancak geçinir. Sadece araba masrafları bir ton tutuyor. Hayat zor. Bu maaşları yüksek zannetmeyin. Mesleğin ve sektörün sıkıntılarını yazayım mı? Yok boooluum bunalıma girmeyin şimdi. Sonra yazarız. Realist olun. Kendinizi kandırmayın. Genetik-yaratılış olarak kime benzediğinizi tespit edin. Kaderiniz, eşiniz ve hayattaki başarınız ona benzeyecektir. Sistem okullarda insanlara boş hayaller sunuyor. Çoğunluk avucunu yalıyor. Kendilerini kandırıp 35-40 yaşına kadar iyi iş, iyi eş arıyorlar. Bulacak olan hemen bulur iyisini. 1 yılda olmuyorsa 10 senede de olmaz. Karşınıza çıkan işi ve eş adayını reddetmeyin. Daha iyisini beklemek sadece zaman kaybı. Daha kötüsü gelir. Zaman geçtikten sonra değil şimdi akıllanın. Tecrübe konuşuyor burda. İyi kıvranmalar...
cöp
robot yazmis bak authorize yapmamissin patlatmis
İsmet
Ödev yaptırarak derslerinde öne geçenler şerefsizdir.
İsmet
Ödev yaptırarak derslerinde öne geçenler şerefsizdir.
İsmet
Ödev yaptırarak derslerinde öne geçenler şerefsizdir.
İsmet
Ödev yaptırarak derslerinde öne geçenler şerefsizdir.

Bilgisayar Mühendisleri
Here is the website inspired me to use 
it as a guide when I tried to define 
myself as an engineer candidate a few 
years ago. It really helped me to work
 and study feeling in confidence with 
being on the right way. I suggest this 
website to whom it may direct her/his 
to find the right career path. It 
includes many articles varies from 
real life experiences to detailed 
software engineering issues. But the 
most dignified parts for me are the 
articles in general and career titles.
Son okunan makaleler:
Daha iyi kod için 12 adım - Joel Spolsky
Transact-SQL - T-SQL - SQL NEDİR?
Online Java Dersleri - Polimorfizm
Online Java Dersleri - Java NEDİR?
2016 ekonomik krizi
İSTANBUL İSTANBUL İSTANBUL
En büyük sıkıntı
DAYINIZ YOK MU?
Amerika tartışıyor. Programlama dersleri ne zaman başlamalı?
İşsizlik psikolojisi
Bilgisayar mühendisliği öldü?
Database programlama...
Differences between ASP and ASP.NET
İSTANBULU SEÇİN!
Gül'den gençlere öğütler: Boşa zaman geçirmeyin
Yazılım Mühendisliği ve Bilgisayar Mühendisliği arasındaki farklar
Bilgisayar Mühendisi olmanın 10 iyi yönü.
Kulak asmayın.
Patlaklar ordusuna katılacaklara 12 altın öğüt.
Soru sormayı bilmek?

Bilgisayar Mühendisleri Portalı

Daha iyi kod için 12 adım - Joel Spolsky

Daha iyi kod için 12 adım
Joel Spolsky
Fikret Ulug tarafından çevrilmiştir
Ozgur Aydin Yuksel tarafından düzenlenmiştir
9. 8. 2000

SEMA adını hiç duydunuzmu?. SEMA bir yazılım ekibinin ne kadar iyi olduğunu ölçmeye yarayan nispeten anlaşılması zor bir sistemdir. Ancak durun! Hemen bu linke geçmeyin! Burada yazılı olanları anlamanız sizin yaklaşık 6 yılınızı alır. Bu nedenle, yazılım ekibinin kalitesini belirlemek üzere yüzde yüz doğruya yakın, çarçabuk hazırlanmış kendi testimi geliştirdim. Bu testin en büyük avantajı sadece 3 dakika sürmesi. Tasarruf edeceğiniz zamanda da tıp okumayı deneyebilirsiniz.
Joel Test
  1. Kaynak kodu kontrol sistemi kullanıyor musunuz?
  2. Tek bir adımda sistemi oluşturabiliyor musunuz?
  3. Sistem oluşturma (build) işlemi günlük yapılıyor mu?
  4. Hata veritabanınız var mı?
  5. Yeni bir kod yazmadan önce hataları düzeltiyor musunuz?
  6. Güncel iş takviminiz var mı? 
  7. İş tanımlamalarınız var mı?
  8. Programcıların sakin bir çalışma ortamı var mı?
  9. Paranın alabileceği en iyi araçları kullanıyor musunuz?
  10. Test elemanınız var mı?
  11. İş görüşmelerinde adaylara kod yazdırılıyor mu?
  12. Koridor kullanım testi yapıyor musunuz?
Joel Test’in en güzel tarafı her bir soruya kısa Evet veya Hayır yanıtı verilebiliyor olmasıdır. Günlük yazılan satır sayısı veya her bir bükülme noktası için ortalama hata sayısını bilmeniz gerekmez. Ekibinize her bir “evet” yanıtı için 1 puan verin. Ancak bu testi nükleer santral yazılımınızın emniyetli olup olmadığından emin olmak için kullanmamanız gerekir.
12 puan mükemmel, 11 idare edilebilir, fakat 10 veya daha düşük ise ciddi sorunlarınız var demektir. İşin doğrusu birçok yazılım şirketi 2 veya 3 puan ile çalışmakta ve bu şirketlerin ciddi yardıma ihtiyacı var. Çünkü Microsoft gibi firmalar her zaman12 puan ile çalışmakta.
Şüphesiz bunların dışında da başarı veya başarısızlığı belirleyen faktörler var: Diyelim ki mükemmel bir yazılım ekibiniz var ve hiç kimsenin istemediği bir ürün üzerinde çalışıyorlar. Sonuçta kimse o ürünü istemeyecek. Veya yukarıda sözü geçen özelliklere sahip olmaksızın dünyayı değiştiren inanılmaz yazılımlar yaratan silahşörler ekibi düşünülebilir. Kurallarımız bunların dışındaki tüm durumlarda geçerlidir, yani, bu 12 maddeyi karşılıyorsanız istikrarlı biçimde ürün çıkaran disiplinli bir ekibiniz var demektir.
1. Kaynak kodu kontrol sistemi kullanıyor musunuz?
Ticari kaynak kodu kontrol paketlerini kullandım, ücretsiz olan CVS’yi kullandım, CVS’nin gayet iyi olduğunu rahatlıkla söyleyebilirim. Eğer kaynak kodu kontrolunuz yoksa, programcıları birarada çalışmaya zorluyorsunuz demektir. Programcıların diğerlerinin ne yaptıklarını bilme şansı yoktur. Hatalar kolaylıkla geri alınamazlar. Kaynak kodu kontrolunun bir diğer güzel özelliği, kaynak kodlarının her programcının hard diskinde kaydedilmiş olmasıdır—Bu güne kadar kaynak kodu kontrol sistemi kullanan bir projede büyük miktarda kodun kaybolduğunu hiç duymadım.
2. Tek bir adımda sistemi oluşturabiliyor musunuz?
Bununla kastettiğim şu: Kaynak kodlarının son halinden bir sistem oluşturmak kaç adım gerektirmekte? İyi ekiplerde, tüm kaynak kod ayrılışlarını en baştan oluşturan tek bir betik (script) vardır, her bir kod satırı yeniden oluşturulur, EXE’ler yaratılır, tüm değişik sürümler, diller, ve #ifdef kombinasyonları için kuruluş paketi ve son ürün (CDROM oluşturulması, web sitesi güncellenmesi gibi) yaratılır.
Eğer bu işlem birden fazla adımı içeriyor ise, hataya açık demektir. Üstelik ürün dağıtımı aşamasına gelindiğinde “en son” hataların düzeltilmesi, son EXE’lerin yaratılması çevriminin çok hızlı yürümesi gerekir. Eğer kodun derlenmesi, kuruluş oluşturucunun çalıştırılması gibi işlemler için 20 adım gerekiyorsa, zamana karşı çalışılan bu çok sıkışık ortamda deli olmanız işten değildir ve çok aptalca hatalar mutlaka yapılır.
Bu yüzden çalıştığım son şirket WISE’den InstallShield yazılımına geçiş yaptı: Çalışma ortamımız, kuruluş işleminin, NT'de otomatik olarak gece çalışmasını gerektiriyordu ancak WISE bunu sağlayamadı, bu yüzden bu ürünü kullanmaktan vazgeçtik.(İyi niyetli WISE ekibi son sürümlerinin gece sistem oluşturulmasını sağlayacağı konusunda bana garanti verdiler)
3. Sistem oluşturma işlemi günlük yapılıyor mu?
Kaynak kodu kontrol sistemi kullanılırken, bazen bir programcı kazara oluşturulan sistemi bozan bir değişiklik yapar. Örneğin, yeni bir dosya eklenir, kendi bilgisayarında herşey doğru çalışır, ancak bu dosyayı kod deposuna aktarmayı unutur. Bilgisayarını kapatıp olan bitenden habersiz evine gider, mutludur. Ancak diğer tüm programcıların çalışması durur ve sonuçta diğer herkes evine gider ama kimse sevgili programcımız kadar mutlu değildir.
Sistemin oluşturulmasının bozulması çok kötü (ve çok yaygın) bir durumdur. Bu nedenle günlük sistem oluşturulmasını zorunlu hale getirir. Bu sayede sistemde oluşan hiçbir bozulma gözden kaçmaz. Büyük ekiplerde, bozulmaların hemen duzeltilmesini garanti etmenin en iyi yolu öğle arasında günlük sistem oluşturulmasının yapılmasıdır. Herkes yemekten önce olabildiğince çok değişikliği kaydeder. Geri döndüklerinde sistem oluşturma işlemi tamamlanmıştır. Eğer herşey yolunda ise ne ala! Herkes kaynak kodlarının son haliyle devam eder. Eğer sorun var ise , düzeltme işlemi yapılır, fakat bu sırada herkes bozulma olmayan daha önce oluşturulmuş kaynak kodları üzerinde çalışmaya devam edebilir.
Excel ekibinde sistem oluşturulmasının hatalı olmasına neden olan kişiye ceza olarak, bir sonraki hataya kadar sistem oluşturma işlemleriyle ilgilenme zorunluluğu getiriyorduk. Bu yanlış yapmamak için iyi bir motivasyon olmasının yanısıra, herekese işlerin nasıl yürüdüğünü öğretmenin iyi bir yoluydu da.
Günlük sistem oluşturma ile ilgili daha ayrıntılı olarak Günlük Sistem Oluşturma Sizin Arkadaşınızdır isimli makalemi okuyabilirsiniz
4. Hata veri tabanınız var mı?
Ne derseniz deyin eğer tek başınıza bile kod yazıyorsanız, kod içinde oluşan bilinen tüm hataları listeleyen bir veri tabanı yok ise kod kalitesi düşer. Birçok programcı hataları hafızalarında tutabileceklerini düşünür. Ance bu çok saçmadır. 2 veya daha fazla hatayı aynı zamanda hatırlayamam ve bir sonraki gün, sistemin dağıtımı aşamasında unutulur. Hataların mutlaka çok ciddi bir şekilde takip edilmesi gerekir.
Hata veritabanı çok basit veya çok karmaşık olabilir. Minimum veri tabanı her bir hata için aşağıdaki bilgileri içermelidir:
  • Hatanın yeniden yaratılması için gereken tüm adımlar
  • Beklenen davranış
  • Gözlenen (hatalı) davranış
  • Sorumlu kişi
  • Düzeltilip düzeltilmediği
Eğer hata takip yazılımının karmaşık olması hata veri tabanı oluşturmanıza engel oluyorsa, yukarıda belirlenen önemli alanları içeren 5 sütunlu bir tablo oluşturun ve kullanmaya hemen başlayın.
Hata takip sistemi konusunda daha detaylı bilgi için Sorunsuz Hata Takibi yazımı okuyabilirsiniz.
5. Yeni bir kod yazmadan önce hataları düzeltiyor musunuz?
Windows için Microsoft Word’ün ilk sürümü “ölüm marşı” projesi olarak adlandırılmıştı. Sürekli gecikmeye uğradı ve hiçbir zaman bitirilemedi. Tüm ekip anlamsız uzun saatler boyunca çalışıyordu fakat proje tekrar tekrar gecikiyordu, herkesin üzerinde inanılmaz bir stres oluşmuştu. Lanet şey en sonunda piyasaya sürüldüğünde bir yıl gecikmiş durumda idi. Microsoft tüm ekibi Cancun’a tatile gönderdi ve ciddi bir vicdan muhasebesine girişti.
Farkedilen en önemli şey proje yöneticilerinin “takvim” konusunda çok ısrarcı olmaları nedeniyle programcıların kodlama işlemini alelacele yapmaları, hata düzeltme aşaması programın bir parçası olmadığı için de yazılan kodun çok kötü olmasıydı. Hata sayısını azaltma konusunda hiçbir çaba gösterilmemişti. Tam tersine uygulanan yöntem hata sayısının artmasına neden olmuştu. Bir yazı karakterinin yüksekliğini ölçmek için kod yazması gereken programcının kısaca “return 12” yazdığı ve bunun her durumda doğru çalışmadığını görmek için hata raporunun gelmesini beklediği rivayet edilir. Takvim, hatalara dönüşmeyi bekleyen özellikler listesinden ibaret hale gelmişti. Çalışma sonu özeleştiri raporlarında bu durum “sonsuz hatalar metodu” olarak adlandırıldı.
Problemi düzeltmek için Microsoft tüm birimlerinde geçerli olacak şekilde “sıfır hata metodunu” adapte etti. Firma içindeki programcıların çoğu, bu duruma kıkır kıkır güldü. Yönetimin, tepeden gelen bir emirle tüm hataları sıfırlamak istediği sanıldı. Aslında “sıfır hata”, herhangi bir anda yeni bir kod yazmadan önce en yüksek önceliğin hataların düzeltilmesine verilmesi anlamına geliyordu. Neden böyle olduğu şöyle açıklanabilir.
Genellikle, bir hatayı düzeltmeden önce ne kadar uzun süre beklenirse hatanın düzeltilme maliyeti(zaman ve para olarak) o kadar yüksek olur.
Örneğin, derleyicinin yakaladığı yazım veya söz dizimi hatası yapıldığında, bu hatanın düzeltilmesi çok basit bir işlemdir.
Kod içinde ilk çalıştırmada ortaya çıkan bir hata var ise, bu hatayı hemen hemen hiç zaman harcamadan düzeltebilirsiniz, çünkü kodun tamamı aklınızdadır.
Eğer birkaç gün önce yazmış olduğunuz bir kodda hata bulursanız, hatayı yakalamanız biraz zaman alabilir, fakat yazdığınız kodu tekrar okuduğunuzda herşeyi tekrar hatırlarsınız ve hatayı kabul edilebilir bir sürede düzeltebilirsiniz.
Fakat, birkaç ay önce yazmış olduğunuz kod içinde bir hata bulursanız, kod hakkında muhtemelen birçok ayrıntıyı unutmuş olduğunuz için hatanın düzeltilmesi çok daha zor olacaktır. Bu esnada bir başkasının kodunu düzeltiyor olabilirsiniz ve bu kodu yazan programcı Marmaris’te tatilde olabilir. Bu durumda hatanın düzeltilmesi bilimsel bir keşif gibidir: Ağır, metodlu ve büyük bir titizlik içinde çalışmanız gerekir ve tedaviyi bulmanızın ne kadar süre alacağı konusunda tahmin yürütmeniz çok zordur.
Ve eğer dağıtımı yeni yapılmış bir kod içinde hata bulduysanız, bu hatanın düzeltilmesi için inanılmaz miktarlarda harcama yapmanız gerekecektir.
Tüm bu nedenler hataların derhal düzeltilmesini gerekli kılar: çünkü daha az zaman alır. Bir diğer neden ise, yeni bir kodun yazılmasının alacağı sürenin, var olan bir hatanın düzeltilmesinin alacağı süreye göre daha kolay tahmin edilmesi ile ilgilidir. Örneğin, eğer size bir listeyi sıralamak için ne kadar süre gerektiğini sorarsam bana doğruya yakın bir tahminde bulunabilirsiniz. Ama eğer Internet tarayıcının 5.5 sürümü yüklendiğinde programınızın çalışmama nedenini tahmin etmenizi istersem, hiçbir tahminde bulunamayabilirsiniz, çünkü tanım gereği hataya neyin sebep olduğunu bilmiyorsunuz. Hatanın bulunması 3 günde sürebilir 2 dakikada sürebilir.
Tüm bunlar, düzeltilmek üzere bekleyen birçok hatayı içeren bir çalışma takviminiz var ise, bu takvim güvenilir değil anlamına gelir. Ama eğer tüm bilinen hataları düzeltti iseniz, ve geriye sadece yeni kodların yazılması kaldı ise, çalışma takviminiz çok daha gerçeğe yakın olacaktır.
Hata sayısının sıfırda tutulmasının diğer büyük yararı ise rekabet avantajı sağlamasıdır. Bazı programcılar bunu ürünün her an sürüme hazır halde bulundurulması olarak düşünürler. Eğer rakip firma müşterileriniz çalan yeni bir özellik geliştirdi ise, sadece bu özelliği ekleyerek, birikmiş birçok hatayı düzeltmeye gerek kalmaksızın hemen yeni ürününüzü piyasaya sürebilirsiniz.
6. Güncel iş takviminiz var mı?
Eğer geliştirdiğiniz kod işiniz açısından önemli ise, kodların yazımının ne zaman tamamlanacağının işiniz açısından önemli olması için birçok nedeniniz var demektir. Programcılar tahmin yürütme konusundaki aksilikleri ile meşhurdur. Satıcı personele “tamamlandığında bitecek” diye çıkışırlar.
Ne yazık ki bu işin tamamlanmasını garanti etmez. Ticaretin gerektirdiği birçok planlama kararına ihtiyaç vardır: Demolar, ticari gösterimler, reklamlar bunlardan sadece bazılarıdır. Bunu yerine getirmenin tek yolu bir takvimin olması ve bu takvimin güncel tutulmasıdır.
İş takvimi olmasının bir diğer önemli yararı, hangi özelliklerin yerine getirileceği konusunda karar vermeye zorlamasıdır. Bu kararın ardından gereksiz özelliklerin (kapsam genişlemesi) sisteme eklenmesi yerine en az önemdeki özelliklerin seçilerek kapsam dışına alınma zorunluluğunu getirir.
İş planının güncel tutulması işleminin zor olması gerekmez. Çok yararlı iş planlarının nasıl yapılacağını görmek için Sorunsuz Yazılım İş Planları makalemi okuyabilirsiniz.
7. Belirtimleriniz var mı?
Belirtim (spec) yazma diş ipi kullanmaya benzer: herkes iyi bir şey olduğu konusunda görüş birliğindedir, ancak kimse kullanmaz.
Bunun neden böyle olduğunu bilmiyorum, fakat bu durum muhtemelen programcıların döküman yazmaktan nefret etmelerinden kaynaklanmaktadır. Sonuçta, problemi çözecek ekip tamamen programcılardan oluşuyorsa, açıklamalarını döküman yerine kaynak kodu içinde ifade etmeyi tercih ederler. Programcı önce belirtim yazmak yerine hemen kodlamaya başlar.
Tasarım aşamasında, bir problem belirlendiğinde, tasarım notlarından birkaç satır değiştirilerek problem çözülür. Kod yazıldıktan sonra, problemlerin düzeltilme maliyeti hem zaman hem de duygusal olarak (insanlar yazdıkları kodu çöpe atmaktan hiç hoşlanmazlar) çok yüksektir. Bu nedenle, gerçekte problemlerin çözülmesine karşı direnç vardır. Belirtim kullanılmadan yazılan yazılımlar genellikle kötü tasarlanmış duruma düşerler ve iş planı kontroldan çıkar. Netscape programında olan durum budur. İlk dört sürüm öylesine karmaşık bir hal aldı ki sonunda yöneticileri aptalca bir kararla kodu tamamen çöpe atarak yeniden yazmaya karar verdiler. Daha sonra aynı hatayı Mozilla ile, alfa aşamasına gelmesi birkaç yıl alan bir çalışma ile kontroldan çıkmış bir canavar yaratarak tekrar ettiler.
Benim bu konudaki basit teorim, programcıları yazma konusunda sıkıştırılmış bir kursa göndererek onların yazmaya karşı daha az dirençli olmalarını sağlayarak problemin çözülebileceğidir. Bir diğer çözüm yazılı belirtimler üreten akıllı program yöneticileri tutmaktır. Her iki durumdada mutlaka uygulanması gereken basit kural “belirtim olmadan kod yazılmamasıdır”.
Belirtim yazmayı ayrıntıları ile öğrenmek için dört kısımdan oluşan makalemiokuyabilirsiniz.
8. Programcıların sakin bir çalışma ortamı varmı?
Bilgisayar çalışanlarına sessiz ve kendi başlarına çalışabilecekleri bir ortamı sağlayarak verimliliğin artırılabileceği konusunda yazılmış çok yazı vardır. Klasik yazılım yönetimi kitabı olan Peopleware’de bu verimlilik artışı konusu ayrıntılı olarak yer almaktadır.
Hepimiz bilgisayar çalışanlarının çalışma ortamından tamamen bağımsız işlerine konsantre olduklarında çok iyi çalıştıklarını biliriz. Zamanı unuturlar ve iyi bir konsantrasyon ile mükemmel işler başarırlar.Bu zamanlar onların en verimli oldukları zamanlardır. Yazarlar, programcılar, bilim adamlar ve hatta basketbol oyuncuları aynı süreci yaşar.
Ancak sorun şu ki, “havaya girmek” çok kolay değildir. Ölçmek gerekirse, maksimum verimle çalışmaya başlamak için yaklaşık 15 dakikalık bir süre gerekmektedir. Bazan, çok yorgun iseniz veya o gün için verimli birçok çalışma yaptı iseniz, havaya giremezsiniz ve günün geri kalan kısmını internet’te gezinerek veya tetris oynayarak geçirirsiniz.
Bir diğer sorun ise konsantrasyonun çok kolay bozulabilmesidir. Gürültü, telefon, öğle yemeği için dışarıya çıkma, kahve almak için migrosa 5 dakika için gitme ve çalışma arkadaşları tarafından bölünme – özellikle çalışma arkadaşlarının araya girmesi – gibi nedenlerle konsantrasyon bozulur. Eğer bir çalışma arkadaşı sorusu ile sizi 1 dakika için meşgul ederse bu konsantrasyonunuzu öyle bozar ki,  tekrar verimli olarak çalışmaya dönüş yarım saat alabilir. Bu şekilde genel verimliliğiniz ciddi şekilde düşer. Eğer, kahvehane görünümlü nokta com şirketlerinin çok sevdiği gibi, pazarlama elemanlarının programcıların hemen yanı başında telefonda bağıra çağıra görüşmeler yaptığı bir ortamda iseniz verimliliğiniz bilgisayar çalışanlarının çalışmalarının kesintiye uğradığı ve konsantre olamadıkları oranda tehlikeye girer.
Özellikle programcılar için bu çok zor bir durumdur. Verimlilik, birçok küçük detayın kısa süreli bellekte aynı anda alınıp verilebilmesine bağlıdır. Herhangi bir araya girme bu küçük detayların kaybolmasına neden olur. Çalışmaya yeniden döndüğünüzde, bu detaylardan hiçbirini hatırlamazsınız (kullanmakta olduğunuz bölgesel değişkenler, veya bir arama algoritmasının uygulanmasına geçmek üzere olduğunuz aşama gibi). Tüm bu detayları hatırlamanız, eski verimli çalışma hızınıza erişmeniz içi bir sürü zaman kaybetmeniz gerekir.
İşte size basit bir hesap. Eğer bir programcının çalışmasını sadece bir dakika için dahi bölersek (ki veriler bu yönde) 15 dakikalık bir verimli çalışmayı yok ediyoruz demektir. Bu örnek için Can ile Pınar’ı birbirine komşu iki odacıkta çalışan iki programcı olduğunu varsayalım. Can strcpy rutininin unicode sürümünün adını hatırlamamaktadır. Açıp bakabilir ve bu sadece 30 saniyesini alır, veya Pınar’a sorabilir, bu da sadece 15 saniyesini alır. Pınar hemen bitişiğinde olduğu için ona sorar. Pınar’ın dikkati dağılır ve Can’a 15 saniye kazandırmak için verimli çalışmasından 15 dakika kaybeder.
Şimdi bu iki programcının farklı odalarda olduğunu varsayalım. Can rutinin adını hatırlamadığında açıp bakabilir ve hala bu işlem onun sadece 30 saniyesini alır veya pınara sorabilir ki bu sefer ayağa kalkıp yürümeyi gerektirir (programcıların fiziksel sağlık durumları gözönüne alındığında bu pek de kolay bir faaliyet değildir!) ve 45 saniyesini alır. Can dökümanlara bakmaya karar verir. Sonuçta Can verimliliğinden 30 saniye kaybeder fakat Pınar’ı 15 dakikalık kayıptan kurtarmış oluruz.
9. Paranın alabileceği en iyi araçları kullanıyor musunuz?
Eğer derleme  işleminiz birkaç saniyeden fazla sürüyorsa, en yeni ve en hızlı bilgisayarı almanız size zamandan tasarruf sağlar. Eğer derleme 15 saniye sürerse, programcılar sıkılır ve derleyici çalışırken Soğan’ı okumaya başlarlar ki bu da saatler sürecek verimlilik kaybına neden olur.
GKA (Grafik kullanıcı arayüzü) kodlarında bir ekran ile yanlış ayıklama işlemi imkansız olmasa da çok sıkıntılıdır. Eğer GKA kodu yazıyorsanız iki ekran işleri çok kolaylaştırır.
Birçok programcı eninde sonunda araç çubukları veya simgeler için ikil eşlemli (bitmapped) resimler üzerinde çalışmak zorunda kalır. İkil eşlemli resimleri değiştirmek için Microsoft Paint programının kullanılması kötü bir şaka gibidir, ancak birçok programcı bunu yapmak zorunda kalır.
Son işimde, sistem yöneticisi  bana hard diski gereğinden fazla kullandığımı (dikkat! 220MB) bildiren otomatik mesajlar göndermeye başladı. Hard disk fiyatları gözönüne alındığında kapladığım alanın maliyetinin kullandığım tuvalet kağıdının maliyetinden çok daha az olduğunu belirttim. 10 dakikalik temizlik çalışması bile verimliliğimde önemli bir kayıp olurdu.
Büyük hedefler için çalışan ekipler programcılarına eziyet etmezler. Yetersiz araçların neden olacağı çok küçük sıkıntılar bile programcıları mutsuz ve hırçın yapar. Hırçın programcı verimsiz programcıdır.
Son olarak, programcılar onlara verilecek en son ve en havalı bir araç ile kolayca tav olurlar. Bu onların sizin için çalışmasını sağlamak üzere diğer firmalar ile rekabet edecek yüksek maaş vermekten çok daha ucuz bir yoldur.
10. Test elemanınız var mı?
Eğer ekibinizde herbir iki veya üç programcı için bir test elemanı yoksa, hatalı ürünleri piyasaya sürüyorsunuzdur veya saat ücreti 30 USD olan test elemanları yerine saat ücreti 100 USD olan programcıları kullanarak paranızı boşa harcıyorsunuz demektir. Test personelinden tasarruf etmek çok berbat bir ekonomik hesaptır ve ne yazık ki giderek daha fazla kişinin bunu farketmiyor olması beni çok şaşırtıyor.
Bu konu üzerine yazdığım, Test elemanına sahip olmamanızın en önemli beş (yanlış) nedeni isimli makalemi okuyun.
11. İş görüşmelerinde adaylara kod yazdırılıyor mu?
Size sihirli numaralar göstermeden bir sihirbazı işe alırmısınız? Tabi ki hayır.
Düğün partisi için yiyeceklerini tatmadan bir yemek firması tutar mısınız? Çok az bir olasılık. (Sözkonusu olan Macide teyze ise, onun meşhur kekinden yapmasına izin vermediğiniz için sizden ömür boyu nefret edebilir).
Ancak, birçok yerde, programcılar etkileyici resume’leri görüşmeyi yapanlar tarafından çok beğenildiği için işe alınmaktadır. Veya “CreateDialog() ile DialogBox() arasındaki fark nedir” gibi, dökümana bakılarak kolayca yanıtlanabilecek saçma sorular sorulmaktadır. Programcının programlama üzerine yüzlerce saçmalığı aklında tutmasının bir önemi yoktur, önemli olan nasıl kod yazdığıdır. Çok daha kötüsü ise  “AHA” tipi sorulardır: bu tip sorular yanıtı bilindiğinde çok basit ancak yanıtı bilmiyorsanız bulunması imkansız sorulardır.
Lütfen bütün bunları yapmaktan vazgeçin. Görüşme süresince ne istiyorsanız yapın, fakat adayın bir miktar kod yazmasını sağlayın. Daha fazla öneri için Görüşme için gerilla taktikleri başlıklı yazımı okuyun.
12. Koridor kullanım testi yapıyor musunuz?
Koridor kullanım testi, koridordan geçen ilk kişiyi yakalayıp yazmış olduğunuz kodu kullanmasını sağlamaktır. Bu işlemi beş kişide denerseniz, kodunuzun kullanım problemleri hakkında %95’e varan oranda bilgiye sahip olursunuz.
İyi arayüz tasarımı tahmin edildiği kadar zor değildir ve müşterinizin ürününüzü sevmesi ve satın alması açısından çok büyük önem taşır. Programcılar için kısa bir giriş olan, Arayüz tasarımı üzerine ücretsiz online kitabımı okuyabilirsiniz.
Arayüzlerle ilgili en önemli konu, programınızı bir miktar kullanıcıya (aslında beş veya altı kişi yeterlidir) gösterdiğinizde çabucak insanların zorlandıkları yeri farkedersiniz. Bunun nedeni için Jakob Nielsen’in makalesini okuyun. Arayüz tasarım becerileriniz yeterli olmasa dahi, kendinizi hiçbir maliyeti olmayan Koridor kullanım testini yapmaya zorlarsanız, programınızın arayüzü çok daha iyi hale gelir.
Joel Testini kullanmanın dört yolu
1.      Yazılım firmanızın seviyesini ölçün ve bana bildirin. Ben de dedikodusunu yapayım.
2.      Programlama ekibinin yöneticisi iseniz, bu kontrol listesini kullanarak ekibinizin mümkün olduğu kadar iyi çalıştığından emin olun. 12 puan almaya başladığınızda programcılarınızı kendi haline bırakın ve tüm zamanınızı pazarlama elemanlarının onları rahatsız etmesine engel olmaya adayın.
3.      Bir programlama işini almak konusunda karar aşamasında iseniz, müstakbel yöneticinize bu testin sonucunun ne olduğunu sorun. Eğer çok düşük ise, işleri düzeltmek için yetkiniz olduğundan emin olun. Aksi halde hayal kırıklığına uğrarsınız ve verimsiz çalışırsınız.
4.      Eğer bir programlama ekibinin değerini ölçmek üzere yerinde inceleme yapan bir yatırımcı iseniz veya yazılım firmanız bir diğer firma ile ortaklık yapacak ise, bu test sizin pratik tahminler yapabilmenizi sağlar.


Bu makalenin orijinali İngilizce olarak The Joel Test: 12 Steps to Better Code başlığıyla yayımlanmıştır. 

Joel Spolski, New York şehrinde küçük bir yazılım şirketi olan Fog Creek Software'in kurucusudur. Yale Üniversitesi'nden mezun olmuş, ve programcı ve yönetici olarak Microsoft, Viacom ve Juno'da çalışmıştır.
Bu makaleyi beğendin mi? Yorumunu Yaz!







Sizden Gelen Yorumlar:

Yorum Yazın

Hakan(26.2.2010 04:00:30)
Herşey iyi,güzel hoş da siteyi hazırlayan arkadaşın ufak bi hatası makaleyi okumaktan vazgeçirdi...

Makale içinde geçen "Günlük Sistem Oluşturma Sizin Arkadaşınızdır" ve "Sorunsuz Hata Takibi" ifadelerine verilen linklere bir bakar mısınız....... Bilgisayar Mühendisliği temalı bir siteye hiç de yakışmamış...
%20 %0 %80
Katılıyorum Çekimserim Katılmıyorum






Copyright© 2001-2019. Bilgisayar Mühendisleri Portalı | Bütün hakları saklıdır.