Blog

Mobil Yazılım

Mobil Uygulama Teklif Brief Şablonu (Kurumsal)

Kurumsal bir mobil uygulama için teklif toplamak istiyorsanız, en çok zaman kaybettiren şey şudur:
“Herkes farklı anlıyor, teklifler kıyaslanamıyor.”

Benim önerim: Teklif istemeden önce 1 sayfalık net bir brief çıkarın. Böylece:

  • Gelen tekliflerin kapsamı aynı olur,
  • Süre / bütçe sapmaları azalır,
  • “Sonradan çıkar” kalemler en baştan konuşulur.

Aşağıdaki mobil uygulama teklif brief şablonu, kurumsal projeler için pratik bir başlangıçtır. İsterseniz direkt kopyalayıp doldurun.

1) Projenin Özeti (1 paragraf)

  • Proje adı:
  • Amaç (neden yapıyoruz?):
  • Başarı kriteri (ne olursa “başardı” diyeceğiz?):

Örnek: “Saha satış ekibinin ziyaretlerini, fotoğraf + konum kanıtıyla raporlamak ve ERP’ye anlık aktarmak.”

2) Hedef Kullanıcılar ve Roller (RBAC)

  • Kullanıcı tipleri (rol listesi):
    • Admin / Yönetici
    • Saha personeli
    • Bayi / müşteri temsilcisi
  • Her rol ne yapacak? (kısa maddeler)

3) Platform ve Kapsam

  • Platform: iOS / Android / Flutter
  • Dil: TR / EN / çoklu dil?
  • Tahmini kullanıcı sayısı:
  • Bölge: Türkiye / global

4) Temel Özellikler (Must / Should / Nice)

Aşağıdaki gibi 3’e ayırın:

Must Have (Olmazsa olmaz)

  • Login / SSO
  • Rol bazlı yetkilendirme
  • Listeleme / detay / form akışları
  • Fotoğraf / dosya yükleme
  • Konum alma + zaman damgası
  • Offline çalışma (var/yok)
  • Bildirim (push) (var/yok)

Should Have (Olursa iyi olur)

  • Rota / görev yönetimi
  • Harita
  • Raporlama ekranları
  • Yönetim paneli

Nice to Have (Sonraya kalabilir)

  • AI destekli öneriler
  • Otomatik etiketleme vb.

5) İş Akışları (2–5 ana senaryo)

Her biri 3–6 adım olacak şekilde yazın:

Senaryo 1: Saha ziyareti

  1. Check-in
  2. Fotoğraf çek
  3. Form doldur
  4. Check-out
  5. Rapor ERP’ye gitsin

6) Veri ve Entegrasyonlar

  • Entegrasyon var mı? ERP / CRM / başka sistem:
  • API var mı? (varsa dökümantasyon)
  • Veri akışı:
    • Uygulamadan ERP’ye gidenler
    • ERP’den uygulamaya gelenler
  • Entegrasyon yöntemi: REST / SOAP / middleware / file transfer?

7) Offline Çalışma ve Senkronizasyon (Kurumsalda kritik)

  • Offline gerekli mi? (Evet/Hayır)
  • Offline iken hangi işlemler yapılacak?
  • Senkron ne zaman olacak?
    • otomatik / manuel / wifi olunca
  • Çakışma durumunda kural ne? (son yazan kazanır vb.)

8) Güvenlik / KVKK / Loglama

  • KVKK açısından hassas veri var mı? (var/yok)
  • Yetkilendirme: JWT / OAuth2 / SSO
  • Loglar nerede tutulacak?
  • Fotoğraf/konum gibi kanıt verisi için saklama süresi?

9) Performans ve SLA (bakım beklentisi)

  • Çalışma saatleri: 7/24 mü?
  • SLA beklentisi:
    • kritik hata müdahale süresi
    • normal hata
  • Bakım modeli: aylık bakım paketi / çağrı başı

10) Teslimatlar (tekliflerin kıyaslanması için şart)

  • Kaynak kod teslimi (Git repo)
  • Test ortamı / staging
  • Dokümantasyon
  • Yönetim paneli (var/yok)
  • App Store / Google Play yayın desteği

