Ide Sistem yang Menarik Namun Hampir Tidak Berfungsi

Ide Sistem yang Hampir Tidak Berfungsi

• "Cukup buat agar bisa dipasang plug-in"

  • Ketika satu implementasi tidak berfungsi, idenya adalah agar pengembang dapat menambahkan implementasi baru dengan mudah. Namun, di banyak kasus, fitur yang disediakan API tidak bekerja semudah yang diharapkan. Agar benar-benar memungkinkan plugin, implementasi kedua harus didesain sejak awal.

• "Tambahkan saja API"

  • Sering kali orang menambahkan API untuk membangun platform dan menarik pengembang. Namun penyediaan API membutuhkan upaya berkelanjutan untuk kompatibilitas dan interoperabilitas, dan menyediakan API tidak berarti pengguna pasti muncul. Membangun platform adalah bisnis yang serius, dan menyediakan API saja tidak cukup untuk menyediakan fondasi ekonomi.

• "Abstraksikan sekali lagi"

  • Dalam ilmu komputer, ada anggapan bahwa masalah dapat diselesaikan dengan satu tingkat referensi tidak langsung lagi. Namun abstraksi terlalu dini dapat menimbulkan tantangan terhadap pemeliharaan, keamanan, dan optimisasi kinerja. Abstraksi yang ditambahkan tanpa perencanaan membuat pemeliharaan kode lebih sulit.

• "Buat asinkron"

  • Asinkronisasi telah lama menjadi topik penelitian di bidang ilmu komputer. Web framework mengabstraksikannya dengan baik, tetapi ketika mencoba mengelola asinkronisasi sendiri di luar framework, kemungkinan bug tak terduga sering kali tinggi.

• "Tambahkan kontrol akses nanti"

  • Keamanan sistem seharusnya dipikirkan sejak awal, tetapi sering kali ditunda demi kecepatan peluncuran pasar. Jika kontrol akses tidak dipikirkan sejak awal dari perspektif pelanggan dan musuh, kemungkinan produk perlu dirancang ulang di kemudian hari cukup tinggi.

• "Sinkronkan data"

  • Sinkronisasi data adalah masalah yang sangat sulit dengan banyak tantangan yang hanya bisa dipecahkan melalui pengalaman. Membangun solusi yang berdasar pada sinkronisasi data hampir tidak disarankan.

• "Buatlah lintas platform"

  • Pengembangan lintas platform mirip dengan membangun penyedia sistem operasi, penyedia cloud, atau browser. Jika platformnya baru atau aplikasi tetap sederhana, ini bisa berfungsi, tetapi seiring waktu akan semakin sulit.

• "Beri jalur untuk melarikan diri ke native"

  • Pada batasan cross-platform, hal yang umum dilakukan adalah menyediakan cara agar pengguna dapat keluar ke fitur native. Namun metode ini bisa berbenturan dengan keadaan yang dipertahankan oleh framework, dan 9 dari 10 kali gagal.

• Kesimpulan

  • Meskipun pendekatan ini tidak selalu gagal, dalam sebagian besar kasus ada cara yang lebih baik. Penting untuk menyelesaikan masalah berdasarkan prinsip-prinsip dasar dan menghindari pola perangkat lunak yang berisiko tinggi gagal.

[ndrgrd]

Untuk plugin, yang paling penting adalah merancang antarmuka dengan menyaring tindakan yang benar-benar esensial sebanyak mungkin.
Jika antarmuka dibuat dengan cara sekadar meniru struktur dari kode saat ini, tentu saja akan menghasilkan antarmuka yang tidak perlu dan terikat pada implementasi tersebut, dan ini memang sering sekali terjadi...

[GN⁺]

Komentar Hacker News

• DSL dan API sering kali berhasil dengan baik. Engine inferensi seperti TensorFlow juga bisa dianggap sebagai DSL atau API yang membungkus DSL

  • SQL, bahasa Shader, BPF, dan lain-lain juga bisa dilihat sebagai contoh serupa
  • Pendekatan "cuma tambahkan API" tidak selalu berhasil. Harus dikerjakan dengan teliti dan menyeluruh, seperti saat membangun UI

• DSL kadang-kadang juga bekerja dengan sangat baik. Anda dapat melihat jOOQ.org sebagai referensi

• Elastic Load Balancer adalah kontrol loop yang bereaksi terhadap beban kerja. Ini merupakan semacam produk

• Kekurangan sumber daya sangat umum di hampir semua industri. Untuk referensi, lihat erikbern.com dan "Goal: Process of Ongoing Improvement"

• Deteksi anomali bukanlah masalah sistem terdistribusi. Tapi orang yang mengalami masalahnya bisa jadi merasa ini diperlukan

  • Algoritme Isolation Forest kadang-kadang seperti mukjizat. Pada 2018, hasil yang baik didapat dengan embedding berbasis CNN untuk teks

• Penggunaan kata "hampir" tidak efektif di sini. Ini hanya pesimisme dan sinisme yang polos

• Banyak orang mencoba menemukan fungsi keputusan halus untuk handling exception. Tapi sebenarnya sederhana. Kalau saya yang melakukannya, berjalan; kalau orang sebelumnya melakukannya, tidak

• "Domain Driven Design"—mendesain aplikasi agar mengikuti struktur bisnis adalah resep malapetaka

  • Pada bisnis kecil, hal ini mungkin tidak bermasalah, tetapi pada bisnis yang sukses atau tumbuh bisa langsung dityesalkan
  • Sebaliknya, desain berdasarkan layer fitur, dan pertahankan logika bisnis sebanyak mungkin di fitur, baris-baris database, dan alur kerja pengguna

• Loop kendali yang bereaksi terhadap beban adalah elemen dasar dan esensial. Ia digunakan di banyak sistem

• Saya telah mengerjakan proyek-proyek yang memakai berbagai DSL, cache P2P, dan paralelisme hibrida, dan kebanyakan berhasil

  • Cache P2P tidak terlalu bermanfaat karena tidak diperlukan, sehingga tidak menghasilkan banyak hal
  • Meskipun kompleks, kompleksitas tersebut menyuguhkan kemampuan yang sulit dicapai dengan cara lain

• Pendekatan "hanya sinkronkan datanya" dapat menimbulkan masalah

  • Banyak sistem dirancang untuk target "skala internet" tetapi sebenarnya masih di bawahnya
  • Tim seperti itu naif, atau dalam kasus terburuk mengeluarkan dana untuk menggunakan manajer non-insinyur guna menyelesaikan masalah

• Berhasil mengeksekusi banyak ide. Karena itu, terdengar agak aneh