Cara menulis lebih sedikit kode [ditutup]

Kualitas yang ingin saya kembangkan adalah menulis kode yang lebih ringkas. Dengan menulis lebih ringkas, setidaknya menurut saya, peluang untuk menambahkan bug ke kode lebih kecil. Lebih mudah untuk membaca kode untuk yang lain.

Pertanyaan saya adalah apakah itu sesuatu yang baru saja datang dengan pengalaman atau apakah itu sesuatu yang dapat Anda lakukan secara eksplisit untuk mengembangkan kualitas itu?

Saya akan mengatakan bahwa secara keseluruhan itu adalah sesuatu yang datang dengan waktu dan pengalaman, tetapi Anda mungkin menemukan bahwa jika Anda melakukan beberapa pekerjaan dengan bahasa yang lebih singkat Anda membawa kualitas itu kembali ke bahasa kerja reguler Anda.

Tentu saja setelah satu atau dua tahun bekerja dengan Ruby, saya menemukan C # saya semakin kencang. Saya pikir jika saya memahami pemrograman fungsional lebih baik (ambisi yang sedang berlangsung) saya mungkin akan mengambil lebih dari itu.

Juga ada beberapa pedoman yang dapat membantu - misalnya jika Anda menulis dua baris yang sama lebih dari sekali membaginya menjadi metode mereka sendiri. Itu adalah pedoman sederhana tetapi dengan cepat mengurangi baris kode dan memotong dan menempel pemrograman, yang sebagian besar dari kita bersalah dari waktu ke waktu.

Jika Anda memahami warisan, Anda sering dapat menghemat pengulangan kode yang sama di tempat yang berbeda dengan memberikan fungsionalitas umum ke kelas induk. Ini jelas pada prinsipnya tetapi sesuatu yang sering dilewatkan orang dalam praktik.

Mungkin ada perbedaan antara menulis lebih sedikit kode dan memiliki lebih sedikit kode dalam aplikasi Anda - kadang-kadang Anda dapat menggunakan pembuatan kode untuk menghindari keharusan mengulang sendiri sehingga Anda hanya menulis beberapa baris kode tetapi yang kemudian menghasilkan banyak kode lain untuk Anda - yang dapat memberi Anda banyak pengaruh. Lihatlah apa yang dilakukan alat seperti Rails atau Entity Framework dalam hal ini untuk memahami betapa bermanfaatnya itu. Lebih jelas tentang perlunya dan berpikir dua kali, tiga kali dan kemudian empat kali tentang menggulirkan kode Anda sendiri - yang dapat membuat Anda masuk neraka YAGNI.

Pahami bahasa Anda, API Anda, dan alat Anda. Sekali lagi ini tampak jelas tetapi selama bertahun-tahun saya telah menulis begitu banyak kode yang kemudian saya sadari mereproduksi fungsionalitas saya bisa saja diwarisi dari API atau menggunakan fitur bahasa untuk menyederhanakan bahwa saya telah menyadari bahwa beberapa jam membaca di dokumentasi untuk API tempat saya bekerja akan menghemat banyak waktu untuk pengkodean atau debugging nanti. Demikian pula, sebagian besar platform Anda bekerja dengan memiliki biji-bijian - belajar untuk bekerja dengan cara yang mereka harapkan dan hidup Anda akan jauh lebih mudah. Luangkan waktu untuk menemukan arah resistensi paling tidak untuk platform yang Anda gunakan dan Anda akan menyelesaikan banyak hal dengan lebih baik.

Jika Anda bertanya-tanya apakah ada cara yang lebih baik untuk melakukan sesuatu, mungkin ada dan selalu ada baiknya mencari tahu bagaimana melakukan sesuatu dengan lebih baik.

Satu cara hebat untuk menulis lebih sedikit kode adalah mencoba menghindari menciptakan kembali roda , dan menggunakan komponen perangkat lunak yang ada saat tersedia.

Satu jawaban umum yang saya dapatkan ketika saya bertanya mengapa orang melakukan ORM mereka sendiri, atau mesin logging mereka sendiri, atau komponen UI mereka sendiri, atau segalanya mereka sendiri:

Tapi kami lebih baik

Saya percaya pernyataan ini benar sebagian besar kasus, tetapi dampak negatif pada ROI sangat tinggi dalam banyak kasus. Anda ibu melakukan hidangan terbaik kan? Tetapi Anda tidak bisa meminta ibu Anda pulang dan menyiapkannya setiap hari.

Itu sebabnya saya berpikir bahwa pengembang harus mendapatkan minat pada dampak finansial dari pilihan mereka. Beberapa dari mereka adalah:

