Bir kursu tamamladınız, YouTube'da bir dizi video izlediniz veya iOS geliştirmeyle ilgili bir dizi makale okudunuz ve artık ilk evcil hayvan projenizi yazmaya hazır olduğunuzu hissediyorsunuz.

Öncelikle aferin! Bu harika. Sen havalısın! 💪

İkinci olarak, bir evcil hayvan projesi becerilerinize harika bir katkı sağlar. Talimatları takip etmeden kendi başınıza bir şeyler yapmaya başladığınızda, tonlarca zaman ve çaba harcamanız, Google'a çok fazla harcamanız, yığınla yeni bilgi okumanız ve bunları filtreleyip durumunuza tam olarak uydurmaya çalışmanız gerekir. Kısacası sizi beş kat güçlendirecek gerçek bir görev zaten.

Ancak yeni başlayanların çoğu önemli şeyleri görmezden gelir (kendi inisiyatifleriyle değil, önemlerini anlamadan). Son altı aydır aktif olarak mentorluk ve evcil hayvan projeleri de dahil olmak üzere yeni gelenlerin soru ve sorunlarına yardımcı olmak.

Yeni başlayan biri olarak mutlaka sahip olmanız, uzmanlaşmanız, anlamanız ve kullanmanız gerekenler listenize dahil etmeniz gereken en önemli 3 noktayı belirledim.

Erişim Düzeyi

İlk başta neredeyse hiç kimse private değiştiriciye dikkat etmiyor. Bu arada, gece yarısı uyandırırsanız herkes anında SOLID'i açıklayabilir. Çeşitli akıllı makaleler okuyan insanlar, S (tek sorumluluk) fikrine göre bir grup sınıf oluşturmaya çalışırlar.

Ve sonra, vicdan rahatlığıyla, class A özelliğini, class B özelliğini değiştirirler.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

Genel olarak, eğer hala belirsizse, plan şu: her zaman her yere private yazın ve derleyici şikayet ettiğinde, bu özelliğe veya işleve dışarıdan erişmenin uygun olup olmadığını düşünün. Ve eğer öyleyse - private kaldırın .

Düşündüğünüzde gerçek dünya karşılaştırmalarıyla kendinizi yönlendirin. Örneğin, sınıfınız bir mağazaysa, goods özelliğinin harici müşterinin erişimine açık olması gerekir. Ancak moneyInCashRegister yalnızca dahili bir mağaza çalışanı tarafından değiştirilebileceği açıktır.

Sonuçta, bir müşterinin bırakın fetch , put ile bile kasaya erişimi olmamalıdır.

Birisi şöyle iddia edebilir: "Hangi özelliğe dokunulabileceğini ve hangisine private bir değiştirici olmadan bile dokunulamayacağını çok iyi anlıyorum". Ancak erişim düzeyi değiştiricilerinin yazılması tasarımın bir parçasıdır. Üçüncü katında kapısı dışarıya açılan bir evin planını eminim yapamazsınız.

Ve sonra açmamayı unutmayın. Sonuçta başkalarının da kodunuzu kullanması muhtemeldir.

Bu arada var ve let için de benzer bir durum mevcut. Tekrar ediyorum, değeri değiştireceğinizden hemen emin olmadığınız sürece her zaman let kullanın.

Mimari Sadelik

Yeni başlayanların her şeyi önceden planlamaya çalıştıkları bir eğilim fark ettim. Bu övgüye değer olsa da geliştiriciler deneyim eksikliğinden dolayı sıklıkla hata yapıyorlar. Aşırı karmaşık yöneticileri önceden hazırlarlar (genellikle Yığın Taşması ) sonunda asla kullanmadıkları birçok karmaşık yöntemle. Sonuç olarak kodun miktarı ve karmaşıklığı artar.

Programcımız, kullanışlı ve hazır bir hizmet gibi görünen bir hizmet yerine yalnızca sorunlarla ve yanlış anlamalarla karşılaştı. Aynı şey mimari için de geçerli.

Demek istediğimi anlatmak için size programlama tarihi boyunca kısaca yolculuk yapmama izin verin. 1960'ların sonuna gelindiğinde programlamanın popülaritesi artmaya başladıkça programların boyutları da arttı. Anlayabileceğiniz gibi, daha büyük bir program boyutu daha fazla kod satırı anlamına gelir, bu da karmaşıklığın artmasına ve programın anlaşılmasının zorlaşmasına yol açar.

Bu sorunu çözmek için, programların daha küçük, yönetilebilir parçalara bölünmesine olanak tanıyan işlevler ve prosedürler olan yapılandırılmış programlama ortaya çıktı. Kod modüler, yeniden kullanılabilir ve daha anlaşılır hale geldi.

