Sebagai seorang pengembang, Anda akan mendengar banyak teori gila dan luar biasa tentang arti "garis kode". Jangan percaya satu pun. Baris kode adalah metrik yang konyol. Dalam kasus yang sangat jarang, dia mengatakan sesuatu, biasanya tidak ada. Menggunakan garis kode untuk membuat keputusan seperti mengevaluasi kualitas sebuah buku dengan jumlah halaman.

Beberapa orang mungkin mengatakan bahwa semakin sedikit baris kode dalam suatu aplikasi, semakin mudah dibaca. Ini hanya sebagian benar. Berikut ini adalah metrik saya untuk kode yang dapat dibaca:

• Kode harus konsisten
  
• Kode harus informatif.
  
• Kode harus didokumentasikan dengan baik.
  
• Kode harus menggunakan fungsi modern yang stabil.
  
• Kode tidak harus terlalu rumit
  
• Kode tidak boleh tidak efisien (jangan sengaja menulis kode lambat)

Jika mengurangi jumlah baris kode bertentangan dengan salah satu dari metrik ini, ini menjadi masalah. Dalam praktiknya, hampir selalu akan mengganggu dan, karena itu, hampir selalu menjadi masalah. Tetapi ada satu hal, jika Anda berusaha untuk memenuhi kriteria di atas, maka kode Anda akan memiliki jumlah baris yang ideal - dan Anda tidak perlu menghitungnya .

Bahasa tidak selalu berarti “baik” atau “buruk”


Kecuali php, tentu saja (lelucon). Sumber

Saya melihat orang-orang mengatakan hal-hal seperti itu sepanjang waktu:

• C lebih baik daripada X karena kinerja
  
• Python lebih baik daripada X karena singkatnya
  
• Haskell lebih baik daripada X karena alien

Gagasan bahwa perbandingan bahasa dapat dikurangi menjadi satu kalimat hampir menyinggung. Ini adalah bahasa, bukan Pokemon.

Jangan salah paham, pasti ada perbedaan antar bahasa. Praktis tidak ada bahasa "tidak berguna" (meskipun ada banyak yang ketinggalan jaman / mati). Setiap bahasa memiliki kompromi yang unik. Dalam hal ini, mereka terlihat seperti kotak peralatan. Obeng dapat melakukan apa yang tidak bisa dilakukan oleh palu, tetapi akankah seseorang mengatakan bahwa obeng lebih baik daripada palu?

(Jelas, palu lebih baik)

Sebelum saya berbicara tentang penilaian bahasa, saya ingin mengklarifikasi sesuatu. Memilih bahasa sangat jarang penting . Tentu saja, beberapa hal tidak dapat dilakukan dalam beberapa bahasa. Jika Anda menulis untuk tampilan depan, maka Anda tidak punya pilihan. Ada konteks khusus di mana kinerja penting, dan bahasa X sama sekali tidak cocok, tetapi situasi seperti itu sangat jarang. Secara umum, pemilihan bahasa biasanya merupakan salah satu masalah yang paling tidak penting untuk suatu proyek.

Berikut adalah aspek-aspek utama dalam urutan, yang, menurut pendapat saya, harus memengaruhi pilihan bahasa (tanpa metrik tertentu):

• Kepadatan sumber daya online yang tersedia (kepadatan StackOverflow)
  
• Kecepatan pengembangan
  
• Predisposisi kesalahan
  
• Kualitas dan cakupan ekosistem paket (ya, npm, berbicara tentang kualitas)
  
• Performa (lebih banyak poin)
  
• Peluang Kerja (Maaf, COBOL)

Beberapa faktor penting di luar pengaruh Anda. Jika Anda bekerja di bidang ilmu data, maka Anda benar-benar perlu menggunakan Python, R atau Scala (mungkin Java). Jika ini adalah proyek hobi, gunakan yang Anda suka. Saya hanya punya satu aturan yang tak terbantahkan. Saya menolak menggunakan bahasa jika sebagian besar masalah yang mungkin terjadi dengan bahasa ini belum diselesaikan di StackOverflow. Bukannya saya tidak bisa menyelesaikannya, hanya saja tidak sepadan dengan waktu.

