Seperti kata pepatah, jika Anda tidak malu dengan kode lama Anda, maka Anda tidak tumbuh sebagai seorang programmer - dan saya setuju dengan pendapat ini. Saya mulai pemrograman untuk hiburan lebih dari 40 tahun yang lalu, dan 30 tahun yang lalu secara profesional, jadi saya mendapatkan banyak kesalahan. Sebagai seorang profesor ilmu komputer, saya mengajar siswa saya bagaimana belajar dari kesalahan - kesalahan mereka, milik saya, orang asing. Saya pikir sudah waktunya untuk berbicara tentang kesalahan saya agar tidak kehilangan kesederhanaan. Saya harap seseorang akan merasakan manfaatnya.

Tempat ketiga - kompiler Microsoft C

Guru sekolah saya percaya bahwa Romeo dan Juliet tidak boleh dianggap sebagai tragedi, karena para pahlawan tidak memiliki rasa bersalah yang tragis - mereka hanya berperilaku bodoh, sebagaimana remaja seharusnya. Kemudian saya tidak setuju dengannya, tetapi sekarang saya melihat bahwa menurutnya kernel yang rasional - terutama yang berhubungan dengan pemrograman.

Pada saat saya menyelesaikan tahun kedua saya di MIT, saya masih muda dan tidak berpengalaman, baik dalam kehidupan maupun dalam pemrograman. Di musim panas, saya melakukan praktik di Microsoft, di tim compiler C. Awalnya saya terlibat dalam rutinitas seperti dukungan profil, dan kemudian saya dipercayakan dengan pekerjaan pada bagian paling menyenangkan (seperti yang saya pikir) dari kompiler - optimasi backend. Secara khusus, saya harus meningkatkan kode x86 untuk pernyataan percabangan.

Bertekad untuk menulis kode mesin optimal untuk setiap kasus yang mungkin, saya bergegas ke kolam dengan kepala saya. Jika kepadatan distribusi nilai tinggi, saya memasukkannya di tabel transisi . Jika mereka memiliki pembagi umum, saya menggunakannya untuk membuat tabel lebih padat (tetapi hanya jika pembagian dapat dilakukan menggunakan sedikit shift ). Ketika semua nilai adalah kekuatan dua, saya melakukan optimasi lain. Jika set nilai tidak memenuhi persyaratan saya, saya membaginya menjadi beberapa kasus yang dapat dioptimalkan dan menggunakan kode yang sudah dioptimalkan.

Itu adalah mimpi buruk. Setelah bertahun-tahun, mereka mengatakan kepada saya bahwa programmer yang mewarisi kode saya membenciku.

Pelajaran yang dipetik

Seperti yang ditulis oleh David Patterson dan John Hennessy dalam buku Arsitektur Komputer dan Desain Sistem Komputer, salah satu prinsip utama arsitektur dan pengembangan adalah bahwa secara umum, semuanya bekerja secepat mungkin.

Mempercepat kasus umum akan meningkatkan produktivitas lebih efisien daripada mengoptimalkan kasus yang jarang terjadi. Ironisnya, kasus-kasus umum seringkali lebih sederhana daripada jarang. Nasihat logis ini menyiratkan bahwa Anda tahu kasus mana yang dianggap umum - dan ini hanya mungkin dilakukan melalui pengujian dan pengukuran yang cermat.

Dalam pembelaan saya, saya dapat mengatakan bahwa saya mencoba mencari tahu seperti apa operator cabang dalam praktik (misalnya, berapa banyak cabang yang ada dan bagaimana konstanta didistribusikan), tetapi 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 memanggil pengembang yang berpengalaman dan bersamanya untuk memikirkan apa saja kasus yang umum, dan menangani secara khusus. Saya akan menulis lebih sedikit kode, tetapi itu bahkan bagus. Seperti yang ditulis oleh pendiri Stack Overflow, Jeff Atwood, musuh terburuk programmer adalah programmer:

Saya tahu Anda memiliki niat terbaik, seperti yang kita semua miliki. Kami membuat program dan suka menulis kode. Jadi kita diatur. Kami berpikir bahwa masalah apa pun dapat diselesaikan dengan pita, kruk buatan sendiri dan sedikit kode. Tidak peduli betapa menyakitkannya bagi coders untuk mengakui hal ini, kode terbaik adalah kode yang tidak ada. Setiap baris baru perlu debugging dan dukungan, itu harus dipahami. Saat menambahkan kode baru, Anda harus melakukannya dengan enggan dan jijik, karena semua opsi lain telah habis. Banyak programmer menulis terlalu banyak kode, menjadikannya musuh kami.

Jika saya menulis kode sederhana yang membahas kasus-kasus umum, maka akan jauh lebih mudah untuk memperbarui jika perlu. Saya meninggalkan kekacauan yang tidak seorang pun ingin mengacaukannya.

