Kekuatan pemrograman malas

Siapapun yang berkata bekerja keras adalah kebajikan jangan pernah bertemu dengan programmer. Ya, penggali parit yang bekerja keras membuat parit yang lebih panjang daripada mereka yang melamun, dan petani yang bersandar ke bajak menanam lebih banyak makanan daripada mereka yang menatap ke langit. Tetapi pemrograman tidaklah sama. Tidak ada hubungan linier antara keringat di alis dan kepuasan pengguna.

Terkadang membantu jika programmer bekerja semalaman, tetapi lebih sering daripada tidak lebih baik bagi programmer untuk menjadi pintar - dan malas. Para pengkode yang mengabaikan tanda-tanda dinding yang "bekerja keras, tetap rendah hati" sering kali memberikan hasil yang luar biasa, semua karena mereka berusaha untuk menghindari keharusan bekerja terlalu keras. Para jenius sejati menemukan cara untuk melakukan minimum absolut dengan melepaskan tugas-tugas mereka ke komputer. Lagi pula, membuat komputer melakukan pekerjaan itu adalah tugas nyata pemrogram komputer.

Berikut adalah 13 teknik dan alat yang membuktikan kekuatan pemrograman malas. Lain kali bos memberi tahu Anda bahwa inilah waktunya untuk menyingsingkan lengan baju Anda dan bersandar ke konsol, pergilah ke ruang tidur siang sebagai gantinya.

Evaluasi malas

Di suatu tempat, pemrogram cerdas menyadari perangkat lunak mereka akan berjalan lebih cepat jika tidak menghitung dengan patuh setiap bagian ekspresi. Fitur ini, terkadang disebut sebagai "panggilan berdasarkan kebutuhan" atau "evaluasi malas", sekarang secara resmi menjadi bagian dari bahasa pemrograman seperti Haskell, F #, dan Python 3.0.

Contoh paling sederhana adalah penggunaan strategi dalam memeriksa pointer nol. Objek xdiperiksa menjadi bukan-null sebelum rutinitas kalkulasi dimulai dalam pernyataan ini:

if (x && x.calculation()) then …

Menguji keberadaan xmencegah crashing. Dalam contoh yang lebih rumit, evaluasi malas menyimpan kalkulasi dalam jumlah tak terbatas yang akan dibuang dengan melihat ke depan untuk melihat kapan pohon komputasi dapat dipangkas. Jika tes cepat adalah yang pertama dijalankan, ini dapat menghemat satu miliar siklus kemudian. Ketika struktur data berpotensi tidak terbatas, seperti dalam beberapa contoh teori bilangan, evaluasi malas memungkinkan program untuk benar-benar selesai.

Teknik ini tidak hanya berguna untuk mempercepat bahasa fungsional seperti Haskell. Pemrogram cerdas tidak akan menghabiskan waktu berjam-jam menghitung nilai jika hanya sedikit yang akan digunakan. Mereka akan menyematkan sakelar malas yang memicu penghitungan hanya ketika seseorang ingin menggunakannya. Di sini, melakukan jumlah pekerjaan minimum masuk akal.

Caching

Mengapa mengulang sendiri? Siapa pun yang diprogram untuk web tahu bahwa ada banyak pengulangan diri Anda kepada semua orang yang muncul di situs Anda. Caching adalah jawabannya - dan tidak hanya untuk situs web. Kode apa pun yang menghitung ulang masalah yang sama dapat dipercepat dengan menyimpan salinan jawabannya.

Itu tidak harus menjadi jawaban akhir. Cache yang canggih dapat menyimpan sebagian jawaban untuk berbagai bagian masalah. Jika beberapa bagian perlu dihitung ulang, mereka masih dapat mengetuk cache untuk bagian yang tidak perlu dilakukan ulang. Situs web yang menyusun halaman web, misalnya, sering menyimpan cache memblokir untuk bagian halaman yang berbeda, kemudian mengumpulkan halaman penuh dari blok tersebut.

Orang-orang ekstralazy mungkin mengeluh bahwa caching lebih merepotkan programmer. Setelah kode untuk menemukan jawabannya selesai, saatnya untuk menulis lapisan lain yang berada di atas untuk menyimpan cache jawaban. Mereka mungkin benar tentang lapisan tambahan ini, tetapi mereka kehilangan pekerjaan lain yang sedang disimpan. Cache yang baik dapat menyelamatkan kita dari semua pekerjaan penskalaan server farm untuk menangani beban ekstra. Penskalaan seringkali lebih merupakan pekerjaan daripada menulis beberapa kode caching.

Tentukan semuanya hanya sekali

Salah satu aturan terpenting yang saya pelajari tentang pemrograman adalah bahwa setiap konstanta harus ditulis hanya sekali dalam kode. Jika perangkat lunak dispesifikasi untuk meletakkan margin satu inci di sekitar halaman, nilai satu seharusnya hanya muncul sekali dalam definisi konstanta. Kemudian konstanta digunakan di tempat lain.

