“X ile y arasında” değişmeli olmalı mı?

Uygulamamda, verileri filtrelemek için kullanılabilecek önceden tanımlanmış bazı ifade şablonları var. Bunlardan biri " between x and y". Bir QA mühendisi, tanımında bir kusur olduğunu iddia ediyor çünkü " between 100 and 200", " between 200 and 100" den farklı sonuçlar veriyor . İfade dahili olarak " value >= x and value <= y" e çevrilir , bu nedenle, ikinci sınır birinciden daha düşük olduğunda netice yoktur. Aynı davranışın SQL'de olduğunu kontrol ettim - " between x and y", y> = x olduğunu ya da sonuç olmadığını varsayar. Bu, operatörün değişmez olmadığı, en azından SQL'de olduğu anlamına gelir.

Öyleyse, KG, " between x and y" değişmeli olmalı mı?

Mevcut spesifikasyonunuz bunu tanımsız bırakırsa, davranış tamamen keyfidir, "doğru" veya "yanlış" bir tanım yoktur. Eğer QA mühendisiniz sizi bu davranışın tanımlandığı şartnamede tam paragrafa işaret edemezse, muhtemelen talebini reddedebilirsiniz (bunun için onu uygulamak için çok çaba gerektiren bir şart gibi görünmese de). İkiniz de fikir birliği bulamazsanız, ekibinizdeki bir kişi başvuru bağlamında neyin daha önemli olduğuna karar vermelidir:

• SQL standardını mümkün olduğunca yakından takip etmek
• ergonomi, özel kullanım durumları veya diğer gereklilikler nedeniyle takip etmemek

Ekibiniz ne karar verirse verilsin, davranışı ve kararın neden alındığını belgelemek iyi bir fikir olabilir.

Bu bir kullanılabilirlik veya kullanıcı deneyimi sorusudur. SQL veya başka herhangi bir sistemin nasıl davrandığı önemli değil, soru kullanıcıların bakış açısından en mantıklı olan soru.

Mevcut davranış, kullanıcı açısından bir anlam ifade etmiyor. Ya x ve y birbiriyle değiştirilebilir olmalı ya da y'den büyük bir x seçmesine izin verilmemelidir. X'in y'den büyük olmasına izin vermek, ancak boş bir küme döndürmek, herhangi bir fayda sağlamadan gereksiz bir hata olasılığına neden olur.

Bu nedenle, QA mühendisi doğru bir hata var, ancak önerilen çözüm mutlaka en iyisi değil. Kullanılabilirlik testlerini yapmanız gerekir, ya da en azından bazı temsilci kullanıcılara kendileri için en doğal görünen şeyi sorun.

Alternatif olarak, soruyu https://ux.stackexchange.com/ adresinde sorabilirsiniz . Oradaki insanlar aslında kullanıcı deneyimi hakkında bir iki şey biliyor.

Birkaç mantıklı seçenek var ve hangisinin seçileceği sistemin geri kalanına ve kullanıcılarınızın beklentilerine bağlı.

QA mühendisinin işaret ettiği gibi, ifadeyi değişmeli hale getirebilirsiniz, sonra çeviri olacaktır.

between x and y => value >= min(x, y) and value <= max(x, y)

Geçerli kullanımı x <= y, kullanıcı arayüzünüzün "geçerli bir ifade değil" ifadesini olabildiğince erken görüntülemesini gerektiren şekilde sınırlayabilirsiniz .

Yukarıdakilerin bir varyasyonu olarak, x < ybir ifadeniz varsa kısıtlama equals xve değerlendirmeyi tercih ediyorsanızvalue >= x and value <= x

Sınırlarınızın bir komut dosyası tarafından oluşturulduğu etkileşimli olmayan bir ortamda, genellikle sıralı olmalarını isteme mantıklı olur. Bu, yapmak için daha az bir doğrulama kontrolü oluşturur, anlamsal olarak daha mantıklı ve yönetmesi çok önemlidir.

Etkileşimli bir ortamda, kullanıcıya yardımcı olmak istersiniz. Mümkünse, değiştirilmiş aralıkların girilmesine izin vermeyen bir GUI yapın veya en azından sırayla aralıkların girilmesini mümkün olduğunca kolaylaştırın. Aralıkları metne göre giriyorsanız, vim'den, bu kullanılabilirlik paragrafından bir sayfa alın ve kullanıcıdan otomatik olarak ters çevrilmiş aralıkları değiştirmesini isteyin:

