Archive of ‘Yazılım’ category

Kodlamak Yazılımcı olmak için Yeterli mi ?

Mezun olmamın üzerinden beş sene geçmişken daha geçen gün diplomamı almak için lisans okulum olan İstanbul Üniversitesi Bilgisayar Mühendisliğinin Avcılar Kampüsüne gittim. Gencecik dimağlar  kampüste oturmuş sabahın dokuzunda patsolarını yerken arkadaşımla gittiğim kampüsü gezip bir de bölümümüz hocalarının yanına gidip konuşunca o günler gözümde daha iyi canlandı ve bu konuyla ilgili bir blog yazısı yazmaya karar verdim. (Bu satırları yazmamın üzerinden uzun bir süre geçti 🙂 ) Filmlerdeki geriye dönüş sahneleri gibi şu ana kadar yaşadıklarımdan edindiğim tecrübelerle o senelere gitsem neyi daha farklı yapmaya çalışırım sorusuna cevap niteliğinde bir yazı haline getirmeye niyetlendim. Yazı taslağı ve değineceğim konuları belirleyince bunun çokça anlatılan genel iletişim, sosyallik, proje yapma gibi klişeleşmiş konuların olacağı bir yazı olacağı için yazıyı yazmaktan vazgeçmiştim. Blog okurken şu yazıya denk gelince yazmaktan vazgeçtiğim konu ve bu yazıyı toparlayarak bir yazı hazırlamaya karar verdim.  Bu uzun girizgahtan sonra hazırsanız yazıya geçiyoruz.

Kendimize yazılım geliştirici, yazılım uzmanı, geliştirici ya da  yazılımcı her ne dersek diyelim günün sonunda yaptığımız iş bir yazılım üretmek oluyor. Kimi zaman var olan bir yazılıma küçük eklemeler yapıp; kimi zaman sıfırdan başlayarak bir yazılım ortaya çıkarabiliyoruz. Kimi zaman da doğrudan kod yazmasak da sistem, altyapı, donanımsal ya da teknik konularda çalışarak yazılımımızın daha iyi bir noktaya taşınması için çalışıyoruz. Eğer freelance bir çalışan değilseniz bu aşamaların çoğunda da bir takımın parçası, bir hiyerarşinin basamağı olarak çalışıyoruz. Bu yüzden yaptığımız tek işi kodlama olarak nitelemek eksik bir tanımlama olacaktır. Bu yazıda, yazılımcı eşittir kodlama şeklindeki eksik gördüğüm tanımlamayı başka hangi yetkinliklerle besleyebiliriz sorusuna kendimce cevaplar vermeye çalışacağım. Bu konuda yazılımcılar başta olmak üzere yazılım ile bir şekilde ilişkisi olan herkesin söyleyecekleri vardır mutlaka. Fikrini paylaşmak isteyenler yorumlar yazının daha iyi bir noktaya gelmesini sağlayabilirler. İyi bir yazılımcı olmak için teknik donanımın iyi olması gerektiğini ön kabul olarak bu yazıya devam edeceğim 🙂

Haydi maddelendirmeye başlayalım 🙂

Algoritmik Düşünme

Yazılım geliştiren bireyler olarak çoğu zaman en hızlı çözümü düşünerek sonuç odaklı çalışmalar yapmamız gerekebiliyor. Kısa vadede istenen çözüm bu olabilir ancak hızlı çözümlerin ya da kısa yolların başımıza iş açma ve sürprizleri sever bir yanı olduğunu da unutmayalım. Murphy’e selamlarımızı iletelim bu noktada. Ancak büyük sistemlerde ya da etki analizi büyük, kullanıcısı çok olan yani yazılım ekosistemindeki bir çok ürün için istenen şey ürünün stabil, oluşabilecek problemlerin ön görülerek önlemlerin alınması istenir. Bu sebeple yazılım geliştirirken yaptığımız değişikliklerin neleri etkileyeceği performanstan, sistemsel etkisine kadar her adımını tek tek düşünerek işlemlerimizi yapmalıyız. Algoritmik düşünme bir yazılım geliştirici için yazılım geliştirmeyi sadece kodlamanın ötesine taşıyan önemli özelliklerden birisi. Çok basit olacak ama  indexleme ya da ilişkilendirme yapılmadan, zamanla tablonun tutacağı data düşünülmeden, veri tabanı mimarisine kafa yorulmadan hazırlanmış bir tablolar bütünü er geç sizi zorlayacak belki de başta kurgulamış olmaktan daha fazla vaktinizi alacaktır.

Kod okuma becerisi

Zamanla gelişecek olan bu beceri problem çözümü, önceden yazılmış olan kodların nasıl çalıştığını kavrama açısından oldukça önemlidir. Kimi zaman devraldığınız bir projenin önceki yazılımcısı gitmiş olabilir ya da tam aktarım almadan siz projeye dahil olmuş olabilirsiniz. Bu noktada kodun çalışma sürecini uçtan uca anlayabilmek için debug, Find All Reference vs. desteği ile beraber kodun nasıl bir süreç izlediğini anlayabilmek hayatımızı oldukça kolaylaştıracaktır. Önceki yazılımcının temiz kod yazmış olması sonraki yazılımcılara güzel bir miras olacaktır. Sektör içi dayanışma için temiz kod yazmaya çalışalım 🙂

Image result for code review funny

Problem Çözme

Yazılım geliştiriciler olarak işimiz her zaman yeni bir yazılım üretmek olmuyor elbette. Yazıp üretim ortamına aldığımız projelerde problemler ortaya çıkabilir ya da var olan projelerde çıkan problemlere bakmamız gerekebilir. Problem çözme süreci başlı başına anlatılacak, üzerine çalışılacak bir konu bence. Süreci yönetme, problemin tespiti, problemin kritiklik ve aciliyeti, problemin düzeltilmesi ve üretim ortamına alınması.

Süreç Yönetimi

Aslında süreç yönetimine problem çözme alt başlığı altında değinmiştim. Ancak ayrı bir başlık olarak da eklemem gerektiğini düşünüyorum. Çoğunlukla yaşayan bir yazılım ürünü ya da yeni yeni yeşeren, yeni başlanmış projelerde çalışıyoruz. Bu projelerle ilgili yöneticilerinizin hedefleri, müşterilerin beklentileri, -büyük ölçekli bir proje ise – şirket planları, proje yönetimi ekiplerinin planlamaya uygun ilerlemesi ve kendinizin yazılımcı olarak tatmin olma beklentileriniz oluyor. Tüm ürün oluşturma sürecindeki yazılımcı dışındaki analist, testi yapan, Önyüz geliştirici, kabul testlerini yapan müşteri tarafını da düşündüğümüzde yazılım geliştirme sürecinin çok fazla paydaşı oluyor. İyi günlerde zaten bir problem olmuyor ama kötü günde bu paydaşların büyük bir kısmı ile olan iletişimi iyi yönetmeniz gerekiyor. Bu biraz da zamanla ve tecrübe edinmeyle gelişen bir beceri olsa da bu yetkinliğin farkında olmak ve kendimizi bu konuda geliştirmenin önemli olduğunu düşünüyorum. Önceki cümlelerde kötü zamanlarda süreç yönetimi ve iletişim oldukça önemli olduğundan bahsetmiştim. Bir ekleme daha yapayım: İyi yaptığınız işleri de bu profesyonellikte ifade edip, farkındalık yaratmanız da oldukça önemli.

Empati

Yazılımını gerçekleştirdiğimiz ürünleri kimi zaman biz de kullanıyor olabiliriz ama çoğunlukla müşteri/kullanıcı diye isimlendirdiğimiz başka insanlar geliştirdiğimiz ürünleri kullanıyor. Bunun dışında geliştirme sürecinde beraber çalıştığımız başka insanlar da olabiliyor. Onlarla empati yapabilme, ihtiyaç ve varmak istedikleri noktayı anlamak açısından empati önemli. Bu başlık eleştirilmeye müsait; daha fazla uzatmadan bir sonraki başlığa geçeyim 🙂

Image result for empathy 6

İşbirlikçilik

Yazıyı yazarken farkediyorum ki aslında başlıkların bir çoğu birbiriyle ilişkili. İletişimi sağlıklı kurmanız ve süreç yönetimi iyi yönetmeniz doğal olarak sizi işbirlikçi bir çalışan yapacaktır. Bununla beraber kimi  zaman başka ekiplerle, başka firmalarla çalışmak zorunda kalabilirsiniz; ya da agile çalışıyor ve sprinte başlamışken sizden bir iş talebinde bulunan başka bir ekip olabilir. Bu durumlarda planlamanızı yapıp işbirliği içerisinde çalışmak da hem o gün için takdir edilmeyi hem de imajınızın iyi olarak anılmasını sağlar.

Çok Yönlülük

Bu başlık daha iyi programcı olmak için gerek olmayabilir. Ancak vizyon sahibi olma, farklı düşünme, farklı yönleri görebilme gibi önemli becerilere sahip olmanın önemli ve insanı bir adım öne çıkarabilecek özellikler olduğunu gözlemliyorum. (Öne çıkma derdi olmasa da güzel yetkinlikler bence 😀 ) Bu açıdan kendisini her açıdan geliştirmeye çalışmanın önemli olduğunu düşünüyorum. Buradaki maksadım her alanda iyi olun; her şeyi bilin demek değil elbette. Her konuda iyi olamazsınız ama mesleğiniz, hobileriniz ile ilişkili alanlarda biraz bilgi sahibi olup, bu bilgi neticesinde konuşabiliyor olmanın da bir yazılımcı açısından önemli bir özellik olabileceğiniz düşünüyorum. Başta dediğim gibi bu biraz daha genel bir özellik.

Başta söylediğim gibi bu konu, oldukça geniş ve saydığım özelliklerin dışında bir çok özelliği belirtebileceğimiz bir konu. Tabi kimisi de “ben yazılımcıyım; kodumu yazar gerisine karışmam diyebilir ” ki bunu küçük ve orta ölçekli firmalar da düşünmek bile mümkün değil ama büyük, iş tanımları net olan kurumsal firmalarda bile söylemek bana pek mümkün gelmiyor. Bu yazıyı yazmama sebep olan daha geniş yazının linkini tekrar buraya bırakıyorum.  Bu yazıyı o yazının tercümesi olarak değil; tecrübelerim neticesinde yazmaya çalıştım. Umarım faydalı olur 🙂

Dependency Injection

Debug ve Temiz Kod yazılarından sonra ismini sıkça duyduğumuz, adını bilmeden uyguladığımız ya da tam da uygulanması gereken noktalarda özen göstermediğimiz Dependency Injection konusunda yazmak istedim. Şu ana kadar yazmaya çalıştığım konular zemini sağlam yapmaya yarayacak konular oldu. Temiz kod yazımı, SOLID prensipleri, birim testlerin önemi ve Debug yapabilmek doğrudan kod yazmayı değil yazılmakta olan ya da var olan kodlar bütününü daha doğru şekilde yazmayı amaçlamanın neticesinde oluşmuş yazılardı. Bir önceki yazımızı SOLID Prensipleri ile bitirmiştik. Bu yazıya önceki yazıda bırakmış olduğumuz noktadan başlayalım.

SOLID diye kısaltılan prensiplerin en sonundaki harf tarafından temsil edilen Dependency Inversion Principle ile tümüyle aynı şeyleri ifade etmese de benzer amaçları olan Dependency Injection kavramına değinmek istiyorum.

dependencyinjectioncaps

Yazının başında ifade ettiğim gibi Dependency Injection kavramı bilerek ya da bilemeyerek de olsa bir çok yazılım geliştiricinin uyguladığı bir desendir. Kodun okunabilirliği ve mimarinin kurgulanması açısından yazılım geliştiricilere fazlasıyla yardımcı olan bir desendir. Dependency Injection, kodun aritmetiğini işin kitabına uygun ve verimli şekilde yapmayı amaçlayan bir konu. Dependency Injection’ı kısaca açıklayacak olursak projemizin dışarıya bağımlı olmasıdır. Fazlasıyla kısa bir ifade oldu sanırım 🙂 Bu bağımlılık bir fremawork, dll, obje, konfigürasyonlar, statik tanımlamalar, new keywordü ile yaratılan nesneler, email servisi, log servisi, sistem kaynakları (sunucudaki tarih,saat vs.) veya third party bir ürün olabilir.

