Web uygulamasından korkma “geleceğe hazır” değildir

Küçük, yerel bir SaaS web uygulamasının web geliştiricisiyim. Şu anda yaklaşık yarım düzine müşteriye sahiptir.

Uygulamayı tasarlamaya devam ettikçe, kendimi başlangıç ​​aşamasında olan projeye herhangi bir zaman ayırmaya ikna etmek benim için giderek zorlaşıyor. Projeye ve daha önce yazdığım kodlara bağlı olarak büyüdüğümde, iş büyüdükçe uygulama ölçeklenemediğinde ortaya çıkacak olan tüm ek işlerin yakın gelecekte devrilmesinden korkuyorum.

Staj başvurusu yapan bir üniversite öğrencisi olarak, işverenlere görüşmeler sırasında herhangi bir web çerçevesini kullanmama yönündeki tercihimi sordum, bu sadece önceki çalışmalarımdan daha fazla şüpheye düşmeme neden oldu. Sadece herhangi bir web çerçevesini bilmiyorum ve hangisini kullanmaya başlayacağımı bilmiyorum.

Ocak'ta tam yığın geliştirici olarak stajyerlik yaptım, burada ön uç çerçeveler öğrenmeye başlayacağım, ancak uygulamanın tamamlanması için baskı artıyor ve uygulamayı tamamen hurdaya çıkarmayı ve baştan başlamayı düşünüyorum. bu daha önce yaptığım bir şey. Uygulamanın şu anda PHP ve jQuery (AJAX aramaları için) inşa edilmiştir ve veritabanı için MySQL kullanır. Bu zihinsel bloğun üstesinden nasıl gelebileceğim ve uygulamamın ölçeklenebilir olacağına dair düşünceleriniz var mı? Şimdiden teşekkürler.

Mükemmel, iyinin düşmanıdır.

Ya da başka bir deyişle, bugün endişelenmeyin. Uygulamanız ne yapması gerekiyorsa, o zaman sorun değil. O var değil satır aşağı yazılımın parçalarını yeniden yazmak için kötü bir şey; o noktaya kadar siz 1) ne yapmaya çalıştığınızı daha net olarak bilirsiniz ve 2) hangi bitlerin aslında tıkanıklık olduğunu bilirsiniz. Bir milyon kullanıcıya ölçeklenecek bir uygulama yazmak için çok fazla zaman harcayabilirsiniz, ancak mevcut altı müşteriniz için bugün sahip olduğunuzdan daha iyi olmaz .

Bu zihinsel bloğun üstesinden nasıl gelebileceğim ve uygulamamın ölçeklenebilir olacağına dair düşünceleriniz var mı?

Konunun noktası ölçeklenebilirlik değildir. Konunun temel noktası , ilk defa doğru yapacağınızı düşünüyor .

Temiz kod yazmaya odaklanmalısınız. Çünkü temiz kod, (kaçınılmaz olarak) gelecekte bir şeyleri değiştirmek zorunda kaldığınızda rahatlığı en üst düzeye çıkarır. Ve sahip olman gereken asıl amaç bu.

Şimdi yapmaya çalıştığın şey, yazmak için mükemmel kodu düşünmeye çalışmak. Ancak bunu yapmayı başarsanız bile, şartların değişmeyeceğini kim söylüyor, ya da kararlarınızı yanlış bilgilere veya yanlış iletişime dayanarak verdiniz?

Senin suçun olmasa bile, hata yapmaktan kaçınamazsın. İleride değiştirmek zorunda kalmayacağınız bir kod yazmak umuduyla, daha sonra işleri kolayca değiştirebileceğiniz kod yazmaya odaklanın.

Projeye ve daha önce yazdığım kodlara bağlı olarak büyümek,

Bu düşünceye kesinlikle sempati duyuyorum. Ancak yazdığınız koda bağlı kalmak bir problemdir.

Sürekli olması gereken tek şey, belirli bir sorunu çözme arzunuzdur . Bu sorunu çözme yolunda gitmeniz, yalnızca ikincil bir endişedir.