11) Zaman Planı ve Milestone

  • Hedef başlangıç:
  • Hedef canlıya çıkış:
  • Tercih edilen yöntem:
    • MVP → iterasyon
    • Tek seferde final

12) Bütçe ve Teklif Formatı (bu bölüm teklif kalitesini uçurur)

Tedarikçiden şunu isteyin:

  • Tahmini süre (hafta)
  • Tahmini ekip: PM/BA, mobile dev, backend dev, QA
  • Kalem kalem fiyat kırılımı:
    • analiz & tasarım
    • geliştirme
    • test
    • yayın
    • bakım

En sık yapılan 5 hata (ve nasıl önlersiniz)

  1. “10 ekran” deyip akışları yazmamak → senaryoları ekleyin
  2. Offline ihtiyacını belirsiz bırakmak → net karar verin
  3. Entegrasyon dokümanı olmadan teklif istemek → API dokümanı paylaşın
  4. Teslimat tanımı yok → kaynak kod, doküman, test ortamı yazın
  5. Bakım/SLA konuşulmuyor → en baştan bakım modelini belirtin

NOT: Bu şablon genel olarak tüm yazılım projelerinde, inhouse veya outsource geliştirilen projelerde, kurumsal olmayan projelerde de kullanılabilir. Kendi ihtiyacınıza göre düzenleyebilirsiniz ana hatlara sadık kalarak. Bu sayede ne istediğinizi daha net anlatmış olursunuz ve daha düzgün bir teklif/çıktı alırsınız.

Yardımcı olmamı istediğiniz bir konu var ise iletişim sayfamdan benimle irtibata geçebilirsiniz.


2026 da ai ile mobil uygulama maaliyetleri değiştii mi

Mobil Uygulama Fiyatları: AI Maliyeti Düşürür mü? (2026)

Son dönemde en çok duyduğum sorulardan biri şu:

“Ferhat, AI çıktı… artık yazılım daha ucuz değil mi?”

Kısa cevap: Bazı işlerde evet, ama kurumsal projelerde resim biraz daha farklı.
AI (kod asistanları, otomatik test, tasarım üretimi, dokümantasyon araçları) geliştirme süreçlerini hızlandırdı. Fakat iş “kurumsal mobil uygulama”ya geldiğinde, maliyetin asıl belirleyicileri hâlâ aynı: kapsam, mimari, entegrasyonlar, kalite ve sürdürülebilirlik.

Ben bu yazıda, sahada gerçek projelerde gördüğüm şekilde anlatacağım: AI mobil uygulama maliyetini nerede düşürür, nerede düşürmez? Ve “mobil uygulama fiyat hesaplama” yaparken nelere bakmak gerekir?

1) AI gerçekten neyi ucuzlattı?

AI’nın en net faydasını, tekrarlayan ve standart işlerde görüyorum:

  • Basit ekranlar (listeleme, detay, form gibi)
  • Standart kullanıcı akışları (login, profil, ayarlar)
  • Boilerplate kodlar (temel altyapı)
  • Dokümantasyon ve örnek kod hazırlığı
  • Bazı test senaryolarının hızlı çıkarılması

Bu tip işlerde AI, geliştirme süresini kısaltabildiği için mobil uygulama fiyatları tarafında aşağı yönlü bir etki yaratabiliyor.

Ama…

2) Kurumsal projelerde neden “maliyet otomatik düşmüyor”?

Kurumsal bir mobil uygulamanın maliyeti genellikle “kod yazmak”tan ibaret değil. Hatta çoğu zaman en büyük maliyet kodun kendisi değil, şu parçalar:

  • İş analizi (scope): Ne yapılacağı doğru tanımlanmazsa AI sadece yanlış işi hızlandırır.
  • Mimari & ölçeklenebilirlik: Çok kullanıcı, rol-yetki, performans, raporlama.
  • Offline çalışma & senkronizasyon: Saha ekipleri için kritik ve karmaşık bir konu.
  • ERP/CRM entegrasyonları: Kurumsalda asıl zorluk burada başlar.
  • Güvenlik & KVKK: Yetkilendirme, loglama, veri saklama politikaları.
  • Kalite ve yayın süreçleri: Cihaz çeşitliliği, App Store süreçleri, stabilite.

