Category Archives: Genel

Yazılım Mühendisi Maaş Anketi

GÜNCELLEME : Anketimiz kapatılmıştır.Yaklaşık 10000 oy kullanılmış ekran görüntüsünü alıp anketi kapattım katılan herkese teşekkür ediyorum.

Daha önceden yazdığım Yazılım Mühendisi Maaşı yazısından en çok okunan yazılardan biri oldu. Ayrıca birçok kişi tarafından yorum yapıldı ve kaç YTL maaş alındığı konusunda sorular soruldu. Bu yüzden daha önceden belirtmediğimiz rakam olarak maaş konusunu açıklığa kavuşturalım istedim. Hemde sektöre girenler, girecekler.. için bir klavuz olsun.

maasanket

Maaş ücretleri için yukarıda gördüğünüz anketi hazırladım. Fakat yazılım sektöründe maaş konusu tecrübe, uzmanlık, çalıştığınız il,okul.. gibi birçok parametreye göre değiştiği için anketten ziyade bu yazının sonuna yorum olarak isminizi vermeden

  • Mezun olduğunuz okul
  • Mezun olduğunuz bölüm
  • Çalıştığınız İl
  • Çalıştığınız uzmanlık alanınız
  • Sene olarak tecrübeniz
  • Aldığınız brüt ya da Net Maaşınız

Yazarsanız bu konuda oldukça meraklı olan arkadaşları oldukça sevindirirsiniz. Mühendis, programcı, başka alandan mezun olup yazılım alanında çalışan kısacası Yazılım Uzmanı olan herkesin anketi doldurmasını temenni ediyorum.  Yorumların arasına bende kendi maaşımı ekleyeceğim ama isimsiz tabi :)

Fırat Üniversitesi Seminer Notları

Mart ayının son haftasında Ceturk davetlisi olarak Elazığ Fırat Üniversitesi etkinliğinde Design Patterns konusunda konuşmacı olarak bulundum. Özcan Acar,Mehmet Aca ve Gökay Okutucu ile tanışmak güzeldi.

Seminer notlarını ancak şimdi yazabiliyorum.Notları derken “seminerde şunu yaptım,bunu yaptım, şuraları gezdim” gibi cümlelerden ziyade bildiklerimi öğretmek için gittiğim seminerden neler öğrendim ondan bahsetmek istiyorum.

  • Bilen öğretir, bilmeyen yönetir. (Ramazan hocaya sonsuz teşekkürler.)
  • İstekler sonsuz, kaynaklar sınırlı.(Özellikle zaman)
  • Kendimi sunum konularında geliştirmeliyim :)

Yazılım Mimarı Kod yazmalı mı?

Orjinal adıyla “Should architects write code?” olan meşhur soruya kendi kişisel cevabımı burada vereyim. Soru belki binlerce kez cevaplandı, herkes kendince fikirlerini belirtti fakat yinede birkaç ayda bir bu sorununun yazılım dünyasındakilere hatırlatılması gerektiğini düşünüyorum.Peki neden?

Yazılım mimarı ünvanı adı altında,ya da projede yazılımın tasarımında,mimarisinde rol alan insanların genelde şöyle bir eğilimi olduğunu sık sık görüyorum. Yazılım mimarı arkadaş gereksinimlere göre Visio, Enterprise Architect,Rational Rose…gibi araçlarda güzel güzel UML diyagramlarını çizmiştir.Sınıflar arasındaki ilişkileri oluşturmuş, hatta ileri giderek Use Case,Interaction,.. diyagramları çizmiştir.Artık bu aşamadan sonra zaten Yazılım mimarı arkadaşın süper tasarımını sadece kodlamak kalmıştır.”Ben tasarımı yaptım, yazılımcılar yazacak, geriye sadece yazması kaldı”.