Yarın, kod tabanınızı% 80 azaltan yeni bir araç piyasaya sürülürse, kodunuzun artık kullanılmadığı için üzüleceksiniz; ya da kod tabanınızın daha küçük ve daha temiz / daha yönetilebilir hale gelmesinden memnun olacak mısınız?

Eski ise, bir sorununuz varsa: Kodun çözümünü görmüyorsunuz . Başka bir deyişle, koda odaklanıyorsunuz ve daha büyük resmi göremiyorsunuz (sağlamayı amaçladığı çözüm).

İş büyüdükçe uygulamanın iyi ölçeklenemediği ortaya çıktığında yakın gelecekte taahhüt ettiğim tüm ek işlerin devrilmesinden korkuyorum.

Bu farklı bir gün için farklı bir sorundur.

İlk önce, işe yarayan bir şey yap. İkincisi , hala gösterebileceği kusurları düzeltmek için kodu geliştirin. Şu anda yaptığınız şey, ikinci görevi yapmak zorunda kaldıktan sonra ilk görevin korkusundan uzak durmak.

Fakat başka hangi seçenek var? Geleceği söyleyemezsin . Vaktinizi gelecekteki olasılıkları düşünmek için harcarsanız, yine de tahmin etmeye başlayacaksınız . Bir tahmin her zaman yanlış ölü olmaya meyillidir.

Bunun yerine, uygulamayı oluşturun ve gerçekten bir sorun olduğunu kanıtlayın . Sorun çözüldükten sonra ele almaya başlarsınız.

Başka bir deyişle: Henry Ford hiçbir zaman 2018 standardına / beklentisine uygun bir araba üretmedi. Fakat Modern standartlara göre kusurlu bir otomobil olan Model T'yi yapmamış olsaydı, hiç kimse araba kullanmaya başlamazdı, otomobil endüstrisi olmazdı ve hiç kimsenin daha sonra geliştirmeye çalışabilecekleri bir arabası olmazdı.

İşverenlere, görüşmeler sırasında web çerçevelerini kullanmama konusundaki tercihimi sordum, bu da önceki çalışmalarımdan daha fazla şüpheye düşmeme neden oldu.

Buradaki önemli kısım, hangi çerçeveyi kullandığınız değil (sizi bu konuda yargılayan herhangi bir işveren işini düzgün yapmamaktır). Buradaki önemli kısım ne yaptığınızı ve neden yaptığınızı bilmek .

Örneğin, özel olarak mevcut çerçeveden kaçınıyor olabilirsiniz, çünkü öncelikle bir çerçevenin neden zor yoldan başladığını, neden yararlı olduğunu öğrenmek istiyorsunuz . Veya kendi çerçevenizi oluşturmaya çalışıyor olabilirsiniz.

Bilgilendirilmiş kararlar vermedeki yetersizliği gösterdiği için buradaki tek kötü cevap "bilmiyorum". Yani olan bir işveren için bir kırmızı bayrak.

Sadece herhangi bir web çerçevesini bilmiyorum ve hangisini kullanmaya başlayacağımı bilmiyorum.

Aynı sorun burada da ortaya çıkıyor. Çözüm, daha fazla düşünmek değil, harekete geçmek:

• Mükemmel cevabı düşünmeyi bırak .
• Bir çerçeve seç. Tercihiniz yoksa, rastgele birini seçin. Dart tahtası kullanın, bir kalıp açın, yazı tura atın, bir kart seçin.
• Kullanın.
• Kullanmayı beğendiniz mi? Sinir bozucu bulduğun bir şey var mıydı?
• Bu kötü unsurların nasıl önleneceğine bakın. Çerçeveyi kötüye mi kullandınız, yoksa çerçevenin nasıl çalışması gerekiyor?
• Çerçeveyi kavradığınızı hissettiğinizde (hoşunuza gidip gitmediğinize bakılmaksızın), yeni bir çerçeve seçin ve bu döngüyü tekrarlayın.

Bunun hakkında daha fazla okumak için, Düşünme zihniyetinde> düşünce zihniyetini okuyun . Yazar benden daha iyi açıklıyor.

Ancak uygulamayı sonlandırma baskısı artıyor ve uygulamayı tamamen hurdaya çıkarmayı ve baştan başlamayı düşünüyorum