Uygulamalar geliştirilirken ihtiyaçlar kapsamında yukarıda bahsettiğim dışa bağımlı kısımlar olabilir. Dependency Injection bu bağımlılıkları aza indirgeyip yönetilebilir hale getirilmesini amaçlar. Dependency Injection ile uygulamanın bağımlı olduğu alanları uygulamaya enjekte ederken enjekte edilen alanların dinamik olarak değiştirilmesine olanak sağlanması hedeflenir. Yapılan bir işin ihtiyaç duyulan başka çalışmalara mümkünse hiç değişiklik olmadan uyarlanabilecek şekilde tasarlanmış olmasıdır. Loosely coupled (gevşek bağlı) tasarım prensibi dikkate alınarak yazılım içerisinde kullanılan obje, sınıf ya da komponentler değişiklik taleplerine cevap verebilecek şekilde tasarlanmalıdır. Dependency Injection bakımı daha kolay yapılabilir, test edilebilir, loosely coupled (gevşek bağlılık) kod yazmayı amaçlayan bir desendir. Solid prensiplerine uygun kod yazılmasını sağlar. Dependency Injection deseni dikkate alınmadığında uygulama büyüdükçe yapılacak küçük değişiklikler bile uygulamanın bir çok yerini etkileyebilir ve etki analizi büyük olabilir. Dependency Injection desenine uyulmadığında her yeni veya değişiklik ihtiyacı için geniş geliştirme yapmak gerekecektir. Bu durumda bir süre sonra var olan yerlerde değişiklik yapmaktansa yeni classlar oluşturmak gibi yollara gidilebilir ki bu da uygulamada gereksiz kodlama veya karmaşıklığa sebep olur. Bir süre sonra Lemi Orhan’dan alıntıyla ifade edecek olursak “Kod’dan kötü kokular gelmeye başlar.”

Bir genelleme yapmak istemem ama galiba toplumumuzun genel bir özelliği kervan yolda düzelir düşüncesi bir çok yazılım projesinde de kendisini gösteriyor. Uzun süren toplantılar, hazırlanan analiz dökümanları, net olarak belirtilmeyen use case’ler ve oluşturulmayan mimari sebebiyle bir çok proje yapım aşamasında olgunlaşıyor.  Oysa ki başta use case’lerin belirlenmesi, mimarinin tasarlanması ve bağımlılıkların ortaya konulması projenin daha net iterasyonlarla devam etmesine katkı sunar. Aksi takdirde süreç içerisinde yeni isteklerle, öngörülmeyen ihtiyaçlarla proje sürekli yeniden düzenlenmek zorunda kalır. Dependency Injection deseni biraz da sonrada gelecek ihtiyaçlara hızlı entegrasyonun sağlanmasına katkıda bulunur.

DI tasarım deseni sayesinde aşağıdaki sorular cevaplanmış olur.

  • Bir uygulamanın nesnelerinin nasıl oluşturulduğundan bağımsız olarak nasıl olabilir?
  • Bir sınıf, ihtiyaç duyduğu nesnelerin nasıl oluşturulduğundan bağımsız nasıl çalışabilir?
  • Nesnelerin oluşturulma şekli, ayrı yapılandırma dosyalarında nasıl belirtilebilir?
  • Uygulama farklı konfigürasyonları nasıl destekleyebilir?

Avantajları :

  • Kod bağımlılığını azaltır
  • Kodun tekrar kullanılabilirliğini artırır.
  • Kodun sürdürülebilirliğini artıtrır
  • Uygulama testinin yapılabilmesini kolaylaştırır.
  • Sınıf birleştirmeyi azaltır
  • Merkezi yapılandırma

Dezavantajları

  • Karmaşıklık katabilir. Çünkü her şey metod ya da sınıfın içerisinde yazılmamıştır.
  • Öğrenmek, kodu anlamak biraz vakit alabilir.

Dependency Injection için yazmış olduğum kod projesine github adresimden inceleyebilirsiniz.

Temiz Kod

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

Debug yazısından sonra bu yazıda kodun okunurluğu açısından son derece önemli olan temiz kod konusuna  değinmeye çalışacağım. Temiz Kod’dan kastın ne olduğu, Temiz Kod’un avantajları, temiz kodun nasıl yazılacağı gibi sorulara deneyim ve araştırmalarım neticesinde oluşan bilgilerimi aktarmaya çalışacağım. Çoğu kulağımızın aşina olduğu, bilip de bazen dikkat etmediğimiz pratikleri bu yazıyla not etmiş olacağım. Bu yazıyı yeni öğrendiğim ya da deneyimlediğim tecrübelerim neticesinde sürekli güncellemeye çalışacağım. Bu yazıyı okumaya devam ediyorsanız, muhtemelen bir yazılımcı ya da yazılımcı olmaya niyetli birisiniz. Bu yazının amacı işte daha temiz bir yazılım yapmak, temiz yazılım yapmanın neticesinde daha iyi bir yazılımcı olmak.

Öncelikle temiz kod yazımı bugünden daha fazla geleceğe yatırımdır. Yarın daha fazla zaman harcamamak için kodu yazarken temiz kod için vakit ayrılmalıdır. Temiz kod, prensipleri basit ama biraz vakit alıcı, üzerinde düşünülmesi gereken bir konudur. Temiz kod yazmada temel amaç kodun basit ama verimli, okunulabilir, test edilebilir ve yeni ihtiyaçlara uyarlanabilir olmasıdır. Temiz kod yazmak sizden sonra gelecek yazılımcının kodu anlayabilmesi ya da ileride çıkabilecek herhangi bir problemde kodu anlamada oldukça yardımcı olacaktır. Buradan hareketle sadece çalışan kod yazmak hedef olmamalıdır. Kodu yazmak kadar geliştiricilerin kodu okuyup, anlayıp, yeni ihtiyaçları ve bakımını kolay yapabilecekleri şekilde yazılmasıdır. Kurumsal firmalar, büyük modül ve projelerde bu daha da önemlidir. Bu amaçla bazı firmalar KGG’si yapılmamış, standartlara uygun olmayan kodların üretimine izin vermeyen toollar kullanmaktadırlar.

Kod yazma sürecinde uzmanlaştıkça programın çalışması işin tamamlanması açısından yeterli olmaktan çıkıyor.  Yeni kodlamaya başlayan ,Junior bir geliştirmeci için kodun çalışması yeterliyken; yıllar geçtikçe  kodun doğru bir şekilde çalışmasının yanında performans, kodun okunabilirliği, unit test gibi kavramlar önem kazanmaya başlıyor. Bu iki farklılığı kavramlaştıracak olursak; birisi Programlama iken diğeri İyi Programlama olarak ifade edilebilir. Kodun çalışmasını referans almak günü kurtarabilir ama daha sonra gelen bir hatayı anlama ve çözme ya da yeni bir geliştirmecinin orada çalışma ihtiyacı doğduğunda oldukça problemli bir hal alacaktır.

Yukarıda saydığımız tüm gerekçeler neticesinde temiz kod yazmak bir ek katkı değil zorunluluk haline geliyor. Programlamanın sanat olduğuna inanan birisi olarak Donald Knuth’ın alıntısıyla söylemek istediğimizi daha net ifade edelim.

Programming is the art of telling another human what one wants the computer to do.

Donald Knuth

Kodun da bir eser olduğunu düşünüyorum. Ve bu eserin başkalarına bir şeyler ifade etmesi eseri daha da kıymetli hale getirir.

Bu kadar  Temiz Kod Dedikten sonra temiz kodun özellikleri nelerdir onları sıralayalım :

  1. Okunması kolay olmalı. Okurken kod parçaları arasında kaybolmayıp, bir parçanın bütünün keşfeder gibi okunmalı
  2. Net olmalı. Her bir sınıf, entity, business katmanı ya da metod sadece bir amaca hizmet etmeli.
  3. Bakımı yapılabilir olmalıdır. Bakımı yazımından daha zor olacak kodlardan kaçınmalıyız 🙂
  4. Tüm testlerin başarılı bir şekilde tamamlaması
  5. Tekrar (duplicate ) olmaması
  6. Kullanılmayan kodların olmaması.

Kodumuzu bu maddelere uygun yazıp sonuçlandırdık. Peki bu şekilde  Temiz Kod yazmanın bize avantajları ne olacak diyecek olursak;

Temiz kod’un avantajları

  1. Kod parçalarının amacının ne olduğunu anlamayı kolaylaştırır.
  2. Uygulamanın akışını kolaylaştırır
  3. Farklı objelerin birbiriyle nasıl çalıştığını anlamayı kolaylaştırır
  4. Her class, entity ya da metodun rolünü ve sorumluluğunu anlamayı kolaylaştırır.
  5. Refactor, bugları bulma ve kodu düzenlemede hızlı aksiyon almaya yardımcı olur. Bakımı kolaylaştırır. Zaman kurtarır.
  6. Kodun değiştirilmesini, yeni ihtiyaçları hızlı entegre etmeyi sağlar.
  7. Kodun testini kolaylaştırır. Unit testleri anlama ve yazmada kolaylık sağlar.
  8. Yeni geliştirmeler için efor tahmin etmeyi kolaylaştırır. Beklenmeyen durumlarla karşılaşma olasılığını azaltır.
  9. Kodda sıkılmadan geliştirme yapmanızı sağlar. Temiz olmayan bir kodda geliştirme eziyete dönüşebilir çünkü. Eziyettir. Lemi Orhan’ın ifadesiyle o kod kokmaktadır. Ve kötü kokan bir kodda yazmak istemezsiniz.

Temiz Kod yazmada en önemli hususlardan birisi isimlendirmedir. Doğru yapılmış bir isimlendirme metodu incelemeye gerek bırakmayabilir. Ve bu da vaktinizi size bırakır. İsimlendirme oldukça zaman alan bir uğraş. Ancak doğru verilmiş bir isim daha sonra ayıracağınız zamanı size bırakır. Değişken, sınıf ya da fonksiyon ismi onunla ilgili sorulara cevap vermelidir. Neden olduğu, ne olduğu, nasıl kullanıldığını anlatmalıdır. Eğer bu soruların cevaplarını yorum ile yazıyorsanız isimlendirmeniz eksik kalmış demektir.  List gibi genel ifadeler yerine customerCardList gibi daha net ifadeler kullanılmalı. Önek ya da altçizgi gibi ifadeler kullanılmamalıdır. Şimdi sırayla değişken, sınıf, metod isimlendirmelerini ele alacağız.

Değişken İsimleri :  Anlamlı, aranabiliyor olmaları kolay bulunması açısından  önemlidir. (startDt yazmak yerine startDate). Açık, anlaşılır olması teknik bir ifade olmasından iyidir. Değişkeni tanımladığınız sınıf ya da obje isminde kullanılan bir ifadeyi değişken adında tekrarlamaktan kaçınılmalıdır. GetCustomer metodunda müşteri bilgisi atanan bir değişkeni Customer öneki eklemek fazlalık olacaktır.  Bazı metod değişkenlerinin default atamaları vardır. Değişken default atamaları  parantez içerisinde değişken yazılırken atamasını yapılmalıdır.

Sınıf İsimleri: Sınıf isimleri isim veya isim türevli ifadeler olmalıdır. Genel ifadelerden kullanmak yerine sınıfı ifade eden isimlendirmeler yapılmalıdır. Sınıf ismi sıınf içerisindeki metodların üst başlığı gibi görülmelidir.

Metod isimleri : Metod isimlerinin bir fiil ile başlaması daha doğru olacaktır. GetCustomer,DeleteCustomer,SaveCustomer, CreateCustomer gibi. Metod ismi metodun işlevini net olarak ifade etmelidir. İsimlendirme son derece kibar veya sert olmalıdır. (Üniversite birinci sınıf BMG dersi kodlama sınavında nasıl nazik bir sonuç yazdırdığımı hatırlayan arkadaşlar bunu daha iyi anlayacaklardır. Zira halen gülme konusu olur bu nazik uyarım :))

Metodlar : Fonksiyonlar öncelikle tek bir amaca hizmet etmelidir. İkinci olarak metodlar kısa olmalıdır.  Max sınır olarak tüm metodun ekranda tek seferde görüntülenmesi gibi bir varsayım konulsa da mümkün olduğu kadar kısa, okunabilir ve amaca hizmet etmelidir.  Metodlar ile ilgili yorum yazmaktan kaçınılmalıdır. Gerçekten yazılması zorunluysa yorum yazılmalı.  Eskiden metod üzerine vs’nin default verdiği syntax ile yorum yazmanın faydalı olduğunu düşünürdüm ve uygulardım. Ancak zamanla kodun kendisini anlatması gerektiğini düşünmeye başladım. Metodlar ile ilgili yorumlar sadece business bilgisi ya da bilinmeyecek bir yazılım kullanımı yapılmışsa yazılmalı.  Aksi takdirde KOD KENDİSİNİ ANLATABİLMELİ.