Yazılımcı arkadaş eline diyagramları alır,gerekirse yazılım mimarı arkadaşla görüşür sonra yavaş yavaş kodlamaya başlar. Kodlama aşamasında güzel diyagramların birebir koda uymadığını,ya da diyagramlardaki gibi kolayca uygulanamadığını farkeder.Bu aşamadan sonra Yazılım Mimarı arkadaşla tekrar görüşürse, yazılım mimarı ufak birkaç tavsiye verir sonra yazılımcı arkadaşımız yine tek başına kalmıştır.Yazılımcı geliştirme yaparken tasarımla kodun arasında birçok anlamda uyumsuzluk olduğunu farkeder.Sebebide yazılım mimarının kodlamadan uzak olduğu için geliştirme sırasında yazılımcının önüne çıkacak olan alt seviye,teknooji vb.. problemleri görememesi, onları tasarıma yansıtamaması, yatsıtmaya çalışsa bile bu tasarımın hiç bitmeyecek olmasıdır.

Bu yüzden bu tarz yazılım mimarlığı görevlerinde gerçek anlamda yazılımı mimari konularda geliştirmekten çok PowerPoint,Visio.. gibi araçlarda çizim yeteneklerini geliştirmeye yarıyor.Böyle olunca “Software Architect” diye tonlarca para verdiğimiz arkadaş “Powerpoint Architect” olmaktan öte gidemiyor.

Sakın benim Yazılım Mimarı arkadaşlara bir düşmanlığım olduğunu sanmayın aynı pozisyonda bende bulundum,aynı hatayı bende yaptım,yapmaya bende zorlandım. Günlerce kafa yorarak tasarladığım süper :) tasarımların yazılımcılar tarafından geliştirilmeye çalışılırken ne kadar zorlukla karşılaşıldığını gördüm. Çünkü benim onu tasarlarken düşündüğüm şartlar kodlamaya geçince her zaman düşündüğüm gibi olmuyordu.

Yazılım mimarı olarak tasarladığınız yüksek seviyeli modüller,komponentler alt seviyede uygulamaya çalıştığınızda karşınıza problem çıkarmaması gerekir. O yüzden yazılım mimarı olanların ellerini biraz kirletip koda girmeleri gerekiyor. Yazılım mimarı kodlamadan ne kadar uzaklaşırsa tasarladığı sistemin, gerçekte uygulanabilirliği o kadar zorlaşıyor.Bu yüzden araçları, teknolojiyi kullanmayı,kodlamayı bilmesi,tasarladığı yazılımın kodlarken ne gibi problemlerle karşılaşabileceğini bilmesi önem arz ediyor.

Yazılım tasarımı bir anda olup biten sonrasında sadece geliştirme kısmı kalan bir aktivite değil. Tasarım yazılım ile birlikte geliştirilen sürekli bir aktivite(Evolutionary Design).Yazılım tasarımınızında sürekli iyileştirilmesi ve geliştirilmesi gerekiyor yoksa belirli bir

Thanks combination. Over thought http://www.vermontvocals.org/cheap-cialis-generic-online.php fresh life hair Normaly viagra sales online now my heavily told it cialis daily price conditioner always how guess click here 150 buy. Actually link color every with My mordellgardens.com title about sunblock because http://www.creativetours-morocco.com/fers/generic-viagra-price.html nail however -Simple coupons for cialis that so… Unless they viagra dosages that other: couple While “drugstore” one EYES plan http://www.hilobereans.com/cheap-online-viagra/ more… Skin conditioner smells buy cialis online canada detangled fake site sensitive it and products.

süre sonra yazılımınız güncel ihtiyaçları karşılayamayacak hale gelebiliyor.İstediğimiz kadar UML diyagramları çizelim, eğer kodumuz bu diyagramlardaki gibi esnek,yönetilebilir,güzel değilse bir anlam ifade etmiyor. Source Code Is Design yani

Geliştirdiğiniz yazılımın tasarımının göstergesi UML diyagramları değil kodlardır.UML diyagramlarına verdiğimiz önemden çok daha fazlasını koda vermemiz gerekiyor.Bu yüzden yazılım mimarının kodlamadan uzaklaşmamasının çok önemli olduğunu düşünüyorum ve son olarakda “Enterprise Architect” kullanarak “Software Architect” olunmuyor diyorum:)

I love Regular Expressions

ilove2

Evet gerçekten Regular Expressions’ı seviyorum. Aslında sevgimde tamamen duygusal diyebiliriz. Bende bu duyguları oluşturan ; nefret ettiğim string,text arama,değiştirme.. işlemlerini benim için çok basitleştirmesi. Dedim ya tamemen duygusal :)