Geçerli kod temeli kesinlikle elde edilemez bir karışıklık değilse; tam tersi bir karar veriyorsun.
Geliştiriciler genellikle bir şeyleri atmanın daha iyi bir seçim olacağını düşünüyor. Bu çok yaygın bir his. Ancak bu nadiren doğru seçimdir.

Kodları atmak ve sıfırdan başlamak, işe giderken trafikte sıkışıp kalmak, işe geç kalacağınızdan endişe duymak (son teslim tarihini kaçırmak) ve bunun yerine eve gitmek ve aynı yolda tekrar araba sürmeyi denemek gibidir. Mantıklı değil. Trafikte sıkışmış olabilirsiniz, ancak yine de çalışmaya evdeyken olduğundan daha yakınsınız.

Facebook ve Google, sizi ikna etmek için pazarlamaya harcadıkları muazzam para miktarına rağmen, iki temel nedenden ötürü ön uç çerçeveler var:

• Birincisi, istemciye durum ve mantık koyarak, istemci tarafı işlemlere donanım / ağ taleplerini boşaltmak
• İkincisi, ilk noktayı desteklemek için gerekli olan ek müşteri mantığıyla ilgili olarak, başkalarının kodunu hiçbir şeyi bozmadan bir sayfaya tıkayabilmeniz için yalıtılmış yürütme bağlamları sağlarlar.

Büyük olasılıkla, eğer uygulamanız doğal olarak durumdaysa, istemci tarafında tasarruf ettiğiniz uygulama durumu oldukça karmaşıksa, ağ gecikmesi olan çok sayıda müşteriyi bekliyorsanız (mobil, veya sunucudan uzak), veya özellikle gelişmiş CSS veya dinamik öğe oluşturmayı desteklemek için güçlü bir iş ihtiyacı varsa.

Çerçeve pazarlama, özel mimarlık yöntemlerinin geliştirme hızını arttırdığına ve bakımı kolaylaştırdığına inanmanızı istiyor. Bu basit projeler üzerinde çalışan küçük takımlar için kesinlikle doğru değildir. Kod ayırmak ve ithalat düzenlemek, büyük bir ekibin bir ürünü pazara daha hızlı bir şekilde getirmesine yardımcı olabilir. Zaten işlevsel bir proje üzerinde çalışan tek bir kişi geliştirme ekibine çok daha az sağlar.

Mevcut, işlevsel kodun çerçeveye gerçekten nasıl uygulanacağından daha uygun olduğunu öğrenmek için daha fazla zaman harcayacaksınız ve şanslar bir yerde birisinin bir şeyi güncelleyeceği ve bu çerçevede yazılan kodun 18 ay içinde işlemesi sona ereceği sürece oldukça iyi sürekli onu korumak için biri var.

Vanilla JS ve daha az fakat yine de önemli ölçüde bir JQuery bu sorunlardan muzdarip değil. Bazı dikkate değer istisnalar dışında, JQuery + AJAX uygulamaları tarayıcıya özgü davranışlara dayanmaz ve mantıklı olan dışsal bağımlılıklara dayanır, başlangıçta çok küçük değişikliklerle yazıldıktan 10-15 yıl sonra çalışmaya devam eder.

Altyapılar devam eden, karmaşık, halka açık web uygulamalarını destekleyen tipik girişimler için mükemmeldir. Büyük ekiplerin birlikte iyi bir şekilde koordine olmalarına, satıcıya çerçeveler eklemelerine güzel bir şekilde entegre olmalarına ve rekabetçi kalmanıza yardımcı olmak için gösterişli yeni widget'lar ve tasarım paradigmalarını desteklemelerine izin veriyorlar.

Bunların hiçbiri, terk etmek üzere olduğunuz sabit bir kitleye sahip küçük bir yazılım aracı için önemli değildir. Bir çerçeveye bürünmek, yeni bir paradigmaya adapte olurken gelişim hızınızı yavaşlatır ve gereksiz uyumluluk riskleri ortaya çıkarır. Müşteri tarafı kodunu basit tutmak (ve ideal olarak kendi kendine barındırılan), uyumluluk riskinin yüzey alanının önemli ölçüde azalması anlamına gelir. Tarayıcılar değişecek, CDN URL'leri çalışmayı durduracak, bağımlılıklar modası geçmeyecek - Ama kimse bu sunucuya dokunmayacak ve iyi çalışmaya devam edecek.