Metod içerisinde koşul ifadeleri ile de birkaç cümle yazarak metod kısmını da tamamlayalım. Bazen if, switch koşullarında oldukça uzun kontroller yapılıyor. Satırlar süren, or ve and keyleri ile zincire dönen koşulları bir if() parantezine sığdırmak kodu okunur olmaktan çıkarıyor. Bu durumlarda koşulları yeni bir metod yapıp buradan çağırmak hem okuma hem anlama açısından daha sağlıklı olacaktır.

Metod değişkenlerinin sayısı : Bunun için 2 diyeni de duydum, üç diyeni de, dört diyeni de duydum. Dörtten fazla alabilir diyeni duymadım ama gözlerim üç dört satır değişken alan fonksiyon gördü J  Bir fonksiyon üçten fazla değişken almamalı. Bu sayı mümkün olan minimum sayıda tutulmalı. Eğer üçten fazla değişken bekleniyorsa da değişkenleri barındıran bir obje tanımlanıp oluşturulan obje tipinde bir değişken gönderilmelidir.

Temiz kod açısından yazılım bileşenlerinin isimlendirmelerine tek tek değindik. Şimdi de OOP açısından da önemli olan SOLID’ten kısaca bahsedelim.  SOLID,  OOP projelerinin standartları olarak bilinir. Kendisini oluşturan maddelerin baş hraflerinden oluşur:

S – Single Responsibility Principle (SRP): Her nesnenin sadece bir sorumluluğu olmalı, tek bir amacı olmalıdır. Herhangi bir değişiklik yapıldığında bu nesnenin amaç ya da sorumluluğunun değişmesinden dolayı olmalıdır.

O – Open/Closed Principle (OCP): Yukarıda belirtmiştik.; Metod düzenlemelere, yeni şart ve güncellemelere açıktır. Ancak metod ya da nesnesin varlık sebebini etkileyecek değişiklikler yapılmamalıdır.

L – Liskov ‘s Substitution Principle (LSP): Türetilen bir nesnenin türetildiği sınıfın metodlarını kullanmasıdır.

I – Interface Segregation Principle (ISP): Nesnelerin ihtiyaç duymadıkları Interface’ten ayrılması ilkesidir.

D – Dependency Inversion Principle (DIP): Yüksek seviyeli sınıfların daha düşük seviyeli metodlara bağımlılığının olmamasıdır. Alt sınıflardaki değişiklikler üst sınıfları etkilememilidir.

Toparlayacak olursak ; Temiz kod kodun kaliteli olması açısından önemli ve vakit ayrılması gereken bir aşamadır. Tabi bunu söylerken çok temiz kod yazacağım diye aşırı titiz davranmak da gerekmez. Temiz kod yazımı dikkat edilmesi durumunda zamanla gelişecek bir çalışma. İlk denemede olmayabilir, dolayısıyla üzerinde çalıştığımız kodu geliştirmek için her zaman çaba göstereceğimiz bir zihniyet benimsememiz gerekiyor. Yazılan kodun temiz kod açısından yeterince iyi olduğunda karar verdiğimizde yeni koda devam etmeliyiz.

Kaynaklar:

https://medium.com/mindorks/how-to-write-clean-code-lessons-learnt-from-the-clean-code-robert-c-martin-9ffc7aef870c

https://github.com/ryanmcdermott/clean-code-javascript

https://cvuorinen.net/2014/04/what-is-clean-code-and-why-should-you-care/

Debug yapmak derde deva mı yoksa cefa mı ?

Uzun süredir ara verdiğim blog yazılarına bu yazıyla yeniden başlama niyetindeyim. İlk konu olarak da sevdiğim bir konu olan Debug ile başlamak istedim. Umarım arkası da gelir 🙂  İşe Debug kavramını tanımlayarak başlayalım: Debug, bir yazılımda beklenilenin dışında çalışan, kodun çalışmasına engel olan veya olması muhtemel hataların saptanması ve kaldırılması sürecidir. Debug bir yazılım veya sistemin hatalı çalışmasını önlemek için hata veya kusurların bulunup çözülmesi için yapılır. Küçük boyutlu yazılımlarda debug ile hata ayıklama nispeten kolayken; alt sistem veya modüllerden oluşan bir yazılımın debug edilmesi daha zor ve vakit alıcı olacaktır. Bu durumda bir modülden yapılan herhangi bir değişikliğin diğer modüllerde hataya sebep olabileceğinden, debug ve etki analizi daha da önemli bir hale gelmektedir. Etki analizi demişken unit testlerin yazılmazı ve ölçeklenebilirlik konularının ayrı bir yazı konusu olduğunu ekleyerek yazımıza devam edelim.

Birkaç ay önce twitter’da sektördeki bir çok insanın görüş bildirdiği bir Debug yapılmalı mı ? yapılmamalı mı ? minvalinde bir tartışma başladı.

Her şey bu tweetle başladı 🙂 Ve twitterda bizim sektörde gördüğüm en çok görüş bildirilen tartışmalaradan biri böylece start aldı 😀

Gerçekten de debug yapıyorsak; kodu anlamamış mı oluyorduk. Debug yaparken kodu anladığımızı düşünüyorsak, aslında debuga ihtiyacımız yok mudur ? şeklinde soruları soran bir tweetti. Oldukça iddialı bir fikir olsa da oluşturduğu tartışma ortamı açısından faydalı bir tweet oldu. Bu fikre destekleyen kullanıcılar olduğu kadar çoğu kullanıcı da kendi argümanlarıyla bu fikirlere karşı çıktı.

Debug yapmayla ilgili bu faydalı tartışmayı geride bıraktığımıza göre şimdi yazımızın esas konusu olan Debug ve debug pratiklerine gelebiliriz.

Debug yapmanın faydalı olduğunu düşünen biri olarak yazının bu kısmından sonrası bunun gerekçelerini anlatmaya çalışacağım. Debug (hata ayıklama), kodun satır satır nasıl işlediğini gösterir. Bir nevi kodun sonuca hangi adımlardan geçerek gittiğini bize gösterir. Sonuca giden yolu bulmanın daha kolay yolları da olabilir.

Eğer kodumuz standartlara uygun yazılmış, okunabilir bir kod ise debug yapmaya gereksinim duymadan da kodun nasıl çalıştığını görebiliriz. Küçük sistemler ya da kod blokları için bu mümkündür. Ancak büyük sistemlerde kod okunur olsa bile kodun çalışma mantığını kavramak daha zor olabilir. Üstelik debug yapmadan birbirini çağıran kod bloklarını okuyarak ne yaptığını anlamaya çalışmak vaktimizin boşa geçmesine neden olabilir. Çünkü kodu gözle okurken kodun çalışmasını engelleyen bir durumu göremeyebiliriz. Kodu okurken yeterli gördüğümüz kontrollerden birini kod hata veriyor olabilir. O yüzden debug yapmayı son başvurulacak çözümlerden biri olarak görmüyor; aksine bir çok zamanlar ilk başvurduğum inceleme şekli oluyor. İki durumda debugger’ı kullanıyorum.

  1. Mevcut, çalışmakta olan bir kodu devraldığımda
  2. Hata ayıklamada

Bir projeye sonradan dahil olduğunuzda ya da know-how bilgisine sahip birisi olmadığında kodun nasıl çalıştığını, hangi aşamalardan geçtiğini görmek için debug etmeyi tercih ediyorum.

Hata ayıklamada ise öncelikle exception veya log bilgisinden hatanın sebebini anlamaya, kodun hata verdiği kısmı incelemeye çalışıyorum. İlk aşamada problemi tespit edemeyince case’i oluşturarak debug yapıyorum.  Daha önceden bilmediğim bir sistemde debug yapıp sonuç elde edince keşif yapmış gibi mutlu oluyorum 🙂 Tabii bir de mutsuz eden sonuç vermeyecek debug süreçleri oluyor. Özellikle karmaşık sistemlerde debug yapmak bazen o ihtiyaç için gerekli yazılımı yapmaktan daha uzun süre alabiliyor.

Verimli ve etkili debug yapabilmek için bazı adımlar var: Kimisi altı kimisi yedi adım diyor. Yazmaya başlayalım bakalım kaç olacak 🙂

  1. Problemi gerçekleştirebiliyor, yeniden oluşturabiliyor olmak. (Benim localde çalışıyor diyenler; haklısınız bende de çalışıyor ama hep çalışması gereken kişilerde çalışmıyor )              
  2. Hatayı kullanıcısından  tanımla : Hatayla karşılaşılan kullanıcıdan hatayı hangi aşamalarda, hangi işlemi yaparken aldığını anlamak. Hatanın kesin nedenini tam anlamak için kullanıcıdan mümkün olduğu kadar detay almaya çalışın.
  3. Hata alındığındaki durumda olan durumu not et. Programında tüm değişken değerlerini ve durumlarını o anda almaya çalışın
  4. Hatayı oluştur.
  5. Bir üst maddedeki duruma göre analizi yaparak hatayı bulmaya çalışın.
  6. Mevcut hatayı fixleyin             
  7. Testlerinizle hatanın fixlendiğine emin olun.
  8. Çalışmanızın yeni bir hataya sebep olmadığını kontrol edin.
  9. Son olarak bu çalışmanızı bir yere not alarak dökümante edin. Daha sonra benzer problemlerle karşılaşıldığında hızlı aksiyon alınmasını sağlar.

Debugdan bahsettiğimiz bu yazıda doğru hata mesajları fırlatmanın önemine değinmemek olmaz. Öncelikle mümkün mertebe hataya sebep olabilecek caselerin kontrol yapılarıyla kontrol edilmesi sağlanmalıdır. Öngörülemeyen durumlarda ise  exception döndürmemiz gerekiyor. Exceptionları doğru şekilde fırlatmak üst katman, log ve son kullanıcıda anlaşılır olacak şekilde handle edilmesi problemin sebebini hızlıca saptama noktasında oldukça fayda sağlayabilir. En basitinden ex’ı döndürmek yerine ex. Message şeklinde dönüş yapılması küçük, basit görünse de mesajın daha çabuk anlaşılmasını sağlayacaktır. Ayrıca hata ayıklama da try catch ile kontrollerin yapılmasındansa kontrol yapılarıyla kontrollerin yapılması performansa da olumlu yönde katkı sunacaktır.

O sebeple öngörülen tüm hata case’lerinin kontrol yapılarıyla kontrol edilmesi, öngörülemeyen caseler için exception fırlatılması tercih edilmelidir. Burada da direkt Exception yerine belli amaçlara hizmet eden exception class’larının fırlatılması daha doğru olacaktır.

Yazının son bölümünde ise  debug yapanların aşikar olduğu Visual Studio’nun bir kaç özelliğinden bashetmek istiyorum.

Breakpoint: Breakpoint, Debug’un temel taşı diyebiliriz. Kodun execute zamanında durmasını istediğimiz kısımda durmasını sağlar. Uygulamanızın çalışması esnasında süreç bu kod satırına geldiğinde durur. Debug adımlarıyla bundan sonraki sürecin işleyişi kontrol edilir.

Condition :  Breakpoint konulan satırda belli şartlar sağlandığında durmasını sağlar.
Watch window: Değişkenlerin değerlerinin görüntülenebileceği kısımdır.
Locals window: Lokal değişkenlerin değerlerini gösteren kısımdır.

Immediate Window: Değişkenleri görüntüleme, kod yazabileceğimiz penceredir.
CallStack : Stack içerisinde kullanılan fonksiyonları görüntülemimizi sağlar. Bu sayede sürecin nasıl olduğumuz noktaya geldiğini görebiliriz.

Kaynak :

https://www.codementor.io/mattgoldspink/how-to-debug-code-efficiently-and-effectively-du107u9jh

https://economictimes.indiatimes.com/definition/debugging

Agile Yönteme Geçiyoruz. Hayat Daha Güzel Olacak !

Teknoloji çağında neredeyse her gün yeni bir kavram, yeni bir teknoloji ya da yazılımdan haberdar oluyoruz. Hızla gelişen ve her geçen gün hızına ivme katan teknoloji dünyasını takip etmek ve yeniliklere adapte olmak da zorlaşıyor.  Fazla geriye gitmeden son beş on senede sıkça duymaya başladığımız bir çok kavram hayatımıza girdi. Akıllı sistemler, NFC vb teknolojiler,  Big Data, Drone, Devops gibi kavramlar hızlı bir şekilde popülerleşti. Bu teknolojilerden bazıları üstüne katarak gelişirken bir kısmı da  popülerliğini kaybedebiliyor. Birkaç sene önce sıkça duyduğumuz Big Data kavramı artık eskisi kadar dillendirilmemektedir. Big data’dan vazgeçilmiş değil, şahsi fikrim ileri de duymaya devam edeceğiz. Büyük şirketler bu alana yönelip sadece bu alanda çalışacak ekipler oluşturuyor ancak aktif ve başarı olarak –en azından takip etmeye çalıştığım büyük firmalar arasında- duyduğumuz bir çalışma yok. Eğer big data ilginizi çekiyorsa big data ile ilgili verilerin de yer aldığı “2017’de Big Data Projelerinin %60’ı Başarısız Olacak” isimli çalışmayı okuyabilirsiniz. Bu kısa girişten sonra yukarıdaki kavramlar gibi son zamanlarda daha çok duymaya başladığımız bu yazının konusuna gelebilirim :Agile. Türkçeye çevik yöntem olarak çevirilen Agile projenin varolmaya başlamasından bitirildiği son ana kadar ki süreci belirleyen bir yöntemdir.

