Bildiklerimin yolunu takip edin, sonra doğru kodlama uygulamalarını uygulamaya çalışın veya iyi kodlama uygulamalarıyla başlayın ve yoluma devam etmeye çalışın.

Öncelikle, Prosedür Programlamayı hobim olarak yapmaya alışkın olduğumu söylemek istiyorum - OOP'u birkaç dilde öğrenmeye ve teoriyi anlamaya çalışıyorum , sadece uygulamayı değil.

Ben, özellikle PHP bir veritabanı arka uç (ne bir umurumda değildi) ile inşa etmek istedim bir evcil hayvan projesi var. Temel nedenim uygulamanın herhangi bir cihazda kullanılmasıydı, bu yüzden bir WebApp mantıklı bir seçim gibi görünüyordu.

Sürdürülebilir PHP WebApps oluşturmak için, OOP, Sınıflar, Çerçeveler, Kütüphaneler, vb kullanmak gerektiğini anlıyorum. Bu mantıklı geliyor, bu yüzden popüler olanlardan bazılarını denemeye karar verdim. Ancak, sadece onları denemek ve öğreticiler geçmeye çalışırken bütün bir hafta sonu sonra, öğreticiler küçük projeme adapte çalışırken hem karışık hem de sinirli kaldı.

Temelde bir kavram kanıtı için uygulamayı başka bir programda (Microsoft Access) oluşturmaya karar verdim ve ana hedeflerimi Web bölümü dışında yalnızca birkaç saat içinde gerçekleştirdim.

Sorum şu: Bildiklerimin yolunu izlemeli miyim, sonra doğru kodlama uygulamalarını mı denemeliyim yoksa iyi kodlama uygulamalarıyla mı başlamalı ve yolumu geçmeye çalışmalı mıyım? Bu proje için GitHub'da Açık Kaynaklı olmasını istiyorum, bu yüzden kodumu kullanan ve değiştiren diğer insanlara açık olacağım, ancak kod kötü yazılırsa yardımcı olmak için kodlayıcıları toplamak zor olacağını da biliyorum.

En iyi uygulamalar çoğunlukla projelerin daha kolay * oluşturulmasına yardımcı olmak için deneyimden toplanan öneriler ve önerilerdir.

Bu IMHO'nun temel yönleri deneyim bölümüdür. Her ne kadar bu en iyi uygulamalar yeni başlayanlarla paylaşmak için daha fazla deneyime sahip insanlar için iyi bir yol olsa da, bunun en iyi uygulama olduğunu gerçekten anlamak için kişinin minimum düzeyde bir deneyime ihtiyacı olduğunu düşünüyorum. Aksi takdirde, onları körü körüne takip etmek, sonunda başkalarının sizin için düşünmesine yavaşça izin verirken öğrenmenizi yavaşlatacağını düşünüyorum.

Her halükarda, bir yazılım projesinde benim için yaptığım en önemli şey, ... iyi ... bitir, gönder ... kısaca çalışmasını sağla!

Bu noktadan önceki her şey hayal gücünüzün bir ürünü olan buharlı yazılımdır. Sadece bir kez işe yarayan bir şey olduğunda, yavaş, bakımı zor, test edilmesi zor vb.Gibi gerçekten değerlendirebilirsiniz. bu hedefe ulaşmayı kolaylaştıracak şekilde.

Yani evet, önce bildiklerinizle başlayın, zor olan şeyleri not edin. Bir duvara çarptığınızda geri adım atın ve o duvara bakın, ne yapıldığını öğrenin. Birçok durumda SİZİN sorunun kökü olduğunu anlayacaksınız. Çözmeye çalıştığınız sorunun bir kısmını anlamamanız, sahip olduğunuz araçları nasıl daha iyi kullanabileceğinize dair bilgi eksikliğiniz veya her zaman burnunuzun hemen altında olan ancak hazır olmayan diğer araçları bilmemeniz ustalıklarına başlayın.