Bugün sahip olduğunuz belirli bir mimari sorunu çözmedikçe ya da yakında öngörebildiğiniz sürece bir çerçeve benimsemeyin ve bu endişeyi yerine getirilebiliyorsa bunun yerine başka bir yöntemle ele almayı şiddetle düşünün.

Uygulamanızı "gelecekte kanıtlamak" için yapabileceğiniz en iyi şey, gevşek eşleşmeyi ve endişelerin ayrılmasını en üst düzeye çıkarmak için sisteminizin tasarımındaki en iyi uygulamaları izlemektir. Uygulamanızın eski hale gelmekten güvenli olmadığı bir kısmı yoktur, ancak X nedeniyle etkilenmeyen kodu, X tarafından etkilenmesi gerekmeyen koddan yalıtmak için birçok şey yapabilirsiniz .

Ancak, endişenizin uygulamanızın büyümesi / ölçeklenebilirliği için kendi deneyiminizin ve yeteneklerinizin büyüme hızından daha az olması gerektiğini iddia ediyorum. Tanımladığınız zihinsel blok, öğrenme durgunluğu veya onlarla başa çıkma stratejisi veya araçları olmadan bilinen birçok bilinmeyenin farkındalığı gibi geliyor.

Altyapılar, “geleceğe yönelik” sorununu çözmek için özellikle uygun değildir, ancak deneyimsizlere, genellikle MVC gibi üst düzey tasarım desenleriyle ilgili başlangıç rehberliği sağlayabilirler . Daha ziyade, güçlü bir uyum sağlayarak ve genellikle daha sıkı birleşme pahasına sağlayarak gelişmeyi hızlandırmanın yolları olarak daha faydalı olma eğilimindedirler . Örneğin, veritabanınızla etkileşimde bulunmak için önbellekleme sistemi entegrasyonuyla tamamlanan, uygulama boyunca çerçeve tarafından sağlanan bazı nesne-ilişkisel haritalama sistemini kullandığınızı varsayalım. Belki daha sonra bir anda ilişkisel olmayan veri deposu ve geçmek gerekir her şeyi o etkilenir kullanır.

Şu anda sahip karışıklık gelmedi neyi kullanmış, ancak nereye sen (arka uçta muhtemelen hemen hemen her yerde) kullandı. Bir sayfayı oluşturan kod, oluşturduğu verileri hiçbir zaman almazsa ne kadar iyi olursunuz?

Düzgün çalışması için fazladan komut dosyaları ve kaynaklar gerektiren bir sayfaya küçük bir widget eklemek istediğinizi varsayalım. Bir çerçeve kullanıyorsanız, "Bu şey için bir sayfaya bağımlılıkları nasıl eklememi istiyor?" Diye sorabilirsiniz. Eğer değilseniz, o zaman soru daha açık uçludur: "Bir şekilde ayrılması gereken hangi teknik endişelere dokunuyorum?" Bu sorunun cevaplanması daha fazla tecrübe gerektirir, ancak işte bazı ipuçları:

• Yarın tüm statik kaynaklarınızı (komut dosyalarınızı, resimlerinizi vb.) Ayrı bir sunucuya, içerik yayınlama ağına vb. Taşıdıysanız veya performansınızı iyileştirmek için hepsini bir araya getirmeye çalışırsanız ne olur?
• Bu widget'ı farklı sayfalara veya aynı sayfaya birden çok örneğini yerleştirmeye başlarsanız ne olur?
• Widget'ın farklı sürümlerinde AB testi yapmaya nasıl başlayabilirsiniz?

Bunlardan herhangi biri ezici geliyorsa , uygulamanızın uğruna değil, kişisel gelişiminizin uğruna bir çerçeve kullanmanız gerektiğini öneririm . Yine de baştan başlamayın. Bunun yerine, uygulamanızın gelişimine rehberlik etmek için müfredat olarak çerçeveler kullanın.