Backwards range given, OK to swap (y/n)?

QA mühendisinizin UX yolunda ters çevrilmiş bir menzili bulunmadığını göstermek için hiçbir şeye sahip olmaması halinde makul bir varsayım yaptı.

Açıkçası? "Arasında" kullanmayın. Hiç.

İlk olarak, terim özellikle İngilizce'de inanılmaz derecede belirsizdir. Değişmeli mi? Terimler münhasır mı? Dahil?

İkincisi, arka uçtan boşanmış bir arayüz yapıyorsanız, arka uç davranışı hakkında endişelenmeyin; ve kullanıcılarınızın da miras kalmış davranışlar üstlenmelerine izin vermeyin. Elbette, SQL bunun BETWEENkapsayıcı olduğunu tanımlar , ancak bu neredeyse hiçbir zaman istenen davranış değildir (örneğin - bir şey rows BETWEEN :start and :start + :strideyaparsanız stride + 1satır alacaksınız ).

Bunun yerine, bitiş noktaları için yapılan karşılaştırmaları açıkça listelemeniz gerekir. "X'ten büyük veya ona eşit". "Dün". Bu belirsizliği ortadan kaldırır. Ayrıca daha temiz kod yazmanıza ve sinsi hatalardan kaçınmanıza yardımcı olur. Daha önceki satırlardan örnek olarak, esasen Djikstra'nın indeksleme konusundaki yayını yer almaktadır . SQL'in bazı türlerde kapsayıcı bir üst sınır kullanmasına izin verilmesi , yanlış verilerin seçilmesine neden olabilir .

KG'nizde kimin "doğru" ve kimin "yanlış" olduğu konusunda tartışmak verimli değildir. Özellikleri onlardan daha farklı yorumladın. Bu, spesifikasyonun netleştirilmesi gerektiğini yeterince belirsiz olduğu anlamına gelir.

Kullanıcı arayüzü teknik özellikteyse ve KG'nın beklediği davranış değilse, en azından bazı kullanıcıların beklediği davranış olmayacaktır. Bu bir kullanılabilirlik problemini gösterir (PEBKAC'ı tartışmak isteseniz bile). Bunun için tatmin edici bir çözüm bulmak için KG ile çalışın.

Genel bir nokta olarak, "anlaşılır" gibi görünen ve açık olmayan kelimelere dikkat edin. İşe gidip gitmemesi gerektiği konusundaki anlaşmazlığınızın yanı sıra, her iki ucunda kapsayıcılık sorunu var ve sezgisel olarak farklı alanlarda farklı anlamlara gelebilir (örneğin, "Cuma ve Pazartesi arasında" çoğu insan için "Pazartesi ve Pazartesi arasında" farklı bir anlam ifade eder. Cuma")

Basit arayüzlerden bahseden bir UNIX prensibi kuracağım.

Dış dünyaya sunduğunuz bir arayüzün olduğu her yerde, mümkün olduğunca şaşırtıcı olanı saklayın!

Şimdi, sorun bildirimini daha pragmatik bir ifadeye indirgedim, sanırım sayı aralıklarını belirlerken, daha küçük olanı eski *** olarak tutmaya devam etmenin sadece birkaç dakikanızı alacağını düşünüyorum. Hala bir bilmece ise, şöyle düşünün: Çocuklara bunları nasıl karşılaştıracağınızı söylerken kaç kez iki sayıyı temsil etmenin ters yolunu kullandınız?

QA mühendisiniz buna böcek diyorsa, kibarca bazı gerçek böcekler beklediğinizi ve önemsiz şeylere pahalı enerji yaymanın yollarını beklediğinizi söyleyin .

Hata ayıklama kodunuzun bir hata koşulu atmasını sağlayın veya değerleri yanlış sırayla iletildiğinde bir uyarı girin. Bu şekilde arama kodu, gerekirse parametreleri kontrol edebilir ve değiştirebilir. Bu şekilde, bu 'özelliğin' kullanıcıları, farkına varacaklar ve doğru olanı yapacaklar (önceden bilmediğiniz).