Tempat Kedua: Iklan Media Sosial

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

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 dapat segera melihat kesalahan: argumen terakhir harus j, bukan i. Pengujian unit tidak mengungkapkan kesalahan, dan reviewer saya juga tidak menyadarinya. Peluncuran dibuat, dan suatu malam kode saya pergi ke server dan menabrak semua komputer di pusat data.

Tidak ada yang mengerikan terjadi. Tidak ada yang rusak, karena sebelum peluncuran global, kode diuji dalam pusat data yang sama. Kecuali jika insinyur SRE berhenti bermain biliar untuk sementara waktu dan melakukan rollback kecil. Pagi berikutnya saya menerima email dengan crash dump, memperbaiki kode, dan menambahkan tes unit yang akan mengungkapkan kesalahan. Karena saya mengikuti protokol - jika tidak kode saya tidak akan berjalan - tidak ada masalah lain.

Pelajaran yang dipetik

Banyak yang yakin bahwa kesalahan besar semacam itu tentu merupakan penyebab pemecatan, tetapi tidak demikian: pertama, semua programmer salah, dan kedua, mereka jarang membuat satu kesalahan dua kali.

Sebenarnya, saya memiliki programmer yang sudah dikenal - seorang insinyur yang brilian, yang dipecat karena satu kesalahan. Setelah itu, dia disewa oleh Google (dan segera dipromosikan) - dia jujur ​​berbicara tentang kesalahan yang dibuat dalam wawancara, dan dia tidak dianggap fatal.

Inilah yang dikatakan Thomas Watson, kepala IBM yang legendaris:

Perintah pemerintah senilai sekitar satu juta dolar diumumkan. IBM Corporation - atau lebih tepatnya, secara pribadi Thomas Watson Sr. - benar-benar ingin mendapatkannya. Sayangnya, perwakilan penjualan tidak bisa melakukan ini, dan IBM kehilangan tender. Hari berikutnya, petugas ini datang ke kantor Tuan Watson dan meletakkan sebuah amplop di atas mejanya. Mr. Watson bahkan tidak memandangnya - dia sedang menunggu seorang karyawan dan tahu bahwa ini adalah surat pengunduran diri.

Watson bertanya apa yang salah.

Perwakilan penjualan menjelaskan secara rinci perkembangan tender. Dia menyebut kesalahan yang bisa dihindari. Akhirnya, dia berkata, “Tuan Watson, terima kasih telah mengizinkan saya menjelaskan. Saya tahu betapa kami membutuhkan pesanan ini. Saya tahu betapa pentingnya dia, ”dan akan pergi.

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

Saya memiliki T-shirt yang mengatakan: "Jika Anda benar-benar belajar dari kesalahan, maka saya sudah menjadi master." Bahkan, sejauh menyangkut kesalahan, saya seorang Doktor Ilmu Pengetahuan.

Tempat Pertama: API Penemu Aplikasi

Kesalahan yang benar-benar menyeramkan memengaruhi sejumlah besar pengguna, menjadi publik, sudah lama diperbaiki dan dilakukan oleh mereka yang tidak bisa mengizinkannya. Kesalahan terbesar saya memenuhi semua kriteria ini.

Semakin buruk semakin baik

Saya membaca esai Richard Gabriel tentang pendekatan ini di tahun sembilan puluhan sebagai mahasiswa pascasarjana, dan saya sangat menyukainya sehingga saya memintanya kepada siswa saya. Jika Anda tidak mengingatnya dengan baik, segarkan ingatan Anda, itu kecil. Dalam esai ini, keinginan untuk "melakukannya dengan benar" dan pendekatan "semakin buruk semakin baik" dikontraskan dalam banyak hal, termasuk kesederhanaan.

Sebagaimana mestinya: desain harus mudah diimplementasikan dan antarmuka. Kesederhanaan antarmuka lebih penting daripada kesederhanaan implementasi.

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

Lupakan sejenak. Sayangnya, saya lupa tentang itu selama bertahun-tahun.

Penemu aplikasi

Sementara di Google, saya adalah bagian dari tim Penemu Aplikasi , lingkungan pengembangan online dengan dukungan seret dan lepas untuk pengembang Android pemula. Saat itu tahun 2009, dan kami sedang terburu-buru untuk merilis versi alpha pada waktunya, sehingga di musim panas kami dapat mengadakan kelas master untuk guru yang dapat menggunakan lingkungan belajar di musim gugur. Saya mengajukan diri untuk menerapkan sprite, nostalgia untuk bagaimana saya dulu menulis game di TI-99/4. Bagi mereka yang tidak tahu: sprite adalah objek grafis dua dimensi yang dapat bergerak dan berinteraksi dengan elemen program lainnya. Contoh sprite adalah pesawat ruang angkasa, asteroid, bola, dan raket.

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

Perbedaan utama antara bola dan sprite adalah persis apa yang digambar - lingkaran penuh atau raster. Sejak saya pertama kali mengimplementasikan sprite, adalah logis untuk menentukan koordinat x dan y dari sudut kiri atas tempat di mana gambar itu berada.


