Seperti yang mereka katakan, jika Anda tidak malu dengan kode lama Anda, maka Anda tidak berkembang sebagai seorang programmer - dan saya setuju dengan pendapat ini. Saya memulai pemrograman untuk bersenang-senang lebih dari 40 tahun yang lalu, dan secara profesional 30 tahun yang lalu, jadi saya memiliki banyak kesalahan. banyak. Sebagai profesor ilmu komputer, saya mengajar siswa saya untuk belajar dari kesalahan—kesalahan mereka, kesalahan saya, dan kesalahan orang lain. Saya pikir sudah waktunya untuk membicarakan kesalahan saya agar tidak kehilangan kerendahan hati. Saya harap mereka akan bermanfaat bagi seseorang.

Tempat ketiga adalah kompiler Microsoft C

Guru sekolah saya percaya bahwa Romeo dan Juliet tidak dapat dianggap sebagai tragedi karena karakternya tidak memiliki rasa bersalah yang tragis - mereka hanya berperilaku bodoh, sebagaimana seharusnya remaja. Saya tidak setuju dengannya saat itu, tetapi sekarang saya melihat ada sedikit rasionalitas dalam pendapatnya, terutama yang berkaitan dengan pemrograman.

Saat saya menyelesaikan tahun kedua saya di MIT, saya masih muda dan belum berpengalaman, baik dalam kehidupan maupun pemrograman. Di musim panas, saya magang di Microsoft, di tim kompiler C. Awalnya saya melakukan hal-hal rutin seperti dukungan pembuatan profil, dan kemudian saya dipercaya untuk mengerjakan bagian paling menyenangkan dari kompiler (seperti yang saya kira) - optimasi backend. Secara khusus, saya harus meningkatkan kode x86 untuk pernyataan cabang.

Bertekad untuk menulis kode mesin yang optimal untuk setiap kasus yang mungkin terjadi, saya langsung terjun ke dalam pool. Jika kepadatan distribusi nilai tinggi, saya memasukkannya ke dalamnya tabel transisi. Jika mereka memiliki pembagi yang sama, saya menggunakannya untuk membuat tabel lebih rapat (tetapi hanya jika pembagian dapat dilakukan dengan menggunakan sedikit pergeseran). Ketika semua nilai adalah pangkat dua, saya melakukan optimasi lagi. Jika sekumpulan nilai tidak memenuhi kondisi saya, saya membaginya menjadi beberapa kasus yang dapat dioptimalkan dan menggunakan kode yang sudah dioptimalkan.

Itu adalah mimpi buruk. Bertahun-tahun kemudian saya diberitahu bahwa programmer yang mewarisi kode saya membenci saya.

Pelajaran yang didapat

Seperti yang ditulis oleh David Patterson dan John Hennessy dalam Computer Architecture and Computer Systems Design, salah satu prinsip utama arsitektur dan desain adalah membuat segala sesuatunya bekerja secepat mungkin.

Mempercepat kasus-kasus umum akan meningkatkan kinerja lebih efektif daripada mengoptimalkan kasus-kasus yang jarang terjadi. Ironisnya, kasus yang umum sering kali lebih sederhana dibandingkan kasus yang jarang terjadi. Nasihat logis ini mengasumsikan bahwa Anda mengetahui kasus mana yang dianggap umum - dan ini hanya mungkin terjadi melalui proses pengujian dan pengukuran yang cermat.

Dalam pembelaan saya, saya mencoba mencari tahu seperti apa pernyataan cabang dalam praktiknya (seperti berapa banyak cabang yang ada dan bagaimana konstanta didistribusikan), namun pada tahun 1988 informasi ini tidak tersedia. Namun, saya seharusnya tidak menambahkan kasus khusus setiap kali kompiler saat ini tidak dapat menghasilkan kode optimal untuk contoh buatan yang saya buat.

Saya perlu menghubungi pengembang berpengalaman dan, bersama dengannya, memikirkan kasus umum dan menanganinya secara spesifik. Saya akan menulis lebih sedikit kode, tapi itu hal yang bagus. Seperti yang ditulis oleh pendiri Stack Overflow, Jeff Atwood, musuh terburuk seorang programmer adalah programmer itu sendiri:

