Haruskah “antara x dan y” bersifat komutatif?

26

Dalam aplikasi saya ada beberapa templat ekspresi yang telah ditentukan yang dapat digunakan untuk memfilter data. Salah satunya adalah " between x and y". Seorang insinyur QA mengklaim bahwa ada cacat dalam definisinya, karena " between 100 and 200" memberikan hasil yang berbeda dari " between 200 and 100". Ekspresi diterjemahkan secara internal ke " value >= x and value <= y", jadi jelas tidak ada hasil ketika batas kedua lebih rendah dari yang pertama. Saya telah memeriksa bahwa perilaku yang sama ada di SQL - " between x and y" mengasumsikan bahwa y> = x atau tidak ada hasil. Ini berarti bahwa operator tidak komutatif, setidaknya dalam SQL.

Jadi, apakah QA benar bahwa " between x and y" harus komutatif?

requirements pkalinow
sumber
11
Tidak, tapi mungkin ui Anda akan memerah ketika seseorang salah mengisinya.
Ewan
3
juga, itu salah satu dari mereka> = <= harus eksklusif sehingga Anda dapat rantai 100-> 200 200-> 300 dll tanpa mendapatkan tumpang tindih
Ewan
23
Tidak jelas apakah betweenharus memasukkan atau mengecualikan nilai yang lebih rendah dan lebih tinggi. Orang QA mungkin bertele-tele tetapi selama ada ketidakpastian seseorang perlu mengklarifikasi cerita pengguna / persyaratan. Mungkin ternyata cara mereka dilakukan adalah seperti yang seharusnya, tetapi keputusan harus diambil.
Bent
11
Ini bukan kasus benar atau salah. Ini adalah kasus ... bagaimana bisnis ingin aplikasi berperilaku? Jawabannya adalah fungsionalitas apa yang diharapkan. Debat teknis tidak mendorong fungsi yang diperlukan. Fungsionalitas yang diperlukan mendorong debat teknis dan mudah-mudahan menginspirasi solusi terbaik untuk bisnis ini.
Brad Thomas
2
Pertanyaan ini lebih tentang apa yang diharapkan pengguna daripada apa yang diharapkan oleh seorang programmer. Karena itu, akan lebih tepat untuk Pengalaman Pengguna .
Makyen

Jawaban:

32

Jika spec Anda saat ini tidak terdefinisi, perilaku ini sepenuhnya arbitrer, tidak ada definisi "benar" atau "salah". Jadi, jika insinyur QA Anda tidak dapat mengarahkan Anda ke paragraf yang tepat dalam spesifikasi di mana perilaku ini didefinisikan, Anda mungkin dapat menolak permintaannya (meskipun tampaknya tidak menjadi persyaratan yang membutuhkan banyak upaya untuk mengimplementasikannya). Jika Anda berdua tidak dapat menemukan konsensus, satu orang di tim Anda harus membuat keputusan apa yang lebih penting dalam konteks aplikasi:

  • mengikuti standar SQL semirip mungkin
  • tidak mengikutinya karena ergonomi, kasus penggunaan khusus, atau persyaratan lainnya

Apa pun keputusan yang diambil tim Anda, mungkin merupakan ide bagus untuk mendokumentasikan perilaku dan alasan mengapa keputusan itu dibuat.

Doc Brown
sumber
57
Anda mungkin dapat menolak permintaannya => Saya benar-benar akan mengatakan bahwa pertama dan terutama, perilaku harus didefinisikan. Kemudian Anda dapat berterima kasih kepada orang QA untuk menunjukkan masalah ini dan mengatakan bahwa sekarang sudah ditentukan untuk bekerja dengan <cara spesifik> (dan pastikan kode cocok dengan spesifikasi).
Matthieu M.
1
@ MatthieuM. Saya pikir itu jawaban terpisah yang seharusnya memiliki 33 upvotes sendiri. ;)
jpmc26
1
Konversikan bug menjadi peningkatan dan biarkan di backlog selamanya. Terima kasih QA atas ketekunan mereka.
Sandy Chapman
1
@ MatthieuM. ya, di dunia ideal akan ada persyaratan yang jelas untuk setiap detail. Dalam kasus seperti itu saya tidak perlu bertanya di Stack Exchange :)
pkalinow
@ pkalinow: Saya pikir Anda salah memahami komentar saya. Maksud saya adalah sebelum menutup bug, Anda harus (1) berterima kasih kepada orang QA karena menunjukkan potongan kode yang tidak ditentukan dan (2) duduk bersama dengan siapa pun yang tertarik untuk benar-benar menentukan perilaku. Ini mungkin berarti memberikan laporan QA kepada siapa pun yang bertanggung jawab untuk menulis spesifikasi, kepada pemilik produk jika Anda memiliki hal-hal seperti itu dll ... maka, setelah perilaku itu seharusnya disetujui, Anda dapat mengevaluasi apakah perangkat lunak perlu diubah atau tidak. Mungkin itu berarti mengubah perangkat lunak, mungkin itu berarti menutup laporan ...
Matthieu M.
13