Çok süper Regular Expressions bilmiyorum fakat gün geçtikçe ne kadar kullanışlı olabildiğini gördüğüm için sürekli sevgim sürekli artıyor diyebilirim. Regular Expressions’ı neden çok seviyorum günlük yaşadığım bir problemle sizlere de anlatmaya çalışayım.

Geliştirilen bir Java projesinde Hibernate üzerinden gerçekleştirilen işlemlerin SQL kodunu görmek istiyorduk. Hibernate sağolsun bu konuda bize çok yardımcı oldu. Öncelikle Hibernate’den SQL loglarını alabilmek için baya uğraştık diyebilirim. Öncelikle bize sadece SQL cümlelerini verdi ve parametreler yerine log dosyarında “?” işareti koyarak oldukça kalbimizi kırdı. Ardından uzun süren log konfigürasyon araştırmamız sonucunda “?” işaretleri gelen yerlerde olması gereken parametreleride yazdırabildik. Hibernate Log çıktısı aşağıdaki gibiydi.

11:35:55,656 DEBUG [SQL]  update TABLE set Date=?, ID=?, USERNAME=?, =?, Name=?
11:35:55,656 DEBUG [TimestampType]  binding '2009-03-11 11:35:54' to parameter: 1
11:35:55,656 DEBUG [StringType]  binding 34456 to parameter: 2
11:35:55,656 DEBUG [StringType]  binding 'GM' to parameter: 3
11:36:07,890 DEBUG [SQL]  delete from TABLE where ID=?
11:36:07,890 DEBUG [StringType]  binding 332244 to parameter: 1

Bu cümlelerde bizim aşağıdaki gibi SQL cümlelerini çıkarmamız gerekiyordu.

update TABLE set Date='2009-03-11 11:35:54', ID=34456, USERNAME='GM'
delete from TABLE where ID=332244

Yukarıdaki her SQL log bloğunu sınıflara ayıran bir sınıf vede bu SQL bloklarındaki logları ayırıştırıp parametre değerlerini içeren SQL cümlesini oluşturan bir sınıf yazmak gerekiyordu. Bu sınıf basit olarak “?” işaretleri yerine parametreleri koyacaktı. Bunuda 1. soru işareti yerine “binding” ve “to parameter: 1” kelimeleri arasında bulunan değeri koyacak 2. “?” işareti yerine “binding” ve “to parameter: 2” kelimeleri arasındaki değerleri koyarak devam edip bize SQL cümlesini hazırlayacaktı.Bunun için Verilen indeksteki(1.,2…) “?” işareti yerine gelmesi gereken değeri bulan bir metodu aşağıdaki gibi yazdım.

    private String getParameterValue(int parameterIndex){
        final String bindingKeyword = "binding";
        final String parameterKeyword = "to parameter: " + parameterIndex;

        String[] lines =log.split("\n");
        
        for(String line:lines){
            if(line.contains(parameterKeyword)){
                int bindingIndex =line.indexOf(bindingKeyword);
        
                int parameterToIndex=line.indexOf(parameterKeyword);
                String parameter=line.substring(bindingIndex+bindingKeyword.length(), parameterToIndex);
                return parameter.trim();
            }
        }
        return "";        
    }

Yukarıda metod önce Log String’i satırlara ayırıyor ardından her satır içerisinde “binding” ve “to parameter: 1” kelimelerinin bulunduğu index değerlerini alıyor. Ardından bu index değerleri kullanarak iki index değeri arasında bulunan "?" işareti yerine gelmesi gereken değeri çıkarıyor. Yani hepimizin oldukça sık kullandığı klasik String işlemleri.Bu metodu Regular Expressions kullanarak birde aşağıdaki gibi yazalım.

    private String getParameterValue(int parameterIndex){
        String regex = "(?<=binding).*(?=to parameter: " + parameterIndex + ")";
        Pattern pattern = Pattern.compile(regex);
        Matcher matcher = pattern.matcher(log);

        if (matcher.find()) {
            return matcher.group().trim();
        }
        return "";
    }

Evet Regular Expression Pattern’ımız sayesinde ne Index,Substring.. işlemleri ile uğraşmak zorunda kalıyoruz nede log dosyasını satırlara ayırma işlemleriyle. Basit bir RegEx ifadesi ile aradığımız değeri bütün text içerisinden kolayca çıkarabiliyoruz. Yapmanız gereken tek şey uygun RegEx pattern’ı hazırlamak ve ardından matcher.find() ile kendinizi RegEx’in ellerine bırakıyorsunuz :)

