Geliştirme

Web uygulaması mı site mi: sınır nereden geçer

Site bilgi gösterir, uygulama kullanıcının işini yapar. Sınırın tam olarak nereden geçtiğini ve kullanıcı panelinin görevin sınıfını neden değiştirdiğini ele alıyoruz.

Resmi olarak hem site hem web uygulaması tarayıcıda bir adresle açılır ve müşteri tarafından fark çoğu zaman karmaşıklık farkı gibi görünür: "site daha basit, uygulama daha zor". Gerçekte bunlar farklı mimariye, farklı ekibe ve farklı sahip olma maliyetine sahip farklı görev sınıflarıdır. Sınırı, teknik şartnamede kullanıcı paneliyle ilgili bir satır belirmeden önce anlamak faydalıdır.

Fark fiildedir

Basit bir ayrım: site gösterir, uygulama yapar.

Site bilgiyi şirketten ziyaretçiye aktarır. İçerik önceden hazırlanmıştır, açan herkes için aynıdır ve editör değiştirdiğinde değişir. Ziyaretçi okur, karşılaştırır, sonunda talep bırakır. Talep sitenin sınırıdır: sonrası e-postada, CRM'de, telefonda devam eder.

Uygulama kullanıcının kendi işini yapar. Kişi oraya okumaya değil, bir şey yapmaya gelir: sipariş verip takip etmek, rapor oluşturmak, görev atamak, belge imzalamak, aylık rakamlarına bakmak. Eylemlerinin sonucu kaydedilir ve bir dahaki sefere göreceğini etkiler. Herkesin içeriği kendine aittir.

Pratik sonucu: sitede ziyaretçi anonim ve birbirinin aynısıdır, uygulamada ise geçmişi olan belirli bir kişidir. Sınır budur.

Uygulamayla birlikte gelen üç şey

Projede kullanıcı işi ortaya çıktığı anda sitede hiç olmayan üç varlık belirir.

Durum. Siparişin statüsü, belgenin sürümü, görevin sorumlusu ve son tarihi vardır. Durumlar değişir, kurallara göre birbirine geçer ve bu kuralların tarif edilmesi gerekir. "Yalnızca ödemeden önce iptal edilebilir", "onaydan sonra düzenlenemez" — tartışmada bu tür ifadeler bir uygulama tasarladığınız anlamına gelir.

Roller. Uygulamada nadiren tek bir kullanıcı türü olur. Müşteri ve yönetici, çalışan ve amir, yönetici hesabı vardır. Her biri kendisininkini görür ve her şeyi yapamaz. Erişim hakları ayarlardaki onay kutuları değil, tüm ürüne yayılan bir mantıktır: her ekran ve her veri isteği tam olarak kimin yaptığını sormalıdır.

Kaybedilemeyecek veriler. Sitedeki metin yedekten geri yüklenip yeniden yazılabilir. Kullanıcıların siparişleri, işlem geçmişi ve yüklenen belgeler yeniden oluşturulamaz. Bu, yedeklere, veritabanı göçlerine ve güncellemelerin nasıl yayına alındığına ilişkin gereksinimleri değiştirir.

Bu üçüne neredeyse her zaman dördüncüsü eklenir: hatalar pahalı hâle gelir. Hizmet sayfasındaki yazım hatası bir tatsızlıktır. Depodaki stok hesabındaki hata ise para ve soruşturma demektir. Buradan, sıradan bir sitede kısılabilen ama burada kısılamayan test ihtiyacı doğar.

"Siteye bir panel ekleyelim"

Bu ifade küçük bir genişletme gibi duyulur ama görev sınıfının değişmesi anlamına gelir. Arkasında neyin durduğuna bakalım.

Kayıt ve giriş belirir — dolayısıyla şifreler, şifre kurtarma, e-posta doğrulama, kaba kuvvete karşı koruma, oturumlar ve sona ermeleri gerekir. Kullanıcı verileri belirir — dolayısıyla nerede saklandıklarına, kimin gördüğüne, talep üzerine nasıl silindiklerine karar vermek gerekir. Kullanıcıya bağlı içerik belirir — dolayısıyla alışılmış tam sayfa önbellekleme artık çalışmaz ve performans farklı hesaplanır.

Sonra her şeyi belirleyen soru gelir: panel verileri nereden alıyor. Kullanıcı siparişlerini görmeliyse, bunlar zaten bir yerde vardır — muhasebe sisteminde, CRM'de, depo yazılımında. Panel başkasının veritabanının vitrinine dönüşür ve projenin yarısı entegrasyona döner: nasıl çekilecek, ne sıklıkla güncellenecek, kaynak erişilemediğinde ne gösterilecek.