Yani AI iyi bir hızlandırıcı ama kurumsalda maliyetin “kritik kalemleri” hâlâ uzmanlık ve süreç yönetimi istiyor.

3) Mobil uygulama maliyeti neye göre çıkar?

“Mobil uygulama maliyeti”ni hesaplarken ben genelde şu 7 başlığa bakıyorum:

  1. Ekran sayısı ve akış karmaşıklığı
  2. Rol-yetki yapısı (admin, saha, bayi, yönetici…)
  3. Offline gereksinimi
  4. Cihaz özellikleri (push, konum, foto/video, dosya yükleme)
  5. Entegrasyonlar (ERP/CRM, ödeme, SMS/e-posta, kargo vb.)
  6. Raporlama ve yönetim paneli
  7. Bakım & SLA (kurumsalda asıl değer burada)

Bu yüzden “mobil uygulama fiyat hesaplama” dediğimiz şey tek bir kaleme bakarak yapılmıyor. “10 ekran var” demek tek başına yeterli olmuyor; o ekranların arkasındaki iş akışı, entegrasyon ve kalite beklentisi fiyatı asıl belirliyor.

4) AI ile birlikte bütçe nereye kaydı?

Benim gözlemim şu: AI sayesinde bazı proje tiplerinde toplam maliyet düşebiliyor; ama çoğu kurumsal projede olan şey şu:

  • Geliştirme süresi kısalıyor (iyi)
  • Ama analiz, test, entegrasyon ve bakım daha çok önem kazanıyor (zorunlu)

Yani şirketler “daha ucuz yazılım”dan çok daha hızlı ve daha güvenli teslimat kazanıyor. Bu da uzun vadede toplam sahip olma maliyetini (TCO) düşürüyor.

5) Kurumsal müşteri için en doğru soru: “Ucuzlar mı?” değil, “Sürdürülebilir mi?”

Kurumsal tarafta benim için kritik olan şey şu:

  • Yarın bir ekip devraldığında bu sistem yürür mü?
  • Yeni özellik geldiğinde sistem çatlar mı?
  • Saha operasyonunda internet gidince çalışır mı?
  • ERP değişince entegrasyon yönetilebilir mi?
  • Bakım ve SLA düzgün mü?

Bunlar oturduğunda, zaten maliyet “doğru yerden” optimize edilmiş oluyor.

Sonuç: AI tek başına fiyat düşürmez, doğru süreç fiyatı düşürür

AI, iyi kullanılırsa geliştirmeyi hızlandırır. Ama kurumsal işlerde maliyetin ana belirleyicileri hâlâ: kapsam, mimari, entegrasyon, kalite ve bakım.

Eğer sen de “mobil uygulama geliştirme” projen için net bir yol haritası ve gerçekçi bir bütçe aralığı istiyorsan, en hızlı yöntem şu: 15 dakikalık kısa bir ihtiyaç analizi.

İletişim / Teklif

Projene göre mobil uygulama maliyeti ve zaman planını netleştirmek için buradan iletişime geçebilirsin:
👉 https://ferhatbalaban.com/#contact

Flutter vs Native: Tartışma artık bitsin :)

“Flutter mı native mi?” sorusunu son yıllarda çok sık duyuyorum. Açık konuşayım, bu cümle bana artık biraz eski geliyor. Çünkü Flutter’ı gerçekten kullanmış, production uygulama çıkarmış biri için bu tartışma çoktan başka bir yere evrildi.

Hâlâ “flutter mı seçelim native mi?” noktasında takılıyorsak, genelde konunun tamamına bakılmıyor demektir. 2025’e geldiğimizde bu tartışma teknik bir tartışma olmaktan çıktı. Daha çok karar verme biçimiyle, projeye nasıl yaklaşıldığıyla ilgili bir mesele hâline geldi.

Şunu baştan netleştirelim. Zaten Flutter native çalışır. Dart kodu AOT olarak derlenir. Android’de native binary çıkar, iOS’ta native binary çıkar. UI WebView üzerinden dönmez, JavaScript yoktur. Flutter kendi render engine’i ile ekranı doğrudan GPU’ya çizer. Yani Flutter web değildir, hybrid değildir, React Native hiç değildir. Bu kısım artık tartışmaya açık değil.