Saya tahu Anda memiliki niat terbaik, begitu pula kita semua. Kami membuat program dan suka menulis kode. Begitulah cara kita dibuat. Kami pikir masalah apa pun dapat diselesaikan dengan lakban, kruk buatan sendiri, dan sedikit kode. Meskipun sulit bagi pembuat kode untuk mengakuinya, kode terbaik adalah kode yang tidak ada. Setiap baris baru memerlukan debugging dan dukungan, ini perlu dipahami. Saat Anda menambahkan kode baru, Anda harus melakukannya dengan enggan dan jijik karena semua opsi lain telah habis. Banyak programmer yang menulis terlalu banyak kode, sehingga menjadikannya musuh kita.

Jika saya menulis kode sederhana yang mencakup kasus-kasus umum, akan lebih mudah untuk memperbaruinya jika perlu. Saya meninggalkan kekacauan yang tidak ingin ditangani oleh siapa pun.

Tempat kedua: beriklan di jejaring sosial

Ketika saya bekerja di Google pada periklanan media sosial (ingat Myspace?), Saya menulis sesuatu seperti ini di C++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Pemrogram mungkin langsung melihat kesalahannya: argumen terakhir seharusnya j, bukan i. Pengujian unit tidak mengungkapkan kesalahannya, begitu pula pengulas saya. Peluncuran dilakukan, dan suatu malam kode saya masuk ke server dan membuat semua komputer di pusat data crash.

Tidak ada hal buruk yang terjadi. Tidak ada yang rusak bagi siapa pun, karena sebelum peluncuran global, kode tersebut diuji dalam satu pusat data. Kecuali para insinyur SRE berhenti bermain biliar untuk sementara waktu dan melakukan sedikit kemunduran. Keesokan paginya saya menerima email dengan crash dump, memperbaiki kode dan menambahkan pengujian unit yang akan menangkap kesalahan. Karena saya mengikuti protokol - jika tidak, kode saya akan gagal dijalankan - tidak ada masalah lain.

Pelajaran yang didapat

Banyak yang yakin bahwa kesalahan besar seperti itu pasti akan menyebabkan pelakunya dipecat, tetapi kenyataannya tidak demikian: pertama, semua programmer melakukan kesalahan, dan kedua, mereka jarang melakukan kesalahan yang sama dua kali.

Faktanya, saya mempunyai seorang teman programmer yang merupakan seorang insinyur yang brilian dan dipecat karena melakukan satu kesalahan. Setelah itu, dia dipekerjakan di Google (dan segera dipromosikan) - dia dengan jujur ​​​​mengatakan kesalahan yang dia buat dalam sebuah wawancara, dan itu tidak dianggap fatal.

Ini dia apa memberi tahu tentang Thomas Watson, kepala IBM yang legendaris:

Perintah pemerintah senilai sekitar satu juta dolar diumumkan. IBM Corporation - atau lebih tepatnya, Thomas Watson Sr. secara pribadi - sangat ingin mendapatkannya. Sayangnya, perwakilan penjualan tidak dapat melakukan hal ini dan IBM kalah dalam penawaran. Keesokan harinya, karyawan ini datang ke kantor Tuan Watson dan meletakkan sebuah amplop di mejanya. Tuan Watson bahkan tidak repot-repot melihatnya - dia sedang menunggu seorang karyawan dan tahu bahwa itu adalah surat pengunduran diri.

Watson bertanya ada apa.

Perwakilan penjualan berbicara secara rinci tentang kemajuan tender. Dia menyebutkan kesalahan yang dilakukan yang sebenarnya bisa dihindari. Akhirnya, dia berkata, “Tuan Watson, terima kasih telah mengizinkan saya menjelaskannya. Saya tahu betapa kami sangat membutuhkan pesanan ini. Saya tahu betapa pentingnya dia,” dan bersiap untuk pergi.