Öğrenmenin sadece iki yolu var. Bunlardan biri deneme yanılma, diğeri ise başkalarının deneyimlerinden ders almaktır. Deneme ve hata ortadan kaldırılamaz. Yazılım geliştirme, doğası gereği sürekli bir öğrenme alanıdır ve yeni veya farklı bir şey yapmayan herhangi bir kod, tanım gereği gereksizdir. (Bunun yerine zaten yazılmış olan kodu kullanın.)

İşin püf noktası, geliştirme sürecinin her adımında önceden var olan bilgileri (stratejiler, en iyi uygulamalar ve kod / kütüphaneler / çerçeveler) arayarak en aza indirmektir, böylece kendinizi tekerleği sürekli olarak yeniden icat ederken bulmazsınız.

Şu anda yazmakta olduğunuz uygulama için gibi, ancak, ilk endişe sadece bunu minimum halletmek için olmalıdır sıradan çaba (tür kod kokusu gibidir, ancak gelişim süreci için). İnsan öğrenmesinin doğası göz önüne alındığında, yüksek kaliteye ulaşmanın en hızlı yolu bir şeyle başlamaktır . Zaten sahip olduğunuz bir şeyi eleştirerek, onu şekillendirebildiğiniz zaman hedefi anlamak çok daha kolaydır.

Yazdığınız kodun çoğunun tek kullanımlık bir öğrenme süreci olduğunu ve iyi tasarımlar bulmak için gerekli olduğunu kabul edebiliyorsanız , bu size yardımcı olmaya yardımcı olacaktır. Ne de olsa, yazılım geliştirmeyi ilgi çekici kılan bir problem çözme zorluğudur ve yaptığınız işe değecek bir şey varsa bu zorluk her zaman mevcuttur (yukarıdaki "sürekli öğrenme" ifadesine bakın).

Başka her şeyden "şey hurdaya ve baştan başlamak" olduğunu asla bir seçenek ... sonuçta, sahip olduğunu söylemedi "yarım düzine istemcileri?" Şu anda (muhtemelen) “işinizle tamamen mutlu olduklarını düşününce”, duyurularınız hakkında ne düşünebileceklerini düşünmeyi henüz aramadınız mı?

İşte kullanmaktan hoşlandığım bir benzetme:

