Jika seorang pembuat kode yang lancar mengabaikan praktik-praktik yang baik, bukankah kelancarannya bekerja melawannya? [Tutup]

Saya sedang mengerjakan aplikasi yang cukup besar dan bermasalah - dan karena cara penulisannya (saya akan berikan Anda detail, tetapi itu melanggar aturan di sebagian besar area yang dapat Anda pikirkan), hampir tidak mungkin untuk mengembangkannya tanpa refactoring besar.

Bagian penting dari aplikasi ini ditulis oleh pekerja magang, n00bs dll .; tetapi ada juga seorang programmer di peringkat Master Developer, dan dengan segala kerendahan hati, kode yang ditinggalkannya juga meragukan, dengan cara yang berbeda mungkin tapi tetap saja.

Memang, kodenya cenderung menyelesaikan pekerjaan - sebagian besar waktu - tetapi biasanya samar, menciptakan kembali roda (mis. Metode kustom besar menyelesaikan cadangan SQL db yang agak biasa) dll. Pada dasarnya, kebingungan yang tidak perlu ditambah banyak rekayasa ulang

Dan itu membuat saya berpikir bahwa menjadi pembuat kode yang sangat terampil (saya sengaja tidak menggunakan kata "pengembang", dengan asumsi itu menunjukkan serangkaian keterampilan yang lebih luas), jika tidak disertai dengan kualitas lain, sebenarnya dapat menjadi semacam racun.

Dengan asumsi itu benar, beberapa alasan yang dapat saya pikirkan adalah:

• jika Anda mengkode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.
• jika seseorang cukup berpengalaman untuk dengan mudah memelihara citra mental dari program yang kompleks, seseorang cenderung untuk membaginya menjadi modul, lapisan dll.

Jadi poin saya adalah bahwa jika seorang pembuat kode yang lancar menjadi pengembang yang buruk, kelancaran mereka tidak hanya tidak mengimbangi yang terakhir, tetapi sebenarnya malah malah lebih membahayakan.

Apa yang kamu pikirkan tentang itu? Apakah benar (sampai sejauh mana jika demikian)?

jika Anda mengkode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.

Iya. Saya sudah menjadi pria itu. Dan saya telah belajar bahwa itu adalah hal yang mengerikan.

Ini semua sangat baik untuk Anda, Anda tidak perlu belajar sesuatu yang baru.

Tetapi bagaimana dengan anggota tim Anda yang lain? Mereka menjadi sangat bergantung pada Anda. Mereka tidak dapat google untuk "Clive's Quicky ORM" untuk mendapatkan bantuan pada mapper-relasional objek yang telah Anda tulis.

Dan kemudian tibalah saatnya mereka perlu mempekerjakan seseorang yang baru dan mereka tidak dapat mencari orang-orang yang berpengalaman dalam ORM Clive's Quicky.

Dan akhirnya datang hari ketika Anda pergi dan seseorang melihat ada bug di ORM Anda. Dan itu akan ada di sana, karena Anda tidak memiliki seluruh komunitas orang yang menguji dan memperbaiki produk Anda.

Ya, belajar Hibernate mungkin membutuhkan waktu lebih lama daripada menulis sesuatu yang ringan. Tetapi manfaat melakukannya terlalu besar untuk diabaikan, IMHO.

• jika Anda mengode dengan mudah, rasanya (atau sebenarnya, dalam jangka pendek) lebih cepat untuk mengeluarkan solusi Anda sendiri di tempat, tanpa beralih ke perpustakaan, fungsi yang sudah ada, dll.

Terampil dalam bahasa tetapi bukan alat. Itu bahkan bukan menjadi pembuat kode yang kuat. Ini hanya memoles satu keterampilan (pengetahuan bahasa) dan memungkinkan yang lain untuk berkarat (pengetahuan perpustakaan). Cara sebaliknya sama buruknya, tetapi lebih mudah dikenali.

• jika seseorang cukup berpengalaman untuk dengan mudah memelihara citra mental dari program yang kompleks, seseorang cenderung untuk membaginya menjadi modul, lapisan dll.

Itu hanya kemalasan yang menyamar sebagai keterampilan. Tidak perlu banyak upaya untuk mempertahankan apa yang Anda kerjakan secara aktif di kepala Anda. Dibutuhkan keterampilan untuk menemukan jahitan yang tepat dan membagi kode di sepanjang mereka. Coder yang mengatakan lebih cepat atau lebih baik untuk meninggalkan semuanya di satu tempat sering tidak dapat melihat item mana yang harus dibagi.

Pastikan ini bukan karena dia bekerja di lingkungan "Jika keyboard Anda tidak mengklik, Anda tidak berfungsi". Kami semua melihat kembali kode dan bertanya-tanya apa yang kami pikirkan. Juga, apakah toko ini dalam praktik refactoring kode mereka? Itu mungkin sebuah kemewahan yang tidak diberikannya.

Namun, kita perlu melepaskan diri dari ide pertama kami (ide yang bisa Anda duduki dan tempati) dan melakukan sedikit lebih banyak perencanaan, penelitian, pemikiran. Godaan untuk menyingkirkan setiap masalah kecil memang menggoda dan seluruh proyek dipenuhi dengan praktik ini. Tidak ada yang mau membayar orang untuk memperbaiki hal-hal yang "tidak rusak", jadi mengapa refactor.

