Manifesto Pengembang Sistem Cerdas: 15 Prinsip

Kami memberi perhatian Anda sebuah artikel oleh Vladislav Zaitsev ( vvzvlad ), tamu undangan blog kami. Vladislav telah lama terlibat dalam topik "rumah pintar," dan meringkas pengalamannya, ia menawarkan prinsip-prinsip dasar berikut untuk desain sistem tersebut.

Hari ini saya ingin berbicara dengan Anda tentang rumah pintar khususnya dan perangkat IoT secara umum. Tetapi ini tidak akan menjadi artikel biasa: tidak akan ada kelenjar, tautan ke pabrik, potongan kode dan gudang di github. Hari ini kita akan membahas sesuatu tingkat yang lebih tinggi - prinsip - prinsip di mana sistem "pintar" diorganisir



Dengan terus membaca artikel, Anda setuju bahwa Anda puas dengan penafian berikut.

---

Rumah pintar adalah sistem yang mengambil alih sebagian dari kekhawatiran sehari-hari seseorang. Dari sini mengikuti prinsip pertama dan paling dasar:

1. Rumah pintar harus membuat hidup lebih mudah dan lebih mudah.

Rumah pintar adalah sistem seumur hidup, bukan mainan untuk Geeks. Sistem apa pun yang lebih sulit untuk menggunakan ¹ daripada sakelar konvensional bukanlah rumah pintar.

Setiap produk baru harus diuji kepatuhannya dengan prinsip ini. Jika itu tidak membuat hidup lebih mudah, dan Anda tidak mengerti bagaimana membuatnya lebih mudah, itu bukan milik rumah pintar. Anda dapat mencoba membayangkannya sebagai sistem pembelajaran.

---

Prinsip terpenting kedua menyangkut bagaimana pengguna berinteraksi dengan sistem:

2. Pengalaman pengguna yang baik lebih penting daripada fungsi.

Berharga adalah alat keren yang tidak dapat digunakan secara normal. Perangkat yang nyaman dan andal dengan fungsionalitas terbatas lebih mungkin berhasil daripada produk canggih untuk "semua kesempatan".

2.1. Antarmuka yang nyaman lebih baik daripada kemampuan kustomisasi.

Tidak mengerti bagaimana cara menyimpan banyak fungsi dan antarmuka yang sederhana? Anda mendorong semua fungsi berturut-turut dengan harapan bahwa pengguna akan mengetahui apa yang dia butuhkan? Keluar dari profesi!
Tidak mengerti bagaimana cara menggabungkan kenyamanan dan banyak pengaturan? Donasikan pengaturan. Fungsionalitas apa pun akan lebih dingin daripada sakelar biasa, tetapi kompleksitas yang berlebihan akan dengan mudah memaksa pengguna untuk kembali ke sakelar.

Hal yang sama berlaku untuk kualitas kerja. Sebuah tombol yang hanya menyalakan lampu lebih baik daripada bilah geser pengatur kecerahan, yang terkadang mengalami gangguan:

2.2. Kualitas fungsi yang diterapkan lebih penting daripada kuantitasnya.

Fungsionalitas yang sedikit andal, tetapi terbukti lebih baik daripada yang banyak, tetapi berfungsi entah bagaimana.
Salah satu mekanisme yang diperbaiki dalam jiwa manusia melalui evolusi adalah reaksi yang lebih aktif terhadap rangsangan negatif. Faktor negatif lebih penting daripada yang positif: melewatkan pendekatan predator berbahaya jauh lebih buruk daripada tidak memperhatikan dan tidak makan buah yang lezat di pohon. Jika sistem Anda tidak memiliki fungsi apa pun, itu tidak menakutkan, itu hanya karena tidak adanya insentif positif. Tetapi fungsi yang ada, tetapi berfungsi buruk, adalah insentif negatif: ia diingat lebih mudah dan diingat lebih lama.

2.3. Implementasi sistem seharusnya tidak mengurangi kecepatan kerja yang biasa.

Penundaan tidak dapat diterima karena menurunkan pengalaman pengguna. Ini juga merupakan insentif negatif. Jika seseorang tidak melihat penundaan ² antara klik sakelar konvensional dan masuknya cahaya, ia seharusnya tidak memperhatikannya di sistem Anda.

