🚆 👨🏽‍💼 🧑🏼‍🤝‍🧑🏼 Delapan Kebiasaan Pemrogram Penting 🐋 🦏 👨🏻‍⚕️

“Seseorang bisa menjadi seseorang hanya melalui pendidikan. Dia adalah apa pendidikan membuat dia. "
I. Kant

Menurut pendapat saya, kutipan ini sangat cocok untuk programmer. Sebenarnya, seorang programmer bukan hanya spesialis yang berpengalaman dalam masalah teknis. Seorang programmer adalah, pertama-tama, seorang pengrajin yang membuat kode setiap hari menggunakan pengetahuannya. Membuat kode yang baik tidak mungkin tanpa disiplin penggunaan keterampilan tertentu. Dan penggunaan rutin ini adalah kebiasaannya.

Kebetulan kebiasaan buruk menghalangi kita untuk hidup dan bekerja, dan kebiasaan yang baik meningkatkan produktivitas, dan secara umum seseorang mendapat lebih banyak kesenangan dari kehidupan. Jika Anda berusaha dan mulai memperoleh dan memompa kebiasaan baik, Anda akan segera mulai memperhatikan bagaimana Anda menjadi spesialis dari tingkat yang lebih tinggi. Tapi bukan itu saja, kolega Anda juga akan dengan cepat melihat perubahan menjadi lebih baik, dan ini akan memaksa mereka untuk belajar dan mengadopsi teknik yang bermanfaat. Saat Anda bekerja dengan kode dalam tim, Anda dapat membaca sikap orang tersebut untuk bekerja di setiap komit.

Jadi, mari kita pelajari delapan kebiasaan berguna dari seorang programmer yang akan membuat Anda menjadi profesional terbaik.

1. Jangan ulangi (KERING - Jangan ulangi diri Anda sendiri)

Anda mungkin menemukan fakta bahwa, melihat bagian kode berikutnya, Anda berpikir: "Hmm, di sini saya sudah melakukan sesuatu yang serupa, tetapi dengan argumen yang berbeda, dan secara umum ada array data yang berbeda."

Ini harus menjadi panggilan kepada Anda bahwa kode ini akan diulangi di masa depan, lagi dengan perubahan kecil dalam kondisi dan data. Tetapi jika Anda tidak memperhatikan sinyal ini atau sedang terburu-buru, maka kemungkinan besar Anda akan menulis algoritma lagi dari awal ketika solusi serupa dibutuhkan di masa depan. Secara bertahap, algoritma tersebut akan terakumulasi, kode akan tumbuh, dan pada akhirnya Anda akan benar-benar kehilangan motivasi untuk mengedit dan meningkatkan mie tersebut.

Karenanya, kembangkan kebiasaan yang baik untuk mengikuti prinsip KERING (Jangan Ulangi). Setiap kali Anda menemukan diri Anda menulis algoritma yang sama, luangkan waktu untuk memikirkan beberapa opsi yang mungkin dengan entitas yang berbeda. Atur fungsi generik kecil atau bahkan kelas jika algoritmanya kompleks. Ini akan memakan waktu sedikit lebih lama daripada menulis solusi cepat untuk tugas tertentu, tetapi ini akan menghemat banyak waktu di masa depan untuk debugging dan pengujian.

Secara bertahap, seluruh perpustakaan yang kosong seperti itu akan menumpuk di Anda, dan Anda dapat dengan mudah menggunakannya dalam proyek apa pun.

Pemrograman secara keseluruhan terdiri dari upaya kecil yang dilakukan dalam proses. Buatlah diri Anda keluar sedikit lebih dari apa yang dibutuhkan saat ini. Maka Anda akan mulai tumbuh.

Ada daftar seluruh prinsip serupa yang sangat berguna untuk dipatuhi. Tapi, menurut saya, KERING adalah hal mendasar untuk semua hal lain dalam pekerjaan seorang programmer.

2. Setelah Anda memutuskan bahwa semuanya dilakukan, refactor

Sebagian besar programmer, terutama pemula, percaya bahwa pekerjaan mereka dilakukan segera setelah kode mulai melakukan tugas sebagaimana dimaksud. Hanya sekarang kata "dibuat" mencakup konsep yang lebih luas daripada penulisan kode sepele.

