Standart Belirleme Çalışmaları

* Android - Http Networking Tool -> Retrofit
* iOS - Http Networking Tool -> Alamofire
* VCS - Git
* Android - iOS MVVM  pattern referenced design.
* Common - İçeriği boş dahil olsa kullanılan her user interactional component Custom Component hale getirilmelidir.
* Common - Custom Componentlerde view design ve code behind mümkün mertebe birbirinden bağımsız olmalıdır.
* Android - Activity ve Fragment kullanım tercihleri Activity first olmalı ve mimariye bağlı olarak Fragment first ilerlemek gerekirse Navigation Component altyapısından yararlanılmalı.
* Android’te Kotlin first, iOS’te Swift first ilerlenmeli ve framework tercihlerinde de bu dillerin kullanılmış olması tercih esnasında kritik faktörler arasında yer almalı.
* Common - Kodlama esnasında yorum satırları içerisinde sadece kod blokları olmamalı, yorum satırları haline getirilen kodlar için mutlaka açıklamalar bırakılmalıdır.
* Common - Custom Component lerde Android - iOS tasarımsal benzerlikler, ilgili platformun doğasına uygun olarak mı yapılmalı yoksa bire bir mi yapılmalı konusu, her proje için değerlendirme konusu olmalı, her ne kadar bire bir benzerlik akla yaktın gibi görünse de, platformun doğasına uygun tasarlanan component ler, platform sahibi provider company ler tarafından update ler ile desteklenmekte ve takip eden geliştirme araçlarındaki değişiklikler sonucunda daha çabuk adapte edilebilir olmakta ve platform specific kullanıcı deneyimine katkı sağlamaktadır. Bu durum, ufak çaplı projelerde çok göze batmasa da, uzun vadeli ve gittikçe büyüyen projelerde development sürecini hızlı, platform specific kullanıcı deneyimini yüksek ve stability’i kararlı kılmaktadır.
* Common - Platformların native davranışlarına mümkün mertebe müdahale edilmemeli çünkü platform deneyimi, uygulama deneyiminden daha önceliklidir. Sayfalar arası geçişler, popuplar vb. gibi birçok yapı, platform native bırakılmalı. Özellikle cihaz çeşitliliğinin gittikçe arttığı bu dönemler, ileride bu durumun ne kadar değer yaratacağını daha da gözler önüne serecektir.
* Common - Kullanılan platform specific yazılımlar, Android ve iOS ta benzer şekilde wrapper ler ile wrap edilmeli ve platformlar arası geliştirmede ortak geliştirme deneyimi kolaylığı sağlanmalı.
* Common - Canlıya Alınan Her Versiyon için Deployment Kaydı Açılmalı ve bu kaydın id sinin bulunduğu bir tag, master branch’ine eklenmeli. Canlıya çıkacak olan versiyon QA den çıkılmalı ve canlıya alındıktan bir süre sonra master’a ilgili deployment kaydının id si ile taglenmeli ve merge edilmelidir.
* Common - Client larda debug mode için yapılan her network req res console a son olarak loglanmalı.
* Common - Uygulama kullanımı esnasında kullanıcının yaptığı hemen her network based işlem,  splunk, seq vb. toollarda  indexlenmeli. 
* Common - Servisler yapılan işleme bağlı olarak batch(bulk) olmalı yani istek gereksinimleri atomik hale getirilmeli ve Httip Batch - HttpMultipartBatch istekler yapılmalıdır. Bunun için servislerin de multiple işlemlerde mümkün mertebe birleştirilmiş atomik hale getirilmesi lazımdır(Sub Requesting).
* Common - Client lar business logic management anlamında mümkün mertebe dummy bırakılmalıdır. Logic hakimiyeti mümkün mertebe backend te olmalıdır. Client content değişiklikleri için CMS ler hazırlanmalıdır.
* Common - Çok dosya - az satır kod prensibine uyulmalı.
* Common - En ufak bir satırlık kod bile olsa task’ı açılmalı ve Task ID ler commit mesajlarında mutlaka yer almalıdır.  Task üzerinden takibi olmayan 1 satır kod bile olmamalıdır.
* Common - Bir senaryoya bağlı olarak tasarlanan servisler, url yapıları, istek parametreleri, header ları, body leri ve response structure ları, yazılım mimarının onayı alınmadan yapılmamalıdır. Bu şekilde standart yapı oluşturulmuş ve next development süreçlerinin hız akışları artırılma evresine girmiş ve development estimation time ların doğruluğu arttırılmış olur.
* Common - Agile süreçler oturtulmalı, amaç değil araç olmalıdır. Paradokssal olarak agile’ın amaçlaştırılması agile a aykırı süreçler doğurur.
* Common - Yapılan kodlamalarda development süreci ya develop branch’i üzerinden mevcut repo forklanarak, yahut ilgili TaskID isimli branch açılıp aynı repo üzerinden pull request ler üzerinden sürdürülmelidir ve ilgili platformda yetkili birileri varsa, o arkadaşlara PR(pull request) lar açılmalı ve PR onaylanmadan merging işlemi yapılamamalıdır.
* Common - High level development platformlarında (Android, iOS vb..)  ilgili platformların IDE leri ile de sunulan (Xcode, Android Studio vb..) lint warningler, coding changes ler için temizlenmeden açılan pull request lere bakılmamalı, bunu yakalamak için de IDE lere sağlanan bu toolar, CI(Continues Integration) toolarının pull requesting triggerlarına entegre edilmelidir ve pull request ekranına lint warningler bastırılmalıdır.
* Common - Büyük çaplı ve çok developer lı projelerde projenin geliştirildiği IDE versiyonunun upgrade’ine dahi yazılım mimarı karar vermelidir. Yazılım mimarı yeni versiyonda projenin stability sinden emin olduktan sonra onay vermeli ve geliştiricileri yönlendirmelidir.
* Common - Proje yazılım dosyaları kullanıcı senaryosu bazlı değil, platform specific teknik bazlı olarak klasörlenmelidir. Çünkü kullanıcı senaryoları, gelen CR(Change Request) lara bağlı olarak klasörler içerisinde yer alan kod dosyalarının hitap ettiği senaryoyu değiştirebilmektedir ve bu da yeniden manage edilmesi gereken klasör yapısı güncellemeleri gibi anlamsız iş yükleri doğurabilmektedir.
* Common - Mümkün mertebe external library kullanılmadan geliştirmeler yapılmaya çalışılmalıdır. CD(Continous Delivery) müşteri öncelikli olması münasebetiyle aksatmamak için external library support alınacak olsa da, daha sonrasında ilgili feature ler için bütçe(zaman) ayrılırsa, proje  external library independent hale getirilmeye çalışılmalıdır. Bu external library lerin versiyonları, kullanılan build toollarına bağlı olarak(gradle, carthage, cocoapods vs..) sabitlenmelidir, dynamic bırakılmamalıdır.
* Common - Belirlenen standartlar iş sürecinin takibine bağlı olarak süreç olgunlaşmasına binaen incremental olarak uygulanmalıdır.
* Common - In House Distribution - İlgili platformların en azından son 10 versiyonlarının olduğu bir web FQDN(Full Qualified Domain Name) üzerinden versiyonlarına erişilebilecek altyapı oluşturulmalıdır. Bu versiyonların olduğu alana: ** Evvela manual olarak alınan ipa - apk - aab lar yine manual olarak eklenebilir. ** Sonrasında CI vasıtasıyla otomatik olarak alınan buildler yine otomatik olarak ilgili alana eklenmelidir.
* Common - Böyle çok katmanlı süreçlerden oluşan mimari, belli periyotlarla incelenmeli ve  proje verimliliğine olan katkısı yeterli değilse veya olumsuz yönde ise değiştirilmeli, yahut kaldırılmalıdır.
* Common - Hemen her proje için en azından 2 ortam olmalıdır. Bunlar <PROD> - [PILOT] - [QA] - <TEST> şeklinde olmalıdır.(<> -> Required , []  -> Optional). PROD ortamı kesinlikle geliştirmeye bağlı verilerin ve yazılımların değiştirildiği ortam olmamalıdır. Bu durum kesinlikle yanlıştır. Yazılımlarda gereken her değişiklik VCS üzerinden PR lar ile  from .. to PROD, verilerde ise sağlanan son kullanıcı arayüzlerinden yapılmalıdır.
* Backend - Her servis için swagger benzeri yapı mevcut olmalı ve buranın güncel tutulmasının sorumluluğu ilgili backend developer da olmalıdır.
* Business Process - İş sürecinde doğru kararların alınabilmesi için münazara kültürü(ilmi) aşılanmalıdır. Bu süreç, başarılı projelerin ortaya çıkmasında çok önemlidir. Doğru fikirlerin ortaya çıkması için uzak ya da zıt fikirlerin çarpıştırılması gerekmektedir. Bu sürecin başarıyla uygulanabilmesi için konumu değil iş’i koruma yönelimli kültürün hakim olması gerekmektedir. Agile da bundan dolayı retrofit toplantıları vardır ve özellikle planning evresinden önce yapılması, planning ve refirement’a ciddi katkı sağlamaktadır. İlk bakışta kulağa marjinal gelebilir ama büyük ve başarılı şirketlerde bu bir standarttır ve kimi insanların bunu kurumsal soğukluk algıladığı yönde bir yanılgı vardır.
* Business Process - Bir manager yapılan herhangi bir proje ile ilgili negatif bişey olduğunu ifade ettiğinde, bu negatiflikten sorumlu olan personelin bunu sonuna kadar yalın bir şekilde ifade etmesi gerekmektedir. Aksi durumda sürecin ifade edilmesinin önüne geçilmesi (agile’ın şeffaflık prensibi’ne aykırı olmakla birlikte) personelde demotivasyon meydana getirebilir ve bu durum şirketin kaynaklarından beklenen ve üstünde olabilecek verimi aşağı çekme hamlesine dönüşen bir süreç meydana getirebilir.
* Business Process - İş süreçleri mümkün mertebe mailleşme üzerinden sürdürülmeli ve ilgili işten sorumlu üstlerin cc ye eklenmesi gerekmektedir. Çünkü özellikle büyük ve büyümekte olan şirketlerde işler ve süreçler de büyüdüklerinden takiplerin kolaylaşması, gözden donelerin kaçmaması ve süreci sekteye uğratacak ihmalkarlıkların oluşmaması buna bağlıdır.
* Common - Aynı projelerde çalışan ekibin veya ekiplerin çalıştıkları platformların (Android Studio, Xcode, VS Code, Visual Studio, Mac OS, Win OS vs.) versiyonları dahi aynı olmalıdır, upgrade ya da downgrade talebi teknik lider’e ya da yazılım mimarı’na iletilmeli, gerekli araştırma ve testler yapıldıktan sonra ilgili versiyona geçilmelidir. Bu şekilde ilgili proje sürecine yeni dahil olacak arkadaşlar çok daha hızlı bir şekilde dahil olabilir ve özellikle eleman sirkülasyon’un sık olduğu şirketlerde projeye adapte olma sürecinin teknik gereksinimleri hızlı bir şekilde giderilebilir. Tabi konu spesifik istisnai durumlarda sorumlu personellerin toolarının versiyonları, takım olarak çalışmayı baltalamayacak şekilde değiştirmesi gerekirse bu durum değerlendirilmelidir.
* Common - İlgili proje canlıya QA branch'ten çıkıldıktan sonra master branch'ine merge edilmeli ve çıkılan version name ile VCS üzerinde merge commit taglenmeli.