Watson mendekatinya di pintu, menatap matanya dan mengembalikan amplop dengan kata-kata: “Bagaimana saya bisa melepaskanmu? Saya baru saja menginvestasikan satu juta dolar untuk pendidikan Anda.

Saya mempunyai kaus yang bertuliskan: “Jika Anda benar-benar belajar dari kesalahan, maka saya sudah menjadi master.” Faktanya, jika menyangkut kesalahan, saya adalah seorang doktor ilmu pengetahuan.

Tempat pertama: API Penemu Aplikasi

Kesalahan yang benar-benar mengerikan mempengaruhi sejumlah besar pengguna, menjadi pengetahuan umum, membutuhkan waktu lama untuk memperbaikinya, dan dilakukan oleh mereka yang tidak dapat melakukannya. Kesalahan terbesar saya memenuhi semua kriteria ini.

Semakin buruk semakin baik

saya membaca esai oleh Richard Gabriel tentang pendekatan ini pada tahun sembilan puluhan sebagai mahasiswa pascasarjana, dan saya sangat menyukainya sehingga saya menanyakannya kepada siswa saya. Jika Anda kurang mengingatnya dengan baik, segarkan ingatan Anda, itu kecil. Esai ini mengontraskan keinginan untuk “melakukannya dengan benar” dan pendekatan “lebih buruk lebih baik” dalam banyak hal, termasuk kesederhanaan.

Bagaimana seharusnya: desain harus sederhana dalam implementasi dan antarmuka. Kesederhanaan antarmuka lebih penting daripada kesederhanaan implementasi.

Semakin buruk, semakin baik: desainnya harus sederhana dalam implementasi dan antarmuka. Kesederhanaan implementasi lebih penting daripada kesederhanaan antarmuka.

Mari kita lupakan hal itu sebentar. Sayangnya, saya melupakannya selama bertahun-tahun.

Penemu Aplikasi

Saat bekerja di Google, saya adalah bagian dari tim Penemu Aplikasi, lingkungan pengembangan online seret dan lepas untuk calon pengembang Android. Saat itu tahun 2009, dan kami terburu-buru untuk merilis versi alfa tepat waktu sehingga di musim panas kami dapat mengadakan kelas master untuk guru yang dapat memanfaatkan lingkungan saat mengajar di musim gugur. Saya mengajukan diri untuk mengimplementasikan sprite, merindukan bagaimana saya dulu menulis game di TI-99/4. Bagi yang belum tahu, sprite adalah objek grafis dua dimensi yang dapat bergerak dan berinteraksi dengan elemen perangkat lunak lainnya. Contoh sprite termasuk pesawat luar angkasa, asteroid, kelereng, dan raket.

Kami menerapkan App Inventor berorientasi objek di Java, jadi hanya ada banyak objek di sana. Karena bola dan sprite berperilaku sangat mirip, saya membuat kelas sprite abstrak dengan properti (bidang) X, Y, Kecepatan (speed) dan Heading (arah). Mereka memiliki metode yang sama untuk mendeteksi tabrakan, pantulan dari tepi layar, dll.

Perbedaan utama antara bola dan sprite adalah apa sebenarnya yang digambar - lingkaran terisi atau raster. Karena saya pertama kali mengimplementasikan sprite, logis untuk menentukan koordinat x dan y di sudut kiri atas tempat gambar berada.

Setelah sprite berfungsi, saya memutuskan bahwa saya dapat mengimplementasikan objek bola dengan sedikit kode. Satu-satunya masalah adalah saya mengambil rute paling sederhana (dari sudut pandang pelaksana), menunjukkan koordinat x dan y dari sudut kiri atas kontur yang membingkai bola.

Faktanya, koordinat x dan y dari pusat lingkaran perlu ditunjukkan, seperti yang diajarkan dalam buku teks matematika mana pun dan sumber lain yang menyebutkan lingkaran.