Apakah kode berfungsi dengan benar? Iya! Jadi apa masalahnya?

Ya itu betul. Tepat sebelum Anda melanjutkan ke tugas berikutnya, tinjau apa yang Anda tulis. Dari awal hingga akhir. Kemungkinan besar, Anda akan melihat bahwa beberapa variabel dideklarasikan di tempat yang tidak nyaman dan tidak jelas mengapa mereka diperlukan. Mungkin juga ada garis yang terlalu panjang yang tidak sesuai dengan layar, yang berarti bahwa di sini Anda perlu memikirkan cara membuatnya lebih indah. Atau fungsinya ternyata terlalu banyak dan dapat dibagi menjadi beberapa bagian.
Pikirkan tentang orang-orang yang akan membaca kode Anda di masa mendatang. Apakah mereka suka kode ini atau tidak, bir tidak dapat menemukannya.

Buat keputusan yang indah, bukan hanya yang berhasil. Sama seperti penulis yang baik setelah menulis konsep: mereka membaca karya mereka beberapa kali dan membuang bagian yang tidak perlu untuk membuat pembaca menyukainya dan memahami intinya tanpa harus terlalu banyak detail.

Saya sangat merekomendasikan membaca Robert Martin tentang topik ini . Buku yang mencerahkan yang harus ada di perpustakaan setiap programmer.

3. Fokus pada tugas bisnis

Banyak programmer cenderung fokus mempelajari sisi teknis pekerjaan mereka dan percaya bahwa bisnis tidak ada hubungannya dengan mereka. Yang utama adalah memberikan spesifikasi teknis yang baik, dan kemudian saya akan melakukan segalanya dengan cara terbaik. Hanya untuk benar-benar menjadi master kerajinan Anda, Anda harus memahami mengapa apa yang Anda lakukan telah mengambil bisnis.

Jika sangat kasar membayangkan seorang programmer yang bekerja murni pada TK tanpa memahami esensi, maka sebuah contoh dapat diberikan. Sopir bus, di sebelahnya para penumpang duduk dan memberi tahu dia: "Belok kiri, belok kanan, sekarang kanan." Sehingga para penumpang “mengendarai” bus. Tetapi jika pengemudi mengambil inisiatif dan bertanya: "Di mana saya harus pergi?", Maka penumpang dapat dengan mudah mengatakan: "Kita akan ke kota N", dan semuanya menjadi lebih mudah. Pengemudi mengetahui tujuan akhir dan dapat, menggunakan pengalamannya, secara mandiri membangun rute dan memberitahu dirinya sendiri ke mana dan bagaimana berbelok.

Anehnya, tetapi banyak programmer tidak repot-repot memahami tujuan proyek. Dan, di satu sisi, Anda dapat memahami sudut pandang ini, karena pemrograman adalah pekerjaan mental yang sangat sulit. Terkadang pengetahuan tentang instrumen Anda menempati sebagian besar dalam pikiran sehingga tidak ada sumber daya yang cukup untuk yang lainnya. Jadi ternyata programmer, seperti pengemudi dalam tangki tanpa jendela penglihatan, hanya bisa memutar kenop ketika komandan kru memalu mereka.

Juga, memahami masalah bisnis tidak akan membiarkan Anda terjun ke dalam pengembangan sesuatu yang sama sekali tidak perlu pada waktu tertentu. Misalnya, jika tugasnya adalah membuat fungsi yang membantu menyusun statistik saat lulus tes, maka, mengetahui bahwa ini bukan tugas yang kritis terhadap kinerja, Anda tidak perlu lagi menghabiskan waktu untuk optimasi yang berlebihan dan mempercepat algoritme. Semua sama, ini tidak akan mempengaruhi hasil akhir. Tes hanya akan dijalankan oleh pengembang, dan hanya seminggu sekali.

Contoh lain, jika program memiliki fungsi yang dijalankan semua pengguna beberapa kali setiap hari, masuk akal untuk menghabiskan lebih banyak upaya untuk mengerjakan versi ideal fungsi ini dan aksesibilitas ideal di antarmuka. Di sini Anda sudah dapat meluangkan waktu.