On altı senelik bir geçmişi olan Agile proje yönetim süreçlerinin belirlenmesi amacıyla 2001’de guru sayılan 17 kişi  tarafından 12 maddeden oluşan manifesto hazırlanmıştır. Manifesto paydaşlar arası iletişim ve işbirliği, güncellenebilen yazılımlar, ekibin kendisini organize edebilmesi, ve değişimlere adapte olabilmesine vurgu yapar. Agile çerçevesi kesin hatlarla belirlenip  ve yalın üretim(lean manufacturing) prensipleriyle netleştirilmiş waterfall gibi süreçlere karşı yeni bir çözüm olarak ortaya çıkmıştır.

Agile yöntem, zamanı yönetmeyi, müşteriyi sürece dahil etmeyi, yüksek işbirliğini, esnekliği, ürünlerin düzenli production’a alımını, sürecin ve üretimin beraber devam edecek şekilde gelişimini önemser. Waterfall gibi süreçlerde iş hatları daha belirgin ve değişkenken agile ile daha çok söz sahibi ve daha esnek bir iş yapış süreci mevcuttur. Daha az çalışma değil işin değişme imkanı da dikkate alındığı için daha esnektir 🙂  Bir proje ile ilgili ihtiyaç ve hedefler proje sürecinde güncellenebiliyor; değişebiliyor. Bu da sürecin değişime açık ve esnek olmasını zorunlu hale getiriyor. Esnek olması ürün sahibi ve ürünü ortaya çıkaracak ekip için de bu yöntemi cazip hale getiren etkenlerden bir tanesi. Scrum da ilk zamanlarda geleneksel, ardışık yaklaşımlara karşı daha esnek bir yapıda olunmasıyla tanıtılan bir yaklaşımdı. Ancak günümüz yazılım projelerinde dökümantasyon ve sprintler gibi sıkı denebilecek bir metodoloji olarak görülmektedir.   Proje yönetimi, proje üretimi ve yazılım geliştirme takımlarının sayısının artması da geleneksel waterfall metodolojisinden agile metodolijlerine yöneltiyor.  Aslında agile, scrum metodolojlerinden biridir. Scrum, agile hareketinin bir parçasıdır. Agile ve Scrum birbirilyle ilişkilidir ancak farklı yönleri de vardır.

Agile, agile menifestosunda belirtilen prensiplerin iterasyonlar halinde yazılımın geliştirilmesidir. allmethodologies

Scrum ise yazılım geliştirme sürecinde takip edilecek özel kurallar bütünüdür. Agile de iş ve teknik taraf diye iki taraf yerine o işin sorumlusundan geliştiricisine kadar bir takım vardır.

Waterfall eşyayı her katta görevlendirilen birisine aktararak eşyayı taşımaya benzerken agile’da asansörle eşyanın parça parça daha hızlı bir şekilde yukarıya çıkması gibidir.

Agile elbet her derde deva olmayabilir ama yazılım projelerini tüm paydaşlar açısından daha balşarılı ve kaliteli bir şekilde sonuçlandırma adına faydaları vardır. Müşteri açısından bakacak olursak  daha kısa sürelerde ürünün belli kısımlarını üretim ortamında kullanmaya başlayabilir. Inception fazında projenin tüm paydaşları ve özellikle de yazılım ekibiyle beraber ihtiyaçlar belirlendiği için istekleri net bir şekilde anlaşılmış olur. Scrum’da yazılım ekibi analiz safhasında yer almadığı için yazılım açısından uygulanabilirlikten dolayı bazı ihtiyaçlar proje ortasında yapılacak işler arasından çıkarılıyordu. İki ya da üç haftalık periyotlarda öncesinde müşteriye demo yapılarak ürünün belli kısımları üretim ortamına alınır. Bu sayede ürünü kullanmak için projenin sonlandırılması beklenmez.

Geliştirme Ekibi de bu yöntemin mutlu olacak taraflarından biridir. Inception fazında ihtiyacın ne amaçla istendiğini bildiği için yaptığı geliştirmenin business tarafına da hakim olacaktır. Yazdığı yazılımın kullanımı ve değerini daha aktif görebilirler. Analiz süreci ve –kullanılmayacak olan- dökümanların hazırlanması süreci ortadan kalkmış olur. Müşterinin kullanacağını bildiği ve değerini inception fazında gördüğü için daha keyifli çalışmaya başlarlar.Projenin diğer paydaşları için de faydaları sıralamak zaten uzun olacak bu yazıyı daha da uzatacağı için o konuya girmiyorum 🙂

Yukarıda saydığımız agile yöntemin avantajlarının yanında bazı zorlukları da vardır : Raporlanması, finansal yönetimi, zaman ve kaynak yönetimi, müşterinin artık sürece dahil olması, değişikliğin her zaman yapılabilmesi, net bir planın olmaması. Bu zorlukların hepsini tek tek açıklayabiliriz ancak zorluk olmalarının ortak özelliği sürecin esnekliği ve güncellenebiliyor olmasıdır. Agile yöntemde belirlenmiş, kesin çizgiler yoktur.

Agile ile ilgili özellikle üzerinde durulması gereken iki kavram var: User Stories (Kullanıcı Hikayeleri) ve Iterations. Iterasyondan kısaca bahsettiğim için burada kullanıcı hikayelerinden bahsedeceğim. Zira bu kısım önemli. Ürün backlog’unu oluşturmak için en popüler yöntemlerden biri müşteri ya da kullanıcının gereksinimlerinin küçük açıklamalar  ile yazıldığı user storyler şeklinde hazırlanmasıdır. Kullanıcı hikayeleri ürünün müşterileri ya da kullanıcının perspektifinden gereksinimin kısa ve basit olarak ifade edilmesidir. Kullanıcı hikayeleri yazılım dilinden öte müşterinin diliyle oluşturulur. Kullanıcı neyi neden istiyor sorusunun cevabı bulunmaya çalışılır. Yazılım ekibi ve projenin tüm paydaşlarının hem fikir olacağı kullanıcı hikayeleri neticesinde yapılacak projenin kapsamı tahmin edilir. Bu kullanıcı hikayelerinin eforu belirlenerek iki haftalık iterasyonlarla üretim ortamına alınır.

Waterfall, Kanban, Scrum ve Agile Hakkında Kısa Karşılaştırmalar

Waterfall metodolojisinde geliştirme başlamadan tüm gereksinimlerin analiz edilip dökümante edilmesi gerekir. Agile’da ise gereksinimler kısa iterasyonlar halinde geliştirilir ve değiştirilebilir. Geliştirme öncesi bir handshake durumu yoktur. Agile development öncesi geçirilen uzun zaman periyotlarını ortadan kaldırır. Ayrıca uzun geliştirme süreçlerinde ortaya çıkabilecek –analizde olmayan, kaçınılmaz- değişiklerin bir problem olarak ortaya çıkmasını engeller.  Waterfall’de analizde yazılan herşeyi birebir ürün haline getirmiş olabilirsiniz. Bu geliştiren takım için başarılı bir sonuçtur. Ancak müşteri tarafında ihtiyaç değişmiş olabilir ve ortaya konan ürün kullanılmayacak bir ürün olabilir.  Bu şekilde üretici ihtiyacını karşılamadığı , geliştirici efor sarfettiği, proje yönetimi ise kaynak ayrılan bir ürünün kullanılmayacak olmasından mutsuz olur.

Kanban ise Scrumdan biraz daha esnektir. Kanbanda yürütülen bir süreç kolayca Agile a dönüştürülebilir. Kanbanda bir tahta üzerinden süreç yönetilir : progresstestingready for release ve released aşamaları vardır. Eğer etkili ve uzun bir proje süreci olacaksa Scrum ama zaten süregelen bir proje ise kanban kullanılabilir. Scrum ve Agile buz ile su gibi benzerdir. Scrum ve kanban da agile yazılım metodolojilerinin özelleştirilmiş halidir. Scrum ve kanbanı karşılaştırmak ise iki ayrı agile metodolojisini karşılaştırmak gibidir.

methodologies

Sonuç olarak bu metodoloji ve toolların temelde bir amacı var : Projeleri daha verimli, kaliteli ve mutlu bir şekilde sonuçlandırmak. Bu sebeple küçük bir proje için use story’ler için biraraya gelip işin tüm bireylerini biraraya getirmek yerine Kanban belki waterfall bile daha etkili olabilir. Eğer başka birimlere bağımlığınız fazla ve beraber yürüyemeyecek bir süreçse –bence yine de tercih etmeyin waterfall tercih edilebilir.

Son olarak üç tip yöntemde de çalışmış biri olarak Agile yöntemin diğerlerinden çok daha iyi olduğunu düşünüyorum. Tabii burada Agile yöntemlerin tamamiyle uygulanmaya çalışılmasıyla iyi bir şekilde proje yönetilebilir. Esnek diye sürekli geliştiriciye müşteri yeni istek istedi agile yapıyoruz bunu da hemen çıkmamız gerekiyor denilen bir ortamda geliştirici nasıl mutlu olamazsa, her işe uzun eforlar verip esnekliği rahata dönüştüren bir ortam da müşteri için memnun edici bir süreç olmayacaktır.

Çevik süreçler dileğiyle..

Bir kaç link :

http://canertosuner.com/post/kisaca-agile-nedir-neler-gerektirir

https://www.mountaingoatsoftware.com/agile

https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban

Bilgisayar Mühendisliği Eğitimi ve Yazılım Sektörüne Dair Röportaj

 

Uzun süredir blogda yazı yayınlamıyordum. İlk fırsatta yazmak için konular belirlesem de bir türlü yazıya döküp paylaşamadım. Geçen ay Gebze Teknik Üniversitesi Bilgisayar Mühendisliği 3. Sınıf öğrencileri Merve, Alper ve Zehra yazılım sektörüne ve bilgisayar müdendisliğine dair bir mülakat yaptık. Dönem ödevi olarak bir akademisyen ve yazılım sektöründe çalışan bir mühendisle gerçekleştirdikleri röportajları arkadaşlarına da  sunacaklarını ifade ettiler. Benim için keyifli ve verimli geçen mülakattan sonra mülakattaki fikirlerimi düzenleyerek burada da paylaşmaya karar verdim. 🙂  Keyifli okumalar.

  1. Türkiyede bilişim sektöründeki ilerleme hakkında ne düşünüyorsunuz ?

Bilişim sektörü özellikle son senelerde daha hızlı bir ilerleme kattediyor olsada ilki aslında bilişim sektöründeki ilerlemeler devletin de bu konuya eğilmesiyle başlıyor. 2003’te bilgi toplumu olmak için hükümet ve devlet destekli bir proje başlatılıyor. Bunun içerisinde  e-devlet üst başlığı altında e-fatura, e-sağlık, e-imza gibi hizmet sektörüne önemli katkılar sunan çalışmalar gerçekleştirildi. Eskiden bir randevu alacağınız  zaman hastaneye gitmeniz ve ordaki görevli memurdan almanız gerekiyordu ama şimdi telefon ettiğinizde bile randevu almanız zor, internette kendiniz randevu alın şeklinde internete yönlendirilebiliyorsunuz. Tabi sadece devlet bilişim sektöründe çalışmalar yapmadı. Özel sektörde de yapılan çalışmalar vardı, mesela ekşi-sözlük daha öncesinde oluşmuş birşeydi zaten. Kriz sonrası bankaların hızlı büyümesi ve telekom firmalarının da bilişim sektörüne dahil olmasıyla bu alandaki çalışma ve rekabet arttı. Teknolojinin hızlı gelişimi aslında bilişim sektörünün de ilerleme hızını artırdı. Teknolojinin yenilikçiliği, sektörü de yenilikçi olmaya, son teknolojileri takip etmeye zorladı diyebiliriz. Ve teknoloji tek bir koldan ilerlemiyor. Her gün yeni bir kavram, yeni bir alan açılıyor. Örnek vermek gerekirse, son yıllarda büyük veri (big data) diye  bir kavram ortaya çıktı. Bu alan ilgimi  çektiği için biraz bunun üzerinden konuşmak istiyorum. Veri(data) artık ticaret, devlet ,banka, Telekom gibi sektörler  için  çok kıymetli olmaya başladı. Bu dediğimiz sektörlerde çok fazla veri toplanıyor ve bu verilerin değerlendirilmesi gerekiyor. Bu ham haliyle kıymetsiz veriler işlenerek çok değerli bir veri haline dönüştürülebiliyor. Verinin değerlendirebilmesi için de teknolojilerden geride kalmayıp , adapte olup ve hatta daha iyi bir konumda olmak için hızlı bir şekilde öncü konumda çalışmalar yapmanız gerekiyor. Bu da en özet haliyle rekabeti getiriyor. Özetle toparlayacak olursak; teknolojideki ilerlemeden dolayı bilişim sektöründeki ilerleme Türkiye’de de gelişmekte olan ülkelerde de daha hızlı bir şekilde devam ediyor. Türkiye de buna uyuyor aslında , adapte oluyor , önce olmasa da ilerleyen teknoloji ile beraber yoluna devam etmeye çalışıyor diye görüyorum.

  1. İlk profesyonel iş deneyiminizi ne zaman yaşadınız? İlk işinizden bahseder misiniz? İlk iş gününüz nasıldı ?

