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 ve evcil hayvan projeleri de dahil olmak üzere yeni gelenlerin soru ve sorunlarına yardımcı olmak. mentorluk 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 değiştiriciye dikkat etmiyor. Bu arada, gece yarısı uyandırırsanız herkes anında açıklayabilir. Çeşitli akıllı makaleler okuyan insanlar, (tek sorumluluk) fikrine göre bir grup sınıf oluşturmaya çalışırlar. private SOLID'i S Ve sonra, vicdan rahatlığıyla, özelliğini, özelliğini değiştirirler. class A class B 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 kaldırın 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 . 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, özelliğinin harici müşterinin erişimine açık olması gerekir. Ancak yalnızca dahili bir mağaza çalışanı tarafından değiştirilebileceği açıktır. goods moneyInCashRegister Sonuçta, bir müşterinin bırakın , ile bile kasaya erişimi olmamalıdır. fetch put Birisi şöyle iddia edebilir: "Hangi özelliğe dokunulabileceğini ve hangisine 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. private Ve sonra açmamayı unutmayın. Sonuçta başkalarının da kodunuzu kullanması muhtemeldir. Bu arada ve için de benzer bir durum mevcut. Tekrar ediyorum, değeri değiştireceğinizden hemen emin olmadığınız sürece her zaman kullanın. var let let 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 ) sonunda asla kullanmadıkları birçok karmaşık yöntemle. Sonuç olarak kodun miktarı ve karmaşıklığı artar. Yığın Taşması 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 ve 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 🙄🤯 ViewInput ViewOutput 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. 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. 80–20 kuralı burada geçerlidir — uygulamanın temelini oluşturun ve ardından ekstraları ekleyin. 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. da yayınlandı Burada