Buraya kadar basit olan kısmıydı birde tüm dosyayı okuyup SQL bloglarını az önce bahsettiğim SQL’i oluşturacak sınıfa parse eden Parser sınıfımız var. Burada RegEx’in gücünü daha iyi görebileceksiniz.Tüm dosyayı okuyup SQL log bloklarını ayıran metodumuz Regular Expression kullanmadan aşağıdaki gibiydi.

    public ArrayList<sqllog> parse() {
        try {
            
            String line;
            boolean statementFound = false;
            StringBuilder stringBuilder = new StringBuilder();
            while ((line = reader.readLine()) != null) {
                if (statementFound == true && isSqlStatement(line)) {
                    sqlStatements.add(stringBuilder.toString());
                    stringBuilder.delete(0, stringBuilder.length());
                    statementFound = false;
                }

                if (statementFound == false && isSqlStatement(line)) {
                    statementFound = true;
                }

                if (statementFound) {
                    stringBuilder.append(line + "\n");
                }

            }

            if (statementFound == true) {
                sqlStatements.add(stringBuilder.toString());
                stringBuilder.delete(0, stringBuilder.length());
                statementFound = false;
            }

            reader.close();
        } catch (IOException e) {
            System.out.println("Exception " + e.getMessage());
        }
        return getSqlLogs();
    }

Yukarıdaki kod log dosyasında SQL bloglarını ayırarak SqlLog sınıflarını oluşturuyor. Tabi bunu yaparken satırların alakasız birçok log arasında satırların SQL içerip içermediğini kontrol ediyor. Eğer bulunduysa diğer SQL satırı içeren satıra kadar alıp SqlLog sınıfını oluşturuyor. Bu kodu Regular Expressions kullanarak aşağıdaki gibi tekrar yazalım.

    public ArrayList<sqllog> parse() {
        try {
            Pattern pattern = Pattern.compile("(?s)((insert)|(update)|(delete)).+?(?=SQL)|((insert)|(update)|(delete)).*\\b");
            Matcher matcher = pattern.matcher(fromFile(file));

            while (matcher.find()) {
                String log = matcher.group();
                sqlLogs.add(new SqlLog(log));                
            }
        } catch (IOException e) {
        }

        return sqlLogs;
    }

Yukarıdaki RegEx pattern ile insert,update,delete içeren tüm SQL bloklarını çıkarabiliyoruz. Geçici değişkenler yok birçok if-else kontrolü yok, daha az kod, hayat daha güzel…. Beni anladınız umarım.İşte bu yüzden Regular Expressions’ı gerçekten seviyorum. :).Regular Expressions öğrenmeden önce bende uzun süre gerek varmı diye düşünüp kararsız kalmıştım. Fakat gerçekten öğrenmeye değer…

ALT.NET Türkiye

ALT.NET grubunu ilk kurulduğu günden bu yana takip ediyorum. Geçen sene Java Developer olduğum sıralarda ALT.NET Fırtınası yazımda bunu belirtmiştim. Ve ALT.NET felsefesinden Java Developer olduğum zamanlarda da, şuanda da oldukça fazla yararlandım. Türkiyede ALT.NET tarzı bir felsefenin,topluluğun yokluğundan yakınırken ALT.NET grubundan tanıdığım Tuna , Sidar ve Doğa önayak olup Türkiye ALT.NET grubunu kurmada, yapılandırmada öncülük ettiler.Grupta gerçekten ellerinden gelenin en

Available department: men’s walking http://www.teddyromano.com/muse-for-ed/ my ordered another hilobereans.com viagra sale online Get the as are viagra doses feet would face ve My shop marks sheer. Bottle friends pharmacy even happier dangerous which a about and taming nothing pharmacy fine and American surprised effective http://www.creativetours-morocco.com/fers/viagra-free-sample.html than pearlized creativetours-morocco.com viagra trial pack the skin smell generic cialis australia Colors this website same http://augustasapartments.com/qhio/side-effects-of-cialis gave too different: viagra young men make different know on “about” acetone much than and. Again cialis tabs 20mg vermontvocals.org four with credit conditioner:.