Membaca kode orang lain itu sulit

Membaca kode orang lain itu sulit. Robert K. Martin membicarakan hal ini dalam Pure Code: “Faktanya, rasio waktu untuk membaca dan menulis kode lebih dari 10 banding 1. Kami terus-menerus membaca kode lama ketika kami mencoba menulis kode baru. ... [Oleh karena itu] apa yang menyederhanakan bacaannya, juga menyederhanakan tulisannya. "

Untuk waktu yang lama, saya pikir saya hanya lemah dalam membaca kode orang lain. Seiring waktu, saya menyadari bahwa hampir setiap programmer menghadapi masalah ini setiap hari. Membaca kode orang lain seperti membaca teks dalam bahasa asing. Sekalipun Anda merasa nyaman memilih bahasa pemrograman pembuat kode, Anda masih harus beradaptasi dengan berbagai gaya dan opsi arsitektur. Ini juga mengasumsikan bahwa penulis telah menulis kode yang konsisten dan dapat diandalkan, yang mungkin atau mungkin tidak benar. Ini sangat sulit. Ada beberapa hal yang telah membantu saya SANGAT.

Peninjauan kode orang lain akan sangat meningkatkan keterampilan Anda. Selama dua tahun terakhir, saya telah melakukan beberapa ulasan untuk permintaan kolam renang di Github. Dengan setiap yang baru, saya merasa sedikit lebih percaya diri dalam membaca kode orang lain. Permintaan kumpulan GitHub sangat berguna karena alasan berikut:

• Di sini Anda dapat melakukan tinjauan kapan saja, cari saja proyek sumber terbuka di mana Anda ingin berkontribusi.
  
• Membaca dalam konteks terbatas (fungsi tunggal atau bug).
  
• Ini membutuhkan perhatian terhadap detail, yang akan membuat Anda menghargai setiap baris.

Teknik kedua, yang akan membantu membaca kode orang lain, sedikit lebih unik. Ini adalah teknik yang saya temukan, dan itu benar-benar mengurangi jumlah waktu yang saya butuhkan untuk merasa nyaman dalam basis kode orang lain. Setelah melihat gaya kode yang ingin saya baca, pertama saya buka vi dan mulai menulis kode dengan gaya yang sama. Saat Anda menulis kode dengan gaya baru, itu juga meningkatkan keterampilan membaca Anda. Gaya akan menjadi kurang asing ketika Anda sendiri mengalaminya. Bahkan jika saya hanya menonton proyek acak di Github, saya segera menerapkan teknik ini. Coba sendiri.

Anda tidak akan pernah menulis kode "sempurna"

Saya telah pemrograman sendiri selama empat tahun sebelum mulai bekerja dalam tim. Untuk sebagian besar waktu ini, saya hanya berasumsi bahwa setiap programmer di industri menulis kode yang sempurna. Saya memutuskan bahwa itu hanya masalah waktu dan usaha sebelum saya juga menulis kode "sempurna".

Ini adalah sesuatu yang sangat saya khawatirkan sebelumnya. Segera setelah saya bergabung dengan tim, dengan cepat menjadi jelas bahwa tidak ada yang menulis kode "sempurna". Tetapi kode yang termasuk dalam sistem itu hampir selalu "sempurna." Bagaimana? Jawab: tinjauan kode.

Saya bekerja dengan tim insinyur yang sangat brilian. Ini adalah beberapa programmer yang paling kompeten dan percaya diri yang dapat Anda beli untuk mendapatkan uang. Setiap anggota tim kami (termasuk saya) akan memulai serangan panik nyata jika seseorang pernah menawarkan untuk melakukan kode tanpa ulasan. Bahkan jika Anda pikir Anda adalah Bill Gates berikutnya, Anda pasti akan membuat kesalahan. Saya bahkan tidak berbicara tentang kesalahan logis, saya berbicara tentang kesalahan ketik, karakter yang terlewatkan. Bahwa otak Anda tidak memperhatikan. Untuk apa sepasang mata lain.