Daha önce part-time yerlerde çalışmıştım ama ilk profesyonel iş deneyimim mezun olduktan bir ay sonra kurumsal bir bankada başladı. Kurumsal bir bankanın iştirakçısı olan teknoloji şirketinde ATM biriminde işe başladım. Burada genel olarak C#, MySql ve MsSql yazılımları ile transaction, raporlama ekranları geliştirdikten sonra ATM yazılımları geliştirme alanında çalıştım. Bu çalışmaların dışında ve farklı teknolojilerle yaptığımız çalışmalar olsa da genel olarak ilk iş tecrübemi bu şekilde özetleyebilirim.

Heyecan olarak ta ; stajlarınızı  özellikle  yazılım evlerinde yapmışsanız , yazılım evleri nispeten daha az sayıda kişinin çalıştığı herkesin herkesi tanıdığı, bildiği ortamlardır. Ama ilk defa büyük ölçekli, kurumsal bir firmada çalışıyorsanız ortama adapte olmanız daha uzun sürebilir. Beraber bir arkadaşla aynı gün işe başlamamdan ötürü ilk günüm kolay geçmişti diyebilirim. En azından vakit hızlıca geçip erkenden akşam olmuştu.

  1. Mezun olduktan sonra iş hayatına ilk adım attığımız adaptasyon süreci nasıl olacaktır? Sizin bu döneminiz nasıldı ?

Final dönemini aratmayacak bir süreç oluyor açıkçası, yine stres oluyor, yine çabalıyorsunuz ama sonucun ne olcağını tam kestiremiyorsunuz. Birçok yere başvuruyorsunuz , birçok yerle görüşüyorsunuz ve klasik bir şekilde biz sizi ararız diyorlar arayanlar olduğu gibi, aramayanlar da oluyor. Mezun olduktan sonra iş aramaya başladıysanız bu süreç sıkıntılı oluyor ama daha öncesinde yaptığınız projeler varsa veya çalıştığınız staj yerleri ile ilişki bağınızı koparmadıysanız bu süreç daha rahat oluyor; çünkü çalışabileceğiniz bir işiniz olmuş oluyor. İş bulur muyum bulamaz mıyım telaşından öte istediğim sektörde bir iş bulur muyum diye düşünüyorsunuz. Bu süreçte kısa sürede iş arayışınız sonuçlanmaza moraliniz bozulacak, artık olabilecek kötü  iş seçeneklerini bile değerlendirmeyi düşünmeye başlayabilirsiniz. Hangi sektörde çalışmayı düşünüyorsanız, o sektör dışında bir sektörde çalışmam diyorsanız onun temelerini 4. sınıfta aldığınız bitirme projesiden itibaren çalışmalarınızı o sektörde yapmanız faydalı olacaktır. Özellikle tavsiye ediyorum eğer IBM ya da Microsoft un yarışmaları gibi onların  üzerinden bitirme projelerinizi yaparsanız hem bitirme projesini yapmış oluyorsunuz hem de sektörde birileri ile tanışma fırsatı yakalıyorsunuz ve CV’inizde fark yaratacak bir yarışmaya dahil olmuş oluyorsunuz. İş görüşmelerinde iş tecrübeniz yoksa işverenin size sorabileceği tek şey bitirme projesidir stajlarda etkili olabilir ama özellikle sizin bitirme projenize bakarak sizinle ilgili bir fikirde bulunuyorlar. O yüzden bence şimdiden bitirme projelerini araştırın ve Tübitak ‘ın ,IBM’in yarışmalarına katılın.

  1. Sektöre ilk adımımızı attığımızda bize en büyük katkıyı sağlaması açısından hangi alana yönelmeliyiz ?

Bilgisayar mühendisleri mezunları için çok fazla alan var. Üniversitedeyken temelde 4 alan vardı diyebilirim : Yazılım, veritabanı ,sistem ve proje yönetimi şeklinde alanlarda çalışabiliriz diye düşünüyoruz ama daha sonra sektöre girince özellikle de son senelerde birçok yeni alan ortaya çıkıyor. Örneğin büyük veri(big data) , veri analitiği gibi her gün varolan  alanlara yeni bir alan ekleniyor.O yüzden Bilgisayar Mühendisliği seçeneği çok olan bir alandır. Burada kişinin kendisinin hangi alanda daha iyi olabileceğine karar vermesi gerekir diye düşünüyorum. Örneğin; döküman hazırlamaktan sıkılıyorsanız analist olamazsınız ya da iyi bir analist olursunuz belki  ama mutlu olmazsınız veya kod yazmayı çok seviyorsanız yazılımcı olmanız lazım veritabanında çalışmak beklentilerinizi karşılayamayabilir. Ya da güvenlik ilginizi çekiyordur güvenlikçi olunca o alanda daha çok mutlu olursunuz gibi. O yüzden üniversitedeyken sektörle çok ilişkili değilseniz tüm alanları bilemeyebilirsiniz ama hangi alanda daha mutlu olabileceiğinizi araştırabilirsiniz. Şu aşamada hangi alanlara yönelmeniz gerektiğini söylememiz gerekiyorsa; mobil uygulamaları , veri analitiği(bu alanla ilgilendiğim için bu alanı takip ettiğim içinde olabilir J ama şu bir gerçek ki veri(data) gerçekten çok önemli bir hale geldi), güvenlik gibi alanlar şu an  revaçta görünüyor ama teknoloji çok hızlı geliştiği için alanların revaçta olma durumları her an değişebiliyor.

rop

  1. Yeni mezun olan arkadaşların şirket kurup risk alması ne derece önemli sizce , Bu konuda onlara ne tür önerileriniz olabilir?

Eğer gerçekten fikrinize inanıyorsanız ben bunu yaptım (veya yaparım) ve satarım diyorsanız çok mantıklı bir karar vermiş olursunuz. Neden? Çünkü başka bir firmaya girdiğinizde  8.00-17.00 arası o firmanın  işini yapmak zorunda olucaksınız ve hiç mesai yapmasanız bile  8.00-17.00 arasında o işle uğraşacak haliyle yorulacaksınız eve geldiğinizde kendi fikirleriniz üzerinde  düşünmeniz gerekecek buda son derece yorucu olacaktır. Sonuçta akan bir hayat ve sosyal bir hayatınız var. Yani  başka firmada çalışıp bir yandan  kendi firmamı kurayım, kendi fikrim üzerinde çalışayım dediğinizde bu zor olacaktır. Mezun olur olmaz bir firma açayım dediğinizde de sonuçta bu firmanın vergisi olacak, çalışanı olacak yani bir sermaye elinizde olması gerekiyor ve günümüz şartlarında az bir sermaye ile firma kuramıyorsunuz ama bedavaya firma kurabiliyorsunuz. Bu nasıl oluyor? Şu an birçok girişimciliğinizi(proje) verdiğinizde sadece bakanlığın bile verdiği destekler var ve  buna Teknoparkların,Tübitak desteklerini de ekleyebiliriz. Bu şekilde girişimleriniz varsa birçok yerden destek alabiliyorsunuz bu yerde(mekan) olabilir parasal da olabiliyor  yoksa diğer şekilde firma kurma süreci sıkıntılı bir süreç olucaktır. Eğer mezun olur olmaz  firma kurma gibi düşünceleriniz varsa bu tür girişimcilik desteklerini araştırmanızı tavsiye ederim ve eğer mezun olur olmaz  sektörde tanıdığınız veya  çevreniz de yoksa bu durumda tabi baya bi deli yürek(cesaretli) olmanız lazım J.Bu tür girişimlerde bulunmak gerektiğine inananlardanım yani kendini garantiye almak biraz da standart bir hayat yaşamak demektir her ayın 1’in de maaşınızı alırsınız , standart bir hayatınız olur ama sürekli aklınızın bir kenarında  firma açsa mıydım sorusunu atmak için girişilebilir  fakat dediğim gibi üzerinde iyi düşünülmesi gerekir.

  1. Mezun olduktan sonra akademik anlamda eğitim görevlisi olmak ya da özel sektöre atılım konusunda bize ne gibi önerileriniz olucaktır? Akademisyen olmayı hiç düşünmüş müydünüz ?

Lisans’tan mezun olduktan sonra daha da üniversiteye adımımı atmam diyenlerdenim. Belki hiçbir öğrenci çalışmayı sevmez ama ben hiç sevmem J J Çalışmayı severim ama ders çalışmak veya sınavı geçmek için çalışmayı hiç sevmezdim. Eğer kendim okuyacaksam bu  belki hoşuma gider veya ilgimi çeken bir konuda çalışmak hoşuma gider ama sınavlar ve stresi  deyince  ben bunları yapamam tekrar bu stresi kaldıramam diye düşünüyordum(yordumJ)  ama şuan Yüksek Lisanstayım ve teze başladım. İnsan, kendisini planladığının çok tezatını yaşarken bulabiliyor. Bazıları gerçekten ders çalışmayı çok sever işte o insanların akademiye yönelmesi gerektiğini düşünüyorum. Eğer gerçekten ders çalışmak, araştırmalar yapmak, makale yazmak , tez yazmak , birilerine birşeyler öğretmek sizi mutlu edecekse gördüğüm ve gözlemlediğim kadarıyla akademik dünya sizin için çok güzel bir seçenek olacaktır diye düşünüyorum. Eskiden maaşları düşüktü o yüzden pek seçenek haline gelmiyordu düşünüldüğünde tamam gider mühendis olurum belki biraz daha stresli olurum , belki daha çok çaba sarfetmem gerekiyor  ama iyi bir karşılığını alırım düşüncesi vardı ; ama  gördüğümüz gibi son senelerde de  akademik dünyasının maaşlarında da bir iyileştirme yapıldı onun dışında kendilerine vakit ayırabiliyorlar sektördeki gibi 8.00-17.00 gibi bir çalışma durumları yok. Akademisyenler de  biz çok çalışıyoruz diyorlar ve haklılarda ama en azında 8.00-17.00 arasında sürekli çalışmaları  gereken bir iş değil , yani o stresi yaşamamazlar akademide çalışmanın böyle avantajlı yanları var. Bu yüzden eğer  araştırmayı seviyorsanız,bir şeyleri öğretmeyi gaye edindiyseniz iki kişinin daha hayatını kurtarayım bir yerlere gelsinler diye düşünüyorsanız akademisyen olun. Çünkü mühendisin en güzel  ürünü yazılım olurken , akademisyenin en güzel ürünü yetiştirdiği öğrencisi oluyor ve insanlar yetiştiriyorlar. Herşeyden önce çok  kıymetli bir şeydir bu. Ve gerçekten hakkını verebiliyorsanız , öğrenci yetiştireceğim mantığıyla yaklaşıyorsanız  akademik dünyada kariyer yapın yoksa rahat diye akademiye geçip te öğrenciye PowerPoint Sunumundan  ders anlatıyorsanız bu hiç hoş olmaz o zaman akademiye geçmeyin derim. Bu tür sebeplerden dolayı akademisyen olmayı hiç düşünmedim ve halen de düşünmüyorum açıkçası bana hiçbir zaman cazip gelmedi.

  1. Yüksek lisans yapan ve lisans eğitimi alan mühendis arasında ne gibi farklılıklar var? Bize Yüksek lisans eğitimini almayı tavsiye eder misiniz?