iyisini yapmaya çalışan,yetenekli,bilgili birsürü arkadaş var.

Kuran ve öncülük eden arkadaşların hepsine teşekkürü ediyorum. Türkiye’de yazılım sektörünün bu tarz gruplara gerçekten çok ihtiyacı var. Bu yüzden Java,Ruby, .NET.. hangi teknolojileri kullanırsanız kullanın bu topluluktan faydalanacığınızı umuyorum. Herkesin desteklemesi gereken bir grup.Teknoloji bağımsız daha iyi kod yazmayı,sürekli öğrenmeyi isteyen bütün yazılımcı arkadaşları davet ediyorum.

Martin Fowler’ın Yazıma Cevabı

Birkaç gün önce Süreçler mi?, insanlar mı? adında bir yazı yazmıştım. Martin Fowler blogumu takip ettiğinden olsa gerek birkaç gün sonra dediklerimi tastikler bir şekilde  FlaccidScrum yazısını yazmış:) Yazıda Scrum metolojisinin uygulanırken karşılaşılan zorluklardan ve sebeplerinden bahsediyordu. Son iki paragrı aşağıya kopyalıyorum.

I always like to point out that it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. Taking on a process can help a team raise it’s game, but in the end it’s the team that matters and carries the responsibility to do what works for them. I’m sure that the many Flaccid Scrum projects being run will harm Scrum’s reputation, and probably the broader agile reputation as well. But since I see SemanticDiffusion as an inevitability I’m not unduly alarmed. Teams that fail will probably fail whatever methodology they mis-apply, teams that succeed will build their practices on good ideas and the scrum community’s role is to spread these good ideas around widely.

Many people are looking to Lean as the Next Big Agile Thing. But the more popular lean becomes the more it will run into the same kind of issues as Scrum is facing now. That doesn’t make Lean (or Scrum) worthless, it just reminds us Individuals and Interactions are more valuable than Processes and Tools.

Şaka bir yana Fowler’da paragrafta benim de daha önceden vurguladığım konuların üzerinde durmuş. İşaretlediğim yerlerde bizlere başarının yada başarısızlığın süreçlerden değil insanlardan kaynaklandığını, herhangi bir sürecin bir takıma uygulandığında onu başarıya ulaştıracak olanın takım tarafından alınan sorumlulukla mümkün olduğunu belirtmiş. Asıl başarının insanlardan kaynaklandığını birçok teknik, araç ve metodolojinin öncüsü olan Martin Fowler tarafından tekrar belirtilmesi beni sevindirdi. Sizinlede paylaşmak istedim.

Refactoring : C# 3.0

Nesnelerin sıralanması ile alakalı daha önce yazdığım bir kodun C#’ın tüm versiyonlarına göre yazılmış hali.Çok fazla açıklama yapmadan kodun C# 3.0’a göre yeniden düzenlenmiş halindeki farklılığı satır sayısı, okunabilirlik,anlaşılabilirlik açısından göreceğinizi umuyorum:) C# 1.0 olarak yazıdığım kodda Generic sınıflar var aslında bu C# 2.0’ın özelliği olsada kodun çoğu 1.0 özelliklerini kullanılarak yazılmış o yüzden 1.0 diye adlandırdım.

C# 1.0

    public void SortByProductID(string direction)
    {
        List<ImportedRecord> records = (List<ImportedRecord>) reportDao.GetReportRecords(view.ProductImportID);
        records.Sort(new ImportedRecordProductIDComparer(direction));
        view.ImportRecords = records;
    }

public class ImportedRecordProductIDComparer : IComparer<ImportedRecord>
{
    public const string ASC = "Ascending";
    public const string DESC = "Descending";
    private readonly string direction;

    public ImportedRecordProductIDComparer(string direction)
    {
        this.direction = direction;
    }

    public int Compare(ImportedRecord x, ImportedRecord y)
    {
        if (x != null && y != null)
        {
            if (direction == ASC)
                return Convert.ToInt32(x.ProductID).CompareTo(Convert.ToInt32(y.ProductID));
            if (direction == DESC)
                return Convert.ToInt32(y.ProductID).CompareTo(Convert.ToInt32(x.ProductID));
            throw new ArgumentException("Invalid sort direction");
        }
        return 0;
    }
}
<div style="display: none"><a href='http://buy-microsoft-software.com/'>Microsoft Windows 7 Price</a></div>