Tapi, Anda lihat, dari sudut pandang seorang programmer yang tidak terbiasa dengan tugas bisnis, kedua tugas ini akan tampak setara.

Untuk pemahaman yang lebih baik, saya sarankan Anda membaca buku "Mulailah dengan Mengapa" oleh Simon Sinek .

4. Komitmen kecil

Fakta bahwa seorang programmer perlu menggunakan sistem pelacakan versi, saya pikir, sudah jelas. Saya ingin berbicara tentang kebiasaan lain yang sangat berguna - ini adalah untuk membuat komitmen sesering mungkin dan dalam porsi sekecil mungkin. Pada saat yang sama, tambahkan komentar yang bermakna dan bermanfaat untuk setiap komit.

Seringkali, programmer pemula dan bahkan yang lebih berpengalaman hanya pada akhir hari melakukan satu dorongan dengan semua file yang diubah dan beberapa jenis komentar yang tidak berguna seperti "memperbaiki masalah29". Atau "memperbaiki bug dalam permintaan." Tidak seorang pun dari deskripsi seperti itu akan mengerti apa yang dilakukan secara spesifik. Dan ketika saatnya tiba untuk menggabungkan komit besar menjadi cabang bersama, pemilik repositori, pertama, secara mental mengaburkan pengembang yang malas. Kedua, jika terjadi konflik selama merger, kemungkinan pemilik akan membatalkan komitmen ini dan tidak menerimanya. Siapa yang ingin mendapatkan sebagian bug dari kenyataan bahwa ia salah paham kondisi mana yang ternyata berlebihan ketika menyelesaikan konflik secara manual.

Di sisi lain, jika Anda secara teratur mendorong perubahan Anda sekali dalam satu jam dan memberikan setiap komitmen dengan deskripsi yang lebih rinci, sehingga di masa depan mudah, tanpa melihat kode, untuk memahami apa yang Anda ubah dan pertimbangan apa yang Anda miliki tentang ini perubahan, maka Anda akan mencapai tingkat pemahaman baru dari filosofi umum penulisan kode. Sekarang Anda tidak hanya akan "memperbaiki primus", sekarang Anda akan menjadi bagian dari tim kreatif dan akan berkomunikasi dengan kolega Anda melalui komitmen Anda, seperti halnya dalam obrolan. Ini akan menjadi dialog yang bermakna.

Sebagai literatur, saya sangat merekomendasikan membaca setidaknya bab pertama dari buku "Git for a Professional Programmer" oleh Scott Chacon dan Straub Ben. Ketika Anda mengetahui fungsi luar biasa apa yang ada di Git dan apa yang mampu dilakukannya, maka tetap hanya untuk melakukan lebih sering, dan sisanya dapat diselesaikan dengan alat yang diperlukan.

5. Hitung waktu

Pekerjaan apa pun memiliki awal dan akhir. Efektivitas seorang programmer diukur dalam jumlah jam yang diperlukan baginya untuk menyelesaikan masalah-masalah tertentu. Semakin cepat tugas diselesaikan, semakin baik. Ini cukup jelas dan tidak memerlukan penjelasan apa pun.

Tetapi ada sisi lain dari bukti ini, yang seringkali menghindarkan pemrogram - Anda perlu secara akurat menghitung waktu yang dihabiskan untuk solusi. Bukan apa yang Anda rasakan ketika Anda duduk di tempat kerja dari jam sembilan hingga jam lima, diselingi dengan segel dan rapat. Dan sekarang adalah pekerjaanmu.
Pada awalnya, saya mengembangkan kebiasaan menghitung waktu hanya dengan menuliskan laporan tentang apa yang saya lakukan pada siang hari dan mencari tahu perkiraan waktu. Meski begitu, saya secara kasar menghitung bahwa saya hanya mendapatkan 4 jam dari 8 untuk bekerja secara efektif.