Aynı zamanda, bir şeyler yapmanın yeni yollarını okumaya devam edin. Bu en iyi uygulamaları okuyun ve projenizde zorlandığınız herhangi bir şey için geçerli olup olmadıklarını görmeye çalışın. Değilse, varlıklarını hatırlayın ve zaman zaman tekrar ziyaret edin. Meraklı kal. Zamanla, yukarıda yapılan gözlemlerin burada edindiğiniz bilgilerle doğal olarak tıklandığını göreceksiniz.

Son olarak öğrendiklerinizi deneyin ve işlerin daha basit olup olmadığını görün. buna devam edin ve sonunda onlar için en iyi uygulamayı okuyacaksınız. Acı çeken ve daha kolay hale getirmenin bir yolunu öğrenen insanlardan basit bir tavsiye. Hatta bazılarına katılmıyorsunuz ve yolunuzun sizin için daha iyi çalıştığını görebilirsiniz. Ama bilgi olmadan sadece kör yürürsün.

iyi şanslar

TL; DR

Hepsini asla bilemezsiniz. Bildiğiniz her bir "şey" etrafında neredeyse her zaman daha fazla derinlik ve genişlik vardır. Kullandıkça öğrenin. Şimdi alakalı olduğunu düşündüğünüz "en iyi uygulamaları" uygulayın . Hata yapmak. Sadece çok maliyetli hatalar yapmaktan kaçının . Projeniz maliyetli hatalara yol açabiliyorsa danışmanları bulun.

Ve şimdi uzun cevap ...

1. "Çalışan yazılım ilerlemenin birincil ölçüsüdür." ( Çevik Manifesto )

Bilginizin kenarlarını görebiliyorsanız, bu harika! Kenarları takip edin! Öğrenmeye devam et! Ama unutmayın, sonsuza dek öğrenebilir ve analiz edebilirsiniz .

Bir şey inşa et.

2. Öğrenme ve hata yapma; ama "kötü" olanları yapma. *

Bilgi / becerinizin sınırlarını zorlamaya devam edin. Sen edecek hata yaparlar. Onlardan öğrenebilirsiniz. Ama pervasız olmanıza gerek yok .

Daha deneyimli geliştiriciler ve danışmanlar bulmak ve onlarla çalışmak için harcadığınız zaman , projenin iş değeri ve risk profiliyle orantılı olarak artmalıdır .

Kendiniz için küçük bir CLI yapıyorsanız : İstediğiniz gibi çalışmasını sağlayın.

Bir bankanın web portalını yazıyorsanız: Kendinizi çok deneyimli geliştiricilerle çevreleyin .

3. "En iyi uygulamalar" tırnak içinde yazılmalı ve göz kırpma ile konuşulmalıdır.

"Uygulamalar", en azından bazı durumlarda X'e ulaşmada başarılı oldukları gözlemlendiğinde "en iyi uygulamalar" a yükseltilir . Birisi, Fayda X'a ulaşmak için A Uygulamasının yararını tanır ve bunu internette "en iyi uygulama" olarak ilan eder. Diğerleri aynı fikirde - çoğu zaman iyi bir sebepten dolayı. Ancak, bu noktadan itibaren, genellikle bazı uygulamaların neden "en iyi uygulama" ve diğerlerinin "anti-desen" veya "kokmuş " olduğu görüşünü kaybediyoruz .

Sorun şu ki, "en iyi uygulama" asla kendi kendine hizmet etmez. "Antipatterns" aslında kendi başlarına şeytani değildir. Ve bir "kokusu" bile bazen bazen çürümeden gelir. Bazen, bu pislik sadece süslü, lezzetli bir peynirdir ...

"Bağımlılık enjeksiyonu" (DI) gibi şeyler uygulamıyorsunuz çünkü "bağımlılık enjeksiyonu" doğal olarak işletme için değerlidir. Çalışan bir ürün oluşturmak için uzaktan bile gerekli değildir. Bu başarır şey bu belki istediğiniz son üründe. Ama, belki de sadece işinizi hiçbir yararı için daha uzun süre geçmesine ...