Berbeda dengan kesalahan saya sebelumnya, kesalahan ini tidak hanya berdampak pada kolega saya, namun juga jutaan pengguna App Inventor. Banyak dari mereka adalah anak-anak atau baru mengenal pemrograman. Mereka harus melakukan banyak langkah yang tidak perlu saat mengerjakan setiap aplikasi yang berisi bola. Jika saya mengingat kesalahan saya yang lain dengan tertawa, maka kesalahan ini membuat saya berkeringat bahkan sampai hari ini.

Saya akhirnya menambal bug ini baru-baru ini, sepuluh tahun kemudian. “Ditambal”, bukan “diperbaiki”, karena seperti yang dikatakan Joshua Bloch, API bersifat abadi. Tidak dapat membuat perubahan yang akan mempengaruhi program yang ada, kami menambahkan properti OriginAtCenter dengan nilai false di program lama dan true di semua program mendatang. Pengguna mungkin mengajukan pertanyaan logis: siapa yang berpikir untuk menempatkan titik awal di tempat lain selain pusat. Kepada siapa? Kepada seorang programmer yang terlalu malas untuk membuat API normal sepuluh tahun yang lalu.

Pelajaran yang Dipetik

Saat mengerjakan API (yang terkadang harus dilakukan oleh hampir setiap programmer), Anda harus mengikuti saran terbaik yang diuraikan dalam video Joshua Bloch "Cara membuat API yang baik dan mengapa itu sangat penting"Atau dalam daftar singkat ini:

• API dapat memberi Anda manfaat besar dan kerugian besar.. API yang baik menciptakan pelanggan tetap. Yang buruk menjadi mimpi buruk abadi Anda.
• API publik, seperti berlian, bertahan selamanya. Berikan segalanya: tidak akan pernah ada kesempatan lagi untuk melakukan segalanya dengan benar.
• Garis besar API harus singkat — satu halaman dengan tanda tangan dan deskripsi kelas dan metode, tidak lebih dari satu baris. Ini akan memudahkan Anda merestrukturisasi API jika pertama kali hasilnya tidak sempurna.
• Jelaskan kasus penggunaansebelum mengimplementasikan API atau bahkan mengerjakan spesifikasinya. Dengan cara ini Anda akan menghindari penerapan dan penentuan API yang sepenuhnya tidak berfungsi.

Jika saya menulis sinopsis singkat dengan naskah buatan, kemungkinan besar saya akan mengidentifikasi kesalahannya dan memperbaikinya. Jika tidak, maka salah satu rekan saya pasti akan melakukannya. Keputusan apa pun yang memiliki konsekuensi luas perlu dipikirkan setidaknya selama satu hari (ini tidak hanya berlaku untuk pemrograman).

Judul esai Richard Gabriel, "Lebih Buruk Lebih Baik", mengacu pada keuntungan menjadi yang pertama memasuki pasar—bahkan dengan produk yang tidak sempurna—sementara orang lain menghabiskan waktu lama untuk mengejar produk yang sempurna. Berkaca pada kode sprite, saya menyadari bahwa saya bahkan tidak perlu menulis kode lagi untuk melakukannya dengan benar. Apapun yang orang katakan, saya salah besar.

Kesimpulan

Pemrogram membuat kesalahan setiap hari, baik itu menulis kode yang bermasalah atau tidak ingin mencoba sesuatu yang akan meningkatkan keterampilan dan produktivitas mereka. Tentu saja, Anda bisa menjadi seorang programmer tanpa melakukan kesalahan serius seperti yang saya lakukan. Namun tidak mungkin menjadi programmer yang baik tanpa menyadari kesalahan Anda dan belajar darinya.

Saya terus-menerus menjumpai siswa yang merasa mereka membuat terlalu banyak kesalahan dan oleh karena itu tidak cocok untuk pemrograman. Saya tahu betapa umum sindrom penipu di bidang TI. Saya harap Anda akan mempelajari pelajaran yang telah saya sebutkan - tetapi ingat yang utama: kita masing-masing membuat kesalahan - memalukan, lucu, mengerikan. Saya akan terkejut dan kesal jika di kemudian hari saya tidak memiliki cukup bahan untuk melanjutkan artikel tersebut.

Sumber: www.habr.com