Peki o zaman neden hâlâ “Native daha performanslı” lafı dönüp duruyor?

Bence burada asıl karışan şey performansla kontrolün aynı kefeye konması. Oysa bunlar farklı şeyler. Ve kafa karışıklığı tam da buradan çıkıyor.

UI tarafında konuşalım. Animasyonlar, scroll’lar, ekran geçişleri… Düzgün yazılmış bir Flutter uygulamasıyla native bir uygulama arasında, kullanıcıya hissettiren bir performans farkı yok. Hatta bazı animasyon ağırlıklı ekranlarda Flutter daha tutarlı bile olabiliyor. Bunun sebebi tek bir render pipeline’a sahip olması. O yüzden bugün hala UI performansı üzerinden Flutter’ı eleştirmek bana çok anlamlı gelmiyor.

Asıl fark, işin platforma ne kadar yakın çalıştığı noktada başlıyor.

Native geliştirirken işletim sisteminin içindesin. Lifecycle senin elinde, background servisler senin kontrolünde, sensörler, Bluetooth, kamera gibi konularda doğrudan söz sahibisin. Flutter’da ise işler biraz daha katmanlı ilerliyor. Dart tarafındasın ve native tarafa geçerken platform channel kullanıyorsun. Bu kötü bir şey değil ama şu gerçeği de kabul etmek gerekiyor: Flutter native’e çok yakındır ama native kadar “içeride” değildir.

Bu fark her projede kendini göstermez. Hatta birçok projede hiç hissetmezsin bile. Ama bazı projelerde net şekilde ortaya çıkar. Özellikle yoğun background işlem yapan, sürekli sensör okuyan, OS lifecycle’ına çok hassas çalışan uygulamalarda Flutter tek başına yetmemeye başlar. O noktada genelde Flutter + native plugin yazma yoluna girilir. Bu yanlış bir yaklaşım değildir ama artık saf Flutter’da olmadığını kabul etmiş olursun.

Bu arada şunu da net söylemek istiyorum. Flutter projelerinde yaşanan performans problemlerinin büyük kısmı Flutter’dan kaynaklanmaz. Yanlış state yönetimi, gereksiz rebuild’ler, karmaşık widget ağaçları, kötü mimari… Bunlar varsa native yazsan da aynı problemleri yaşarsın. Flutter bu noktada sadece günah keçisi olur.

Benim gözlemim şu: Bu tartışma yıllardır bitmiyor çünkü genelde teknoloji seçimi, düzgün flutter yapısının kurulması proje başlamadan önce değil, sorunlar çıktıktan sonra sorgulanıyor. Proje yavaşlıyor, ekip zorlanıyor, bakım maliyeti artıyor… Sonra dönüp “Flutter mı hatalıydı?” deniyor. Oysa çoğu zaman sorun yanlış başlangıç kararlarında oluyor.

Kendi tecrübemden söyleyeyim. Flutter’ı kullandığım ve “iyi ki Flutter seçmişiz” dediğim bir sürü proje oldu. Hatta hiç pişman olmadım bu seçimden. Sadece ilk flutter a geçtiğimiz zamanlarda biz de bazı hatalar yaptık 🙂 Bunları çabuk farkedip düzelttik ve ustalaştık bu konuda.

Hızlı MVP çıkarmamız gereken, tek kod tabanıyla iOS ve Android’e aynı anda gitmek istediğimiz, UI ve iterasyon hızının kritik olduğu projelerde Flutter gerçekten çok güçlüydü. Bir projede, başladıktan sonra uzun bir süreden sonra ilk defa flutter kütüphanelerinin yetmediği bir yere denk geldim. Onda da kendi plugin imizi yazıp konuyu çözdük. Yani yine bir sorun yaşamadık.

Burada iş sadece teknik değil, ekip yapısıyla da ilgili. Küçük bir ekip, hızlı hareket etmesi gereken bir ürün ve sınırlı bütçe varsa Flutter ciddi avantaj sağlar. Ama büyük ekipler, uzun vadeli kurumsal projeler, çok sık geliştirici değişimi olan yapılar söz konusuysa, teknoloji seçiminin bakım maliyetine etkisi çok daha belirgin hâle gelir.