Setrika modern bekerja dengan kecepatan sangat tinggi. Tidak ada masalah mencapai frekuensi puluhan megahertz pada mikrokontroler dan setidaknya puluhan kilobit per detik, bahkan di udara. Jika Anda tidak dapat membuat sistem dalam kondisi ini, pengguna tidak merasakan keterlambatan dalam operasinya, keluar dari profesi!

2.4. Sistem seharusnya tidak menghentikan kebiasaan pengguna yang sudah terbentuk.

Sistem Anda hanyalah sebagian kecil dari kehidupan manusia. Waktu hidup seseorang melebihi umur sistem paling baik beberapa kali, dan paling buruk dengan urutan besarnya. Sistem Anda akan pergi sebagaimana mestinya, dan kehidupan manusia akan berlanjut. Dan dalam kehidupan ini, seseorang telah membentuk kebiasaan mengenai kecerahan cahaya yang disukai, lokasi sakelar, bagaimana nyaman baginya untuk menyalakan lampu dan mengontrol iklim di rumah.

Anda tidak dapat dengan paksa mengubah kebiasaan ini. Adalah mungkin untuk menawarkan. Untuk memaksa - itu tidak mungkin.
Anda tidak dapat memberi tahu pengguna "sekarang Anda akan menyalakan lampu dari telepon - gaya, modis, muda." Ini merupakan pelanggaran prinsip ini dan beberapa lainnya.

Jadi apa yang harus dilakukan?

2.5. Sistem harus membawa pengalaman baru, dan tidak mencoba menggantikan yang lama.

Jika Anda berpikir cara Anda mengelola sistem di rumah lebih baik daripada yang lama, tawarkan kepada pengguna. Jika ini benar-benar lebih nyaman, ia akan memilih yang baru (ya, metode yang berbeda cocok untuk orang yang berbeda). Yang dapat Anda (dan harus) lakukan adalah memberinya pilihan.

---

Tempat penting di rumah pintar ditempati oleh logika kerja. Apa yang menentukan oleh aturan apa rumah pintar ini akan berfungsi. Dan prinsip penting berikut hanya tentang itu:

3. Pengguna tidak dapat dibatasi dalam logika yang dapat diakses olehnya.

Jika pengguna ingin menyalakan ketel ³ saat suhu naik di ruangan, beri dia kesempatan untuk melakukan ini. Suatu situasi harus dikecualikan ketika tidak ada batasan fisik atau perangkat lunak untuk melakukan tindakan tertentu, tetapi tidak tersedia, karena pengembang berpikir "tidak ada yang akan membutuhkan ini."

3.1. Sesederhana mungkin: menulis logika seharusnya tidak memerlukan pengetahuan khusus tentang perangkat sistem

Jika Anda memiliki perangkat versi yang berbeda dengan protokol yang berbeda, pastikan bahwa pengguna mengetahuinya hanya dalam kasus yang benar-benar diperlukan, ketika Anda tidak dapat melakukannya tanpa itu. Jika Anda dapat menyelamatkan pengguna dari memperoleh pengetahuan khusus, meskipun dengan biaya waktu pengembang, lakukanlah. Pengembang akan menghabiskan dua hari, dan seribu pengguna per jam. Empat puluh delapan jam versus seribu? Jawabannya jelas.

Bagaimana Anda tidur, John adalah seorang programmer serial?

3.2. Perangkat dengan fungsi yang sama harus dikontrol secara merata.

Pengguna tidak harus tahu bahwa katup air dikendalikan oleh beberapa perintah, dan keran oleh yang lain. Jika keduanya mengontrol air di dalam pipa, maka keduanya harus memiliki antarmuka pengguna yang sama: "air terbuka" dan "air dekat".

---

Kita semua hidup di dunia fisik. Tubuh dan otak manusia dibentuk untuk berinteraksi dengan benda-benda fisik. Karena itu prinsipnya:

4. Perangkat kontrol fisik lebih baik daripada yang virtual.

Apa pun, bahkan aplikasi terbaik di telepon dengan tombol kontrol virtual kalah dari sakelar fisik biasa di tempat yang tepat.

Hal lain adalah sakelar harus diletakkan di tempat yang tepat . Oleh karena itu aturan penting lainnya:

5. Radio lebih baik dari kabel.

