17 yıldan fazla bir süredir Yazılım Geliştirme endüstrisinde çalışıyorum ve kısaltmalardan payımın uçup gittiğini gördüm, bazıları diğerlerinden daha anlamlı, bazıları diğerlerinden daha komik kelimeler oluşturuyor. Ancak bununla yüzleşelim, geliştiriciler olarak kısaltmalarımızı seviyoruz, MVP ve PoC gibi onları yaratan her kimse gerçek bir çaba harcamamış gibi ses çıkaran bazı normal kısaltmalarımız var. Ve sonra SOLID, DRY ve KISS gibi diğerlerine de sahip oluyoruz, kendilerini bazı komik etkileşimlere borçluyuz.
Bununla birlikte, çevrede o kadar çok var ki, anlamlarını tazelemeye ihtiyacınız olursa diye, en yaygın (ve daha az yaygın) olanları bir tur atacağımı düşündüm.
Kolay biriyle başlayalım, eminim bunu pek çok kez görmüşsünüzdür, ama bunun ne anlama geldiğini biliyor musunuz?
Bu çok yaygın bir yazılım geliştirme ilkesidir. Kendini Tekrar Etme anlamına gelir . Ve temelde, kod yazarken, birden fazla kullandığınız modülerleştirme işlevselliğini düşünmeniz gerektiği anlamına gelir.
Beni yanlış anlamayın, modülerleştirme ile iki kez kullandığınız bir işlev için kitaplıklar oluşturmayı kastetmiyorum, daha ziyade aynı mantığa (veya çok az çabayla genelleştirebileceğiniz kadar benzer) farklı bir şekilde kullanıyorsanız daha sonra bu mantığı bir işlevin içine taşımayı düşünmelisiniz ve birkaç yerde tanımladığınız bir işleviniz varsa, bunu ortak bir modüle taşıyın.
Ve sonra yine, bir modülü bir yerden bir yere kopyalıyorsanız, bu modülü ortak bir kitaplığa dönüştürmeyi düşünün.
Başka bir deyişle: Kendini Tekrar Etme, anladın mı?
Kişisel olarak, üzerinde çalıştığınız dil veya geliştirdiğiniz platform ne olursa olsun, bu ilkenin tavsiye edilmeyeceği çok az durum vardır. Bir geliştirici olarak, işinizin davranışı otomatikleştirmek olduğunu düşünün (burada makro ölçekte konuşun), bu nedenle belirli kodunuzu yakınlaştırırsanız, aynı şeyi yapmanız gerekir. Aynı mantığı defalarca yazmak yerine, genellemeyi ve sıradan bir yere taşımayı düşünün.
İpucu: KURU kuralı tek bir depo ile sınırlı olmamalıdır. Modüllerinizi / bileşenlerinizi kolayca keşfedilebilir ve depolarda kullanılabilir hale getirmek için Bit ( Github ) kullanın .
Bit; Node, TypeScript, React, Vue, Angular ve daha fazlasını destekler.
Bunu hem oluşturan kelime hem de anlamı için her zaman sevmişimdir: Keep It Simple Stupid (ya da aptal denilmekten hoşlanmıyorsanız, Keep It Stupid Simple olarak düşünebilirsiniz, bence işe yarıyor kısaltmanın gerçek anlamı için daha da iyi).
Bazen, bir problemi çözerken, aşırı mühendislik olarak bilinen bir şeye ya da benim ona nasıl hitap ettiğime, bir sivrisineği öldürmek için bazuka kullanmakla karşılaşabilirsiniz. İşi halledecek, ama kesinlikle aynı şeyi çok daha basit bir şekilde yapabilirsiniz.
Karmaşıklığın gerekli olduğu anlar vardır, beni yanlış anlamayın. Basit kod veya basit bir mimari kesinlikle kullanışlı olmadığında, mantığınıza karmaşıklık eklemek gerekir. Bununla birlikte, çoğu zaman, kendinize öpüp atmadığınızı sormalısınız.
Daha doğrusu, mantık yollarınız yeterince basit mi? Bunları anlamak için gereken bilişsel yük nedir? Basit kod veya genel olarak basit tasarım, hatalara daha az yatkın olduğunuz ve bunu anlamaya çalışanların bunu yapmak için daha kolay zaman geçirmesi gerektiği anlamına gelir. Bu yüzden genel olarak, kodunuzu ÖPMEYİN.
Yine başka bir ortak programlama ilkesi. Ancak bu, şu anlama gelir:
Burada, işlevlerinizin yalnızca bir şeyi ve başka bir şeyi nasıl yapması gerektiğinden bahsediyoruz. Sen çok Linux dağıtımı, MacOS veya benzeri olarak * nix tabanlı sistemler, aşina, muhtemelen (Ben gibi şeylerden bahsediyorum onların terminali deneyimli ve bazı komutları kullandıysanız
ls,
cdve benzeri). Bu prensibi de izlerler, yalnızca bir tür görevi yerine getirirler, size dikkat ederler, bu görevle ilgili her şeyi yaparlar, ancak örneğin dizini değiştirmenize ve içeriğini listelemenize yardımcı olan bir komut satırı yardımcı programı bulamazsınız.
Buradaki nokta, işlevlerinizin yalnızca bir sorumluluğu olacak kadar basit olması gerektiğidir, daha karmaşık davranışlara ihtiyacınız varsa, bunları oluşturmak için girdi ve çıktılarını birleştirin.
Burada fonksiyonlardan bahsetmeme rağmen, bu ilke sektörümüzdeki her şey için geçerlidir. Bir platformun mimarisini düşünün, ihtiyacınız olan her şeyi yapmaktan sorumlu bir mega modül oluşturmak yerine, kendi küçük görevlerinden sorumlu birkaç mikro hizmet yaratırsanız, bu sistemin bakımı ve büyümesi çok daha kolay hale gelir. Aynı şey işlevler için de geçerlidir, daha basit işlevlerin bakımı, okunması ve anlaşılması ve hatta yazılması daha kolaydır.
Esasen, kendinizi
getUserAndRelatedBooksher iki görev için de tüm mantığa sahip olduğunuz bir işlev yazarken bulursanız , iki işlev oluşturmayı düşünün:
getUserve
getUsersBooksikincisi birincinin çıktısını alır, böylece
getUserAndRelatedBooksbasitçe söyleyerek
getUsersBooks(getUser)(yani, oluşturarak) uygulayabilirsiniz. onları).
Bu, modüllerinizin veya kitaplıklarınızın (kodunuzu nasıl dışa aktardığınıza bağlı olarak) uzantı için Açık (içinde olduğu gibi, davranışlarını genişleterek), ancak değişiklik için Kapalı (yani kimse gitmek istemediği) gerçeğine bir referanstır. diğer insanların modüllerini değiştirmek etrafında).
Başkalarının mevcut davranışı eklemek veya genişletmek için kodunuzu değiştirmesi gerektiğini gördüğünüz anda, dostum, Açık-Kapalı prensibini başarıyla başarısız oldunuz.
Örneğin aşağıdaki kod, ilkeyi geçersiz kılar, çünkü kullanım durumunuzda çalışmasını sağlamak için fazladan şehirler eklemeniz gerekirse, dosyayı açmanız ve
knownCitiesdiziyi değiştirmeniz gerekir .
Ancak, aşağıdaki kod bunu düzeltir ve Açık-Kapalı olarak kalır.
Artık
addValidCityyöntem, kodunu değiştirmenize gerek kalmadan davranışı sizin için çalışmasını sağlayacak şekilde genişletmenize olanak tanır.
Güzel isim ha? Bu bizi programlama teorisine olabildiğince yaklaştırıyor. Çok derinlere inmek istemiyorum, ancak önce LSP olarak da bilinen bu ilkenin ne söylediğine bir bakalım:
Temel sınıflara işaretçiler veya referanslar kullanan işlevler, bunları bilmeden türetilmiş sınıfların nesnelerini kullanabilmelidir.
Görebileceğiniz ilk şey, bir OOP prensibiyle uğraştığımızdır, bir tanesi kalıtımı doğru bir şekilde kullanmamıza ve diğer alternatifleri kullanabildiğimizde onu kullanmaktan kaçınmamıza yardımcı olmak içindir.
Şu örneği düşünün: Geometride bir kare, bir dikdörtgenin uzmanlığı olarak düşünülebilir, çünkü esasen genişliği ve yüksekliği eşleşen bir dikdörtgendir. Ancak, aşağıdaki kod gibi kodla bu ilişkiyi modellemeye çalışırsanız:
Soyutlamanın bir anlamı yoktur, çünkü ya
setWidthda
setHeightyöntemlerinden birini kullanmak diğerini değiştirmez, esasen kareyi bir dikdörtgene dönüştürür, ki bu istediğiniz şey değildir. Dolayısıyla, yukarıdaki kod Liskov İkame İlkesini ihlal ediyor.
Başka bir deyişle, bu ilke, kodunuzun kalıtımı doğru bir şekilde kullandığından emin olmanızı sağlar, bu nedenle kulağa korkunç bir isim gibi gelse bile, sınıflarınızı tasarlarken bunu aklınızda tutmalısınız.
Bu, kullanıcılarınızı (yani kodunuzu kullanan geliştiriciler) gereksiz yöntemlere maruz bırakmamanız gerektiği gerçeğine atıfta bulunur. Unutmayın, bir arayüz sadece sınıflarınız için bir sözleşmedir (uygulanması gereken yöntemleri listeleyen). Dolayısıyla, arayüzler oluşturuyorsanız (örneğin TypeScript'te), uygulanması gereken gerekli yöntemlerin kullanıcılarınızın ihtiyaç duyacağı yöntemler olduğundan emin olun, onları isteğe bağlı yöntemleri uygulamaya zorlamayın.
Yukarıdaki kodu düşünün, kullanıcıları ve yöntemlerini
MyModuleuygulamak isteyebilir , ancak IE8 ile uğraşmak zorunda değillerse, o zaman bu son yönteme kesinlikle gerek yoktur.
close
open
Bu nedenle bu ilke, arayüz tasarımına bakmaya özen gösterir. Lekeli arayüzlerden kaçınmaya çalışın ve yöntemleri farklı olanlara ayırarak, kullanıcıların ihtiyaçlarına bağlı olarak hangilerinin nasıl uygulanacağına karar vermelerine izin verin.
Son olarak, SOLID konseptini kapatarak, bağımlılık enjeksiyonu olarak da bilinen bağımlılık tersine çevirmemiz var.
Temelde, bu ilke, kodunuzda bağımlılıklar varsa, bunların mantığınıza enjekte edilmesine izin vermeniz gerektiğini belirtir. Nasıl sorarsın Basit! Parametre olarak geçmelerine izin vererek.
Bu, birçok senaryo için çok yararlı bir araçtır, bunlardan biri birim testidir, çünkü yazdığınız ve üçüncü taraf bir kitaplığa bağlı olan kodu test ediyorsanız, davranışını kontrol etmek için bu kitaplığın alay edilmiş bir sürümünü enjekte edebilirsiniz. Size bir örnek göstereyim:
Yukarıdaki kodu göz önünde bulundurun, veri tabanına bağlantı aynı modül içinde bildirilir ve gerçekleştirilir, ancak yalnızca
saveUserişlevi dışa aktarırsınız . Dolayısıyla, bir şekilde test ederseniz, otomatik olarak veritabanına bağlanmaya ve orijinal amacına ulaşmaya çalışır: kullanıcı verilerini veritabanına kaydetmek.
Bununla birlikte, bağımlılık enjeksiyonuna izin verirseniz ve veritabanı bağlantısını (bu harici bir bağımlılıktır) ikinci bir parametre olarak alırsanız, gelecekte alay edilmiş bir sürümü enjekte edebilirsiniz:
Artık, veritabanına bağlanmak için farklı bir modül kullanmak gibi başka amaçlar için bağımlılıkları bile değiştirebilirsiniz ve kodunuz etkilenmez.
Bağımlılık enjeksiyonu harika bir araçtır, çok genişletilebilir bir tasarım oluşturur ve genişletilebilirliğe önem verdiğinizi gösterir. Modüllerinizi tanımlarken bunu düşünün.
Aksi takdirde "İhtiyacınız olmayacak" olarak bilinen, eXtreme Programming'den alınan bir ilkedir ve işlevselliği önceden ya da gerçekten ihtiyacınız olana kadar geliştirmemeniz gerektiğini savunur.
Buradaki nokta, çevik bir geliştirme çerçevesinde , gelecek olanlara değil, yalnızca mevcut iş yinelemenize odaklanmanız gerektiğidir. Bunun nedeni, vaktinden önce çalışmak ve beklediğinizden daha fazla işlevsellik sunmak kulağa cazip gelse de, Agile iş akışının değişen doğası geleceği istikrarsız hale getirmesidir.
Kararsız derken neyi kastediyorum? Demek istediğim, bu metodolojiyi karakterize eden kısa yinelemeler göz önüne alındığında, erken geri bildirim alabilir, projenizin geleceğini potansiyel olarak tamamen değiştirebilir ve teslim ettiğiniz özelliği ihtiyaç duymadan, işe yaramaz hale getirebilirsiniz.
Elbette, aynı düşünce treni, önceden planladığınız ve aynı planı sapmadan takip etmeye çalıştığınız şelale ortamları için geçerli değildir. Bu tür ortamlarda YAGNI uygulanmaz.
Şelale hakkında konuşursak, bu, o ortam için mükemmel olan bir prensiptir. Anlamı " B ig D esign U p F ront", daha ilk kod satırını yazmadan önce uygulamayı tam olarak tasarlamak için daha fazla zaman harcamanız gerektiğini belirtir.
Açıkça, bu şelale, her şeyi tamamen tanımlamak için gereken miktarda zamanı harcayabileceğiniz, geliştirmeye başladığınızda tasarım kusurlarını bulmak ve düzeltmek için çok fazla zaman harcamayacağınız umuduyla her yerde şelale diyor.
Elbette, burada açıklanan diğer ilkelerin birçoğunda olduğu gibi, onun aleyhtarı da yok değildir. Özellikle çevik geliştiriciler, çevik yaşam döngülerinin sürekli değişen doğasının bu prensibi işe yaramaz hale getirdiğini düşünerek buna karşı çıkma eğilimindedir. Tabii ki, proje sonunda tamamen değişeceğini bildiğiniz bir şeyi tasarlamak için zaman harcamaktan hoşlanmıyorsanız .
Burada listelenen en sevdiğim ilkelerden biri ve kesinlikle bir platformun mimarisini ya da sadece projemin iç mimarisini tasarlarken her zaman mevcut olma eğilimindeyim: Separation Of Concerns
Daha önce ele alınan Tek Sorumluluk İlkesi ile karıştırılmaması gereken bu ilkenin amacı, işlevleri veya modülleri bir hizmette gruplandırmanıza yardımcı olmaktır. Buradaki nokta, birkaç kavramla (normalde çoğu sistemin yaptığı gibi) ilgilenen bir sistem tasarlıyorsanız, neyle uğraşmaları gerektiğine bağlı olarak işlevlerinizi modüller halinde gruplamak istersiniz.
Aşağıdaki örneği ele alalım: Kullanıcılarınızın blog gönderilerini yayınlayabilecekleri basit bir blog platformu düşünün. Her şeyle ilgilenen tek bir sisteminiz olabilir (kullanıcı yönetimi, blog gönderileri, analitik vb.). Ancak SOC ilkesini takip etmek istiyorsanız, şu satırlarda daha fazlasıyla karşılaşabilirsiniz:
Bu elbette mimarinin çok kaba bir temsilidir, ancak asıl nokta, farklı sorumlulukları farklı modüllere ayırabilmenizdir, bu da aşağıdaki gibi faydalara izin verir:
Programlama ilkelerini bir kenara bırakırsak, endüstrimizde kullanmaya eğilimli olduğumuz ve anlaşılması önemli olan başka kısaltmalar da var.
Bu durumda MVP, Minimum Uygulanabilir Ürün anlamına gelir ve gerçekte ne kadar uygulanabilir olduğunu anlamak için ürününüzün sahip olması gereken minimum işlevsellik miktarını temsil eder.
Bu, istediğiniz ürünü bitirip% 100'e ulaşmanın zaman kaybı olmayacağını anlamak için kullanılan harika bir tekniktir. MVP aşamanızın çıktısı, genellikle üretime hazır olmasa da, odaklanmış bir kitle tarafından kullanılabilen ve sonuçta uygulanabilirliğini anlamak için gerekli geri bildirimi sağlayabilen bir ürünü gerektirir.
Önemli miktarda planlama ve geliştirme çabası gerektiren MVP'nin aksine, Kavram Kanıtı genellikle daha küçük bir versiyonudur. Normalde MVP'den önce gelir ve yalnızca inşa etmeye çalıştığınız şeyin temel işlevselliğinin mümkün olduğunun pratik bir kanıtı olarak kastedilmektedir.
Şimdi, bu aynı zamanda PoC'lerin atılabilen kod parçaları olma eğiliminde olduğu anlamına gelir . Onları kalıcı olacak şekilde inşa etmiyorsunuz, bir noktaya değinmek için inşa ediyorsunuz. Unutmayın, başarılı bir POC geliştirmenin mümkün olduğu durumlar olabilir, ancak bir noktayı kanıtlamak için kendinizi birkaç POC oluştururken bulma olasılığınız da vardır, bu nedenle hepsini gerçek bir ürüne dönüşecek şekilde planlayın. en iyi fikir değil.
Şahsen, POC konseptini gerçekten seviyorum ama onları çöpe atma kodu olarak düşünmeyi seviyorum. Onları Iron Man'in Mark I zırhı olarak düşünün , ARK reaktörünü kullanabileceğini ve etrafına bir zırh inşa edebileceğini göstermenin harika bir yoluydu, ancak Mark II zaten birkaç kat daha iyiydi.
Tüm bu kısaltmalar önemlidir ve bunlardan bazıları, kendinizi derslerde tekrar tekrar okurken veya meslektaşlarınızın bunları söylediğini duyarken bulduğunuz kelimeler olabilir. Artık ne anlama geldiklerini ve bağlamımıza nasıl uygulanacaklarını biliyorsunuz.
Sevdiklerinden herhangi birini dışarıda bıraktım mı? Aşağıya bir yorum bırakın ve kısaltmayı paylaşın, böylece hepimiz öğrenebiliriz.
Teknoloji dünyasında, işletmeler sürekli olarak siber suçluların şeytani faaliyetlerinin tuzağına düşme riski altındadır. Endişe verici derecede sık hale gelen böyle bir taktik, kimlik bilgilerini doldurmaktır.
Gündem: Giriş: TL; Ama okuyabilirim: A / B testi, CloudFront ve Lamba @ edge hakkında zaten bilginiz varsa, AWS Lambda @ edge ile doğrudan A / B testine gidin. A / B testi nedir? A / B testi, kullanıcıların bir web sitesinin iki farklı versiyonunun katılımını karşılaştırmaya odaklanan bir UX araştırma metodolojisidir.
Bugün AppStore'daki birçok uygulama, tablo görünümünü kaydırırken içeriği tablo görünümü başlığındaki ölçekleme gibi davranışlara sahiptir. Bu tür davranışlara nasıl ulaşabileceğimizin en basit yaklaşımını size göstereceğim.
İlk blogumda söz verdiğim gibi 'DOM Nedir?' burada 'DOM işleme' üzerine bir blog var. Bu blogda DOM'a daha fazla dalacağız ve DOM işlemenin ne olduğunu ve nasıl yapıldığını öğreneceğiz.
Node.js'de akışların nasıl çalıştığını hiç merak ettiniz mi? Sahiptim.