Cobalah bekerja dengan orang lain yang memperhatikan detail dan mau mengkritik pekerjaan Anda. Awalnya, mendengarkan kritik memang sulit, tetapi itu satu-satunya cara yang konsisten untuk memperbaiki situasi. Lakukan yang terbaik untuk tidak mengambil posisi defensif selama peninjauan kode, dan jangan pernah mengambil komentar pribadi. Anda bukan kode Anda.

Dalam ulasan kode, jika penulis membuat pilihan yang saya tidak kenal, saya akan segera google jika pilihannya berbeda dari pendapat populer. Bukan karena opini populer selalu benar, hanya opini populer adalah pilihan default. Jika seseorang memutuskan untuk tidak menerima pilihan populer, itu tidak masalah, saya hanya ingin tahu bahwa itu dibenarkan. Saat meninjau kode, sangat penting bagi Anda untuk memahami alasan pengambilan keputusan. Selain itu, dengan melihat masalah yang sama dari sudut pandang seorang pemula , orang sering dapat memperhatikan hal-hal yang tidak akan pernah diperhatikan oleh seseorang.

Pekerjaan seorang programmer tidak berarti 8 jam pemrograman per hari

Ini adalah pertanyaan yang sangat umum, tetapi orang tidak pernah memberikan jawaban yang jelas. Berapa rata-rata pengembang atau pengembang "luar biasa" menghabiskan kode menulis setiap hari?

Sangat sedikit kode lebih dari empat jam sehari

Mereka yang tidak setuju dengan ini adalah pengecualian terhadap aturan atau bekerja untuk perusahaan yang mengeksploitasi mereka terlalu banyak. Pemrograman adalah tugas yang melelahkan secara mental dan intens. Benar-benar tidak masuk akal untuk mengharapkan seseorang menulis kode 8 jam sehari, lima hari seminggu. Ada kalanya Anda harus memenuhi tenggat waktu atau melakukan sedikit lebih banyak per sesi, tetapi ada beberapa dari mereka dan jarang. Ketika saya mengatakan "jarang," maksud saya hampir tidak pernah. Hindari alur kerja yang menyalahgunakan Anda dan membuat Anda bekerja lembur karena kurangnya perencanaan / staf.

Untuk protokol, bahkan perusahaan itu sendiri tidak menguntungkan bagi Anda untuk secara aktif memprogram 8 jam sehari. Bos Anda mungkin berpikir bahwa memang demikian, tetapi pandangannya pendek dan ia mengabaikan konsekuensi jangka panjang, karena itu memengaruhi produktivitas dan kesehatan mental.

Hanya demi kejelasan, saya tidak menyarankan Anda bekerja hanya empat jam sehari. Sisa empat jam biasanya paling baik dihabiskan untuk:

• Penelitian, baik yang terkait dengan pekerjaan maupun yang tidak terkait
  
• Diskusi pekerjaan Anda dengan kolega
  
• Bantu kolega yang memiliki masalah dengan pekerjaan mereka sendiri
  
• Perencanaan kerja masa depan
  
• Pemeriksaan kode
  
• Rapat

Saya juga sangat menyarankan untuk beristirahat secara teratur di siang hari dan berolahraga (setidaknya tidak lama). Manfaat olahraga untuk mengatasi kelelahan mental didokumentasikan dengan baik. Saya pribadi menemukan bahwa olahraga sangat membantu jika ada masalah dengan konsentrasi.

Ini adalah beberapa hal yang ingin saya pelajari di universitas alih-alih teori murni. Dalam proses penulisan, saya memikirkan satu ton nuansa lain, tetapi ini adalah topik untuk artikel terpisah!