Sistem kabel dapat diandalkan, tetapi hanya komunikasi radio yang memungkinkan Anda memasang sakelar atau relai baru untuk lampu tanpa harus memperbaikinya lagi. Dan transfer, jika Anda bosan dengan tempat sebelumnya. Tetapi prinsip ini memiliki pengecualian:

5.1. Radio yang buruk lebih buruk dari kabel.

Radio yang bagus adalah radio yang memungkinkan Anda untuk tidak memikirkan seberapa jauh jaraknya dari pusat pengontrol perangkat. Radio yang bagus adalah protokol jaringan mesh : ZigBee, Z-Wave, 6LoWPAN dan sebagainya.

Semua opsi lainnya adalah radio yang buruk. Wi-fi adalah radio yang buruk. Protokol buatan sendiri dari masing-masing perusahaan (mereka dikenal dengan buatan sendiri dengan nama "433 MHz", meskipun mereka dapat berada pada frekuensi lain, dan dapat sangat berbeda satu sama lain) - radio yang buruk.

Wi-Fi buruk karena tidak mungkin membuat perangkat "tidur" penuh pada dasarnya, dan sulit untuk melakukan konfigurasi otomatis, serta masalah kompatibilitas dengan perangkat Wi-Fi lain di rumah. Protokol buatan rumah yang sederhana buruk karena seringkali tidak mengandung kontrol pengiriman, enkripsi, atau spesifikasi yang tersedia. Tidak ada yang memiliki perutean jala, yang sering menghasilkan masalah seperti "tapi saya tidak bisa meletakkan saklar di sudut itu - terlalu jauh dari pemancar".

---

Tidak mungkin membuat sistem dengan keandalan absolut dan tanpa perlu pemeliharaan. Perangkat rusak, aliran listrik terjadi dalam jaringan, air mengalir dari apartemen tetangga, baterai terkuras, keretakan plastik, anak menuangkan sup ke lampu dan sebagainya. Tapi:

6. Perbaikan, pembaruan, pemeliharaan, dan diagnostik harus sederhana.

Semuanya jelas dalam B2B: ada pengguna, ada pengembang, dan ada operator - orang atau organisasi yang tahu bagaimana sistem bekerja dan dapat bekerja dengannya di tingkat profesional. Tidak ada yang membutuhkan pengetahuan akuntan tentang pemrograman di bawah 1C, ini adalah orang yang istimewa. Dan tidak ada yang mengharuskan seseorang yang menyewa kantor untuk memahami bagaimana ventilasi bekerja di dalamnya - pekerjaannya adalah untuk mengatakan: "Ini pengap di kantor kami."

Keputusan yang kompeten untuk membeli suatu sistem didasarkan pada perhitungan total biaya kepemilikan, yang merupakan jumlah dari harga sistem dan biaya operasinya.
Dalam sistem yang digunakan seseorang di rumah, semuanya lebih rumit. Di sana, operator dan pengguna adalah satu dan orang yang sama, dan di samping itu sering tidak memiliki pengetahuan yang diperlukan tentang sistem. Sayangnya, ini adalah keterbatasan pasar konsumen. Karenanya prinsip-prinsip berikut:

6.1. Perangkat harus berfungsi atau tidak berfungsi. Tidak ada yang ketiga.

Kemungkinan bekerja, kerja sebagian dan kerja yang salah tidak diizinkan. Anda tidak boleh membiarkan situasi di mana perangkat Anda berfungsi setiap saat atau tidak berfungsi satu dari sepuluh. Jika Anda berpikir bahwa perangkat Anda tidak berfungsi, Anda harus mematikannya sama sekali - untuk keamanan dan untuk mempertahankan pengalaman pengguna yang positif. Mengganti perangkat itu tidak menyenangkan, tetapi lebih baik memaksa pengguna untuk menggantinya daripada membentuk opini “berfungsi sekali” tentang sistem. Sistem harus dalam kondisi yang didefinisikan secara ketat: jika rusak, maka tidak berfungsi, jika tidak rusak, maka berfungsi.

Jika Anda yakin bahwa degradasi fungsi dapat diterima, Anda harus tetap memperingatkan pengguna dengan pesan yang jelas: "Kegagalan saluran peredup kedua telah terdeteksi. Hal ini diperlukan untuk mengganti dimmer. Lanjutkan menggunakan saluran redup pertama? Ya / tidak