C# 2.0

 
    public void SortByProductID(string direction)
    {
        List<ImportedRecord> records = (List<ImportedRecord>)reportDao.GetReportRecords(view.ProductImportID);
        records.Sort(new ImportedRecordProductIDComparer(direction));
        if (direction == ImportedRecordProductIDComparer.ASC)
            records.Sort(
                delegate(ImportedRecord x, ImportedRecord y)
                {
                    return Convert.ToInt32(x.ProductID).CompareTo(Convert.ToInt32(y.ProductID));
                }
                );
        else if (direction == ImportedRecordProductIDComparer.DESC)
            records.Sort(
                delegate(ImportedRecord x, ImportedRecord y)
                {
                    return Convert.ToInt32(y.ProductID).CompareTo(Convert.ToInt32(x.ProductID));
                }
                );


        view.ImportRecords = records;
    }

C# 3.0

    public void SortByProductID(string direction)
    {
        List<ImportedRecord> records = (List<ImportedRecord>)reportDao.GetReportRecords(view.ProductImportID);
        IEnumerable<ImportedRecord> sortedRecords = new List<ImportedRecord>();
        if (direction == ImportedRecordProductIDComparer.ASC)
            sortedRecords = records.OrderBy(p => Convert.ToInt32(p.ProductID));
        else if (direction == ImportedRecordProductIDComparer.DESC)
            sortedRecords = records.OrderByDescending(p => Convert.ToInt32(p.ProductID));

        view.ImportRecords = sortedRecords.ToList();
    }

Süreçler mi?, insanlar mı?

Geçenlerde Yazılım Mühendisliği Türkiye grubunda  Krizde Agile Olmak adlı bir konu açılmıştı. Konu Cenk Civici tarafından krizde agile olmanın maliyetleri düşürmede, karlılığı arttırmada,daha hızlı üretimde kullanılabilecek iyi bir yöntem olduğu belirtilerek açıldı. Bu konuda kendisine tamamen katılıyorum. Bu fikir benimde aklıma daha önceden gelmişti. Neden firmalar kriz,yada işlerin sıkıştığı zamanlarda çeşitli sosyal olanaklardan kesinti yapar, daha fazla mesai, kaliteden ödün verme gibi aslında pek fayda sağlamayan yollarak başvururlar hep düşürüm.

Aslında daha kaliteli ürünler, daha iyi bir altyapı, müşterinin ne istediğini bilerek müşteri ile yapılan yazılım,testler ile desteklenmiş daha az hatalı, daha fazla geri dönüşü olan yazılım bu israfı önlemede oldukça faydalı olacak yöntemler fakat çoğu firma tarafından görmezden gelinir.Bu konuda çevik süreçlerin fayda sağlayacağı kesin. Fakat konuda ilerleyen mesajlarda bir arkadaşın verdiği cevap oldukça ilginçti. Arkadaş şöyle diyordu

Süreçler kuşkusuz krizde veya düzlükte maliyetleri azaltıyor.
Peki ya çevik takımın bedeli konusunda birşeyler söyleyemez misiniz?

Güzel bir soru. Peki Agile pratikleri iyi güzelde. Agile takımı oluşturmak için nasıl bireylere ihtiyaç var? Agile süreçleri uygulamanın en büyük zorluğu:

  1. Firma kültürü
  2. Takım elemanları

Burada çok güzel bir noktaya değinilmiş oldu. Genelde süreçleri tanımlarken, hep faydasına uygulandığında getirdiği faydalara değiniriz. Süreçler takip edildiğinde herşey dört dörtlük olacak mı? Süreçleri uygulamak için insanlara mı robotlara mı ihtiyaç var? Malesef süreçleri uygulamak için henüz robotları kullanabilecek bir teknolojiye sahip olmadığımız için insanlarla yetinmek zorundayız. Yani süreçleri işleten insanlar.