Ini adalah pertanyaan tentang kegunaan atau pengalaman pengguna. Bagaimana SQL atau sistem lainnya berperilaku tidak relevan, pertanyaannya adalah apa yang paling masuk akal dari perspektif pengguna.

Perilaku saat ini tidak masuk akal dari perspektif pengguna. Baik x dan y harus dipertukarkan atau tidak boleh memilih x yang lebih besar dari y. Mengizinkan x lebih besar dari y tetapi mengembalikan set kosong memperkenalkan kemungkinan kesalahan yang tidak perlu tanpa memberikan manfaat apa pun.

Jadi insinyur QA benar ada cacat, tetapi solusi yang diusulkan belum tentu yang terbaik. Anda harus melakukan tes kegunaan memutuskan ini, atau setidaknya bertanya kepada beberapa pengguna representatif apa yang tampaknya paling alami bagi mereka.

Atau, Anda dapat mengajukan pertanyaan di /ux// . Orang-orang di sana sebenarnya tahu satu atau dua hal tentang pengalaman pengguna.

JacquesB
sumber
11

Ada beberapa pilihan yang masuk akal, dan yang harus dipilih tergantung pada sisa sistem, dan harapan pengguna Anda.

Anda bisa, seperti yang ditunjukkan oleh insinyur QA, cukup buat ekspresi komutatif, lalu terjemahannya akan menjadi

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

Anda dapat membatasi penggunaan yang valid x <= y, yang mengharuskan UI Anda dapat menampilkan "itu bukan ekspresi yang valid" sedini mungkin.

Sebagai variasi di atas, pembatasan x < yjika Anda memiliki ekspresi equals xdan lebih suka untuk mengevaluasivalue >= x and value <= x

Caleth
sumber
Catatan: Tolong jangan membuat pernyataan itu sendiri value >= min(x, y) and value <= max(x, y). Hitung ulang apa yang Anda bisa untuk menyimpan pekerjaan server database Anda, terutama jika itu berlebihan seperti itu (Anda dapat melakukan operasi yang relevan sekali dan mengatur kedua hasil sesuai). Mungkin tidak masalah, tergantung pada server basis data dan nilai spesifik yang Anda berikan , tetapi server SQL yang ditulis dengan buruk mungkin melakukan mindan maxuntuk setiap catatan jika Anda memasukkannya ke dalam where, dan jika Anda dapat menghapus upaya itu , tidak ada alasan untuk tidak melakukannya.
Dana Gugatan Monica
6
Tolong jangan dengarkan QPaysTaxes - mengoptimalkan hal-hal tanpa pernah mengukur kebutuhan adalah persis apa yang Knuth sebut sebagai "pengoptimalan dini karena akar semua kejahatan". Peluangnya tinggi di sebagian besar kode dunia nyata Anda tidak akan melihat perbedaan dalam kecepatan jika Min dan Max dihitung untuk setiap catatan, tetapi nilai pra-perhitungan (dan dengan memasukkan kode tambahan dan redundansi ekstra) akan membuat program jauh lebih tidak dapat dipertahankan.
Doc Brown
@DocBrown Saya setuju bahwa kita tidak boleh membuat perubahan untuk keuntungan kinerja potensial tanpa mengukur, tetapi bertentangan dengan klaim Anda, saya akan menemukan batas yang dihitung sebelumnya lebih mudah dibaca daripada satu-liner, dan dengan demikian lebih dapat dipertahankan.
Jacob Raihle
@JacobRaihle: ini mungkin dikritik, tetapi untuk seleraku value >= min(x, y) and value <= max(x, y)dapat dibaca value >= minXY and value <= maxXY, di mana minXYdan maxXYmerupakan batas yang telah dihitung. Namun, untuk yang terakhir harus menulis beberapa kode untuk menambahkan dua variabel baru ke sistem, isi sebelumnya, jangan lupa untuk memperbarui nilai-nilai ini ketika x dan y berubah, dan sebagainya. Data yang berlebihan selalu menimbulkan risiko kesalahan tertentu.
Doc Brown
5

Dalam pengaturan non-interaktif, di mana batas-batas Anda dibuat oleh sebuah skrip, biasanya masuk akal untuk mengharuskan mereka agar dalam rangka. Ini menciptakan satu pengecekan validasi yang lebih sedikit untuk dilakukan, lebih masuk akal secara semantik, dan mudah untuk dikelola.