• “Benim işim, insanların yaşayacağı, iş yapabileceği insanlar vb. İçin evler inşa etmektir.” Benim işim, yararlı işler yapmak için "bu inanılmaz derecede minik, aşırı yüceltilmiş kum parçalarını" yapmak. (Ev inşaatçılarının alçıpan, seramik, beton blok ve 2x4'lü evler yaptıkları gibi.)

• Ancak, ev inşaatçılar gerçekten iki yüz yılda çok şey değişti değil kullanmaları kesinlikle "çivi" oysa ( "yuvarlak" "kare" için gitmek dışında ve sonra pnömatik çivileme-makineleriyle kullanışlı yapılacak), teknoloji kullandığımız sürekli değişiyor ve bazen çok derin bir değişime uğruyor. ("O zaman o gider.")

• "Yine de, her ev, inşa kez sonsuza-sonra olacak şekilde yaşadığı yer." Onları tahliye edemezsin. Bir kere kurup anahtarları teslim ettikten sonra, "artık" senin evin değil. " Şu anki hali buydu ve çok uzun bir süre dayanacak.

Bu aralar iş büyük bir kısmı istemcilerin o günlerde var olan teknolojilerin "teknolojiyi" kullanılarak, otuz veya daha fazla yıl önce, yirmi, on inşa edilmiş yazılım ile başa çıkmak için yardımcı olmaktır - aaaa (ve, Hatırlıyorum) - ve bugün hala hizmette olan (!).

Bir şeyin geleceğin kanıtı olduğunu garanti etmek neredeyse imkansızdır. Bu uygulamanın ölçeklenebilir olup olmadığını kontrol etmek çok zor değil. Sadece uygulama için bazı performans testleri yazmanız ve kaç müşteriyle ilgilenebileceğini görmeniz yeterli. Testler yazmak kesinlikle uygulamanızı daha ileriye dönük kanıtlar haline getirecektir, çünkü uygulamada daha fazla değişiklik yaptıktan sonra uygulamanın nasıl davrandığını ölçebileceksiniz.

wrt çerçeve, performans / ölçeklenebilirlik akıllıca çok endişeli olmazdım. Bu kolayca kontrol edebileceğiniz ve düzeltebileceğiniz bir şey. En büyük sorun güvenlik. Web çerçeveleri genellikle doğru kimlik doğrulama kodu, çerezler, CSRF koruması vb. Yazmanıza yardımcı olur. Özellikle deneyim eksikliğiniz söz konusu olduğunda, bu alana daha iyi odaklanın.

Öğrenme çerçeveleri hakkında bir yorum yazmaya başladım, ama sonunda cevap gibi görünen bir şeye dönüştü, işte burada.

Hiçbir çerçeveyi bilmemek bir sorun gibi görünüyor. Temelde herhangi bir webdev işinde, bazı çerçevelerle çalışmanız gerekir . Sizden sonra başka bir çerçeveyi öğrenmek o kadar da önemli değil , ilkini öğrenmek biraz zaman alabilir - bu yüzden işverenler bu konuyla ilgilenebilir. Çerçevelerden kaçınmak , yaygın şekilde pratik olmayan bir yaklaşım olan burada sendromun bulunmadığını gösterebilir .

İlk çerçevelerinizi bilmenin asıl amacı ortak bir dil öğrenmek, belki de sadece akranlarınız arasında popüler olan bir şey öğrenmeyi deneyin. Bir çerçevede yazılmış basit bir projeyi değiştirmeyi deneyebilirsiniz. Projeye sıfırdan başlayarak bilmediğiniz bir çerçevede öğrenme, çok etkisiz bir öğrenme şeklidir.

Şimdi, asıl sorunuz belirli bir proje hakkında ve onu bir çerçeveye taşımaktı. Bunun için, cevap gibi görünüyor: bağlıdır ve size gerçekten söyleyemeyiz. Ancak, şeyleri bilmediğiniz bir çerçeveye taşımak, kesinlikle mantıklı olup olmadığını bile bilmediğiniz için kesinlikle kötü bir fikirdir . Bu nedenle, olduğu gibi bırakmanız ve bir çerçeveyi bildikten ve sevdikten sonra bu kararı bir noktada tekrar gözden geçirmeniz gerektiği görünüyor. Diğer cevaplar, böyle bir karar verirken nelere dikkat etmeniz gerektiği konusunda iyi noktalar içerir.

Bu makale, 2.5 yıl önce Hacker News'de çok dikkat çekti: Silmesi kolay, genişletilmesi kolay olmayan bir kod yazın. Bu perspektif mevcut kod tabanınızla başa çıkmanıza yardımcı olabilir veya olmayabilir, ancak gelecekte mükemmeliyetçilik / aşırı mühendislik kaynaklı hayal kırıklığının önlenmesine yardımcı olabilir.

'Kod satırlarını' 'harcanan satır' olarak görürsek, kod satırlarını sildiğimizde bakım maliyetini düşürüyoruz. Yeniden kullanılabilir bir yazılım oluşturmak yerine, tek kullanımlık bir yazılım oluşturmaya çalışmalıyız.

Size kod silmek, yazmaktan daha eğlenceli olduğunu söylememe gerek yok.

(vurgu madeni)

Hacker News makalenin iplik de salt değer olabilir.

Geleceği kanıtlamak ve ölçek ve çerçeve ilkelerini uygulamak kadarıyla, kendi başınıza üstlenmek için uzun bir görevdir, muhtemelen endişelenmek istemem, ama:

Kodunuzu temiz tutun, KATI, KURU ilkeleri> google.

En kısa sürede bir yük dengeleyici uygulayın.

En az iki web sunucusu kurun, koddaki yük dengeleme senaryolarını kullanın.

Ve son olarak, en az değil, bir milyon kullanıcıyı idare etmek için LAMP'tan daha iyi yığınlar var, ama kesinlikle yapılabileceğinden eminim.

Durum ve nokta, bakınız: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Bu nokta geçerlidir, ancak 10 gb önemsizdir bir test konusu olarak.