Programmer sepertinya sudah lupa tujuan sebenarnya dari perangkat lunak ini untuk menyelesaikan masalah nyata.
50 tahun yang lalu, pada tahun 1968, sebuah
konferensi kerja tentang rekayasa perangkat lunak diselenggarakan, yang diselenggarakan dengan dukungan dari Komite Ilmu Pengetahuan NATO. Pada saat itu, orang-orang mulai memperhatikan bahwa perangkat lunak menjadi bagian mendasar dari masyarakat. Namun, itu juga menjadi terlalu sulit untuk dipahami. Setelah konferensi ini, pemrograman telah menjadi industri. Dan itu mulai menjauh dari mengendalikan orang-orang bisnis.
Tidak peduli bagaimana pemrograman telah berjalan sejak saat itu, masih ada masalah dengan pemisahan antara pengembangan bisnis dan perangkat lunak - atau "ENGINEERING," sebagaimana konferensi pertama menyebutnya. Jika pengembang terlalu fokus pada pengembangan, mereka mungkin kehilangan tujuan dari perangkat lunak yang mereka tulis. Mereka mungkin tidak melihat solusi tersembunyi yang tidak memerlukan kode apa pun.
Berikut ini sebuah contoh.
Ada startup yang menciptakan perangkat yang memungkinkan seseorang untuk membuka pintu rumahnya melalui Bluetooth. Widget digunakan sebagai antarmuka visual, yang terlihat bahkan ketika ponsel terkunci. Dia memiliki satu tombol yang disebut "Buka pintu."
Ketika pengguna mendekati rumah, ia mengambil telepon, menemukan widget dan kemudian menekan tombol untuk membuka pintu.
Seseorang melihatnya dan bertanya:
Jika kita menggunakan Bluetooth dan model bisnis kita memungkinkan siapa saja yang memiliki telepon masuk ke rumah, mengapa kita harus memaksa seseorang untuk mengambil telepon dan menekan tombol? Biarkan pintu terbuka ketika perangkat mendekati 1 meter. Jadi, kita tidak perlu membayar untuk pengembangan dan pemrograman antarmuka visual!
Kisah Bluetooth ini adalah contoh hebat dari fokus sempit: tujuannya adalah membuka pintu dengan sedikit usaha. Tidak masuk akal untuk mengembangkan antarmuka visual jika sensornya nirkabel.
Jika Anda tahu tujuan apa yang ingin dicapai oleh bisnis dan apa yang bernilai bagi pengguna, maka Anda dapat menggabungkan pengetahuan ini dengan pengetahuan Anda tentang teknologi. Hanya dengan begitu Anda akan memiliki informasi yang cukup untuk menghasilkan jawaban terbaik dan menyimpulkan bahwa produk tersebut tidak memerlukan antarmuka.
Ini adalah contoh yang bagus tentang bagaimana menyelesaikan masalah teknis tanpa harus menulis kode tambahan selain kode buka kunci. Namun, seperti dengan
Tech Debt ,
tidak ada yang bisa membenarkan penulisan kode menyebalkan.
Tidak setiap kode layak ditulis.
Terkadang memperbaiki kesalahan serius mungkin bukan prioritas. Jika Anda memiliki pertukaran mata uang kripto dan sistem telah melakukan pembayaran yang sama dua kali, intervensi manusia mungkin merupakan solusi terbaik dalam hal biaya dan manfaat, jika biaya penyelesaian masalah ini tinggi.
Pertukaran antara Keseriusan dan Prioritas ini mengingatkan saya pada model yang baru saja ditunjukkan oleh
rekan saya. Ini disebut "Matriks Prioritas", model dua dimensi yang dapat digunakan untuk memprioritaskan kesalahan berdasarkan jumlah pengguna yang mereka pengaruhi dan tingkat keparahannya.
Masalah setoran ulang yang dijelaskan di atas termasuk dalam kategori ketidaknyamanan yang memengaruhi satu pengguna. Karena itu, prioritas 3.
Tidak setiap bug layak diperbaiki.
Ini adalah hal yang sangat umum ketika pengembang mencoba menulis naskah untuk semuanya. Namun, beberapa tugas berulang tidak diotomatisasi. Anda tidak perlu menghabiskan waktu memprogram skrip jika Anda ingin menyembunyikan pengetahuan yang diperlukan tentang cara kerja tim utama.
Ada perbedaan antara enkapsulasi logika kompleks dan abstraksi pengetahuan yang bermanfaat. Terkadang informasi perlu dibuat jelas. Jika Anda abstrak mereka, mereka mungkin memiliki efek sebaliknya dan akan lebih sulit untuk dipahami.
Lebih bermanfaat menggunakan beberapa jenis perintah tingkat rendah di CLI daripada perintah tingkat tinggi yang abstrak pengetahuan, seperti
Git .
Beberapa tahun yang lalu saya mengerjakan sebuah proyek menggunakan
pengiriman tambahan . Itu adalah sistem verifikasi identitas yang mengharuskan pengguna untuk menyediakan beberapa data pribadi untuk verifikasi oleh penyedia pihak ketiga.
Ini adalah fitur validasi bidang khusus yang ingin dibuat tim. Namun, sejarah audit diprioritaskan dalam perencanaan setiap sprint, karena tenggat waktu semakin dekat. Pada akhirnya, tim menemukan bahwa tidak ada gunanya memiliki validasi aneh sama sekali.
Dan inilah sebabnya: verifikasi itu wajib!
Adalah kepentingan pengguna untuk memberikan informasi yang andal. Jika pengguna memberikan data yang salah, mereka tidak akan diverifikasi dan mereka tidak akan dapat menggunakan sistem. Selain itu, sebagian besar browser mendukung validasi HTML standar, yang cukup bagus.
Dalam skenario terburuk, pengguna yang tidak dapat memverifikasi diri mereka sendiri dapat menghubungi dukungan untuk memeriksa semuanya secara manual.
Tidak setiap fungsi layak diprogram.
Jika Anda seorang pengembang dan Anda memahami masalah yang Anda coba selesaikan, Anda dapat menemukan kode yang lebih baik, dan kadang-kadang Anda dapat mengatasi tanpa kode sama sekali. Anda bukan "
Kode Monyet " yang dibayar untuk menulis karakter di layar. Anda adalah seorang profesional yang dibayar untuk menyelesaikan masalah.
Namun, jika Anda mencoba menyelesaikan semua masalah dengan bantuan teknologi, tanpa pikir panjang, Anda akan mengalami masalah dalam memahami apa yang berharga bagi klien dan menghasilkan ide-ide hebat.
Tujuan Anda dan tujuan kode yang Anda tulis adalah untuk menciptakan nilai dan membuat dunia yang ada menjadi tempat yang lebih baik, dan tidak memuaskan pandangan egosentris Anda tentang bagaimana dunia seharusnya.
Ada pepatah: "Jika Anda hanya memiliki palu, semuanya terlihat seperti paku."
Lebih baik memiliki kuku terlebih dahulu sehingga Anda dapat mempertimbangkan kebutuhan akan palu.
Artinya, jika Anda membutuhkan paku terlebih dahulu.
Terima kasih sudah membaca artikelnya!
Jika saya memiliki kesalahan dalam terjemahan, silakan tulis di komentar!
Lihat juga situs saya untuk akses cepat ke pertanyaan dan jawaban javascript -
Pertanyaan dan Jawaban JavaScript
Saya akan sangat berterima kasih dan berterima kasih kepada Anda)
Saya di
twitter dan
vkTerima kasih banyak atas perhatiannya!