Evet fark var ve kesinlikle yüksek lisans yapın derim. (Ben profesör’de olun derim J ama söylemek kadar kolay değil tabi J). Kariyer adımlarında yüksek lisans destekleyici bir basamak olabiliyor. Özellikle yönetici pozisyonlarında buna çok dikkat ediliyor diye biliyorum. Eğer iki aday ve bir koltuk varsa tüm parametrelere bakılıyor ve bu parametreler arasında yüksek lisans ve doktora olması da önemli bir kriter. Bunun dışında Bilgisayar Mühendislerinin çoğu İşletme, MBA, Ekonometri gibi branşlarda yüksek lisans yapıyorlar. Açıkçası, Bilgisayar Mühendisi olupta Bilgisayar Mühendisliğinde yüksek lisans , doktora yapmayı pek anlamlı bulmuyorum. Yazılımcı ya da  mühendis olarak başladığınız iş hayatınızın  ilerleyen senelerinde yöneticilik gibi pozisyonlarda çalışacaksınız. Burada teknik bir eğitim almış olan eğitimin sosyal alandaki yeterlilikleri de devreye girecektir. Yüksek lisans’ın kişisel gelişim ve kariyer açısından faydalı, avantajlı olduğunu düşünüyorum.

  1. İş hayatına ilk adımımızı attığımızda küçük bir şirket ile büyük bir şirketin bünyesinde yer almanın bize ne gibi avantaj ve dezavantajları olacaktır ?

Bu soru kendime en çok sorduğum sorulardan biriydi. Yazılım evleri diye tanımladığımız küçük işletmelerde başlarsanız az çalışan olmasından dolayı çok iş olacaktır. Her işi aynı teknoloji ile yapmazsınız yani daha çok çalışmanız ve daha çok farklı farklı teknolojileri bilmek zorundasınız. Örneğin; Ben C# biliyorum yazılım evlerinde sürekli bunu yazarım derseniz işveren açısından bu pek kabul görülen bir seçenek değildir. Kurumsal firmalara gelince bu tür firmalara girdiğinizde zaten sizi bir ekibe alırlar ve bu ekibin standartları , kullandığı teknolojiler vardır siz sadece bu teknolojileri kullanırsınız. Bunun dışında   araştırmacı bir kimliğiniz varsa  teknolojiler nasıl ilerliyor , ne çalışmalar yapılıyor  diye araştırırsınız, takip edersiniz ancak işinizde kullanmanız pek mümkün olmayabilir. Ama yazılım evlerinde teknoloji kullanımı açısından daha esnektir. Bir gün bir iş gelir C# la yapmanız gerekebilir başka bir gün işte Matlab’la  ya da Delphi ile  yapmak isteyebilirsiniz. Şu bir gerçek ki yazılım evlerinde çalışmak farklı teknolojilerden haberdar olma ve bunları öğrenebilme-kullanabilme durumunuz olabiliyor fakat kurumsal bir firmada evet yine bütün teknolojilerden haberdar oluyorsunuz ama bunların hepsini öğrenebilme-kullanabilme durumunuz olmuyor. Kurumsal bir firmada çalışıyorsanız yapacağınız iş, o işin yapılma şekli, kullanacağınız teknoloji , kullanacağınız bilgiler belli  olduğu için bütün teknolojileri kullanabilme durumunuz(şansınız) olmuyor. Yani farklı  teknolojileri öğrenerek  gerçek anlamda mühendislik yapmak  istiyorum diyorsanız  bu sefer maaş konusunda  bir engel çıkıyor ;çünkü yazılım evleri ile kurumsal firma arasında maaş olarak çok fark oluyor. rakam vermek gerekirse örneğin; yazılım evlerinde iki binle (2.000) başlıyorsanız kurumsal firmada üç binle (3.000) başlayabiliyorsunuz. Bu maaş farkındaki uçurum  bazen düşebiliyor bazen daha da açılabiliyor. Sonuç olarak bu iki tür şirketin bünyesinde çalışmak hakkında  karar verirken iş hayatından beklentiniz nedir ? sorusuna net bir cevap vermeniz gerekiyor.

  1. Dünya piyasalarında yazılım sektörü çok büyük bir paya sahip olasına rağmen ülkemizde sahip olduğu pay çok düşük bir rakamda. Ülkemizin yazılım sektöründeki geleceğini nasıl görüyorsunuz?

Aslında bir çok sektör gibi yazılım sektörünün geleceği de ülkenin geleceğiyle doğrudan ilişkilidir. Ülkenin ekonomisi ,gelişmekte olan ülkeler arasında mı yoksa teknolojiye öncü olan ülkeler arasında mı gibi soruların cevapları tüm sektörlerin geleceğini de gösteriyor. Maalesef teknoloji , dolayısıyla yazılım sektöründe öncü olmaktansa daha çok gelişmeleri takip eden bir konumdayız. Yazılım sektörüne bilgisayarın tarihçesinden itibaren baktığımızda bi 50-60 senelik ABD’de doğan bir güneş var , teknolojiyi sürekli onlar ilerlettiği için ilk memba(kaynak) orası olduğu için onlar öncü oluyor buna Japonya ,Rusya ve Almanya’yı da ekleyebiliriz ama son senelerde bizde de gelişmeler görülmektedir. Örneğin; Geçenlerde Amerika’daki bir sağlık girişiminde girişimi desteklenmiş ilk kişi bir Türk girişimci şeklinde bir haber okumuştum. Bu firmanın hiyerarşisine , çalışanlarına baktığınızda birçok Türk var ; bunun gibi Silikon Vadisinde de  Türk çalışanlar var. Artık Türkler de bu alana yönelmeye başlıyor  mesela  şuan ilköğretimde  kodlama dersleri verilmeye  başlanacak. Bu öğrencilere bir bilinç düzeyi  getirecektir. Teknoloji okuryazarlığı artmakta olan gençliğin bu alana yönelmesi de bu sektörde daha fazla çalışma yapılacağına inandırıyor.  Baktığımızda teknolojinin geleceği zaten parlak ve teknoloji artık çok hızlı ilerlediği için istemeseniz bile, dünyadan soyutlanmış bir ülke olsanız bile eğer birşeyler  üretecekseniz her türlü teknolojiye ihtiyaç duyarsınız. O yüzden bizim ülkemizde de yazılım sektörünün geleceği parlak olacaktır; çünkü insanlar işlerini teknoloji üzerinden yapacaklardır dolayısıyla teknolojide  yazılım sektörünü besleyecektir. Evet yazılım sektörünün geleceği parlak olacaktır ama ne kadar hızlı olacağını önümüzdeki yıllar gösterecektir.

  • Türkiye’de Bilgisayar Mühendisliği eğitimi ile ilgili sektörün beklentileri nelerdir? Eğitimin yeterli düzeyde olduğunu düşünüyor musunuz?

Hayır! Eğitimin yeterli düzeyde olduğunu düşünmüyorum ,aslında sadece düzey değil içerik ve planlamala ilgili de sorunlar olduğunu düşünüyorum. Örneğin yazılımcı olmak isteyen bir öğrenci lisans eğitiminde Mikroişlemciler veya Lojik dersinin temelini öğrensin ama bu dersler ile sık boğaz edip Java’yı aşağıda tutmak veya C# ‘ı göstermemek  veya bir veritabanı düşünen öğrenciye  Oracle SQL’i gösteriyorsanız bunu sadece Select Query’si ile  sabit tutmak bu alanları düşünen öğrenciler açısından son derece sıkıntılı bir durum. Gerçi bunun yapılması zor veya  şu an  üniversitelerde olan bir şey değil ama üniversitelerin sektörün ihtiyaç duyacağı alanlara göre öğrenci  yetiştirmesi  gerektiğini düşünüyorum. Örneğin; veritabanı alanında öğrenci yetişriyorsa bu alanda yetiştiripte öylece piyasaya sürmesi lazım  ve bu öğrenci piyasaya çıktığında işte ben bu alanda eğitim aldım , şu şu projeler yaptım bu konuda bilgi sahibiyim diyebilmesi lazım ama şu aşamada gördüğüm kadarıyla proje yönetimi, network , sistem güvenliği , yazılım , donanım ,… alanların hepsi aynı anda verilince öğrenci adeta overload (aşırı yükleme) oluyor. Sanırım üniversiteler  öğrenci mezun olmadan ne kadar çok alan verirsek  o kadar iyi düşüncesinde oysa mühendislikte algıyı düşünmek lazım yani normal bir ders gibi değil , yani en iyi çözüme yaklaşabilmek için  beynin biraz daha kullanılması(motorun yanması) gerekir. Çünkü mühendislikte bir problemi çok farklı yollardan çözebilirsiniz ama en iyi ,en performanslı ,en doğru  çözümü bulmak için biraz daha farklı düşünmek gerekir. Yani üniversite öğrencilere üstünkörü bütün alanları vermektense sektörden , sektör bilgisi iyi olan öğrencilere sektöre dair bigiler veren bir hocayı getirtip öğrencileri sektöre hazırlaması  gerekir. Zaten siz üniversiteyi okurken sektörden biriyle görüşmediğiniz için üniversite  de sizi sektöre hazırlamadığı için  sadece eğitim almış oluyorsunuz ,öğreniyorsunuz. Aslında bu kopukluğu kırmak için de Teknoparklar var. Teknoparkların çıkış amacı da budur yani teknoparklar hem küçük ölçekli firmalara yardımcı oluyor hem de üniversite ile sektör(piyasa) arasında bir köprü oluyor. Daha doğrusu amaçlardan bir tanesi de bahsettiğimiz köprü göreviydi ama bu amaç gerçekleşiyor mu noktasında açıkçası emin değilim.

  • Sektörde çalışmayı düşünüp iyi bir kariyere sahip olmayı hedefleyen bilgisayar mühendisi adaylarına ne tür nasihatlerde bulunurdunuz iş hayatına dair önerileriniz nelerdir ?

Derslerde kapsamlı olmasa bile teknolojileri görüyorsunuz bu teknolojileri tam öğrenmeye çalışın. Dersi geçeyim hoca şuralardan sorar şeklindeki yaklaşımdan ziyade ürün geliştirmeye  çalışın , çünkü ürün somut bir şey oluyor. Siz bir firmaya gittiğinizde yağtığınız bir web uygulamasını gösterip şurda şu var burda bu var demek işte şöyle bir çalışma yaptık şu teknolojileri kullandık demekten çok daha öte bir şeydir. Sonuçta bir projede çalışmış ve ürün çıkartarak sonuca getirmişsiniz. O yüzden ürün yapabiliyorsanız ki şu aşamada web’te , mobil’de , veri madenciliği’inde ürün geliştirmek çok kolay ;ürün geliştirmeye çalışın ve kendinizi geliştirin örneğin; daha çok araştırın , alanınızla ilgili seminer ve konferanslara katılın ,İngilizcenizi olabildiğince çok geliştirin çünkü farkedildiği üzere bilgisayar mühendisliği ile alakalı  Türkçe kaynak bulmak oldukça zor hatta neredeyse yok(Bi Türkçe kaynak diyebileceğimiz Yrd. Doç. Dr. Şadi Evren ŞEKER bilgisayarkavramlari.com var J). Girişimleri takip etmeye çalışın  kim ne yapıyor , sektör nereye gidiyor, hangi teknolojiler revaçta, işe girerken hangi teknolojiler işime yarar gibi soruları cevaplandırın. Bunun dışında yatırım alabiliyorsanız yatırımlık projeler yapmaya çalışın, yaptığınız her bir ürünü bir yere dayandırmaya çalışın. Örneğin bitirme projesi yapıyorsunuz zaten yapacaksınız neden bunu bir yarışmaya sunmayasınız ,sektörden kişiler ile network’unuzu artımaya çalışın; çünkü bazı büyük firmalar genelde kendi içerisinden CV’ler alıyor. Sektördeki ağınızın geniş olması demek CV’inizi gönderebileceğiniz daha fazla kişi demektir. Bunu menfaatçi duygular ile söylemiyorum. O insanlar size ilham da olabilirler bu açıdan network’unuzu geliştirin.

Sorunun ikinci kısmında ise iş hayatında farklı kişilerle çalışacaksınız. Üniversitede kendi arkadaş grubunuzu seçebiliyorsunuz o insanlarla takılabiliyorsunuz ama iş hayatında böyle bir seçeneğiniz yok. Türkiye büyük bir ülke ve bu ülkenin farklı farklı yerlerinden gelmiş farklı kültürdeki insanlar ile çalışabilme ihtimaliniz var. Bu yüzden sıkıntı yaşamamak adına  sosyal ilişkilerinizin iyi olması gerekiyor yok işte ben istemesem bunlarla takılmam gibi bir lüksünüz yok, çünkü o insanlarla iş yapmak zorundasınız. Birde teknolojileri takip etmek sizin açınızdan faydalı olucaktır. Kısaca iş hayatına dair size verebileceğim tavsiyeler bunlar.

 

 

