Dalam artikel ini, kami akan mencoba mempertimbangkan opsi untuk polemik yang salah, yang, sayangnya, sering ditemukan di Habr dan situs lainnya.
Absolutisasi dari pendekatan yang dijelaskan
Diketahui bahwa metode apa pun yang dibawa ke absolut menjadi bodoh.
Misalnya, terlalu sering menggunakan OOP menghasilkan kode yang tidak dapat dibaca. Penolakan lengkap OOP dan transisi ke kode murni fungsional juga mengurangi keterbacaan.
Kebenaran selalu ada di antara keduanya.
Tetapi ketika Anda ingin memberi tahu seseorang tentang bagaimana Anda berhasil menerapkan beberapa metode, bersiaplah untuk kenyataan bahwa ada lawan yang akan mencoba menggunakan metode ini di mana-mana.
Saya pernah menulis sebuah artikel tentang penggunaan acara bernama, dan seorang komentator mendatangi saya dan berkata:
Omong kosong penuh! Saya mengganti semua fungsi dalam kode saya dengan peristiwa bernama. Ternyata pengidentifikasi yang melaluinya sangat sulit untuk dilalui! Setelah itu, saya kembali ke React lama yang baik!
Apa yang harus dilakukan
- Jangan terlibat dalam perselisihan.
- Suatu saat berkomentar bahwa Anda tidak boleh berlebihan dengan alat.
Obrolan terminologis
Bukan rahasia lagi bahwa dalam banyak kasus perbatasan antara istilah-istilah tersebut sulit untuk digambarkan. Seringkali dua istilah berbeda berarti hal yang sama dan sebaliknya. Tergantung pada konteks dan batasan penggunaan.
Misalnya, Anda berbicara tentang sesuatu. Tentang Masalah X :
Pertimbangkan masalah X , yang memanifestasikan dirinya, misalnya, dalam kasus A , B , C dan D Masalahnya adalah ini dan itu. Anda bisa menyelesaikannya begitu-dan-begitu.
Pasti akan ada komentator yang akan mengatakan:
Omong kosong penuh! Istilah D salah diterapkan! Sebenarnya Anda harus mengatakan D- . Istilah D memperkenalkan .. dan itu di tahun ini dan itu. Dan istilah D- .. lain di tahun lain.
Untuk beberapa alasan, tahun dan nama itu penting.
Anda menjawabnya:
Dalam kerangka artikel ini, tidak terlalu penting apakah itu D atau D- , karena di sini kita berbicara tentang masalah X D sini adalah contoh dan D- dapat menjadi contoh yang sama. Dalam konteks ini, tidak ada perbedaan: masalah X hadir di D dan D- .
Peserta lain segera muncul. Nyatakan:
Ini bukan D- , ini E !
Debat tentang istilah dimulai, yang bisa bertahan selamanya. Pulp khusus: jika setelah beberapa hari perselisihan, peserta lain muncul, pada tahap tertentu perselisihan kembali ke istilah D :
Tidak, ini bukan E , ini D !
Akibatnya, pos mengumpulkan 100+ komentar tentang istilah D , D- , E dan tahun-tahun kelahiran mereka yang memperkenalkan istilah tersebut. Tetapi masalah X tidak dibahas.
Saya pernah punya komentar tentang masalah menggunakan variabel global (atau statis).
Ini memberikan contoh dengan singleton. Singleton dalam contoh diimplementasikan menggunakan variabel global.
SingletonSingleton adalah objek yang dipakai dalam sistem hanya sekali. Satu instance dapat dijamin dalam beberapa cara:
- Kelas itu sendiri menjamin ini entah bagaimana (biasanya mengacu pada variabel global / statis).
- Ini dilakukan di luar kelas - pada saat instantiasi (dalam hal ini, beberapa objek dari kelas ini secara teoritis dapat dibuat, tetapi jika titik instantiasi dihubungkan, misalnya, ke variabel global, maka kita dapat mengasumsikan bahwa kita menciptakan singleton).
Saya memilih opsi kedua.
Segera ada karakter yang berseru:
Omong kosong penuh! Ini bukan singleton, ini memoisasi!
Saya menjawab:
Ini adalah singleton, yang dalam contoh ini diimplementasikan menggunakan memoisasi.
Jadi saya terlibat dalam game ini. Masalah variabel global / statis telah dilupakan.
Apa yang harus dilakukan
- Jangan terlibat dalam perselisihan (jika kita benar-benar ingin membahas dengan tepat apa yang mereka tulis dalam artikel).
- Verifikasi persyaratan dalam artikel dengan cermat. Jika sesuatu dapat memiliki dua nama, kami berikan keduanya.
- Perlahan kembalikan audiens ke masalah yang dibahas. Ingatkan aku akan dia.
Ini bukan peluru perak!
Setiap solusi memiliki batasan di mana ia bekerja dengan baik, dan di luarnya ia bekerja dengan buruk - solusi lain diperlukan.
Misalkan Anda sedang mendiskusikan beberapa cara untuk memecahkan berbagai masalah.
Pasti ada seseorang yang akan datang dan berkata:
Omong kosong penuh! Saya mencoba dengan sekop Anda untuk memalu paku ke dinding, ternyata buruk. Hanya tangan yang terluka! Saya akan kembali ke palu tua.
Apa yang harus dilakukan
Jangan terlibat dalam perselisihan. Abaikan saja komentarnya.
Hiperbolisasi masalah
Anda menggambarkan cara untuk menyederhanakan penulisan kode dalam semacam paradigma. Pasti akan ada orang yang akan mencari contoh / opsi yang berlawanan contoh dan akan menghipnotis mereka.
Komentarnya dapat direduksi menjadi ini (hanya saja dia tidak secara langsung mengatakannya):
Setelah dari 100 kasus, kami hanya meningkatkan 99, dan semuanya tidak diperbaiki, proposal Anda berantakan total.
Sebagai aturan, pada saat yang sama ia menawarkan solusi lain, yang Anda usulkan untuk ditolak di artikel Anda.
Apa yang harus dilakukan
- Kenali masalah.
- Cobalah untuk memberikan lebih banyak contoh saat pendekatan Anda lebih baik.
Mengabaikan masalah
Kebalikan dari opsi sebelumnya.
Salin kode 23 kali? Pff apa yang sepele! Tetapkan sendiri IDE yang benar, di mana itu dilakukan dengan satu tombol, dan Anda tidak perlu menulis artikel di sini!
Apa yang harus dilakukan
Abaikan komentar seperti itu.
Dan pilihan polemik yang salah apa yang Anda ketahui?