• Diperlukan kerja ekstra untuk membangun komponen
• Kerja ekstra bagi pendatang baru untuk mempelajarinya
• Pekerjaan ekstra besar untuk mempertahankannya

Saya suka berpikir bahwa vendor komponen tersebut adalah tim besar Anda yang bekerja untuk Anda untuk sebagian kecil dari apa yang akan Anda bayarkan untuk membangun, memelihara, dan memperbaikinya sendiri.

Lebih baik bagi seluruh perusahaan untuk ROI maksimum daripada bekerja untuk memaksimalkan kepuasan ego kami;) Semakin banyak uang yang didapat perusahaan Anda, semakin besar kemungkinan kondisi kerja dan gaji Anda akan meningkat.

Menurut pendapat saya, menulis lebih sedikit kode dapat dilakukan dengan beberapa cara:

• Anda Tidak Akan Membutuhkannya . Jangan kode sesuatu yang belum Anda butuhkan. Kode hanya menyatakan persyaratan begitu. Dengan cara ini, kita akan mengurangi kode yang dibutuhkan untuk menulis.

• Jangan Ulangi Diri Anda Sendiri . Saya percaya menggunakan CMS, framework atau perpustakaan pihak ketiga adalah salah satu cara untuk menerapkan prinsip KERING.

• Abstraksi . Dan yang tak kalah pentingnya, pemrograman abstraksi dapat mengurangi kode juga. Dengan mengabstraksi kode, peluang untuk menggunakan kembali kode akan lebih tinggi karena mengurangi dupacity.

Di luar pemahaman bahasa pemrograman, saya pikir pemahaman seseorang tentang suatu masalah dan muncul dengan solusi yang baik ada banyak hubungannya dengan itu. Ada banyak solusi untuk sebagian besar masalah, tidak semuanya optimal. Anda dapat berkendara dari kota A ke kota B melalui jalan yang berbeda - yang satu bisa memakan waktu dua jam, yang lain bisa dua kali lipat. Itu ide yang sama dalam pemrograman. Anda mungkin tahu bahasa dengan sangat baik, tetapi Anda mungkin menemukan solusi yang membutuhkan, katakanlah, dua halaman kode, sementara orang lain akan menemukan solusi yang dapat diimplementasikan dalam seperempat dari setengah ukuran kode. Saya sudah sering melihat ini selama bertahun-tahun.

Pastikan Anda memiliki pemahaman yang baik tentang masalah tersebut. Menganalisisnya, menghasilkan solusi, menimbang pro dan kontra (tentu saja "solusi dengan 's'" akan sangat bervariasi dari masalah ke masalah - hanya secara umum berbicara di sini.) Lalu ada implementasi dari solusi yang dipilih, yang adalah di mana pemahaman Anda tentang bahasa (dan kerangka kerja, jika itu berlaku) akan ikut bermain.

Seluruh seni pemrograman bisa dikatakan turun ke ini.

Anda dapat mempelajari bahasa-bahasa yang memiliki penekanan tradisional pada kejelasan dan keringkasan (misalnya Haskell, Skema, Python), atau bahkan paradigma terser seperti Factor dan bahasa-bahasa gabungan lainnya, tetapi pada akhirnya, segala sesuatu yang Anda pilih untuk dipelajari pada akhirnya harus berkontribusi untuk membantu Anda menulis lebih pendek , kode yang kurang berlebihan.

Seperti semua kesengsaraan lainnya, jika Anda tidak mengaku memiliki masalah, Anda tidak akan mencari solusi. Pengalaman mulai menjadi faktor ketika Anda mempelajari seperti apa kode itu. Ketika Anda meninjau kembali kode Anda, ini adalah waktu yang tepat untuk menentukan apakah Anda dapat menggunakan kembali kode atau refactor untuk mengurangi kode. Microsoft dapat meningkatkan kecepatan pencetakan dengan Windows 2000 dengan TIDAK menggulungnya dua kali (kutipan dari karyawan Microsoft di salah satu demo gratis mereka).

1. Kembali yo kode lama Anda yang panjang lebar,
2. letakkan di bawah kontrol versi,
3. tulis beberapa tes agar memiliki harapan yang masuk akal untuk tidak memperkenalkan bug baru,
4. menulis kembali.

Ulangi libitum iklan. Dan selamat datang di neraka.

Pengembangan Test Driven mungkin membantu. Dengan ini, Anda hanya menulis kode minimum yang diperlukan untuk lulus tes itu.