Sedikit kemalasan terorganisir yang sederhana ini terbayar di jalan. Jika Anda ingin mengubah nilainya - katakanlah, dengan meningkatkan margin menjadi 1,5 inci - Anda hanya perlu membuat satu perubahan pada kode.

Anda juga dapat mengerjakan sedikit dokumentasi mandiri ke dalam nama konstanta Anda, memberi nilai margin Anda nama seperti MarginSizeInInches. Itu dapat menyelamatkan Anda dari masalah menulis komentar terpisah, dan konstanta-as-komentar ini akan mengikuti konstanta di seluruh kode.

Tentu, nama konstan yang lebih panjang bisa berarti lebih banyak mengetik, tetapi kebanyakan editor pemrograman menawarkan pelengkapan otomatis untuk lebih menghemat lagi Anda.

Kerangka kerja: Pintasan utama

Pada satu proyek, seorang gugatan menginginkan situs web baru, jadi saya membuatnya dan membuat kesalahan dengan mengatakan kepadanya bahwa saya menggunakan WordPress. Itu tidak bagus. Salah satu temannya di lapangan golf mengatakan kepadanya bahwa WordPress adalah untuk blog dan ini akan menjadi brochureware. Apakah saya idiot?

Jadi dia menggertak CFO agar mengalokasikan $ 5.000 untuk situs web profesional. Hasilnya tampak hebat dan berfungsi dengan sangat lancar, sebagaimana mestinya karena nyali semuanya adalah WordPress. Perusahaan yang menagihnya $ 5.000 cukup pintar untuk tidak menyebutkan apa yang mereka gunakan untuk yayasan.

Beberapa orang menyukai kode khusus karena alasan yang sama seperti beberapa orang mendaki Gunung Everest: Mereka suka melakukannya sendiri, berapa pun biayanya. Pemrogram cerdas mengunduh kerangka kerja sumber terbuka yang bagus seperti WordPress atau Drupal dan berdiri di atas pundak raksasa. Jika ada kode baru yang ditulis, itu tidak lebih dari beberapa baris.

Berkeringat untuk menulis kode Anda sendiri seringkali merupakan kesalahan besar. Kode sumber terbuka untuk kerangka kerja sudah diuji dengan baik oleh ratusan bahkan ribuan orang. Ini tidak selalu ideal, tetapi seperti memulai dari garis 99 meter dalam lari 100 meter. Selain itu, saat Anda menguji kode dan mengupload laporan bug atau perbaikan apa pun, manfaat penginstalan semua orang akan bermanfaat.

Otomasi: Lebih baik dari sebelumnya

Beberapa joki C masih suka menyimpan memori mereka sendiri dan membebaskannya saat mereka tahu itu sudah selesai. Seperti yang mereka lihat, penghitungan referensi dan pengumpulan sampah adalah untuk pengecut. Tentunya, mungkin juga ada beberapa penambang batu bara yang masih menggunakan kapak, seperti halnya John Henry.

Bagian yang baik dari pengembangan bahasa pemrograman adalah otomatisasi, dan alatnya tidak pernah lebih baik. Manajemen memori, pengecekan tipe, dan pemrosesan paralel diciptakan kembali sebagai alat otomatis, menggantikan semua pekerjaan latar belakang kumuh yang biasa dikerjakan sendiri oleh programmer.

Pemrogram yang malas tidak menolak alat ini. Mereka tahu bahwa dengan semua kekurangan mereka, mereka masih lebih baik dari rata-rata manusia pada hari-hari biasa. Tentu saja, seorang peretas yang sangat pandai dapat menghabiskan waktu ekstra dan menghasilkan karya seni yang sangat cepat, tetapi itu hanya masuk akal untuk putaran dalam dari bagian terpenting dari sistem. Kita semua lebih baik dalam menghasilkan kode rata-rata dan membiarkan alat otomatis mencegah kita membuat beberapa kesalahan terburuk.

Devops: Kemalasan dipersonifikasikan

Beberapa orang mencemooh penulis naskah yang membuat instruksi untuk menjaga kode tetap mutakhir dan server berjalan. Apa susahnya membuka ritsleting beberapa file atau menyalin beberapa direktori?

Tentu saja sebagian besar housekeeping tidak terlalu sulit, dan sebagian besar perintah Unix yang umum hanya terdiri dari dua karakter, tetapi itu melenceng. Malas dan mengotomatiskan penerapan dan pemeliharaan memastikannya akan dilakukan dengan cepat dan - yang paling penting - secara konsisten. Pergeseran tengah malam akan melakukan hal-hal persis seperti tim jam 8 pagi - dan tidak masalah apakah minum kopi atau tidak.

Otomasi menghadirkan ketelitian dan stabilitas. Memang sih, tim devops terlihat gemuk dan malas bahkan saat tidak memencet tombol karena crontab memicunya, tapi semuanya berjalan lebih lancar. Tidak banyak kesalahan saat manusia berada di luar lingkaran.