Yapılanmanın ortaya çıkışı, programların yeniden boyut ve karmaşıklık sınırlarına ulaşana kadar daha da büyümesine yol açtı. Bu nedenle 1970'lerin sonu ve 1980'lerin başında nesne yönelimli programlama yaklaşımı oluşturuldu. Bu çözüm, giderek daha karmaşık hale gelen görevleri ele alan esnek ve ölçeklenebilir sistemlerin oluşturulmasına olanak sağladı.

Sonraki on yılda bilgisayar oyunlarının patlamasına tanık olduk. Kullanıcı eylemlerine (tıklamalar, basmalar) verilen tepkinin kritik olduğu ortaya çıktı ve Olay Odaklı Programlamanın ortaya çıkmasına yol açtı.

Web ve masaüstü uygulamalarındaki kodu düzenlemek için (aynı verinin farklı perspektiflerden yeniden düzenlenmesi gerektiğinde) MVC modeli (yani modeli görsel temsilinden ayırmak) ortaya çıktı.

Ana fikri anladınız: Bir sorun ortaya çıkar, -> bir çözüm ortaya çıkar. Sorun -> Çözüm.

Peki neden yeni başlayan programcılar sorunların henüz ortaya çıkmadığı bir zamanda çözümleri (mimarileri) uygulamaya başlıyor? Öğreticilerde hemen en azından bir MVP seçilmesi öneriliyor. Bir/iki ekran için test görevleri her zaman MVC'nin KULLANILMAMASINI belirtir.

Görüşmeler sırasında, aynı bir/iki ekranla birkaç evcil hayvan projesi yazan bir kişiye VIPER sorunları sorulur. Henüz karşılaşmadıysa sorunları nasıl bilebilir?

İnsanlar sıklıkla mimari bağlamda test edilebilirliğin rahatlığından bahseder, ancak hiçbir zaman test yazmamışlardır. Ve eğer öyleyse, bu yalnızca bazı eğitimlere dayanıyordu ve bunları gerçek bir uygulamaya bağlamadan yalnızca birim testlere odaklanıyordu.

MVP şemasını basit terimlerle açıklayabilirler ancak ViewInput ve ViewOutput gibi benzer adlara sahip protokoller söz konusu olduğunda sıklıkla kafaları karışır. Derinlerde zaten bunların hepsini bir yük olarak görüyorlar 🙄🤯

Sonuç: Kendinize sorun yaratmayın. MVC'den utanmayın. Kontrol cihazınız çok büyüdüğünde veya zorluklarla karşılaştığınızda yeni yaklaşımlar aramanın zamanının geldiğini anlayacaksınız.

Kullanıcı Arayüzü Basitliği

Ön uç geliştirme, yeni başlayanlar için bir dopamin cennetidir. Kodu yazarsınız ve sonucu anında ekranda görürsünüz; ödülünüzü alırsınız 🍭. İnkar edilemez derecede motive edici. Ancak bu madalyonun bir de diğer yüzü var. Yeni başlayanlar genellikle hemen aşırı karmaşık kullanıcı arayüzü oluşturmaya çalışırlar.

Dahası, karmaşık özellikler karmaşık kullanıcı arayüzünü takip etme eğilimindedir. SwiftUI bugün görevi basitleştirse de, kişi gerçek bir ilerleme kaydetmeden zil ve ıslık eklemek için hala çok zaman harcayabilir.

iOS geliştirmeyi ekipler kurarak tek bir proje üzerinde çalıştığımız bir kursta öğrendim. Ekibimdeki bir adam, uygulama geliştirmemize karanlık mod için yazı tiplerini ve renkleri seçerek başlamayı önerdi.

Genel olarak, tüm kursu bunun üzerinde harcadı ve yazı tiplerinin ve renklerin muhteşem ortaya çıktığını belirtmekte fayda var. Ancak adam tüm bu süre boyunca yaklaşık olarak sıfır satır gerçek kod yazdı.

Şüphesiz uygulamanızın güzelliği ve işlevselliği çok önemlidir. Sonunda bu konuya zaman ayırmanız gerekecek. Daha basit bir şeyle başlamak daha iyidir. Bir MVP (minimum uygulanabilir ürün) geliştirin, en kritik özelliklere odaklanın ve oradan başlatın.

80–20 kuralı burada geçerlidir — uygulamanın temelini oluşturun ve ardından ekstraları ekleyin. Aksi yaklaşım, karmaşık nüanslarla boğuşmaya ve sürekli bozulan bir ana işlevsellik ile sürekli uğraşmaya yol açacaktır.

Mobil geliştirmede yeni başlayanlar için karmaşık çözümleri zamanından önce benimseme riski vardır. Ön uç geliştirmenin görsel ödülleri baştan çıkarıcı olsa da, basit bir MVP ile başlamak genellikle daha akıllıca olur.

Tarihsel eğilimler, çözümlerin gerçek zorluklara yanıt olarak gelişmesi gerektiğini ileri sürüyor.

Temel ilkeleri anlamak ve gerçek dünya sorunlarını ortaya çıktıkça ele almak, etkili gelişim için kritik öneme sahiptir.

Burada da yayınlandı