Sebuah ulasan kecil dari buku dua puluh tahun itu
ditulis kembali pada tahun 2016 , diterbitkan dengan koreksi mikro.
Pengakuan asli penulis disebut "Zen Pemrograman Windows 95". Biarkan angka "95" tidak membuat Anda takut, plot kuncinya justru Zen, dan bukan nomor versi yang berubah dengan cepat dari sistem operasi utama beberapa dekade terakhir. Buku ini adalah serangkaian rekomendasi dan praktik untuk pengembang vertikal (full-stack), yang memungkinkan tidak hanya untuk bertahan hidup di dunia pemrograman modern, tetapi juga untuk menghasilkan hasil dari kualitas yang diperlukan.
Pada halaman 22, Lou mendefinisikan pembaca umum: "The Zelot of Quality." Bagi mereka yang dalam hidupnya cukup puas dengan pekerjaan sesuai dengan metodologi "tyap-lyap-commissioning" ("x * yak-x * yak dan produksi"), buku ini tidak mungkin membantu.
Apakah buku itu ketinggalan zaman? Pada awalnya, perubahan cepat dalam adegan dijelaskan pada 1995-96, ketika Windows 95 (pada tingkat yang lebih rendah NT) menjadi luas, antarmuka pemrograman (API) berubah sedikit kurang dari sepenuhnya, sementara itu ternyata diperlukan untuk mempertahankan fungsionalitas program mereka dalam tiga versi sekaligus. Sistem operasi Microsoft. Pada saat itu, Lou Greenaw sendiri berusia tiga puluh tahun (hlm. 87).
Seseorang mengeluh tentang perubahan cepat dalam teknologi modern? Ini terjadi 25 tahun yang lalu ketika beralih dari DOS ke Windows, dan 20 tahun yang lalu ketika mengubah sistem 16-bit ke yang 32-bit. Dibandingkan dengan 1995, migrasi panjang saat ini ke arsitektur 64-bit mewakili puncak kebenaran sehubungan dengan programmer aplikasi yang dipagari dari dapur transformasi oleh banyak lapisan abstraksi dan mesin virtual.
Penulis tidak melewatkan kesempatan untuk berbicara tentang esensi pemrograman, menulisnya di "
kerajinan menggunakan berbagai alat dalam menciptakan tingkat abstraksi dan menerapkannya untuk memecahkan masalah logis ." Tampaknya apa lagi yang dibutuhkan untuk kerajinan itu, jika bukan buku masak yang bagus? Namun, Lou segera mengumumkan (p. 20) bahwa pendekatannya adalah "
untuk berbicara lebih banyak tentang apa yang tidak boleh Anda lakukan " dan "
bergantung pada fakta bahwa Anda akan menilai secara independen bagaimana menerapkan saran ini atau itu ". Sedikit lebih jauh (p. 48) membagi programmer menjadi "ahli matematika" dan "perhiasan".
Yaitu, seperti kerajinan. Tapi tidak juga. Dan terkadang tidak sama sekali. Dalam
buku saya
, saya mendefinisikan rekayasa perangkat lunak sebagai "
paduan eklektik teknologi yang dapat digunakan baik oleh amatir kreativitas teknis dan profesional produksi massal sesuai dengan pola dan preseden, " namun, saya tidak bersikeras pada interpretasi. Pemrograman sangat luas sehingga setiap orang, jika diinginkan, dapat melihat dan berada dalam dirinya apa yang diinginkannya.
Pada bagian pengantar, Lu secara pragmatis membahas program publik dan swasta (saya juga membagi program publik menjadi program yang direplikasi dan yang direplikasi), tentang bantuan program, tentang sikap terhadap pengguna, dan memberikan banyak contoh dari kategori "cerita horor". Kemudian, dengan hati yang tenang, ia melanjutkan (hlm. 63) ke rekomendasi tingkat makro. Ini termasuk topik-topik seperti pelokalan, pengaturan global dengan prospek ekspansi mereka, dokumentasi dan mitos dokumentasi-diri, ergonomi dan kemudahan penggunaan antarmuka, pengujian dan penggunaan kembali kode, pengujian fungsional dan banyak lagi.
Penulis tidak mengabaikan topik penting seperti pengabaian pelatihan dan pendidikan (hal. 90) yang tidak dapat diterima dan kebutuhan akan melek ekonomi (hal. 73) "
Anda harus menjadi seorang ekonom ."
Perbandingan persyaratan sumber daya komputer menarik (hlm. 88). Memang, jika kita mengambil, misalnya, sampel Windows NT tahun 1996, maka untuk pekerjaan yang nyaman dengan aplikasi (lingkungan pengembangan, kantor, Internet), 16 MB RAM diperlukan, sedangkan sistem operasi itu sendiri membutuhkan 8 MB. Untuk Windows 7 atau 10 (dengan kernel NT yang sama) pada tahun 2016, diperlukan memori 4 GB, dan hanya 1 GB yang digunakan oleh OS. Proporsi 1: 2 bahkan turun menjadi 1: 4. Oleh karena itu kesimpulan yang mengecewakan: masalahnya tidak begitu banyak di sistem operasi seperti dalam program.
Di halaman 105, penulis dengan lancar beralih ke rekomendasi tingkat mikro. Apa yang Lou lihat perbedaan antara level makro dan mikro? Ya, faktanya adalah bahwa dengan tidak adanya desain, programmer segera pergi ke tingkat mikro, bahkan tidak curiga bahwa masalah yang dituangkan ke dalamnya sebagian besar disebabkan oleh pengabaian tugas makro.
Di alam, tidak ada ekonom yang hanya tahu makro atau ekonomi mikro. Ini hanya penipu. Tetapi di antara mereka yang menyebut diri mereka programmer, perdukunan seperti itu ada dalam urutan hal-hal!
Dalam bab tentang level mikro, penulis juga memberikan banyak tips bermanfaat. Saya suka yang ini (hlm. 109): "
Jangan pernah memeriksa kesalahan yang Anda tidak tahu bagaimana mengatasinya ." Tampaknya nasihat dari serangkaian "berbahaya" dari G. Oster, tetapi ini adalah kesan yang salah. Saya telah menemukan fragmen kode seperti
try... catch atau
try... except berkali-kali, di mana blok
catch/except itu kosong. Karena kesalahan kadang muncul, dan programmer di tingkat mikronya tidak tahu bagaimana menanganinya. Kode ini tidak hanya terlihat sangat jelek, tetapi juga sangat berbahaya, karena menyebabkan konsekuensi yang tidak terduga pada tingkat abstraksi lainnya.
Teks selanjutnya dikhususkan untuk berbagai subjek yang secara konstan ditemui di sepanjang jalur pengembang vertikal. Saya akan mendaftar hanya beberapa.
- Cara menghindari "false negative" ketika program paranoid dalam mencegah pengguna melakukan tindakan apa pun (centang seperti LooksLike () dan bukannya Is ()).
- Memisahkan kode antarmuka pengguna dari logika. Tanpa menggunakan mantra MVC / MVP, penulis membuat daftar semua keuntungan dari pendekatan ini, tidak melupakan kekurangan, yang terutama terdiri dari pekerjaan tambahan yang serius.
- Setiap perubahan dalam kerangka perpustakaan bergantung pada programmer beban dukungan mereka saat mengubah versi. Masalah adhoc yang diselesaikan dengan cepat berubah menjadi sakit kepala saat memperbarui kerangka kerja.
- Tentang manfaat file konfigurasi biner dan melindungi integritas program dan sumber dayanya.
- Aturan sederhana untuk menggunakan DLL. Ini juga berlaku untuk rakitan .NET modern yang tidak terletak di cache global.
- ... dan banyak lagi
Pada halaman 147, Lou mengutip dua karakteristik programer yang ekstrem, Gizmonaut dan Neoluddites. Kebenaran, seperti biasa, ada di antara keduanya. Anda tidak dapat memilih teknologi dan alat hanya karena mereka baru. Tetapi tidak mungkin bersandar pada tanduk di lingkungan dan metode lama jika ada manfaat dari modernisasi.
Ada beberapa poin dalam buku ini yang kelihatannya lucu dari tahun 2019, misalnya (hlm. 154), rekomendasi untuk menyimpan salinan dari sumber program mereka. Naskah, tentu saja, jangan terbakar, tapi ...
Terlepas dari kenyataan bahwa penulisnya adalah pengembang C ++ profesional, di halaman 167-180, Lou memberi banyak alasan untuk menggunakan Delphi "
di semua proyek baru ." Memang, penampilan Delphi pada tahun 1995 tidak kalah revolusioner dari rilis Windows 32-bit baru.
Mundur dari buku, itu lucu pada tahun 2019 untuk mendengar pernyataan bahwa Delphi adalah produk usang. Dan Java atau C # itu, seperti - lingkungan modern. Biarkan saya mengingatkan Anda bahwa Java muncul hanya setahun, dan C # - empat tahun kemudian. Untuk seorang programmer yang mulai beroperasi di suatu tempat sekitar 2010, ketiga nama ini harus terlihat seperti Kobol atau Fortran.
Menurut Lou dari 1996 (hlm. 146), situasi tipikal: seorang programmer yang terburu-buru membuat kesalahan, tidak punya waktu untuk mempelajari alternatif, memilih jalan yang tidak wajar karena ketidaktahuan. Untuk pengembang berpengalaman dalam hal ini, keputusan yang tepat adalah mendengarkan perasaan Anda.
Ini adalah pemrograman Zen di lingkungan apa pun. Yang saya berharap Anda juga.