6.2. Mengganti perangkat yang rusak seharusnya mudah.

Sistem harus modular. Jika pengguna memecahkan sensor, ia hanya perlu mengganti sensor. Anda tidak dapat meminta untuk mengubah relai dengan panel kontrol, karena, Anda tahu, itu terpasang padanya pada tahap produksi.

Anda bahkan tidak bisa mengatakan "hanya spesialis kami yang dapat memasang sensor baru", karena, jelas, dengan pengembangan sistem Anda, tidak akan ada cukup spesialis untuk jutaan pengguna yang memungkinkan, yang berarti bahwa masalah akan mulai pada titik tertentu. Tentu saja, pengguna tidak akan memperbaiki perangkat itu sendiri, tetapi jika terjadi kerusakan ia harus dapat menggantinya.

6.3. Hapus pesan.

Jika terjadi kesalahan, pengguna harus mengetahuinya, dan tahu apa yang salah.
Tidak mungkin memberi tahu pengguna "Kesalahan # 45", yang menyiratkan bahwa hanya karyawan dukungan teknis yang akan memahami pesan ini. Dia perlu mengatakan: “Perangkat tidak merespons. Coba reboot, ikat lagi atau hubungi layanan. Kesalahan # 45. "

Tidak mungkin mendeteksi bahwa perangkat tidak merespons (jika Anda memiliki kesempatan untuk melakukan ini), dan tidak memberi tahu pengguna tentang hal itu. Tidak terlalu menyenangkan untuk menerima pesan tentang masalah, tetapi jauh lebih tidak menyenangkan untuk memahami bahwa perangkat tidak berfungsi selama seminggu, pada saat Anda sangat membutuhkannya.

6.4. Kurangnya informasi yang tidak perlu dalam pesan.

Tetapi pada saat yang sama, Anda tidak perlu membuang dump debug dan multiline log ke pengguna. Informasi dibutuhkan baik oleh pengguna, seperti pada paragraf sebelumnya, karena itu termasuk informasi tentang apa yang sebenarnya salah, atau tidak diperlukan jika informasi tambahan ini tidak jelas, karena tidak ditujukan kepadanya.

Tidak perlu menunjukkan kepada pengguna seratus pesan dari jenis yang sama: "koneksi dengan perangkat telah hilang", "komunikasi dengan perangkat telah dipulihkan". Putuskan akhirnya: apakah ini masalah kritis, dan Anda harus melaporkannya dengan cara yang benar - “Komunikasi yang tidak stabil dengan perangkat”, atau, karena ternyata dipulihkan, ini bukan informasi penting, dan Anda tidak perlu memperlihatkannya ⁴ .

6.5. Pemeliharaan tidak membutuhkan pengetahuan dan peralatan khusus.

Berikan pengguna kesempatan untuk memperbarui firmware - biarkan diperbarui hanya dengan menekan beberapa tombol. Dan ini akan dilakukan baik melalui antarmuka standar (USB / BT / Wi-Fi), atau tidak menyebutkan dalam dokumentasi pengguna tentang memperbarui firmware menggunakan programmer SPI secara umum.

Anda tidak dapat mengharuskan pengguna untuk menghitung bit mask untuk konfigurasi perangkat jika konfigurasi ini diperlukan dalam penggunaan normal.

6.6. Sistem seharusnya tidak memerlukan pemeliharaan berkelanjutan.

Jika sebulan sekali ada tautan yang terbang di unit eksekutif, dan pengguna perlu memanjat ke kandil dan mengikatnya lagi, ini adalah sistem yang buruk. Jika saklar perlu mengganti baterai setiap dua bulan - ini adalah sistem yang buruk. Bahkan rata-rata periode pemeliharaan enam bulan untuk setiap perangkat buruk: untuk dua puluh perangkat di rumah, pengguna harus mengambil beberapa tindakan rata-rata setiap sembilan hari.

6.7. Sistem harus memiliki kemampuan untuk memperbarui atau memperluas.

Biaya perluasan sistem harus tumbuh secara linear. Blok baru harus menelan biaya blok baru.

Seharusnya tidak ada situasi ketika Anda perlu membeli controller baru untuk menambahkan sensor baru, karena yang lama tidak mendukung lebih dari enam sensor ⁵ .