Hmm ...

Peki, "en iyi uygulamaları" takip etmeli misiniz? Onları anlamasan bile? ... Hata ... evet. Olmaz diyorum. Ama evet. Ancak, sadece sizin ve yazılımınız ve amacı için gerçekten geçerli olanlar.

Çağır POAP ! ^{(Evet, blogum.)}

İlkeler, kalıplar ve uygulamalar nihai amaç değildir.

Bu nedenle, her birinin iyi ve uygun bir şekilde uygulanması, üstün ve daha nihai bir amaçtan esinlenir ve kısıtlanır. Yaptığın şeyi neden yaptığını anlamalısın!

(POAP, POAP'tan muaf değildir.)

Yani, örneğin DI'nin her nüansını tam olarak anlamayabilirsiniz. Ancak, amacı anlarsanız, DI'yi "kullanmanız" gerekip gerekmediğini bileceksiniz ve DI'yı bir tür dolaylı olarak daha iyi anlayacaksınız.

Ve ürünü serbest bıraktıktan sonra, DI'nin (veya herhangi bir şeyin) gerçekten faydalı olup olmadığını düşünebilirsiniz. Eğer öyleyse, neden yazılı olduğunu belirtin. Değilse, neden yazılı olarak belirtin ...

Bonus okuma / Biraz alakalı:

Analiz felci bir şeydir. Analiz etmeniz ve öğrenmeniz gerekiyor; ama aynı zamanda işleri halletmeniz de gerekiyor. Denge.

Her zaman bir kovboy kodlayıcı gibi hissedebilirsiniz .

^{* Aslında edecek sen şey kayda değer yaparsanız kötü hata yaparlar. Ama sen insansın sanırım. Yani, sizi vaktinden önce affediyoruz ... Ya da en azından ben. Olabilir. ... Şey ... Göreceğiz.}

Sorum şu: Bildiklerimin yolunu izlemeli miyim, sonra doğru kodlama uygulamalarını mı denemeliyim yoksa iyi kodlama uygulamalarıyla mı başlamalı ve yoluma devam etmeye çalışmalı mıyım?

Belki elinden gelenin en iyisini yap ama yine de bir şeyler gönder? Kullanıcıların bir ürünün kalitesini ve cazibesini nasıl değerlendirdiği ile arkasındaki geliştiricilerin kod kalitesini nasıl değerlendirdiği arasında iki farklı güç vardır. Bu iki gücü mümkün olduğunca uyumlu hale getirmeye çalışın. Birine diğerinin pahasına çok fazla odaklanmak, genellikle en fazla üretken rotalarla nasıl sonuçlandığınızdır.

Her şeyden önce, iyi kodlama uygulamalarını benimsemenin fuding olmadığını söyleyebilirim ... Hile her uygulamanın amacını ve nasıl düzgün bir şekilde uygulanacağını anlamaktır.

Hızlı uygulama geliştirme ortamları baştan çıkarıcıdır, çünkü çok kısa sürede çok şey yapabilirsiniz. Access'te tüm muhasebe sistemini bir kez oluşturdum. Ama kendiniz söylediniz: böyle bir uygulamayı yeniden yazma olmadan web'e alamazsınız ve ihtiyacınız olan araçlar gerçekten farklıdır.

Artık kimsenin Access veya Visual Basic gibi görsel tasarım araçlarını kullanmamasının nedenleri var. Sizi gerçekten bir şeyi başaran koddan izole etme eğilimindedirler. Erişim iyi bir araçtır, ancak web uygulamalarının özellikle kaçınmak için tasarlandığı şeyi gerektirir: kurulum. Görünüşünün özelleştirilmesi zor olabilir; Web'de ihtiyacınız olmasa bile, bir Access uygulaması her zaman diğer Access uygulamalarına çok benzeyecektir. İlk Access uygulamalarını yazan birçok kişi iyi bir uygulama yazmak için yeterli bilgiye sahip değildir ve Access kötü bir uygulama yazmayı kolaylaştırır.

Şimdi uygulamanızı web'e taşımak için yeni bir teknoloji öğrenmeye istifa ediyorsunuz. En başından itibaren doğru şekilde inşa etmeli misiniz? Elbette. Fakat yeni bir kalkınma ortamı ve felsefesi öğrenmek başka bir şeyi öğrenmek gibidir; bir şeyleri doğru yapmak için bir süre eğimli olmalısın.

Bu yüzden yanlış bir ikilik oluşturduğunuzu düşünüyorum. Önce kimse "en iyi uygulamaları" öğrenemez. Onları giderken öğreniyorlar. Ancak herhangi bir OOP dilinde üretken olabilmek için, biraz OOP'yi veya en azından sınıfların nasıl çalıştığını bilmeniz gerektiğini düşünüyorum.

Değer için PHP'nin en iyi seçim olduğunu düşünmüyorum. PHP "sığ" olduğu için caziptir, yani çalışan bir program yazmak için fazla bir şey bilmenize gerek yoktur. En iyi uygulamalar büyük ölçüde geliştiriciye bırakılmıştır, bu da PHP'nin "iyi" programlar yazmanıza yardımcı olmayacağı anlamına gelir. Bu kötü bir şey gerekli değildir, ancak Access gibi, daha sağlam bir platform için sonunda PHP'yi de atıyor olabileceğiniz anlamına gelir.

OOP'yi doğru zamanda uygulayabileceğiniz başka bir model olarak düşünün. OOP, her görevi metodik olarak çözebilecek bir çerçeve değil. Yazılım mühendisliğinde böyle bir şey yoktur.

Ayrıca, insanların iyi uygulamalar olduğunu iddia ettiklerinin bazen sorgulanabilir olduğunu unutmayın. Deneyimsiz geliştiricilerin genellikle verilen sorun için gereksiz olan çok karmaşık programlama modellerini benimsediğini gördüm. Kodun karmaşıklığı sorunun karmaşıklığı için uygun olmalıdır. Sadelik önemli bir değerdir.

Web'deki makaleler, endüstri uzmanlarının ifadeleri ve kıdemli meslektaşların tavsiyeleri yanlış olabilir. Bunu çok gördüm.

Bu nedenle, sorununuzu çözen en basit çözümü uygulamanızı öneririm. Muhtemelen, bu alanınızdaki popüler çerçevelerden birinin kullanımını kapsayacaktır. Bu kısıtlama dahilinde, istediğiniz kod türünü istediğiniz gibi seçebilirsiniz. Basitçe düşünmeyin onların bunu yapmanın yolu için uygun olan senin durumda.

Ayrıca, belirli tekniklerin neden önerildiğini anlayın . Örneğin, OOP kapsülleme ile ilgilidir. Başka şekillerde de kapsülleme yapabilirsiniz (prosedürler de kapsülleme ile ilgilidir).

Olumsuz bir örnek: Bazen insanlar veritabanını soyutlamak için bir veri erişim katmanı yazarlar. Burada, bu modelin özü, somut veri deposundan bağımsız hale gelmek ve daha yüksek bir kod katmanına daha basit bir arayüz ortaya koymaktır. Ancak bu avantajlara ihtiyacınız yoksa bir veri erişim katmanına ihtiyacınız yoktur ve işi kaydedebilirsiniz. Yine de, birçok uzman her zaman yanlış bir öneri olan bir DAL yapılmasını önermektedir.

İyi kodların genellikle çalışmak eğlenceli olduğunu görüyorum. Bu eğlencelidir çünkü altyapı sorunlarıyla ilgilenmek yerine gerçek gereksinimler üzerinde çalışabilirsiniz. Yaptığınız şeyin çok fazla homurdanma işi olduğunu fark ederseniz, muhtemelen yanlış desen setini seçtiniz.