Sunting: Mari kita pastikan kita tidak menghukum mereka yang mengetahui jawabannya. Ada yang fasih dan menulis kode bagus dengan kecepatan. Kuncinya adalah tidak mendekati setiap masalah dengan cara ini.

100%

Cara sinis dalam memandang hal ini adalah bahwa jenis coders ini benar-benar menjaga mayoritas pengembang dalam pekerjaan, memperbaiki bug yang sangat mendasar sehingga Anda dapat memasukkan ribuan jam pengembang ke dalamnya tanpa harus setengah jalan ke stabil, fleksibel, aman , modular atau sistem [properti perangkat lunak favorit Anda]. Sistem ini memiliki begitu banyak keanehan sehingga pemikiran untuk bermigrasi ke sesuatu yang lain, bahkan dengan 95% fitur yang sudah ada dan komunitas yang hidup di belakangnya, dianggap suatu tempat antara konyol dan alasan untuk dipecat.

Singkatnya, coders yang lancar dapat melakukan lebih banyak kerusakan daripada gerombolan pesaing, tetapi harga biasanya dibayar selama bertahun-tahun. Dan mereka biasanya hanya melakukan pekerjaan mereka (seperti yang didefinisikan oleh orang lain).

Bagaimana cara mengetahui apakah Anda seorang pengembang atau pembuat kode? Saya kira itu tidak mungkin, tetapi setiap kali Anda menemukan cara untuk membuat kode Anda lebih sederhana tanpa mengurangi kualitas, Anda telah mengambil langkah lain menuju pencerahan.

Masalah yang Anda jelaskan pada dasarnya adalah NIH ("tidak ditemukan di sini") - apakah ada gejala lain?

Kadang-kadang NIH, terutama jika itu terisolasi untuk satu atau dua orang, dapat ditangani dalam diskusi kelompok ("Joe di sini memiliki pengalaman dalam melakukan backup SQL menggunakan perpustakaan standar - bagaimana menurut Anda, Joe?"). Ini bisa jadi kurang konfrontatif daripada Anda langsung mendatangi orang itu dan berkata, "Hei! Gunakan perpustakaan standar, dummy!" :)

Setelah berada dalam situasi Anda dan menyebabkan situasi yang sama, saya memahami frustrasi Anda, tetapi saya pikir jawaban atas pertanyaan Anda adalah "tidak". Kefasihan tidak menjamin bahwa seorang programmer akan menghasilkan kode yang dapat dipelihara. Seringkali organisasi memaksa pemrogram untuk memberikan perangkat lunak yang dirancang dan diimplementasikan dengan buruk karena keterbatasan anggaran dan waktu yang konyol. Ada kemungkinan bahwa programmer yang fasih memotong sudut hanya programmer peduli untuk memberikan sesuatu yang pelanggan peduli. Jelas ini tidak baik dalam praktiknya, tetapi sayangnya kenyataan bahwa sebagian besar programmer harus berurusan dengan suatu saat dalam karir mereka. Ada juga kemungkinan bahwa programmer yang fasih hanya menjadi malas atau puas diri. Saya dapat berbicara bahasa Inggris yang sempurna, tetapi lebih mudah dan lebih menyenangkan untuk menggunakan bahasa gaul.

Adapun menggunakan kode orang lain atau menggulirkan argumen Anda sendiri, saya pikir itu benar-benar bermuara pada apa yang membuat pekerjaan terbaik. Terkadang "terbaik" tidak memperhitungkan hal-hal seperti gaya dan pemeliharaan jika "terbaik" berarti memberikan proyek enam minggu dalam dua minggu. Inilah sebabnya kami refactor dan sempurnakan. Selain itu, pengembang harus mengetahui apa yang tersedia dalam hal kode pihak ketiga dan mereka harus tahu cara menggunakannya dan percaya bahwa itu akan berfungsi dan didukung / dipelihara dengan baik. Mengingat bahwa ada ribuan kerangka kerja opsional, pustaka, dan API untuk paradigma pembangunan populer apa pun yang menggunakan hal-hal seperti itu pada akhirnya dapat menghabiskan lebih banyak waktu, energi, dan stres daripada hanya membuat kerangka Anda sendiri. Juga, saya menemukan kasus-kasus di mana kode pihak ketiga tidak melakukan persis apa yang saya perlukan - yaitu saat itu '

Saya berada di kapal itu (kode warisan yang ditulis dengan lancar) dan cukup fasih untuk sementara waktu.

Rintangan terbesar untuk solusi "cepat dan kotor" adalah selalu ketika Anda perlu menambahkan lebih banyak lagi nanti. Ketika Anda membutuhkan lebih banyak fitur. Hanya ada begitu banyak yang dapat Anda lakukan tanpa struktur. Setelah itu, itu rusak, dan itu mahal untuk mengatur ulang (belum memuaskan, tetapi tidak benar-benar dihargai).

Pada dasarnya, Anda harus menjaga diri terhadap HACK APAPUN yang berpotensi menjadi "solusi yang bisa diterapkan", siap untuk dijual oleh tenaga penjualan yang bersemangat. Itu yang lama, "Itu belum siap! - Tapi itu berhasil, bukan?" teka-teki.