Dan kemudian dia menginstal program khusus yang menghitung waktu secara otomatis. Awalnya saya menggunakan www.rescuetime.com . Berkat program ini, saya melihat bahwa jejaring sosial, meskipun tampak seperti pemborosan kecil bagi saya, sebenarnya sangat merusak gambaran kinerja saya. Pada akhirnya, saya memutuskan untuk menonaktifkan akses ke beberapa situs sepenuhnya selama jam kerja. Untuk ini, ada juga plugin khusus di browser.

Langkah selanjutnya dalam pelacakan waktu diperlukan ketika saya memutuskan untuk memperbaiki waktu kerja yang tepat dengan kode program. Untuk ini, saya pertama kali mencoba hubstaff.com . Ternyata, solusi yang agak mahal jika Anda menggunakannya saat bekerja dalam tim.

Kemudian mencoba wakatime.com. Dan ternyata itu peluru perak. Layanan ini memiliki kemampuan untuk berintegrasi ke semua IDE populer, serta integrasi dengan github. Akibatnya, Anda dapat menentukan dengan akurat hingga satu menit berapa menit berguna yang Anda habiskan untuk pemrograman. Selain itu, ada ikatan dengan komitmen. Sungguh luar biasa ketika Anda dapat melihat tidak hanya komitmen itu sendiri, tetapi juga mengetahui waktu yang dihabiskan untuk komit ini.
Kumpulan resep yang luar biasa untuk pengaturan waktu dan pengerjaan proyek yang benar ada dalam buku "Teknik Jedi" oleh Maxim Dorofeev .

6. Stabilitas adalah tanda penguasaan.

Seperti yang mungkin sudah Anda pahami, Anda dapat mengembangkan keterampilan dan kemampuan Anda tanpa henti. Apa yang Anda lakukan setahun yang lalu mungkin tampak konyol dan bersahaja dalam hal pengalaman baru Anda. Anda, tentu saja, akan meningkatkan cara menulis ekspresi yang kompleks.
Tetapi di antara semua ini, Anda harus mengembangkan kebiasaan untuk berpegang pada aturan tertentu. Bahkan jika mereka tidak membuat Anda benar-benar berhasil, gunakan metode kerja ini di mana-mana.

Menggunakan contoh kode: jika Anda memutuskan untuk menggunakan skema spesifik untuk menamai variabel atau menggunakan spasi alih-alih tab, maka ikuti prinsip ini secara konstan. Anda tidak perlu mencoba gaya baru setiap minggu dan mencoba menerapkan praktik lanjutan baru. Jadi, Anda kehilangan fokus.

Masalah dengan ketidakkekalan adalah waktu menghancurkan produk perangkat lunak apa pun. Semakin lama beberapa orang mengerjakan program, semakin banyak perubahan yang dibuat dalam proses, yang pada akhirnya menciptakan kekacauan. Jika masing-masing anggota tim tidak mematuhi perjanjian tertentu.

Jadi apa yang perlu dilakukan untuk mematuhi prinsip keteguhan?

Hal pertama yang perlu Anda adopsi adalah mematuhi gaya yang pasti dalam kode. Di editor JetBrains , saya sangat suka alat yang menunjukkan kualitas kode Anda. Saya dulu takut dengan begitu banyak peringatan, tetapi ketika Anda mulai mengikuti saran dari orang yang suka berdisiplin, maka kode itu menjadi jelas dan menyenangkan secara estetika.

Pelajari juga literatur tentang cara memberi nama kelas, metode, dan variabel. Saya merekomendasikan buku "Kode Sempurna" oleh Steve McConnell.

Pada suatu waktu, saya membaca buku ini selama setengah jam di malam hari, ketika semua orang sudah meninggalkan rumah. Buku itu ada di perpustakaan kantor. Hanya beberapa bulan kemudian, saya melihat semua kengerian yang telah saya sandi sebelumnya. Saya harus secara bertahap memperkenalkan teknik baru dan melakukan refactoring.

7. Lakukan sekali