Seharusnya tidak ada situasi di mana firmware sensor baru hanya dapat bekerja dengan versi baru dari unit kontrol.

Pembatasan tersebut memiliki efek positif pada keuntungan, memaksa pengguna untuk membeli perangkat baru, tetapi ini adalah jalan menuju neraka - kehilangan kepercayaan pengguna karena trik semacam itu, Anda akan kehilangan lebih banyak daripada yang bisa Anda peroleh.

7. Kemandirian: jaringan eksternal adalah pilihan, bukan keharusan.

Sistem di mana tim hanya melalui server eksternal adalah sistem yang buruk. Anda dapat membual tentang antarmuka yang nyaman, aplikasi yang trendi, dan jaringan saraf yang keren sebanyak yang Anda suka, tetapi tidak masalah jika pengguna, bersama dengan jatuhnya Internet, telah kehilangan kemampuan untuk menyalakan lampu di toilet. Pengembang, apakah Anda benar-benar berpikir sistem seperti itu baik?
Tapi serius, saya tidak begitu mengerti mengapa item ini bukan masalah. Dengan mengikat sistem ke server eksternal, Anda membuat titik kegagalan dengan keandalan server biasa, tetapi pada saat yang sama untuk semua pengguna Anda. Layanan eksternal itu keren, mereka memungkinkan Anda untuk memperluas fungsionalitas, tetapi seharusnya tidak menjadi satu-satunya pilihan untuk manajemen operasional. Saluran kontrol tambahan, penyimpanan cadangan, analisis data - sebanyak yang Anda inginkan.

8. Sentralisasi: kurangnya hub pusat membatasi logika yang tersedia.

Namun, jangan buru-buru ke ekstrim lain - cobalah membuat sistem terdesentralisasi, dan karenanya benar-benar dapat diandalkan.

Sistem desentralisasi adalah ketika sakelar mengatakan "nyalakan" ke bola lampu, dan sensor suhu menghidupkan pemanas saat suhu turun. Sistem terdistribusi kehilangan terpusat hanya karena sistem seperti itu hanya ada dalam kerangka paradigma interaksi perangkat yang paling sederhana - “perangkat mengontrol perangkat lain”. Seiring meningkatnya kompleksitas sistem, sistem semacam itu menimbulkan lebih banyak pertanyaan daripada jawaban. Jika ada beberapa sensor suhu, maka haruskah pemanas menerima perintah dari semua orang? Atau haruskah dia sendiri menginterogasi sensor? Dan jika Anda perlu membuat keputusan tentang inklusi berdasarkan tren, di mana menyimpan data arsip? Di setiap pemanas? Bukankah itu berani? Di setiap perangkat? Dan mengarahkan lalu lintas dengan setiap permintaan? Dan di mana menyimpan dan bagaimana mengubah logika? Dan apakah logika mencakup elemen eksternal? Dan bagaimana cara menyimpan logika pada perangkat "bodoh"? Dan bagaimana cara memperbaruinya?

Semua masalah ini hilang jika Anda merekonsiliasi diri sendiri dan mengenali perlunya hub pusat sebagai titik interaksi antara data dan lokasi penyimpanan untuk logika pengguna. Biarkan semua perangkat menjadi "bodoh", mampu mengirim data dan menerima perintah, dan tugas menyimpan data arsip, memproses data ini, membuat keputusan dan berinteraksi dengan layanan eksternal akan jatuh pada pengontrol yang sangat sentral.

Omong-omong, desentralisasi dapat dipertahankan, meskipun sebagian: tidak ada yang menghalangi Anda mengirim perintah secara langsung, karena ada mode gagal-aman, tanpa adanya respons dari hub. Tidak akan ada logika, tetapi akan mungkin untuk menyalakan lampu.

---

9. Sistem tidak boleh melakukan tindakan yang berpotensi berbahaya tanpa konfirmasi atau pemberitahuan kepada pengguna.