Yanlış teknoloji seçiminin faturası genelde hemen çıkmaz. İlk aylar her şey yolunda gider. Ama 6 ay sonra, “buraya dokunmayalım”, “şu kısmı bozmayalım”, “bunu değiştirmek riskli” gibi cümleler artmaya başlar. İşte o noktada mesele Flutter mı Native mi olmaktan çıkar; doğru karar verilip verilmediğine gelir.

O yüzden bana göre “Flutter mı Native mi daha hızlı?” sorusu artık yanlış soru. Asıl soru şu olmalı: Bu proje işletim sistemine ne kadar yakın olmak zorunda? Eğer cevap “çok yakın” ise native daha doğru bir tercih olur. Eğer cevap “çok da gerek yok” ise Flutter gayet güçlü bir çözümdür.

Toparlarsam, Flutter vs native sorusu yerine asıl soru işletim sistemine yakınlığı ve ne kadar çok os tabanlı iş yaptığıdır. Seçim bence buna göre yapılmalıdır. Çok derin bir şekilde os ile çalışıyor ve kütüphaneler performans sorunu çıkaracak bir durum var ise ben anca o zaman native seçerim. Yoksa bugün geldiğimiz noktada hem performans, hem maaliyet hem de kodun okunabilirliği açısından kesinlikle flutter ile devam etmeyi öneririm. Ancak tekrar çok önemli bir notu ekleyerek bitireyim. Düzgün bir flutter yapısı kurmzsanız olmaz. O zaman da flutter ı suçlamak yerine yapıya kuranların ne yaptığına odaklanmak gerekir. Yani herkes bugün flutter kolay ben yaparım diye ortaya çıkabiliyor ama ne kadar düzgün bir yapı kurduğu ve performansa dikkat edip etmediği çok tartışılır. Keşke native yapsaydık dediğiniz bir noktaya gelebilirsiniz dikkatli ve düzgün bir yapı kurulmaz ise.

Flutter ile tek kod ve tüm platformlar

Flutter, Google tarafından geliştirilen, iOS, Android, Web ve Desktop için yüksek performanslı, tüketicinin beklentilerini karşılayan uygulamalar oluşturmayı hedefleyen bir mobil uygulama frameworkü olarak bilinir. Ancak Flutter’ın avantajları sadece bunlarla sınırlı değil. İşte Flutter’ı benzersiz kılan birkaç özellik:

1. Tek Kod Tabanı

Flutter, geliştiricilere iOS, Android, Web ve Desktop için uygulamaları tek bir kod tabanıyla yazma olanağı sunar. Bu, geliştirme sürecini hızlandırır ve işleri kolaylaştırır. Maliyetden tasarruf imkanı sağlar. 4 platforma da geliştirme yapacaksanız tek bir developer ile de işlerinizi yapmanız mümkün hale gelir.

Örnek bir “Merhaba Dünya” uygulaması:

import 'package:flutter/material.dart';
 void main() {
   runApp(MyApp());
 }
 class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Merhaba Dünya',
       home: Scaffold(
         appBar: AppBar(
           title: Text('Merhaba Dünya'),
         ),
         body: Center(
           child: Text('Merhaba Dünya!'),
         ),
       ),
     );
   }
 }

2. Hot Reload

Flutter’ın “hot reload” özelliği, geliştiricilerin yapılan değişiklikleri anında görmesini sağlar. Bu, hataların hızlıca bulunmasını ve düzeltilmesini sağlar ve geliştirme sürecini önemli ölçüde hızlandırır.

class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Hot Reload Örneği',
       home: MyHomePage(),
     );
   }
 }
 class MyHomePage extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return Scaffold(
       appBar: AppBar(
         title: Text("Hot Reload Örneği"),
       ),
       body: Center(
         child: Text("Değişiklikleri anında görün!"),
       ),
     );
   }
 }

Bu kodu çalıştırın ve "Değişiklikleri anında görün!" metnini değiştirin. Hot Reload özelliği sayesinde uygulamanın durumunu kaybetmeden değişikliği hemen görebilirsiniz.

3. Performans

Flutter, Dart dilinde yazılmıştır ve Dart, Just-In-Time ve Ahead-Of-Time derleme yeteneklerine sahiptir. Bu özellikler, uygulamanın başlangıç süresini hızlandırır ve performansını iyileştirir.