Bu yazıda üniversite ve bir sonraki adımı olan sektör hakkında fikirler içerdi. Bu ilişki açısından bu yazı bana daha önce lise ve üniversite arasındaki farklı yazdığım bir yazıyı hatırlattı. Okumak isterseniz bonus olarak o yazı : Fark Var

Veri İşlemede Lider Firma : Teradata

Teradata 1979 senesinde bileşen olarak  NCR ile kurulmuş; 2007 senesinde de NCR’dan ayrılarak tek başına çalışmaya devam etmiştir.  Analitik veri uygulama, platform ve ilişkili servisler sunan Teradata, farklı kaynaklardan dataları hızlı bir şekilde biraraya getirebilir. Veri depolama ve yöneten Veri ambarı sistemidir. Veri ambarı “shared nothing ” mimarisiyle çalışır. Bu mimaride her server kendi hafıza ve işlemci gücüne sahiptir.  Veriler veri ambarı  denen  bir ortama atılır ve veri oradan çağrılıp analiz edilebilir. Farklı türde raporlar sunabilme hizmeti veren Teradata bu raporlar sayesinde iş analizinin kolaylaşmasına katkı sağlar. CRM departmanları bu verilerle kullanıcıyı daha kolay analiz edip ihtiyaçlara göre proje üretebilir.

Farklı kaynaklardaki farklı veri tiplerini tek bir yerde tek formatta tutabilir. Bu da data analizinde kolaylık sağlar.  Teradata kullanılacak dataları paralel bir şekilde işler. Bu costu azalttığı gibi işlemeyi ve etkiyi arttırır.

Teradata’ya Neden Bu Kadar  Önemli ?

Müşteri ve satış kanalları artan şirketlerin için bunlar DB tutulacak verinin artmasıyla eşdeğerdir.  Her geçen gün artan ve çeşitlenen dataların hızlı işlenmesi ve formatlanması raporlama, CRM ve datanın kontrolü açısından daha kolay olacaktır. Aksi takdirde daha fazla depolama alanı gerekecek ve data store problem olacaktır. Yeni iş uygulamaları ve veri kaynakları oluşturulamaz. Ve bu olumsuzluklar maddi bir kayba sebep olacaktır.

Bunların önüne geçmede etkili olan Teradata bu sebeple finans, telekomünikasyon, yazılım vb… bir çok büyük şirketin tercihi ve kendi alanında lider konumundadır. . Teradata Intelligent Memory, en çok kullanılan verileri belleğe alıp güncelliyor ve burada yönetiyor. Bu işlemleri kendi içerisinde yapan Teradata, burada kullanıcıya iş yüklemez. Teradata Intelligent Memory, uygulamalarda, SQL sorgularında veya verilerin depolanma şeklinde değişiklik yapılmasını gerektirmiyor. Teradata müşterilerine, in-memory verileri üzerinde veri analitiğinin kazançlarını sunuyor. In-memory’deki verilere erişim, disk I/O tıkanıklıklarını ve sorgu gecikmelerini ortadan kaldırırken, sabit disklere erişimden üç kat daha hızlı olan in-memory verilerine erişim sayesinde sistem hızı da artıyor.

Teradata Intelligent Memory, veri yönetimini garantilemek için, verileri otomatik olarak izleyen ve sıralayan sofistike algoritmalar kullanıyor. Bu algoritmalar sayesinde veriler, bellek alanındaki veri miktarını maksimuma çıkararak verileri sıkıştırılabiliyor. Teradata Intelligent Memory, yeni genişletilmiş bellek alanına sadece kendileri açısından en önemli verileri yerleştiriyor. Şirketler ve kurumlar bu sayede, yatırımlarında daha iyi finansal dönüşler de sağlayan sorgularının büyük çoğunluğunu gerçekleştirmek için sistem belleğindeki en geçerli verilere hızla erişerek kazançlı çıkıyorlar.

Teradata veri ambarı, veri tabanı ve bunların yanında analitik raporlamanın yapımını sağlayacak toolları da satıyor. Bu alanda aldığı ödüller de liderliğini kanıtlamış oluyor. 

 

Big Data kavramına da bir sonraki yazıda değineceğim. 

Kaynak : http://www.teradata.com.tr/?LangType=1055&LangSelect=true

 

CRM – Customer Relationship Management (Müşteri İlişkileri Yönetimi)

           CRM 1990’larda iş dünyasına girmiş olan bir terim olup kurum – müşteri ilişkilerinin yönetildiği uygulamalardır. CRM Uygulamaları, kurum, işletme ve kuruluşların müşterileriyle olan tüm ilişkilerini yönetmeyi amaçlar. İnternet özelinde teknolojinin hızlı gelişimi, işletme kuruluşlarının giderek artan pazar rekabetinde ayakta kalabilmesi için hali hazırda elinde var olan müşteri hacmini kaybetmemesini gerektiriyordu. Elindeki müşteriyi kaybetmemenin yanı sıra büyümeyi hedefleyen şirketler için müşteri sayısını arttırmak önemli bir hedeftir. Bu hedef doğrultusunda CRM uygulamaları memnun müşteriler oluşturma, müşteri ihtiyaçlarını önceden belirleme ve doğru hedef kitleye doğru pazarlamayı yapma vb. ihtiyaçlara cevap geliştirir.

          CRM’de temel hedef müşteriyi memnun etmektir (müşteri ihtiyaçlarını doğru okumak). ”Müşteri her zaman haklıdır  “  sözü CRM’nin temel taşlarından birisidir diyebiliriz. Bu günlük deyimden esinlenmişken günlük hayattan örneklerle devam edelim. Marketlerde birbiriyle bağlantılı ürünlerin yakın raflarda bulunması, doğum günlerinde şirketlerin müşterilerine mesaj göndermesi, çok satan gazetelerin bakkallarda üst bölmelerde yer alması gibi basit örnekler CRM’in basite indirgenmiş halidir.  CRM Uygulamaları müşteriye daha profesyonel müşteri hizmeti sunmayı sağlar. Müşteriye özel sunulan çözümler müşteri memnuniyetini sağlayıp, şirketin reklamını şirketten daha iyi yapmasını sağlayabilir.

        Müşteri verilerini işlenip analiz edilmesiyle şirketin önünde alacağı yolda yapacağı işlerde güvenilir ipuçları sağlar.  Bu veriler sayesinde müşterilerin sevebileceği ürünler hakkında fikir sahibi olabilir ihtiyaçlarına cevap verebilirsiniz. Yine şirketler bu verilerle ihtiyaç doğrultusunda kampanyalar gerçekleştirerek daha profesyonel bir müşteri hizmeti sunabilir. Verilerin bu şekilde analiz ve gruplandırılması sadece müşteri tarafında olumlu sonuçlar vermekle kalmayıp ; çalışanların verilere çok kolay ulaşmasıyla çalışma verimliliğini de arttıracaktır. Haliyle müşteri memnuniyeti ve çalışanların verimliliği de başarıyı beraberinde getirecektir.

CRM ile ilgili olarak literatürde kullanılan bazı ifadeleri buraya not düşmek istiyorum. Bir sözlük niteliği taşıyan bu ifadeler CRM mantığının oturmasına da yardımcı olacaktır diye düşünüyorum.

Aktif Sadakat: Müşterinin ne sıklıkta ve en son ne zaman şirket ürünlerini kullanıldığını, müşterinin şirkete bağlılığını ifade eder.

Birebir Pazarlama(One to One Marketing) :  Müşteriye özel pazarlama şekli.

Cross Selling (Çapraz Satış) : Müşterinin genel eğilimleri analiz edilerek bu datalar üzerinden müşterinin satın alabileceği ürünleri pazarlamaktır.

Direct Marketing(Doğrudan Pazarlama): Analizi yapılmış müşterinin ihtiyaçlarına göre direk sms, email vb yollarla satış bilgisinin müşteriye pazarlanmasıdır.

En Çok Büyüyebilir Müşteri (Most Growable Customers ,MGC): Firma için stratejik değeri gerçek değerini geçebilecek müşteri tipi. Bu tür müşteriler çapraz satış, daha uzun süreli müşteri bağlılığı hatta belli işbirliğine girilerek etkin maliyet yönetimi ile firma için en karlı müşteri haline dönüştürülebilir.

En Değerli Müşteri (Most Valuable Customers ,MVC):
 Firma için gerçek değeri en yüksek, en karlı, en bağlı ve firma ile öğreten ilişki çerçevesinde en fazla işbirliği yapan ya da yapmak isteyen müşteri tipi.

Veri Ambarı (Data Warehouse): Çeşitli veri tabanlarından çekilerek biçimlendirilen ve karar vermede kullanılan bilgi deposu

Veri Madenciliği (Data Mining): İstatistik veya yapay zeka yardımıyla verilerin analiz edilerek
aralarında yeni bağlantılar kurulmaya çalışılması

Veri Modelleri (Data Models): Bir şekilde ilişkili olan firmanın tüm verilerinin kümeler halinde toplanmasıdır.

Dünden Bugüne İnternet

İnternet’in doğumgünü olan 12 Mart 1987’den bu yana çeyrek asır geçmiş. İnternet bu çeyrek asırlık sürede önceki tüm asırlardan daha hızlı bir gelişim yaşanmasına önayak oldu. 2014 yılı itibariyle çeyrek asırlık bir geçmişe sahip internetin doğumundan önceki gelişim evresine bakıp sonrasında bu yirmibeş senelik zamanı ele alalım. Teknolojiye dair çoğu gelişmenin doğuş seruvenine bakıldığında 1960’lı yıllara denk geliyoruz. İnternete giden ilk adımlar da yine 1960’lı yıllarda atılmış.1962 yılında J.C.R. Licklider’in teknoloji dalında dünyanın önde gelen üniversitelerinden biri olan Massachusetts Institute of Tecnology’de (MIT) tartışmaya açtığı “Galaktik Ağ” kavramı ilk kez global bir ağ fikrini öne sürüyor. Galaktik Ağ kavramı küresel olacak bir sistemde herkesin bulunduğu yerden bağımsız bir şekilde veriye ulaşabilmesini ifade ediyordu. O senelerde savunma sanayisini için bilgisayar çalışmalarına önem veren Amerikan Savunması Licklider’ı 1962 Ekim’inde araştırma projesi olan İleri Savunma Araştırma Projesinin (DARPA ) başına getirdi. Yine MIT’te çalışan Robert Lawrance ve Thomas Merrill, 1965 yılında ilk kez bilgisayarların birbiri ile ‘’ konuşmasını ‘’ gerçekleştirmişlerdir. 1966 yılının sonlarına gelindiğinde Robert, DARPA’da çalışmaya başladı ve ARPANET isimli projeyi öneri olarak sundu. Arpanet adlı bu proje 1970 yılında hayata geçti. Bu ağlar değişik fiziksel ağlardan tek bir mantıksal ağa bağlantı için Internet protokolu (IP) kullanırlar. Internet orjinal ARPANET’ den doğmuş, bağlantılı ağların dünya çapında bir kolleksiyonudur. Arpanet başta sadece 15 bilgisayarın birbirine bağlı olduğu bir ağdan ibaretti ve özel kullanıcılara kapalıydı. ARPANET şu üç işlevi sağlıyordu.
Uzak Makinelere Bağlanma (remote login)
Dosya Aktarımı (file transfer)
Elektronik Posta

ARPANET çerçevesinde ilk bağlantı 1969 yılında dört merkezle yapıldı ve ana bilgisayarlar arası bağlantılar ile internetin ilk şekli ortaya çıktı. ARPANET’İ oluşturan ilk dört merkez University of California at Los Angeles (UCLA), Stanford Research Institute (SRI), University of Utah ve son olarak University of California at Santa Barbara (UCSB) idi. Kısa süre içerisinde birçok merkezdeki bilgisayarlar ARPANET ağına bağlandı. 1972 yılında elektronik posta (e-mail) ilk defa ARPANET içinde kullanılmaya başladı. İngiltere Kraliçesi’nin 1976 yılında ilk e-mailini göndermesiyle internet fikri popüler hale gelmeye başladı.