Selama kita tidak hidup di dunia di mana programmer bertanggung jawab atas kerusakan yang disebabkan oleh programnya (ditulis dengan baik pada topik ini di sini ), akan ada banyak kesalahan dalam program. Mereka akan berada dalam perangkat lunak rumah pintar. Satu-satunya kemungkinan di mana kesalahan-kesalahan ini tidak akan menyebabkan konsekuensi bencana adalah keterbatasan tindakan independen sistem. Tindakan yang berpotensi berbahaya harus dilakukan setidaknya dengan sepengetahuan pengguna, dan lebih baik dengan konfirmasinya. Anda dapat menyalakan lampu secara otomatis: bug dalam program akan menyebabkan pengguna terbangun di malam hari atau menerima faktur untuk seratus rubel tambahan pada akhir bulan. Tidak menyenangkan, tetapi hampir tidak berbahaya. Misalnya, tidak mungkin untuk menyalakan air secara otomatis, jika tidak ada mekanisme yang dijamin untuk mematikannya saat banjir. Tapi matikan air - Anda bisa, karena ini bukan tindakan berbahaya.

Prinsip ini tidak menyatakan bahwa sangat penting untuk melarang kontrol otomatis semua pemanas, ketel, kompor, ceret dan sejenisnya. Sebaliknya, ini tentang fakta bahwa jika Anda sudah membuat perangkat yang berpotensi berbahaya dengan kontrol program, pastikan bahayanya tidak mencapai tingkat pengguna: ketel yang dikontrol harus memiliki sirkuit "besi" yang mematikannya saat kepanasan; bak mandi, yang diisi dengan sendirinya, harus memiliki sensor banjir; setrika harus dapat dimatikan, tetapi nyalakan kembali hanya ketika Anda menekan tombol "setrika", dan seterusnya.

10. Sistem harus dapat mengendalikan diri dan mendiagnosis diri.

Pengembang sistem cerdas sejati harus sedikit paranoid. Anda tidak bisa mempercayai Internet, itu bisa menghilang. Anda tidak dapat mempercayai kode tersebut, mungkin ada bug di dalamnya. Mungkin setidaknya perangkat keras bisa dipercaya? Tidak. Anda tidak bisa mempercayai perangkat keras Anda. Relai dapat menempel, triac terbuka secara spontan, sekering meledak. Akhirnya, pengguna dapat memasukkan ketel kilowatt ke outlet 100 watt. Perlu sensor tegangan, arus, suhu. Apakah suhu di luar kisaran? Matikan semuanya, kirim peringatan. Arus telah melampaui - matikan. Mereka mematikan relay, tetapi apakah masih ada tegangan pada output? Perhatikan. Dihidupkan, tetapi tidak ada tegangan? Perhatikan!

11. Sistem harus dapat dikendalikan secara manual.

Dan bahkan dengan semua hal paranoid ini, masih akan ada situasi di mana cek gagal, dan sesuatu pecah. Beralih di ruangan, router, hub pusat. Dan pengguna ingin menyalakan lampu di toilet. Apa kesimpulannya?

Harus selalu ada tombol yang dapat digunakan untuk membuat "matahari terbenam matahari secara manual." Yang bisa menyalakan atau mematikan lampu SEGERA. Karena mereka akan membawa hub baru besok, Anda dapat membeli sakelar sedikit kemudian, dan Anda ingin mematikan lampu di kamar malam itu untuk tidur nyenyak.

12. Pengembang dan peretas sama pentingnya dengan pengguna biasa.

Pengguna biasa akan membuat Anda menjadi kasir, dan peretas ⁶ - datang dengan fitur baru. Pabrikan tidak dapat dan tidak boleh mengembangkan semua skenario untuk menggunakan sistem, karena jelas tidak memiliki pengetahuan di semua bidang dan tidak dapat mengevaluasi efek pengembangan bidang tersebut. Ada kemungkinan bahwa outlet terkontrol Anda akan menjadi sangat nyaman untuk mengontrol termostat nabati masih, karena ada PID-regulator di perpustakaan solusi, dan sekarang semua penumpang nonton membeli sistem Anda secara massal. Sebuah contoh agak dibuat-buat, tetapi pesan utamanya adalah bahwa dengan mengorbankan beberapa upaya, layak menciptakan lingkungan yang nyaman bagi peretas, karena mereka menambah kekuatan pendorong ke sistem Anda.

13. Keterbukaan: sistem harus memiliki API untuk integrasi dengan sistem lain.

