Sasaran lebih penting daripada kode

Program tersebut memiliki tujuan yang terkadang terlupakan

Gambar palu tergeletak di papan tulis. Sekrup terjebak di papan, yang mereka cetak keras di sana

Tampaknya programmer lupa tentang tujuan perangkat lunak - untuk memecahkan masalah dunia nyata.

50 tahun yang lalu, pada tahun 1968, sebuah konferensi kerja tentang rekayasa perangkat lunak diselenggarakan oleh Komite Sains NATO. Kemudian mereka mulai memperhatikan bahwa perangkat lunak menjadi bagian fundamental masyarakat. Dan pada saat yang sama menjadi lebih sulit untuk dipahami. Setelah konferensi ini, pemrograman mulai berubah menjadi industri nyata. Itu mulai keluar dari kendali bisnis.

Terlepas dari nasib industri, masih ada masalah dengan pemisahan pengembangan bisnis dan perangkat lunak - atau "rekayasa", seperti yang pertama kali diumumkan pada konferensi tersebut. Jika pemrogram fokus terlalu sempit pada pengembangan, mereka mungkin kehilangan tujuan untuk program yang sedang dibuat. Mereka mungkin kehilangan solusi tersembunyi yang tidak memerlukan kode sama sekali.

Berikut ini sebuah contoh.

Satu startup menciptakan perangkat yang membuka pintu ke rumah melalui Bluetooth. Antarmuka grafis untuk komunikasi dengan perangkat - widget di layar ponsel yang terkunci. Dia memiliki satu tombol yang disebut "Buka pintu."

Ketika pengguna mendekati rumah, ia mengambil telepon, menemukan widget dan menekan tombol.

Seseorang melihat mekanik ini dan bertanya:

Jika kita menggunakan Bluetooth dan berasumsi bahwa pemilik ponsel dapat memasuki rumah, mengapa memaksanya untuk mendapatkan telepon dan menekan tombol? Biarkan pintu membuka sendiri ketika ponsel berada dalam radius 1 meter. Tidak perlu membuang waktu untuk desain dan kode GUI!

Ini adalah contoh luar biasa dari fokus sempit: tujuannya adalah membuka kunci dengan sedikit usaha. Tidak masuk akal untuk membuat antarmuka grafis jika sensornya nirkabel.

Jika Anda mengetahui tantangan bisnis dan kebutuhan pengguna, Anda dapat menggabungkan pengetahuan ini dengan pengetahuan Anda tentang teknologi. Hanya dengan demikian Anda akan memiliki informasi yang cukup untuk menghasilkan solusi yang lebih baik dan memahami bahwa program tidak memerlukan antarmuka.

Sebuah contoh yang bagus tentang bagaimana menyelesaikan masalah perangkat lunak tanpa satu baris kode baru , selain kode untuk benar-benar membuka kunci. Tapi seperti tugas teknis , tidak ada yang bisa membenarkan pemrograman yang tidak perlu dari yang lainnya.

Tidak setiap kode layak ditulis.

Terkadang memperbaiki bug yang serius bukanlah tugas utama. Jika Anda pertukaran mata uang kripto dan sistem mengizinkan satu setoran ganda , intervensi manusia mungkin menjadi solusi terbaik dalam hal rasio biaya-manfaat jika biaya solusinya tinggi.

Pertukaran antara Pentingnya dan Prioritas ini mengingatkan saya pada model yang baru-baru ini diperlihatkan oleh seorang rekan . Ini disebut matriks prioritas - model dua dimensi yang dapat digunakan untuk memprioritaskan bug berdasarkan tingkat keparahan dan jumlah pengguna yang terpengaruh.


Matriks prioritas dua dimensi. Sumbu vertikal mewakili jumlah "korban" dengan nilai "satu," "beberapa," dan "semua." Sumbu horizontal mewakili "keseriusan" dengan nilai-nilai "kosmetik," "tidak nyaman," dan "berhenti bekerja." Prioritas bug ditentukan oleh posisi pada sumbu. Misalnya, jika kesalahannya kosmetik dan memengaruhi satu pengguna, prioritasnya adalah 4 (minimum). Jika bug menghentikan beberapa pengguna, prioritasnya adalah 1. Jika itu menghentikan semua pengguna, ia memiliki prioritas tertinggi.

Masalah setoran ganda yang disebutkan di atas termasuk dalam kategori ketidaknyamanan yang memengaruhi satu pengguna . Karena itu, prioritas 3.

Tidak setiap bug layak diperbaiki.

Pengembang sering berupaya untuk meramalkan semua kasus. Tetapi beberapa tugas berulang mungkin tidak pantas diotomatisasi. Tidak perlu membuang waktu menulis skrip jika pengetahuan penting tentang pekerjaan tim utama disembunyikan.

Ada perbedaan antara enkapsulasi logika kompleks dan abstraksi pengetahuan yang bermanfaat. Terkadang hanya informasi yang jelas yang dapat dipahami. Jika kita abstrak, maka kita bisa mendapatkan efek sebaliknya: pemahaman itu sulit.

Lebih bermanfaat menggunakan beberapa jenis perintah tingkat rendah di CLI daripada perintah tingkat lebih tinggi dengan pengetahuan abstrak, seperti alias Git .

Tidak semua tim layak mendapatkan deskripsi.

Beberapa tahun yang lalu saya mengerjakan sebuah proyek dengan pengiriman tambahan . Itu adalah sistem verifikasi identitas yang meminta pengguna untuk memberikan beberapa data pribadi untuk verifikasi oleh pihak ketiga.

Dan di sana tim ingin menyandikan satu fungsi validasi lapangan yang tidak biasa. Namun, validasi ini didorong kembali pada masing-masing perkebunan ketika tenggat waktu mendekat. Pada akhirnya, mereka memutuskan bahwa fungsi yang tidak biasa ini tidak masuk akal sama sekali.

Dan inilah alasannya: validasi sudah dipaksakan!

Memberikan informasi yang andal adalah demi kepentingan pengguna. Jika dia memberikan data yang salah, mereka tidak akan lulus verifikasi dan dia tidak akan dapat menggunakan sistem. Selain itu, sebagian besar browser mendukung validasi HTML standar yang cukup baik.

Dalam kasus terburuk, jika pengguna tidak dapat diverifikasi, maka ia akan memanggil dukungan untuk verifikasi manual.

Tidak setiap fungsi layak dikodekan

Jika Anda memahami inti dari masalah yang sedang dipecahkan, maka sebagai pengembang Anda dapat menemukan kode yang lebih baik, dan terkadang Anda dapat melakukannya tanpa kode sama sekali. Anda bukan byldoder yang dibayar untuk menulis baris untuk tugas tersebut. Anda adalah seorang profesional yang dibayar untuk menyelesaikan masalah.

Tapi tidak perlu untuk memecahkan masalah dengan teknologi tanpa berpikir, seolah-olah kode program adalah solusi universal untuk semuanya. Jika tidak, Anda akan mengalami masalah dalam memahami kebutuhan klien dan menghasilkan ide-ide hebat.

Tujuan Anda dan tugas kode adalah untuk menciptakan nilai dan menjadikan dunia tempat yang lebih baik, dan bukan untuk memuaskan gagasan egosentris Anda tentang bagaimana dunia seharusnya.

Ada pepatah: "Jika Anda hanya memiliki palu, semuanya menjadi seperti paku."

Lebih baik pertama-tama melihat paku untuk mempertimbangkan kebutuhan akan palu.

Jika Anda benar-benar harus memalu paku ini.