"Aku akan memperbaikinya nanti." Masing-masing dari kita mengucapkan ini kepada diri kita sendiri ketika kita menemukan bug dalam kode kita atau kondisi yang kurang benar untuk diproses dalam satu lingkaran. Dan masing-masing dari kita tahu bahwa ini "memperbaiki nanti" dan kemudian tetap dalam kode dalam bentuk komentarmelakukan. Dan ketika Anda sendiri melihat kode komentar dalam gayamelakukan, itu hanya berarti bahwa seseorang tidak mengikuti prinsip "lakukan di sini dan sekarang." Pada saat komentar ini ditulis, programmer kemungkinan besar sangat memahami apa masalahnya dan bagaimana cara memperbaikinya. Karena itu dalam konteks tugas saat ini. Tetapi jika Anda kembali ke bagian kode ini nanti, akan lebih sulit untuk memahami mengapa reservasi semacam itu diperlukan.
Karena itu, buat kebiasaan yang sangat penting untuk diri Anda sendiri - untuk mencari solusi dari awal sampai tugas selesai secara penuh. Yang paling lengkap - karena benar-benar tidak realistis untuk menutup semua opsi dengan seratus persen. Tapi setidaknya jangan tinggalkan ruang untuk inimelakukan-perilaku. Lagi pula, jika Anda datang dan meluangkan waktu untuk berkomentar, itu berarti bahwa untuk langkah selanjutnya - implementasi - hanya ada sedikit yang tersisa.

Cara yang baik untuk memahami bahwa Anda benar-benar telah menyelesaikan bagian kode ini adalah dengan membuat tes untuk memeriksa beberapa kondisi yang masuk.

8. Jangan pernah berhenti belajar

Ini, tampaknya, adalah keterampilan yang jelas dibutuhkan oleh spesialis apa pun, bukan hanya seorang programmer. Namun, sayangnya, banyak yang melupakannya. Terkadang, saya bertanya kepada teman-teman saya yang terlibat dalam pemrograman, buku apa yang mereka baca baru-baru ini. Seringkali, banyak yang mulai mengingat dengan susah payah apa yang mereka baca satu atau dua tahun yang lalu. Pada saat yang sama, mereka menguasai beberapa trik di universitas atau di beberapa kursus dan menggunakannya sepanjang waktu.

Namun, jika dalam bidang yang berkembang pesat seperti ini Anda berhenti setidaknya sebulan sekali untuk berkenalan dengan alat baru, teknologi atau konsep yang menarik, maka setelah beberapa saat Anda mungkin menemukan bahwa Anda benar-benar tidak mengerti apa yang terjadi di masa sekarang.

Ini terjadi pada saya sekali. Saya mengembangkan satu produk yang sukses dan menjualnya untuk sementara waktu. Tentu saja, saya mendengar cerita tentang kerangka kerja baru, tetapi saya tidak terlalu memperhatikannya. Dia sangat tenggelam dalam pengembangan dan dukungan solusinya.

Hanya ketika arus pelanggan menurun, saya menyadari bahwa produk saya perlu dimodernisasi. Dan kemudian saya berlari ke penghalang besar. Saya dulu hanya menggunakan PHP dan fungsi AJAX yang sangat jarang. Dan untuk memahami kerangka React, Angular, Vue JS modern, saya perlu menghabiskan waktu sekitar satu tahun untuk mempelajarinya melalui buku. Yang paling menarik adalah bahwa jika saya telah mencurahkan cukup waktu untuk pelatihan sebelumnya, maka produk saya tidak akan kehilangan daya saing. Hanya saja alih-alih mendukung fungsi lama, perlu untuk mempelajari yang baru dan memperkenalkan teknologi secara bertahap, dan tidak dalam mode darurat seperti itu.

Kesimpulan

Bahkan jika Anda seratus persen percaya diri dengan keterampilan Anda, ingatlah bahwa tidak ada batasan untuk kesempurnaan. Jangan berhenti bertanya pada diri sendiri pertanyaan provokatif. Akui pada diri sendiri bahwa di beberapa bidang Anda memiliki pelatihan yang tidak mencukupi atau Anda tidak tahu poin-poin halus dalam kerangka kerja yang sudah dikenal, tetapi Anda ingin mengetahuinya. Menghabiskan beberapa jam dan menjalankan versi uji langsung dari github di server lokal sekarang sangat mudah.

Dalam eksperimen sekecil itu, Anda akan melatih keterampilan Anda dan mengembangkan semua kebiasaan penting.

Delapan Kebiasaan Pemrogram Penting