Kullanıcı paneli sitenin bir bölümü değil, onun yanında yaşayan ve çoğu zaman ondan daha uzun yaşayan ayrı bir üründür.

Bu yüzden "hazır siteye panel eklemek" kararı her zaman kötü değildir ama kendi bütçesi ve kendi desteği olan ikinci bir projeyi başlatma kararı olarak alınmalıdır. Bu görev sınıfı hakkında daha fazlası web uygulamaları bölümünde.

Ara durumlar

Sınır her zaman belirgin değildir. Birkaç tipik durum ve gerçekte nereye düştükleri.

  • Online mağaza. Resmi olarak bir uygulamadır: sepet, siparişler, durumlar, ödeme. Ama herkesin gördüğü ve arama motorlarınca dizinlenmesi gereken büyük bir vitrin kısmı vardır. Bu yüzden mağaza neredeyse her zaman karmadır: herkese açık sayfalar site kurallarıyla, sepetten sonraki her şey uygulama kurallarıyla çalışır.
  • Sitede hesaplayıcı. Tarayıcıda hesaplar, hiçbir şey kaydetmez, sonuç hiçbir şeyi etkilemez — hâlâ sitedir. Hesaplama kullanıcının kişisel geçmişine kaydedildiği anda artık uygulamadır.
  • Yorumlu blog. Kullanıcılar bir şey oluşturur ama ürünün çekirdeği içerik yayımlamaktır. Uygulama değil, sınırlı etkileşimli bir sitedir.
  • Çalışanlar için yönetim paneli. Dizinleme gerekmez, herkese açık trafik yoktur, ama roller, durumlar ve çok sayıda tablo vardır. Ekran sayısı az olsa bile saf bir uygulamadır.

Düğme sayısına değil, kullanıcı eyleminin sonucunun kaydedilip kaydedilmediğine ve sonraki işi etkileyip etkilemediğine bakmak gerekir.

Geliştirme sürecinde neler değişir

Görev sınıfındaki fark projenin nasıl yürütüldüğünü de değiştirir.

  1. Görsel tasarım yerine mantık tasarımı. Sitede iş sayfa yapısı ve prototiplerle başlar. Uygulamada — senaryolar, roller ve veri modeliyle. Durumlar tarif edilmeden çizilen güzel tasarımlar yeniden yapılmak zorunda kalır.
  2. Farklı iş kapsamı. Uygulamada emeğin önemli bir kısmı ekranda görünmez: arka uç, veritabanı, erişim hakları, entegrasyonlar, hata işleme.
  3. Lansman bitiş çizgisi değildir. Site tesliminden sonra aylarca değişmeden kalabilir. Uygulama lansmandan sonra yaşamaya başlar: kullanıcılar zorluklar bulur, yeni senaryolar belirir, bir geri bildirim kanalı ve düzenli güncellemeler gerekir.
  4. Destek zorunludur. Uygulamanın nöbeti vardır: çökerse insanlar çalışamaz. Bu bir iyi niyet jesti değil, ayrı bir anlaşmadır.
  5. Sahip olma maliyeti daha yüksektir. Sunucu, yedekler, izleme, bağımlılık güncellemeleri, olay analizi. Bu düzenli bir gider kalemidir ve baştan bütçelenmelidir.

Uygulamaya ihtiyacınız olduğunu nasıl anlarsınız

Kendinizi bu sorularla kontrol edin. Görevi site olarak adlandırmayı bırakmak için iki üç "evet" yeterlidir.

  1. Kullanıcı kendi bilgilerini görmek için kendi hesabıyla giriş yapmalı mı?
  2. Eylemlerinin sonucu kaydediliyor ve yarın göreceğini etkiliyor mu?
  3. Farklı haklara sahip birkaç kullanıcı türü var mı?
  4. Nesnelerin kurallara göre değişen durumları var mı?
  5. Başka bir sistemle — muhasebe, ödeme, depo — veri alışverişi gerekiyor mu?
  6. Yanlış bir hesaplama veya kayıp bir kayıt paraya mal olur mu?

Tüm yanıtlar "hayır"sa size bir site gerekir ve onu uygulamaya dönüştürmek kimsenin kullanmayacağı karmaşıklığa ödeme yapmak demektir. Ters hata daha yaygındır ve daha pahalıya patlar: proje site olarak başlar, altı ay sonra panel, sonra roller, sonra entegrasyon eklenir — ve sonunda buna göre tasarlanmamış bir temelin üzerine kurulmuş bir uygulama elde edilir.

Yanıtlarınız karışık bir tablo çiziyorsa, genellikle eksik olan senaryoların tarifidir: sistemde her gün tam olarak kim ne yapıyor. Bunu tarif edin — ve sizin durumunuzda sınırın nereden geçtiğini konuşalım.