Anda tidak dapat memenuhi semua kebutuhan pelanggan Anda dengan perangkat Anda. Akan selalu ada perangkat yang tidak Anda miliki, tetapi produsen lain memilikinya. Atau Anda memilikinya, tetapi produsen lain lebih baik. Atau Anda akan menjadi produsen yang memiliki unit tunggal terbaik. Diperlukan API yang terbuka dan didokumentasikan dengan baik untuk menghubungkan sistem Anda ke orang lain. Jika Anda tidak memiliki API, Anda menyangkal kemampuan pengguna untuk membangun sistem heterogen. Bahkan perusahaan, pendukung perangkat keras dan perangkat lunak yang paling bersemangat sekalipun, tidak mampu membelinya.

14. Dokumentasi: dokumentasi adalah bagian penting dari sistem seperti kode dan perangkat keras.

Apa pun perangkat keras keren yang Anda miliki dan perangkat lunak keren apa pun yang Anda tulis, tidak masalah jika pengguna tidak mengetahui cara memulai sistem Anda dan cara bekerja dengannya. Dokumentasi yang baik adalah ketika bekerja dengan yang pengguna bahkan tidak memiliki pemikiran untuk menghubungi dukungan atau menilai secara negatif kemampuan mental pengembang. Menulis dokumentasi semacam itu hampir mustahil, tetapi kita harus berusaha keras untuk ini.

Dan akhirnya, prinsip terakhir (tetapi jauh dari yang terakhir dalam hal kepentingan):

15. Kemandirian dan kesinambungan diri: sistem harus terus bekerja, bahkan jika perusahaan berhenti bekerja

Seseorang hidup 70-90 tahun, sistem di rumahnya 5-10 tahun (paling banter), dan perusahaan seringkali lebih kecil. Anda seharusnya tidak membuat suatu sistem, kemampuan untuk bekerja dengan yang Anda seret bersama Anda ke kubur. Kasihan pengguna. Rancang sistem sehingga memungkinkan untuk bekerja dengannya, bahkan jika perusahaan dan pengembang telah lama terlupakan.

Apakah pengikatan perangkat baru terjadi dengan menerima token dari server pengembang? Buat tombol "Lewati token". Ketika Anda menyalakan sistem untuk pertama kalinya, apakah Anda perlu memperbarui firmware dari situs? Pastikan firmware default dibanjiri ketika situs tidak tersedia. Dan sebagainya.

---

Dalam artikel ini saya mencoba menggambarkan semua pengalaman menggunakan, bekerja dan merancang sistem seperti itu, dikompresi menjadi 15 prinsip dasar. Beberapa dari mereka mungkin tampak dibuat-buat, beberapa mungkin kontroversial (dan ini normal), dan beberapa mungkin basi (dan ini juga normal).

Tetapi jika Anda memikirkan setidaknya salah satunya, itu berarti artikel itu ditulis tidak sia-sia.

Catatan kaki dan komentar

1. Ketika saya mengatakan "gunakan", saya tidak bermaksud proses konfigurasi, tetapi proses interaksi normal dengan sistem.
2. Harap dicatat bahwa saya tidak mengatakan "penundaan harus sama", tetapi "pengguna tidak boleh memperhatikan". Latihan menunjukkan bahwa seseorang tidak melihat keterlambatan hingga sekitar 300 ms.
3. Mungkin dia tumbuh di Asia Tengah dan percaya bahwa obat terbaik untuk panas adalah teh hijau panas.
4. Tentu saja, ketika saya mengatakan "tidak perlu menampilkan informasi", ini berarti Anda tidak boleh mengirim pesan kepada pengguna tentang hal itu setiap saat. Itu harus ditampilkan atas permintaan pengguna - dengan mengklik tombol "tampilkan log" atau "tampilkan informasi debug". Pengguna tidak boleh dianggap idiot, tetapi waktu mereka harus dihormati.
5. Tentu saja, tidak mungkin untuk merancang sistem yang mendukung jumlah perangkat yang tak terbatas. Akan selalu ada batasan, tetapi tugas pengembang adalah memastikan bahwa mereka tidak berperan dalam 99% kasus. Batas enam sensor tidak dapat diterima. Seratus dua ratus perangkat dalam satu jaringan adalah jumlah yang cukup untuk sebagian besar pengguna rumah pintar.
6. Saya berbicara tentang peretas dalam arti asli kata tersebut, menurut RFC1983 , dan bukan sebagai peretas.