Salah satu pelajaran paling penting yang saya pelajari sebagai pengembang 15 tahun lalu adalah pemikiran sederhana ini:
Kode yang baik itu ekspresif, tidak mengesankan.
Saya ingat ketika saya mendengar ini saya bertanya, "Apa bedanya?", Dan menerima jawaban.
"Ekspresif" - dapat dimengerti, tidak ambigu dan spesifik. Dan jika demikian, menulis kode ekspresif akan memerlukan bekerja dengan tugas tertentu. Investasi waktu dan energi dalam penciptaannya melayani tujuan tertentu, dan hasilnya sesuai dengan harapan.
Impressive adalah kode yang diingat. Menulis kode yang dikenang karena struktur dan algoritmanya yang kompleks, meskipun menggaruk ego Anda, akan sangat menyebalkan bagi seseorang yang akan mendukungnya di masa depan. Dan jika yang terakhir ternyata adalah seorang maniak yang tahu alamat Anda, Tuhan menyelamatkan Anda dari amarahnya.
Itu sebabnya pengembang yang baik itu bijaksana, tidak brilian. Pengembang yang bijak tidak hanya memiliki kecerdasan, tetapi juga kemampuan untuk terus-menerus memikirkan konsekuensi tindakannya. Dia tahu kode spesifik apa yang dia tulis, mengapa dia melakukannya dan, yang paling penting, bagaimana kode ini akan berperilaku di masa depan. Atau, jika lebih sederhana, pengembang yang bijak berusaha menyembuhkan penyakit, bukan gejalanya.
Pengembang "cerdik", memiliki kecerdasan yang sama, sebaliknya, hanya memikirkan masa kini. Mereka dapat memecahkan masalah saat ini dengan cepat dan efektif. Itu hanya gunung dari peretasan dan trik mereka yang terus-menerus terakumulasi dan sekali crash kode, mengubur reputasi semua yang terlibat Inilah mengapa Steve McConnell pernah berkomentar dengan benar:
Pemrograman bukan pekerjaan di CIA, Anda tidak harus pintar.
Dan pengembang yang bijaksana tidak melakukan apa pun yang cerdas. Mereka menulis kode yang membosankan dan sederhana yang mudah dimengerti. Tidak lebih dan tidak kurang.
Berikut adalah beberapa prinsip pengembang yang bijak.
Mereka lebih suka kesederhanaan
Martin Fowler pernah berkata:
Orang bodoh mana pun dapat menulis kode ramah komputer. Pengembang yang baik menulis kode yang dapat dimengerti orang.
Terkadang pengembang memiliki keinginan untuk menegaskan diri mereka sendiri. Tunjukkan orang lain bakat Anda. Dan mereka mulai mencari solusi muskil untuk setiap masalah yang mereka hadapi, meskipun solusi sederhana sudah dekat. Dan ini adalah salah satu kesalahan terburuk yang bisa dilakukan pengembang.
Pengembang yang bijak menulis kode langsung. Mudah untuk mempertahankan, mengoptimalkan, dan memperbaiki jika perlu. Kode tidak melakukan sesuatu yang rumit, semua orang yang menjumpainya segera mengerti kira-kira apa yang terjadi "di bawah tenda". Algoritma yang canggih dan tidak biasa terbukti sangat baik selama sprint malam untuk kopi dan energi, tetapi mereka gagal banyak kemudian dalam produksi.
Ketika ego mulai perlahan menggoda Anda selama pemrograman, tanyakan pada diri sendiri: "Jika saya kembali bekerja dengan kode ini setelah 2 bulan, dapatkah saya mengingat apa sebenarnya yang terjadi di sini?" Jika jawabannya ya, maka lakukanlah. Ingat, bagaimanapun, tentang kolega Anda yang suatu hari nanti harus bekerja dengan kode ini.
Kode itu seperti lelucon. Jika perlu dijelaskan, itu buruk.
Mereka tahu kapan (tidak) Anda perlu mengoptimalkan kode Anda.
Edsger Dijkstra pernah berkomentar dengan benar:
Pengembang yang baik berfokus pada APA, BUKAN PADA APA YANG MEMBANTU saat menulis kode.
Namun, ada banyak cara untuk mengoptimalkan kode Anda. Masing-masing dikaitkan dengan perubahan dalam jumlah memori yang dikonsumsi, waktu prosesor dan algoritma tertentu. Dan pengembang yang bijak memilih jalur ini secara pragmatis.
Tetapi sebelum mulai memperbaiki sesuatu, mereka mengikuti aturan emas "jangan berbuat salah".
Untuk tujuan apa saya akan mengubah sesuatu? Mungkin program sudah menyelesaikan tugas dengan sempurna? Mempertimbangkan bagaimana dan di lingkungan apa program akan diluncurkan, apakah ada gunanya membuatnya lebih cepat? Semua pertanyaan ini harus dijawab sendiri sebelum memulai optimasi.
Setiap optimasi hanya masuk akal dalam konteks tenaga kerja dan pengembalian, jika program itu penting, dan itu benar-benar lambat, dan ada alasan yang masuk akal untuk percaya bahwa itu dapat dioptimalkan sambil mempertahankan keandalan, kebenaran dan kejelasan. Tidak ada yang membutuhkan program yang menghasilkan hasil yang salah, tidak peduli seberapa cepat itu. Kode yang dioptimalkan dengan baik lebih baik daripada tidak dioptimalkan, tetapi dengan pendekatan yang salah, kebalikannya adalah benar.
Ingat: setiap perubahan kinerja selama optimasi harus diukur. Intuisi dalam hal ini adalah penolong yang buruk.
Mereka lebih suka menggunakan daripada membuat kode.
Vic Gundotra menabrak bullseye, pernah berkata:
Anda mulai dengan menulis kode. Saya mulai dengan mencari solusi.
Dan pengembang yang bijaksana mengikutinya. Mereka mulai dengan mencari kode yang sudah jadi. Meskipun tampaknya bagi beberapa orang bahwa mereka sekarang akan melakukan segalanya dari awal “bagaimana caranya”, sebagian besar berakhir dengan penemuan sepeda yang dangkal.
Merasa bebas untuk Google itu. Pencarian solusi, baik online atau di basis kode Anda sendiri, sudah berguna bahkan dari sudut pandang mempelajari pendekatan yang bekerja sebelumnya dalam masalah yang sama, serta pro dan kontra mereka. Itu sebabnya pengembang yang bijak menghabiskan banyak waktu membaca kode orang lain sebelum menulis sendiri. Membuat kode dari awal selalu sepadan dengan waktu, uang, dan energi. Jangan buang sumber daya sampai benar-benar diperlukan.
Jadi, ketika memecahkan masalah lain, pertama-tama cobalah untuk melihat apakah ada yang menyelesaikannya sebelum Anda. Anda tidak menghindari pekerjaan Anda, Anda menghindari pekerjaan yang tidak perlu.
Mereka berusaha menjadi lebih baik.
Aristoteles pernah berkata:
Jika Anda mengerjakan sesuatu yang sudah Anda ketahui caranya, Anda tidak akan menjadi lebih baik.
Pengembang yang bijak berusaha memperbaiki diri, atau lebih tepatnya kode mereka di setiap kesempatan. Mereka cukup sederhana untuk menyadari bahwa mereka belum membuat kode terbaik mereka.
Mereka tidak duduk di zona nyaman berulang-ulang menggunakan pendekatan yang sama. Mereka melakukan yang terbaik untuk memastikan bahwa kebiasaan mereka sendiri tidak menjadi dogma bagi mereka. Mereka terus mencari cara dan peluang untuk melakukan yang lebih baik, terutama jika mereka dapat mempelajari sesuatu yang baru dalam proses tersebut.
Pengembang yang bijak tidak terpesona oleh teknologi modis dan fitur-fitur keren. Mereka cukup pragmatis untuk memahami bahwa peluru perak tidak ada dan pendekatan apa pun memiliki pro dan kontra.
Mereka tidak takut meminta bantuan.
Socrates diucapkan:
Jika kami terus-menerus saling membantu, tidak ada yang membutuhkan keberuntungan.
Sebagai pengembang, kami suka menganggap diri kami sebagai orang pintar. Selain itu, di antara kita benar-benar ada genius. Tetapi kita juga cenderung percaya bahwa kita harus tahu segalanya di dunia. Dan sungguh, siapa yang senang mengatakan di depan rekan-rekannya: "Saya tidak tahu"? Siapa yang mau mengakui bahwa teknologi baru baginya adalah seperangkat hieroglif?
Sebaliknya, Anda diam-diam berbisik pada diri sendiri: “Saya akan mencari tahu sendiri. Saya sudah melakukannya berkali-kali sebelumnya, sekarang saya bisa. "
Pengembang yang bijak tidak melakukan ini. Mereka tahu kapan harus berpikir untuk diri mereka sendiri, dan kapan harus meminta bantuan. Mereka sudah tahu bahwa menyeret permintaan bantuan hanya membunuh waktu sebelum tenggat waktu, yang akan merugikan seluruh tim. Karena itu, mereka tidak takut tampil tidak kompeten dan meminta bantuan ketika dibutuhkan.
Permintaan bantuan yang tepat waktu tidak akan merusak kepercayaan rekan kerja dalam kemampuan Anda. Ini akan memperkuat kepercayaan pada Anda, sebagai seorang profesional, siap untuk melakukan segala yang diperlukan untuk memenuhi tenggat waktu dan mencapai hasil berkualitas tinggi.
Seperti yang pernah dikatakan Cubra Sait :
Perubahan positif dimulai dengan pertanyaan.