4. Zengin Widget Kütüphanesi

Flutter, kullanıcıların modern ve çekici bir arayüz oluşturmasını sağlayan bir dizi widget sunar. Bu widget’lar hızlı ve kolay bir şekilde uygulamaya entegre edilebilir.

class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Zengin Widgetler',
       home: Scaffold(
         appBar: AppBar(
           title: Text('Zengin Widgetler'),
         ),
         body: Center(
           child: RaisedButton(
             onPressed: () {},
             child: Text('Bir Buton Widgeti'),
           ),
         ),
       ),
     );
   }
 }

Bu kod parçası, basit bir buton widget’ini kullanarak kullanıcıya etkileşimli bir öğe sunar.

Flutter, bu gibi özellikleri sayesinde uygulama geliştirmede yeni bir çağ açmaktadır. Tek kod tabanı, hot reload, yüksek performans ve zengin widget kütüphanesi gibi özellikler, geliştiricilere daha hızlı ve daha etkili uygulamalar oluşturma imkanı sağlar. Üstelik bunu tüm platformlara export yapabilme özelliği ile birleştirerek bize zaman kazandırır. Sadece zaman değil ayrıca tek kod sayesinde ortak bir kalite yakalanmış olur. Tekrar eden kodlar azalır. Tabi ki tek kod ortamında kodunuz yine kaliteli olmak zorunda. Yazdığını flutter uygulamasını kötü yazarsanız sonuç tüm platformlarda kötü olacaktır. Bu yüzden işe başlamadan önce iyi araştırmak, örnekleri incelemek ve gerekirse eğitim almak önemlidir. Bir de şuna deyinmeden geçmemek lazım. Flutter bir client geliştirme aracı. Yani siz kapsamlı bir iş yapıyorsanız sağlam bir backend e de ihtiyaç duyacaksınız. Bunun için ayrı bir detaylı backend makalesi yazacağım.

Flutter’ın son gelişmelerini takip etmek ve tüm bu eşsiz özelliklerini keşfetmek için https://flutter.dev sitesini ziyaret edebilirsiniz. Nasıl kurulur, kullanılır ve son stabil sürümleri nelerdir https://docs.flutter.dev adresinde mevcut. Her stabil sürüm upgrade i ile çok daha iyi hale gelen flutter ı siz de öğrenebilir ve projelerinizde kullanabilirsiniz.

Flutter ile herşey daha kolay!

Herkese merhaba,

Uzun zamandır bir yazı paylaşmadığımı farkederek genel olarak bir paylaşım yapmak istedim.

Biliyorsunuz eskiden yaptığım paylaşımlarda ios da swift , android de ise java ve kotlin kullanarak native mobil uygulama geliştirme yaptığımızdan ve flutter a geçtiğimizden bahsetmiştim.

Bu serüven devam ediyor ve yeni yapılan uygulamaları flutter da yapıyoruz. Ancak eskiden gelen bazı uygulamalar hala native swift ve java,kotlin de devam ediyor. Büyük uygulamaları flutter a geçirmek kolay değil tabiki ancak sıfırdan yazılan uygulamalarda flutter ın kolaylıklarını çok aramaya başladık.

Son 3 senedir flutter ile uğraştığımızı düşünürsek oldukça deneyimimiz oldu bu konuda. İlk başlarda eski yönteme göre alışması zor olsada bir kere alıştığınızda artık herşey daha hızlı ve kolay oluyor. Hele birde hazırladığınız bir çatı var ise bu iş artık her projede daha kolay hala geliyor.

Flutter ve Getx kütühanesi de bu işi beraber daha da hızlandırıyor.

Sizler için flutter getx örneği hazırladım. Bu örnekde flutter ı çalıştırmayı ve biraz ön bilgisi olanların anlayabileceği sade bir yapı mevcut. İçerisinde bir başlangıç seti mevcut. Nasıl bir çatı kurmalıyız? Hangi kütüphaneleri kullanmalıyız hepsi mevcut.

https://github.com/balabanferhat/FlutterGetXWithNavigation

Ayrıca sayfamdaki diğer flutter örneklerini de inceleyebilirsiniz.

https://github.com/balabanferhat