Dalam pengaturan interaktif, Anda ingin membantu pengguna. Jika memungkinkan, buat GUI yang tidak memungkinkan rentang yang ditukar dimasukkan, atau setidaknya membuatnya semudah mungkin untuk memasukkan rentang secara berurutan. Jika Anda memasukkan rentang dengan teks, ambil halaman dari vim, paragon kegunaan, dan meminta pengguna untuk secara otomatis bertukar rentang terbalik:

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

Jika insinyur QA Anda tidak menghalangi UX untuk menunjukkan kepadanya rentang terbalik tidak diinginkan, maka dia membuat asumsi yang masuk akal.

Karl Bielefeldt
sumber
2

Terus terang? Jangan gunakan "antara". Sama sekali.

Pertama, istilah ini sangat ambigu, terutama dalam bahasa Inggris. Apakah ini komutatif? Apakah ketentuannya eksklusif? Inklusif?

Kedua, jika Anda melakukan antarmuka yang terpisah dari backend, jangan khawatir tentang perilaku backend; dan jangan biarkan pengguna Anda menganggap perilaku warisan. Tentu, SQL mendefinisikannya BETWEENsebagai inklusif, tetapi ini hampir tidak pernah merupakan perilaku yang diinginkan (misalnya - Jika Anda melakukan sesuatu seperti rows BETWEEN :start and :start + :strideAnda akan mendapatkan stride + 1baris).

Sebagai gantinya, Anda harus secara eksplisit mendaftar perbandingan untuk titik akhir. "Lebih besar atau sama dengan x". "Sebelum hari ini". Ini menghilangkan ambiguitas. Ini juga membantu menulis kode yang lebih bersih, dan menghindari beberapa kesalahan berbahaya. Contoh baris dari sebelumnya pada dasarnya adalah posting Djikstra tentang pengindeksan . Dan memungkinkan SQL untuk menggunakan batas atas inklusif pada beberapa jenis dapat mengakibatkan data yang dipilih salah .

Clockwork-Muse
sumber
Yah, itu layak untuk dipikirkan. Dan terima kasih atas tautannya. Pos Dijkstra mungkin tidak terlalu relevan, tetapi menarik :)
pkalinow
Ini tidak benar-benar menjawab pertanyaan OP, melainkan menambah kebingungan.
Roland Tepp
1

Tidak produktif berdebat dengan QA Anda tentang siapa yang "benar" dan siapa yang "salah". Anda mengartikan spec secara berbeda dari yang mereka lakukan. Itu berarti bahwa spesifikasi tersebut cukup ambigu sehingga memerlukan klarifikasi.

Jika antarmuka pengguna adalah spec, dan itu bukan perilaku yang diharapkan QA, itu tidak akan menjadi perilaku setidaknya beberapa pengguna harapkan. Itu menunjukkan masalah kegunaan (bahkan jika Anda ingin berdebat PEBKAC). Bekerja dengan QA Anda untuk menemukan solusi yang memuaskan untuk itu.

Sebagai poin umum, berhati-hatilah dengan kata-kata seperti "antara" yang tampak jelas, tetapi tidak. Terlepas dari ketidaksepakatan Anda tentang apakah harus bepergian, mereka bermasalah dengan inklusivitas di kedua ujungnya, dan secara intuitif dapat berarti hal-hal yang berbeda pada domain yang berbeda (misalnya, "antara Jumat dan Senin" akan berarti sesuatu yang berbeda bagi kebanyakan orang daripada "antara Senin dan Jumat")

Martijn
sumber
1

Saya akan menggunakan prinsip UNIX yang berbicara tentang antarmuka sederhana.

Di mana pun ada antarmuka yang Anda tawarkan ke dunia luar, pertahankan hal yang paling mengejutkan!

Sekarang saya telah mengurangi pernyataan masalah menjadi yang lebih pragmatis, saya pikir itu akan membawa Anda hanya beberapa saat untuk menyadari bahwa ketika menentukan rentang angka, itu jelas untuk menjaga yang lebih kecil sebagai yang sebelumnya. Jika masih teka-teki, pikirkan seperti ini- Berapa kali Anda menggunakan cara sebaliknya untuk mewakili dua angka sambil memberi tahu anak-anak cara membandingkannya?

Jika insinyur QA Anda menyebutnya bug, katakan padanya dengan sopan bahwa Anda mengharapkan beberapa bug nyata , dan bukan cara untuk mengarahkan energi yang mahal pada hal-hal sepele.

an4
sumber
0

Jadikan kode debug Anda melemparkan kondisi kesalahan atau catat peringatan setiap kali nilai-nilai dilewati dengan urutan yang salah. Dengan cara ini kode panggilan dapat memeriksa dan bertukar parameter, jika perlu. Dengan cara ini pengguna 'fitur' ini akan menjadi sadar dan melakukan hal yang benar (yang sebelumnya tidak Anda ketahui).

Grimaldi
sumber