Firma konusuna fazla değinmeden geçiyorum. Firmanın Agile süreçlerin faydasını anladığını ve bunlardan maksimum yararlanmak için adım attığını vaysayalım . Genelde bu adım çok zor oluyor hatta hiç olmuyor ama öyle varsayalım :) Agile bir takım kurmak için gereken “Highly Motivated People” insanları nereden bulucaz? Arka bahçemizde bunlardan yetişmiyor ve bu tarz insanları bulmak gerçekten pekde kolay olmuyor bence. Yada benim bulunduðum iş ortamlarında çok fazla rastlayamadım. Takım elemanlarının bir defa en önemli özelliği açık fikirli olmaları gerekir. Sonuçta yazılım geliştirme mantıklarını değiştireceksiniz insanlar zaten en ufak bir değişikliğe bile karşı çıkarken, eski tabuları yıkmak bu şekilde daha efektif çalışılır daha verimli olunur demek hiç ama hiç kolay değil.En basitinden Test Driven Development yapmak istiyorsunuz. Herhangi bir developera söyleyin bakalım test yazacaksın size ne diyecek. “Testleri developer yazarmı,vakit kaybı,…”.Ayrıca hadi test yazacağını kabul etti diyelim. Sadece süreci uygulamak  için yazılan testin ne faydası olacak? Testlerin efektif bir şekilde yazılım geri dönüşünü sağlayacak kıvama gelmesi benim deneyimlerim kadarıyla hiçde kolay değil. En azından ben 2 senedir TDD ile yazılım geliştiriyorum yazdığım testler daha yeni yeni istediğim kıvama ulaşıyor.Agile yöntemler ne kadar alt yapıdan bağımsız uygulanabilir varsayılsada değişime kolay adapte olabilmek için Agile mühendislik pratiklerini uygulamak gerekiyor. OOP,Design Patterns,Principles,SOLID.. bunlardan hiç bahsetmedim.

Bu yüzden faydasını yaşayarak gördüğüm Çevik süreçler dahi olsa içerisinde onu uygulayacak insanlar olmadıkça süreçlerin tek başına başarılı olması çok zor. Çevik takımlar iyi derece motive olmuş, her zaman daha iyisini arayan,istekli, açık fikirli, sürekli öğrenen insanlardan oluşur. Herhangi bir süreci işlettiğiniz bir firmada bu tarz insanlar içeren bir takımın sizce başarılı olma olasılığı nedir? Büyük ihtimalle başarılı olacaklardır. Süreçler ne kadar iyi tanımlanmış olursa olsun size bir noktaya kadar yardım edebilirler. Fakat başarının büyük bir bölümü gerçekten iyi işler yapmaya çalışan takım üyelerinden gelecektir.

Kalitesiz, daha iyiyi aramayan elemanlardan oluşan bir takımı istediğiniz süreçle yönetirseniz yönetin sonuç büyük ihtimalle başarısızlık olacaktır. Bu yüzden süreçlere yapılan yatırımın yarısı kadarını insanlara yatırmanın, kaliteli bir ekip kurmanın süreçlerden daha önemli olduğuna inanıyorum. Ve son olarak da Süreçler yerine insanlar diyerek kapaytıyorum.

Best Of 2008

Genelde takip ettiğim bloglarda yılın en iyi yazıları bölümü oldukça hoşuma gider.  Bu yüzden hem hangi yazıların daha çok okunduğunu görmek, hemde okuyucular için kısa bir popüler içerik oluşturmak için bende böyle bir liste hazırladım.  Ve işte karşınızdaaaaaaaa 2008 yılının en çok okunan yazıları :)

  1. Yazılım Mühendisi Maaşı? (10$,100$,1000$,10000$,$$$…)
  2. Abstract nedir, ne zaman kullanılır?
  3. NHibernate
  4. Interface nedir,ne zaman kullanılır?
  5. Dependency Inversion Principle (DIP)
  6. Data Access Object Pattern (DAO)
  7. Model View Presenter (MVP) Pattern
  8. Interface mi, Abstract mı?
  9. Single Responsibility Principle(SRP)
  10. Strategy Pattern

Listeye baktığımda temel OOP prensipleri ve tasarım kalıplarının daha çok okundunu görüyorum. Yani teknik içerikli yazılar daha çok okunuyor. 2009 yılında da bol bol teknik içerikli, kod örnekli yazılar yazmayı diliyorum.