İyi bir yazılımcı olmak için 11 altın kural

İyi bir mobil uygulama yazılımcısı , web yazılımcısı yada backend yazılımcısı olmak bazı ortak temel özellikleri barındırıyor.

Bu ortak özellikler şu şekilde sıralanabilir. Elbette daha vardır ama bunlar ilk etapta aklıma gelenler ve önemli olanlar. Bunları hem yazılımcıların hem müşterilerin düşünmesi için yazıyorum. Umarım herkese faydalı olur.

  1. Her alanda çalışabilmeli (Mobil uygulama, web uygulaması, backend). Sadece hangisine yoğunlaşır ise onda daha hızlı sonuç elde eder.
  2. Konsantrasyonu iyi olmalı. Odaklandığı zaman işi (yada hedeflediği kısmı) bitirebilmeli.
  3. Pes etmemeli. Bazen geceler boyu sabahlamak gereksede pes etmeden devam etmeli.
  4. Çok iyi araştırmalı. Çözemediği konuları yada daha iyi ne yapabilirim gibi düşünerek araştırma yapmalı. Kendi kendine araştıran ve çözüm üretebilen biri olması çok önemli çünkü her zaman size yardımcı olacak birini bulamazsınız.
  5. Temel algoritmaları bilmeli. Günümüzde yazılıma yeni başlayan çoğu kişi algoritma çalışmadan yazılım öğrenmeye kalkıyor. Yazılım dilini öğrensede, zor problemeri algoritmalar kurarak çözemiyor. Önce bir programlama dili seçip (javascript, dart, php, c# gibi) burada algoritma çalışmak çok önemli.
  6. Dokümantasyon yapmalı. Hem kendi için hem kendisinden sonra kodlara girecek kişi için bunu yapmalı. Kodun için gelişigüzel yorumlar yazmak yerine düzgün yorumlar yazıp, bir readme dosyası hazırlayarak içine önemli konuları not etmeli (ör: nasıl build alınır , dev ve prod ortamına nasıl deploy edilir vs…)
  7. Versiyon kontrolü kullanmalı. Ekip halinde çalışmıyor bile olsa, yedek almak, ileride ben ne yapmıştım diye bakmak ve kodu düzgün teslim etmek için git sistemini biliyor olmalı.
  8. Etik olmalı. İşi eksiksiz ve gereken kişiye anlatarak ve dokümantasyonlar ile teslim etmeye özen göstermeli. Açılan bazı hesapları müşteri adına açmalı ve bunlara ait dokümantasyonları işe başlarken tutmaya başlayıp anında müşterisi ile veya işi yaptığı kişi ile paylaşmalı. Kendisine birşey olsa işe ne olacak düşünmeli. Para kazandığı yere ihanet etmemeli, dürüst ve ahlaklı olmalı.
  9. Devir alabilmeli. Başkasının yazdığı kodu incelemeyi çoğu yazılımcı sevmez. Kodu inceleyip sonra sorumluluğu üstlenerek yazan kişiden devir alabilmeli. Çoğu kişi maalesef anlamaya çalışmak yerine bu olmamış ben bunu baştan yazayım diyerek hem daha çok kendine iş çıkarma derdinde hem de öncesinde kodu yazan kişiye çamur atarak prim yapma derdinde oluyor. Düzgün devir almayı öğrenmek zorundayız. Bir kere karşınızdaki kişi işten anlamıyor diye bu olmamış demek bence dolandırıcılıktan başka birşey değildir.
  10. İyi debug yapabilmeli. Maalesef karşılaştığım çoğu yazılımcı debug yapmayı , kodu takip etmeyi bilmiyor. Yazdığınız kodu her durumu düşünerek debug yapmanız ve nasıl davrandığını incelemeniz gerekiyor.
  11. Tasarım gözü iyi olmalı. Tasarımcı olması gerekmiyor ama biraz da zevk olması lazım. Bunun içinde yapılan tasarımları incelemeli , trendleri takip etmeli. Bir iş yaparken ui (arayüz) tarafına özenmeli.

Sizde iyi bir yazılımcı olmak ve bu özelliklerin üstünde durup kendinizi geliştirmek istiyorsanız benimle irtibata geçebilirsiniz.