Ketika sprite mulai bekerja, saya memutuskan bahwa Anda dapat mengimplementasikan objek bola dengan kode yang sangat sedikit. Satu-satunya masalah adalah bahwa saya menggunakan cara yang paling sederhana (dari sudut pandang pelaksana), menunjukkan koordinat x dan y dari sudut kiri atas kontur yang mengelilingi bola.


Bahkan, perlu untuk menunjukkan koordinat x dan y dari pusat lingkaran, sebagaimana buku teks matematika dan sumber lain yang menyebutkan lingkaran mengajar.


Tidak seperti kesalahan masa lalu saya, tidak hanya rekan kerja saya, tetapi juga jutaan pengguna App Inventor menderita ini. Banyak dari mereka adalah anak-anak atau benar-benar baru dalam pemrograman. Mereka harus melakukan banyak tindakan yang tidak perlu ketika mengerjakan setiap aplikasi di mana bola hadir. Jika sisa kesalahan saya, saya ingat dengan tawa, maka ini membuat saya berkeringat hari ini.

Saya akhirnya memperbaiki kesalahan ini hanya baru-baru ini, sepuluh tahun kemudian. "Ditambal", tetapi tidak "diperbaiki", karena seperti yang dikatakan Joshua Bloch, API itu abadi. Tidak dapat membuat perubahan yang akan memengaruhi program yang ada, kami menambahkan properti OriginAtCenter dengan false di program lama dan benar di semua yang akan datang. Pengguna dapat mengajukan pertanyaan yang sah kepada siapa hal itu terjadi kepada siapa saja untuk menemukan titik referensi di tempat lain selain pusat. Kepada siapa? Seorang programmer yang terlalu malas untuk membuat API normal sepuluh tahun yang lalu.

Pelajaran yang dipetik

Saat mengerjakan API (yang hampir setiap programmer terkadang harus lakukan), Anda harus mengikuti kiat terbaik yang diuraikan dalam video Joshua Bloch " Cara membuat API yang baik dan mengapa itu sangat penting " atau dalam daftar pendek ini :

• API dapat sangat bermanfaat bagi Anda, juga sangat merugikan . API yang baik menciptakan pelanggan yang loyal. Bad menjadi mimpi buruk abadi Anda.
  
• API publik, seperti berlian, bersifat abadi . Cobalah yang terbaik: tidak ada kesempatan lain untuk melakukan semuanya sebagaimana mestinya.
  
• Jadwal untuk API harus pendek - satu halaman dengan tanda tangan kelas dan metode dan deskripsi yang tidak lebih dari satu baris. Ini akan memungkinkan Anda untuk dengan mudah merestrukturisasi API, jika pertama kali keluar tidak sempurna.
  
• Jelaskan skenario penggunaan sebelum Anda menerapkan API dan bahkan bekerja pada spesifikasinya. Dengan cara ini Anda menghindari implementasi dan spesifikasi API yang sepenuhnya tidak berfungsi.
  

Jika saya menulis setidaknya sinopsis kecil dengan skrip buatan, kemungkinan besar saya akan mengidentifikasi kesalahan dan memperbaikinya. Jika tidak, maka salah satu rekan saya pasti akan melakukannya. Keputusan apa pun yang memiliki konsekuensi luas harus dipertimbangkan setidaknya sehari (ini berlaku tidak hanya untuk pemrograman).

Judul esai Richard Gabriel, "The Worse, the Better," menunjukkan keuntungan yang datang pertama ke pasar - bahkan dengan produk yang tidak sempurna - sementara orang lain telah mengejar cita-cita selama berabad-abad. Memikirkan kode sprite, saya mengerti bahwa saya bahkan tidak perlu menulis lebih banyak kode untuk melakukan semuanya sebagaimana mestinya. Suka atau tidak suka, saya salah besar.

Kesimpulan

Pemrogram membuat kesalahan setiap hari - apakah itu menulis kode dengan bug atau tidak ingin mencoba sesuatu yang akan meningkatkan keterampilan dan produktivitas mereka. Tentu saja, Anda bisa menjadi programmer dan tidak membiarkan kesalahan serius seperti yang saya lakukan. Tetapi menjadi programmer yang baik tanpa menyadari kesalahan Anda dan tidak belajar dari mereka adalah hal yang mustahil.

Saya terus-menerus bertemu dengan siswa yang berpikir bahwa mereka membuat terlalu banyak kesalahan dan karenanya tidak dirancang untuk pemrograman. Saya tahu seberapa umum sindrom peniru di IT. Saya harap Anda mempelajari pelajaran yang telah saya daftarkan - tetapi ingat yang utama: kita masing-masing membuat kesalahan - memalukan, lucu, menakutkan. Saya akan terkejut dan kesal jika di masa depan saya tidak memiliki cukup bahan untuk melanjutkan artikel.