Burada internetin keşfinde önemli bir payı bulunan Vinton Cerf’in kısa bir hikayesini de sizinle paylaşmak istiyorum. Her başarılı erkeğin arkasında bir kadın vardır ! 🙂
” Vinton Cerf, 1970’lerde genç bir matematik mühendisiydi. Kulakları duymayan karısı dünyayla rahat iletişim kurabilsin diye interneti icat etti. Vinton Cerf, 1970’li yıllarda üniversiteyi yeni bitirmiş, yirmili yaşlarının sonunda bir matematik mühendisiydi. Doğuştan kulakları duymayan Carinne’e aşık oldu. Carinne, kimseyle iletişim kuramıyor, telefonla bile konuşamıyordu. California Üniversitesi Matematik Mühendisliği’nde bilgisayarlar arası bilgi transferiyle uğraşan Cerf’in ise tek isteği karısını mutlu etmekti. İnternet, o zamanlar askeri amaçla kullanılan bir sistemdi. Sivillerin kullanamadığı internet, kısa sürede 200 ayrı sivil kuruma yayıldı. Cerf interneti geliştiren bilim adamları arasındaydı. Ancak o daha önemli bir şey yaptı ve interneti karısının da kullanabileceği bugünkü haline getirdi.

En çok karım sevindi
Eğer bunu yapmamış olsaydı internet denilen uçsuz bucaksız dünyada kimse istediği bilgiye ulaşamazdı. Cerf bugün, “Karım artık üniversitede okuyan oğlumuzla bile internet yoluyla konuşabiliyor. Kimbilir belki de interneti karımı mutlu edebilmek için icat etmişimdir” diye konuşuyor.


1 Ocak 1983 tarihinternetinde İletişim Kontrol Protokolu (TCP/IP) adıyla ARPANET içinde kullanılmaya başladı. TCP/IP bugün varolan internet ağının ana halkası olarak yerini aldı. Yine 1983’te Domain Name System (DNS) kullanılmaya başlandı. .edu, .gov, .com, .mil, .org, .net, ve .int gibi internet alan adları oluşturuldu.

İnternette patlama yaşandığı zaman dilimi ise hiç kuşkusuz 1990’lar. 1990 – ArpaNET’in sonu ve World Wide Web‘in başlangıcı. İlk web sitesi Tim Berners Lee tarafından kuruldu. Sayfada internetin ne olduğu ve nasıl kullanılacağı anlatılıyordu. Host sayısı her yıl katlanarak artıyordu. 1994’e gelindiğinde internetteki site sayısı 10 bine, host sayısı ise 3 milyona ulaşmıştı ve girişimciler bu yeni dünyada yepyeni kazanç kapıları olduğunu farketmişti. Jeff Bezos alışveriş sitesi Amazon.com‘u kurdu. İlk internet radyosu yayına başladı. Hükümetler başta olmak üzere pek çok organizasyon web sitesi açtı. Yepyeni bir pazarlama ve ekonomi anlayışı doğuyordu. Bankalar ve alışveriş merkezleri sanal şubelerini açmaya başladı. 1994’te internetteki ilk reklam ekranlara düştü. 1995 – Dünya üzerinde internet kullanıcılarının sayısı 16 milyon. Jerry Yang ve David Filo Yahoo’yu kurdu.

1995’te Hong Kong’da ilk hacker yakalandı, aynı sene alan adları paralı oldu. Netscape ve Microsoft arasında yazılım savaşları başladı. 1998 – Larry Page ve Sergey Brin Google’ı kurdu

Sosyal medyanın temelini oluşturan Web 2.0 uygulamaları 2004 yılında başladı. Ve aynı sene Mark Zuckerberg Facebook’u kurdu. Fotoğraf paylaşım sitesi Flickr kuruldu. Bu ve benzeri paylaşım siteleri günden güne daha populer bir hal almaya başladı. Nitekim bir sene sonra eski PayPal çalışanı Steve Chen, Chad Hurley ve Jawed Karim YouTube‘u kurdu. 2006’da Web sitelerinin sayısı 100 milyonu geçmişti. Twitter kurulmuş Google, kurulduktan bir yıl sonra YouTube’u satın almıştı.

2012’de  dünya üzerinde internet kullanıcılarının sayısı 2 milyar 267 milyona ulaştı. Dakikada gönderilen e-mail sayısı 204 milyon, atılan tweet sayısı ise 100 bin Facebook Instagram’ı 1 milyar dolar nakit para karşılığında satın aldı, bu rakam bir mobil uygulama için verilen en yüksek miktar olma özelliğinde 2013 ‘te ise İnternet kullanıcı sayısı 2000 yılından bu yana %566 büyüyerek 2 milyar 405 milyona ulaştı. İnternette en çok yaygın olan 5 dil İngilizce, Çince, İspanyolca, Japonca, Portekizce.

Türkiye ise ilk geniş alan ağı 1986’da EARN bağlantılı TÜVEKA’dır. İnternetin ülkemizde yaygınlaşmasında en çok katkısı olan iki kurum TÜBİTAK ve ODTÜ’dür. 1996 yılında TÜRK TELEKOM’un katkılarıyla TURNET kullanılmaya başlanmış , 1997 yılında akademik merkezlerin internet bağlantısını sağlayan ULAKNET ile güzide üniversiteler birbiri ile bağlantılı hale gelerek internet kullanmaya devam etmişlerdir. 1999 TURNET yerini TTNET isimli yeni oluşuma devretmiştir. Şu an alternatifler bulunsa da bu alandaki sektorun öncüsü halen TTNET.

Sosyal Medyanın Doğuşu

Sosyal medya neredeyse herkesin en az bir tane mecrasını kullandığı bazılarının birden fazla hatta 4 5 tane sosyal ağda birden bulunduğu bir ortam. Ancak nasıl oldu da sosyal medya bu kadar hayatımıza girdi ve nasıl oldu da biz bu kadar çabuk benimsedik sosyal ağları ? Bu konuyla ilgili geçmişten gelen merakıma cevaplar araken bununla ilgili bir yazı yazmaya karar verdim. Lakin ne bir yazıya sığabilecek kadar kısa bir hikayesi ne de bir başlık altında toplanabilecek kadar dar kapsamlı bir konu Sosyal Medya.  Bu sebeple bu konuyu kategorilendirip  hakkında birden fazla yazı yazmanın uygun olacağını düşündüm. Hem de uzun süredir burada yazamıyor olmanın acısını çıkaracaktım 🙂 Geçen sene de bu konu ilgimi çekmiş olacak ki sosyal medya ile ilgili bir yazıyı burada yayınlamışım.  Bu yazıda öncelikle ilk çağlardan günümüze iletişimin nasıl sağlandığından bahsedip sosyal medyanın nasıl ortaya çıktığıyla ilgili bilgileri paylaştım. Eğer direkt sosyal medya kısmına geçmek isterseniz sonraki iki paragrafı es geçip dördüncü paragrafa geçebilirsiniz.

Sosyal medya su an için insanlar arasındaki iletişimin sağlandığı en önemli ortam. Daha önce köy,kasaba veya mahallenizle olan sosyal ortamınız sosyal medyayla birlikte ülke sınırlarını da kaldırarak dünyayı bir hane haline getrirdi. Köy bile değil ! Bunları düşünüp bununla ilgili yazmayı düşünürken eski çağlarda insanların nasıl iletişim kurduğu sorusu kurcaladı aklımı. Şu an bizim için iletişim denilince aklımıza ne geliyorsa buyuk çoğunluğu ilk çağlarda  yoktu olabileceği hakkında bir fikirleri olmuş mudur bilemem ama 5000 sene  bu konuda uzun aralıklarla gelişmelerin olduğunu öğreniyoruz.  Konuşma bile sonradan keşfedilmiş. Önceleri sadece vucut işaretleriyle iletişim kuran insanoğlu konuşmayı bulunca ne kadar sevinmiştir kim bilir 🙂  Burada bir merakımı daha paylaşmak isterim. Bir bebeğe konuşma öğretilmezse kendiliğinden konuşabilir mi ?  İlginizi çekerse diye linkten cevaplar bulabilirsiniz.

Yazılı iletişimde ise ilk keşifler M:Ö 3000 senelerine dayanıyor. HİYOROGLİF denilen bu yazı sisteminde şekil ve semboller kullanılıyor. Yazıyla ilk tanışma Mısır ve Mezopotamya coğrafyasında gerçekleşiyor. Ve uzun süre yazıya dair ‘medeniyete’ dair sorularımız bu coğrafyada cevabını buluyor. Mısır medeniyetinin köklülüğü burada da karşımıza çıkıyor. Daha sonra en köklü gelişme 1440 ‘te matbaanın icadıyla gerçekleşiyor. Matbaanın icadı aslında 9.yy da uygurlara dayandırılsa da genel bilinen tarih 15.yy. Matbaa’da basılan ilk kitabın İncil olması her zaman dini kitaplara verilen kıymeti görme açısından önemli diye düşünüyorum. Matbaa, 200 seneye yakın süre sonra – İbrahim Müteferrika -sayesinde Osmanlı’ya gelir.  Yazıyla ilgili bu gelişmeler yaşanırken iletişimle ilgili konuşma tarafındaki ilk buyuk gelişme 1876 da Graham Bell tarafından telefonun icadıyla gerçekleşti. 20.yy ise çok önemli gelişmelere zaman sahipliği yapmış özellikle son donemleri iletişim alanındaki gelişmelerle başdondurucu bir hal almış bir dönem.

Bu kısa ön girişten sonra gelelim konumuza : Sosyal Medya nasıl doğdu ? 1960 lı yılların sonlarına doğru artan programlama dilleri ,Amerikanın özellikle Askeri amaçlarla teknoloji alanında yaptığı çalışmalar teknolojinin gelişmesinde önemli bir rol almıştır. Bu gelişmeler haliyle insanların bu alana yönelmesini sağlamış olmalı ki bu senelerin gençleri Bill Gates, Steve Jobs gibi gelecek yıllarda dünyaca nam sahibi olacak gençlere ve bilgisayarın gizli kahramanları Dennis Ritchie ve Ken Thompson gibi isimlerin yetiştiği dönemlerdir.

Teknoloji sayesinde insanlar arasındaki iletişim yani ilkel sosyal medya 1971 de gönderilen ilk email (elektronik mektup) ile başlıyor.

1991 de WWW(worldwideweb- dünya çaplı ağ) ortaya çıkmasıyla sosyal medyanın tohumları atılmış oluyordu.

1994 ‘te Justin Hall ‘in ilk kişisel blogundan sonra 1995 yılında classmates.com isimli blog ile bir manada sosyal medya doğmuş oldu. İnsanların eski sınıf arkadaşlarını bulabileceği bu ortamda blogun sahibi Ray Sears’ın asıl amacı ilk kız arkadaşı ve sınıf arkadaşı olan kızı bulmaktı. Bulmuştu lakin kız artık evli ve iki çocuk annesi olmuştu. Mutsuz Son 🙂

Eski sınıf arkadaşlarını bulmak amacıyla kurulan bu blog insanların teknolojiyle birbirini keşfedebileceğinin kanıtı olmuştu. 1999 yılında Blogger ve LiveJournal’ın hayatımıza girmesiyle artık sosyal medyada bulunma çok daha kolay hale gelmişti. Ülkemizde ise 1999 yılında kurulan Ekşi Sözlük ile internetteki ilk sosyal topluluk oluşturulmuştur.

2000 yılında bilgi anlamında sosyal medyadaki en büyük kaynak olan Wikipedianın sonrasında Stumbleupon, Friendster ve Linkedin’in açılması ile internet üzerindeki sosyal alanlar daha da artmaya başlandı. Friendster insanların internette kendi profilleriyle var olması açısından önemlidir. Gerçek hayatlarındaki profillerin yanısıra internet ortamında da sahip oldukları bir profilleri vardı artık. Ertesi sene iş hayatındaki insanların birbirleriyle etkileşiminin amaçlandığı Linkedin açıldı. Bu siteye giriş için gerekli bilgilerin doğruluğuna büyük önem veriliyordu.

2003 yılında Google’ın Blogger’ı satın aldığı sene ileride bloggerın en büyük rakibi olacak olan WordPress kurulur.

sosyal medya

2004 yılı ise tam bir dönüm noktası olmuştur. Çünkü ileride büyük bir kesimi içinde barındıracak Facebook bu sene açılmıştı. Eğer hikayesini biliyor ya da filmini izlediyseniz eğlenceli kuruluşu ilgi çekicidir. Harvard üniversitesinde başlayan dalga şimdi tüm dünyaya yayılmış durumda. Şu an 1.5 milyar facebook kullanıcısı var. Ve teknolojiden bihaber insanlar ile küçük çocukları dünya nufusundan çıkardığınızda neredeyse insanları yarısı facebook kullanıyor ! Sizce de bu muazzam bir rakam değil mi ?

 

 

Asıl hikaye bundan sonra başlıyor 🙂

1 2